Subject: RE: Avoiding the use of the password in OTP pre-authentication [Was: RE: OTP-Kerberos Issues]

From: "Richards, Gareth" <[email-masked]>
Date: Thu, 7 Sep 2006 12:03:51 +0100

Tim,

Sorry for the confusion, I was not suggesting that we no longer require two-factor authentication but just hoping to avoid the need for the Kerberos password in order to achieve it.

There were three main aims behind the new draft:
1. To add support for connected devices where the OTP value is read programatically from the device 
2. To support multiple OTP algorithms 
3. To not require the Kerberos password to be used as well as the OTP.

We are hoping to produce a system that can support pre-authentication using devices where the OTP value has been generated using PIN+value, challenge-response, counter-based etc.  In these systems we can't assume that there will be a PIN and we would like to avoid the need for the user to enter their Kerberos password as well as whatever information the OTP device requires.

Two factor authentication can be achieved using local PINs (e.g. to unlock a device) and in these cases, there is no need to require a PIN or password to be included in the pre-authentication.

Gareth 

> -----Original Message-----
> From: Tim Alsop [mailto:[email-masked]] 
> Sent: 07 September 2006 10:50
> To: Richards, Gareth; Sam Hartman
> Cc: [email-masked]
> Subject: RE: Avoiding the use of the password in OTP 
> pre-authentication [Was: RE: OTP-Kerberos Issues]
> 
> Gareth,
> 
> Normally, when a two-factor device is used to authenticate, 
> there is a value from the token (e.g. one that changes each 
> minute) and the user also has to combine this with a PIN code 
> to give extra authentication strength. The user is therefore 
> familiar with the need to enter the value from the device and 
> the PIN code (which only they know). This gives "something 
> you know" and "something you have", and therefore makes the 
> authentication two-factor rather than one-factor. If you 
> don't require both, then if somebody picks up a two-factor 
> auth device that belongs to somebody else they can use this 
> and authenticate as the other person, which is obviously not good ...
> 
> So, when our customers are using two-factor devices with our 
> TrustBroker product (which implements two-factor pre-auth), 
> we suggest that the PIN is disabled for each token, and 
> instead the Kerberos password is used, which is of course 
> much stronger than a simple 4 digit PIN code (e.g.
> there are min/max lengths, password policy rules etc). The 
> user then has to enter their password + the value from the 
> two-factor auth device.
> 
> So, with the above in mind, I am interested to know why there 
> is interest to create a new draft for OTP support, that does 
> not require any password. Perhaps I missunderstand what you 
> are trying to achieve, so can you explain please ? Maybe 
> these new drafts are to allow support for other OTP 
> mechanisms, not the hardware tokens that we are using with 
> our product (e.g. RSA SecurID)
> 
> Thanks,
> Tim 
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of 
> Richards, Gareth
> Sent: 07 September 2006 10:32
> To: Sam Hartman
> Cc: [email-masked]
> Subject: Avoiding the use of the password in OTP pre-authentication
> [Was: RE: OTP-Kerberos Issues]
> 
> Sam,
> 
> > 
> > From your message, you refer to iteration count and imply 
> that it is 
> > stored in s2kparams.  Similarly, you refer to
> > PBKDF2 Both of these are only true/available for AES 
> enctypes.  Please 
> > construct your proposal in terms only of RFC 3961 operations and do 
> > not assume particular uses of s2kparams.
> > 
> In the current I-D (draft-richards-otp-kerberos), I specified 
> that conformant KDCs must support the AES encryption types 
> and so thought that I could then take advantage of the 
> information in the s2kparams.
> However, after re-reading RFC 3961 I see now that this was a mistake.
> Thanks for raising this issue.
> 
> > I understand it's a bit more complicated than that.  You 
> may need to 
> > use additional primitives in coming up with a string for 
> random2key, 
> > etc, but you need to avoid depending on any particular 
> kerberos crypto 
> > system.
> > 
> > I'm still quite concerned about the entropy of the OTP tokens and 
> > suspect that systems with a combined password/OTP token should be 
> > explored.
> > 
> One of the main aims behind the proposal is avoiding the use 
> of the password as well as the OTP since this would probably 
> be a worse user experience than just entering the OTP value.  
> I would very much like to do this if possible.  In the 
> current I-D, this problem is solved by having a random 
> "hardening value" combined with the OTP in the PBKDF2 key 
> derivation. This value is sent by the KDC to the client in 
> the KRB_AS_REP and if the client doesn't have a value then it 
> uses the iteration count from the s2kparams.  
> 
> Since the use of the s2kparams and PBKDF2 is not possible 
> then a possible alternative approach would be to:
> 
> 1. Use string-to-key on the OTP value and string-to-random on 
> the hardening value in a manner very similar to that proposed 
> in Appendix A of draft-ietf-krb-wg-kerberos-sam-03.
> That is, essentially replace the password with the hardening value.
> 
> 2. Have an iteration count included in the challenge sent by 
> the KDC to the client in the KRB_ERROR response to the 
> original KRB_AS_REQ.  
> The iteration count could then control the number of 
> string-to-key calls made on the OTP if there is no hardening 
> value available on the client.
> 
> So if there is a hardening value, the key would be derived as follows:
> 
> K1 = random-to-key(hardening)
> K2 = string-to-key(OTP)
> R1 = pseudo-random(K1, A1)  // Called until enough bits are generated
> R2 = pseudo-random(K2, A2)
> Key = random-to-key(R1 ^ R2)
> 
> If there is no harding value
> 
> Key = string-to-key(OTP) // repeat iteration count times
> 
> Does this approach seem reasonable?
> 
> 
> One final thought, one possible advantage of this approach is 
> that it seems to fit well with the passwordless initial 
> authentication proposal in draft-ietf-krb-wg-hw-auth-03.  
> Here, the service uses a long-lived key of an alternative 
> principal instead of the password-derived key in
> the final key derivation.   I'm wondering if it would be possible for
> the service to instead use a hardening value that is in the 
> same realm.
> 
> 
> > 
> > I am also very interested in seeing this work go forward 
> and thank you 
> > for working with us.
> > 
> I very much appreciate the help of the WG.
> 
> 
> Gareth
> 
>

---

From: "Richards, Gareth" <[email-masked]>
Date: Thu, 7 Sep 2006 12:30:51 +0100

Tim,

> 
> I thought you were suggesting that it was a good idea to use 
> just the value on the token for authentication. Clearly this 
> is not secure without the PIN or a something else known by 
> the user (e.g. password).
> Clearly you are not suggesting this, and this needs to be 
> emphasised in your draft if it is not already.
>
Thanks,  I'll check the draft to make sure that is clear.
 
> I have to appologise, but I haven't yet looked at your draft 
> or the other draft for passwordless auth with hw tokens. Can 
> you point me to where I can get the latest drafts from ? I 
> will then take a look and send you any feedback, if I have any. 
>
The passwordless auth draft can be found at: http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-ietf-krb-wg-hw-auth-03.txt
The OTP-Kerberos draft can be found at: http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-richards-otp-kerberos-00.txt

Any feedback on the new draft would be most welcome.
 
> As our products already support password based pre-auth with 
> RSA SecurID and other token devices we are interested to add 
> support for passwordless auth, so I want to help if I can.
> 
Again, any help would be welcome.

Gareth

> Regards,
> From: Richards, Gareth [mailto:[email-masked]]
> Sent: 07 September 2006 12:04
> To: Tim Alsop; Sam Hartman
> Cc: [email-masked]
> Sorry for the confusion, I was not suggesting that we no 
> longer require two-factor authentication but just hoping to 
> avoid the need for the Kerberos password in order to achieve it.
> 
> 1. To add support for connected devices where the OTP value 
> is read programatically from the device 2. To support 
> multiple OTP algorithms 3. To not require the Kerberos 
> password to be used as well as the OTP.
> 
> We are hoping to produce a system that can support 
> pre-authentication using devices where the OTP value has been 
> generated using PIN+value, challenge-response, counter-based 
> etc.  In these systems we can't assume that there will be a 
> PIN and we would like to avoid the need for the user to enter 
> their Kerberos password as well as whatever information the 
> OTP device requires.
> 
> Two factor authentication can be achieved using local PINs 
> (e.g. to unlock a device) and in these cases, there is no 
> need to require a PIN or password to be included in the 
> pre-authentication.
> 
> Gareth 
> 
> there is a 
> > value from the token (e.g. one that changes each
> > minute) and the user also has to combine this with a PIN 
> code to give 
> > extra authentication strength. The user is therefore 
> familiar with the 
> > need to enter the value from the device and the PIN code 
> (which only 
> > they know). This gives "something you know" and "something 
> you have", 
> > and therefore makes the authentication two-factor rather than 
> > one-factor. If you don't require both, then if somebody picks up a 
> > two-factor auth device that belongs to somebody else they 
> can use this 
> we suggest 
> > that the PIN is disabled for each token, and instead the Kerberos 
> > password is used, which is of course much stronger than a simple 4 
> > digit PIN code (e.g.
> user then 
> > has to enter their password + the value from the two-factor auth 
> > device.
> > 
> > So, with the above in mind, I am interested to know why there is 
> > interest to create a new draft for OTP support, that does 
> not require 
> > any password. Perhaps I missunderstand what you are trying 
> to achieve, 
> > so can you explain please ? Maybe these new drafts are to allow 
> > support for other OTP mechanisms, not the hardware tokens 
> that we are 
> > using with our product (e.g. RSA SecurID)
> > 
> > Thanks,
> > Tim
> > 
> > [mailto:[email-masked]] On Behalf Of Richards, 
> > Gareth
> > In the current I-D (draft-richards-otp-kerberos), I specified that 
> > conformant KDCs must support the AES encryption types and 
> so thought 
> > that I could then take advantage of the information in the 
> s2kparams.
> > One of the main aims behind the proposal is avoiding the use of the 
> > password as well as the OTP since this would probably be a 
> worse user 
> > experience than just entering the OTP value.
> > I would very much like to do this if possible.  In the current I-D, 
> > this problem is solved by having a random "hardening value" 
> combined 
> > with the OTP in the PBKDF2 key derivation. This value is 
> sent by the 
> > KDC to the client in the KRB_AS_REP and if the client 
> doesn't have a 
> > value then it uses the iteration count from the s2kparams.
> > 
> > Since the use of the s2kparams and PBKDF2 is not possible then a 
> > possible alternative approach would be to:
> > 
> > 1. Use string-to-key on the OTP value and string-to-random on the 
> > hardening value in a manner very similar to that proposed 
> in Appendix 
> > 2. Have an iteration count included in the challenge sent 
> by the KDC 
> > to the client in the KRB_ERROR response to the original KRB_AS_REQ.
> > The iteration count could then control the number of string-to-key 
> > calls made on the OTP if there is no hardening value 
> available on the 
> > client.
> > 
> > One final thought, one possible advantage of this approach 
> is that it 
> > seems to fit well with the passwordless initial authentication 
> > proposal in draft-ietf-krb-wg-hw-auth-03.
> > Here, the service uses a long-lived key of an alternative principal 
> > instead of the password-derived key in
> > the service to instead use a hardening value that is in the same 
> > realm.
> > 
> > 
> > >