Subject: OTP-Kerberos Issues

From: "Richards, Gareth" <[email-masked]>
Date: Thu, 24 Aug 2006 09:20:44 +0100

All,

At the recent Montreal meeting, we presented a proposal on the use of
one-time passwords in Kerberos pre-authentiation .  I would like to
thank the WG for giving us the time to do this and for the feedback
received.  

I am currently in the process of updating the I-D and so want to make
sure that I have captured all the points raised.

1. Use of encrypted timestamp
We were asked why the proposal uses the reply key generated from the OTP
to encrypt a timestamp.  Why not challenge response, get rid of clock
synchronization?  

The idea, at least in the initial draft, was to keep it simple and use
the OTP to replace the password in the generation of the reply key.  The
generated key was then to be used in exactly the same way as in
password-based pre-auth.  

I see that this does rely on time synchronization and would welcome
suggestions on other methods.

2. Strength of reply key
Some questions were raised regarding the strength of the reply key.
a) An OTP value is short and open to brute force attack.
b) How is the reply key generated? 
c) What impact will a high iteration count have on performance?

The proposal (described in section 2.4 of the I-D) was based on a system
used in draft-nystrom-eap-potp-04.txt and uses a random hardening value
generated by the KDC and sent to the client.  The reply key is then
generated using a combination of the OTP and hardening value rather than
the password.

In the initial authentication, the client wouldn't have a hardening
value and so would use the full iteration count sent by the KDC in the
s2kparams.  Following a successful authentication, the KDC would send
the client a hardening value to be used in the next authentication.
Therefore, on all but the first authentication, the client would have a
hardening value available and so would be able to use an iteration count
of 1 and so make the generation of the reply key much faster.

I am currently investigating alternatives to this approach such as the
use of ephemeral D-H.

3. What if KDC does not know the OTP?
What happens when the KDC does not know the key/OTP? Hence the need to
pass on third party to validate the preauth.

The current proposal only covers the case where the KDC can obtain the
OTP value.  (It really just provides the basic infrastructure for
supporting connected tokens.)  For example, it can't support basic S/Key
where the client needs to send the OTP value.  As mentioned above, I
have been thinking about the possibility of extending the system to
support ephemeral D-H where the shared secret can then be used to
generate a key to encrypt the OTP.

4. Why combine the hardening value with the salt?
It was pointed out that RFC3962 suggests the hardening value should not
go to the string2key parameters.  It should combine the hardening values
with the OTP passcode instead.

The only reason that the hardening value is combined with the salt
rather than the OTP value is that this is how it was done in EAP-POTP.
I have no problem in doing PBKDF2(OTP|hardening, salt, ...) instead.

I hope I captured the issues raised. 

Again, thanks for the useful feedback during the presentation.

Gareth Richards

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 28 Aug 2006 02:27:13 -0400

>sure that I have captured all the points raised.

(Note: you didn't actually give the name of the I-D in your message, so
if we weren't at the meeting, we might not know which one it is).

Did you look at the existing hardware preauth protocol?  (I am biased,
because I worked on it).  If you did, how come you choose not to use it?

>of 1 and so make the generation of the reply key much faster.

So, as I understand it ... the client would need to store this hardening
value somewhere locally?

--Ken

---

From: "Richards, Gareth" <[email-masked]>
Date: Tue, 29 Aug 2006 18:19:55 +0100

Ken,

> (Note: you didn't actually give the name of the I-D in your 
> message, so if we weren't at the meeting, we might not know 
> which one it is).
> 
Sorry about that, it is draft-richards-otp-kerberos-00.txt

> Did you look at the existing hardware preauth protocol?  (I 
> am biased, because I worked on it).  If you did, how come you 
> choose not to use it?
> 
I was aware of the existing hardware preauth protocol and the draft was inspired by draft-ietf-cat-kerberos-passwords-04.txt and draft-ietf-krb-wg-kerberos-sam-03.txt.  Unfortunately, I was not aware of your passwordless hardware preauthentication draft.  

The main aims of the new draft are to design a system that can generate a reply key from both connected and disconnected OTP tokens, support different OTP algorithms (e.g. challenge response, counter based etc) and not require a password.  The earlier SAM drafts appeared to be aimed at disconnected tokens (for example, it supported a token type but not a key identifier) and relied on combining the OTP with the user's password.  The current version of the new draft is an attempt to define the information needed in the challenge and response to support this type of pre-authentication but does not yet cover a lot of the issues addressed in the earlier drafts.  For example, it does not support basic S/Key or have the track-id or nonce.  

> >hardening value available and so would be able to use an iteration 
> >count of 1 and so make the generation of the reply key much faster.
> 
> So, as I understand it ... the client would need to store 
> this hardening value somewhere locally?
> 
Yes it would.  This is not ideal and I'm currently looking into alternatives.

Gareth