1 Feb 2008 10:31
Re: review of draft-ietf-krb-wg-otp-preauth-02.txt
Richards, Gareth <gareth.richards <at> rsa.com>
2008-02-01 09:31:34 GMT
2008-02-01 09:31:34 GMT
> > 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.(Continue reading)
RSS Feed