Subject: Re: [Ietf-krb-wg] review of draft-ietf-krb-wg-otp-preauth-02.txt

From: "Richards, Gareth" <[email-masked]>
Date: Fri, 1 Feb 2008 09:31:34 -0000

> > Is the byte values of the UTF-8 encoding of the KDC's 
> principal name.
> > Would this clear that up.
> 
> UTF8 alone does not guarantee a unique encoding, think of 
> normalization rules in unicode. It would be a lot easier to 
> say you hash over the DER encoding of the ANS.1 type as it 
> appears in the AS-REQ message. This allows you get around the 
> messy I18N issues in Kerberos. Take a look at RFc4556 and pay 
> attention to the language used in the description of the KDF.
> 

I have been trying to design the system so that the OTP server can be
independent of any protocol details of its client since the interface to
retrieve the hashed OTP values could be used by other authentication
servers. I have therefore been trying to avoid involving any Kerberos
knowledge in the generation of the hash.  

The client and the OTP server need to be configured with the same value
of sname so that they can generate the same hash values.  In theory, it
doesn't really matter what this value is as long as it is unique to the
KDC and so I suppose the DER encoding of the PrincipalName from the
AS-REQ could be used but so could something like the KDC's IP address or
FQDN or any string value that the client has been configured with.

> > The intention was the proposal would not alter the way that 
> > string-to-key functions but have the paramaters either be 
> the default 
> > of the cipher suite or those given by the sk2params of the 
> PA-ETYPE-INFO2.
> > The iteration count for the OTP would be specified by the client in 
> > the PA-OTP-REQUEST while that for string-to-key would come from the 
> > s2kparams.
> 
> Sure how does the client discover the s2kparams if it does 
> not already know it? Once I can understand the abstraction 
> model, I may be able to provide more intelligent comments than this.
> 
These will be sent to the client by the PA-ETYPE-INFO2, PA-ENTYP-INFO
and PA-PW-SALT included in the KRB-ERROR returned by the KDC.  I will
try and clarify this in the I-D.

> > The iterationCount is used to harden the OTP value used in the key 
> > generation by making it computationally more expensive to crack the 
> > OTP value.  The idea is that the OTP Server (or KDC) can dictate a 
> > minimum value for this iterationCount and the client can 
> either select 
> > that or a higher value.
> 
> Why not use PBKDF2 here?
> 
An earlier version of the I-D did use PBKDF2 but I removed it since it
is not supported by all Kerberos cryptosystems. However, now that the
I-D has negotiation of non-keyed hash functions and support for SHA1 is
required, it has gone away from RFC3961 and, you are right, is not very
far from requiring support for PBKDF2.  

> > Yes, the recommendation is that if PIN change is required and a PIN 
> > change service is used, that the KDC should return a ticket 
> for that 
> > service with the "initial" flag set rather than returning a TGT.  I 
> > will try and clarify this.
> 
> You are requesting a service ticket to the PIN change 
> service, not the TGT, right?
> 
Yes, the recommendation is that the KDC return a service ticket for any
PIN change service with the "initial" bit set.

> It is important to let the PIN change service always requires 
> a service ticket with "initial" bit. This way, someone who 
> walks over to an unlocked workstation does not get the 
> ability to change the PIN, she has to present the existing 
> PIN (in order to get the "initial" ticket) if she wants to 
> change the PIN.

I'll add a further recommendation that any PIN change service requires
service tickets with the "initial" bit set.

--Gareth
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg