Subject: Re: OTP-Kerberos Issues

From: Sam Hartman <[email-masked]>
Date: Fri, 01 Sep 2006 15:56:08 -0400

I'm seeing an additional issue here that was not raised in the
meeting.

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.

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.

I am also very interested in seeing this work go forward and thank you
for working with us.

Sam, speaking as an individual.

---

From: "Richards, Gareth" <[email-masked]>
Date: Thu, 7 Sep 2006 10:32:24 +0100

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: Matt Crawford <[email-masked]>
Date: Thu, 07 Sep 2006 08:18:05 -0500

On Sep 7, 2006, at 4:32 AM, Richards, Gareth wrote:

> 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.

I am preparing to update nd submit a new version of draft-ietf-krb-wg- 
hw-auth-03.txt, in which it is assumed the user with the OTP device  
is logging in to a host with a service principal, and the login  
service has access to the key for that principal.  Then it uses that  
key plus the OTP data (mixed in the same way it would normally mix  
the string_to-key result with the OTP data) to get initial creds for  
the user.

We have been using this since January 2000 at Fermilab, and have  
recently brought the implementation up to MIT kerberos 1.4.3 level.

I can send you the expired -03 draft is you can't find it anywhere.

                 Matt Crawford   <[email-masked]>
                 FNAL/CD/CCF/Wide Area Systems
                 +1 630 840 3461

---

From: "Richards, Gareth" <[email-masked]>
Date: Thu, 7 Sep 2006 15:21:40 +0100

> > 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.
> 
> I am preparing to update nd submit a new version of 
> draft-ietf-krb-wg- hw-auth-03.txt, in which it is assumed the 
> user with the OTP device is logging in to a host with a 
> service principal, and the login service has access to the 
> key for that principal.  Then it uses that key plus the OTP 
> data (mixed in the same way it would normally mix the 
> string_to-key result with the OTP data) to get initial creds 
> for the user.
> 
> We have been using this since January 2000 at Fermilab, and 
> have recently brought the implementation up to MIT kerberos 
> 1.4.3 level.
> 

Thanks for the information.  I have tracked down version -03 and will be very interested in version -04.

It seems to me that I am struggling with a similar problem since I am trying to find a way of avoiding the user having to use a password when authenticating with an OTP.  What I have called the "hardening value" is used instead of the user's password and combined with the OTP value and this is very similar to your idea of combining a service principal key.  I am hoping that the same system could be used in both cases.

In your case, how does the service receive the keys for the different realms?

Gareth

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 7 Sep 2006 17:49:59 -0700

It seems as though we're addressing multiple issues in the OTP  
discussions I've seen, so let me play really stupid here for a minute:

A One Time Password, is a password, right?  (The name would seem to  
imply that.)  The existing RFC's and software already describe how to  
convert passwords to encryption keys and authenticate, right?  So if  
the password you type happens to come from a SecureID token, a piece  
of paper, your memory, and some magic dice you bought on the way to  
the market yesterday, why does that change the kerberos protocol?

It has *plenty* to do with how you implement your KDC, since it needs  
to know the output of string-to-key() for all those things, but  
there's no need to change the protocol.

---

If I understand what's being discussed, there are actually three  
things being conflated here, and none of them are necessarily to do  
with OTP's.  They're all useful though (or could be).

1) The KDC may need to instruct the client to make use of some  
hardware device to get the password or key for the authentication  
exchange.  (Use the user's input to unlock this slot from this PIV  
card.)
2) The KDC may need to issue some kind of challenge/prompt *before*  
the real AS-REQ.  (Type this into your card and use the readout as  
the password.)
3) The output from the ID device doesn't have enough bits of entropy  
to armor the authentication exchange by itself.  (SecureID.  Also a  
user type-in can't get too long or the user makes mistakes.  Human  
beings don't obey Moore's Law.)

I'm not opposed to an RFC that addresses all these things.  There's  
some obvious synergy among them.  However, it would be nice if they  
were described in separate sections, and usable separately.  I think  
that increases the possible applicability of the standards  
significantly, and I find it difficult to partition the existing  
proposals that way.
------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 07 Sep 2006 21:26:44 -0400

On Thursday, September 07, 2006 05:49:59 PM -0700 "Henry B. Hotz" 
<[email-masked]> wrote:

> convert passwords to encryption keys and authenticate, right?  So if  the
> password you type happens to come from a SecureID token, a piece  of
> paper, your memory, and some magic dice you bought on the way to  the
> market yesterday, why does that change the kerberos protocol?
>
> It has *plenty* to do with how you implement your KDC, since it needs  to
> know the output of string-to-key() for all those things, but  there's no
> need to change the protocol.

It changes the protocol because in most of these mechanisms, the server 
does not know the password in advance; it only has the capability to verify 
whether a password provided by the user is correct.  Thus, changes are 
needed to the protocol both to provide a way to transport the password to 
the KDC, and to provide an alternate means of determining the reply key.

-- Jeff

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 8 Sep 2006 12:18:51 -0700

On Sep 7, 2006, at 6:26 PM, Jeffrey Hutzelman wrote:

> It changes the protocol because in most of these mechanisms, the  
> server does not know the password in advance; it only has the  
> capability to verify whether a password provided by the user is  
> correct.  Thus, changes are needed to the protocol both to provide  
> a way to transport the password to the KDC, and to provide an  
> alternate means of determining the reply key.
>
> -- Jeff

I would call that case 3) in the part of my message that you didn't  
quote.  I think we're describing opposite ends of the same problem,  
not a real technical requirement though.

To use SecureID as an example, the problem isn't that the KDC can't  
"know the password in advance".  The problem is that the company  
manufacturing the tokens has decided as a matter of policy not to  
allow the KDC to have it.  I suspect that any other example of an  
inaccessible password would boil down to a similar policy (not  
technical) issue.

I accept that there are situations where the policy issue is not  
solvable, though I think that's a better approach.  I believe the  
reply key issue is easy (but requires specification).

I don't think it's easy to solve the problem of creating an  
anonymously encrypted, MITM-proof tunnel for sending passwords to the  
KDC.  To be more precise, I don't think it's solvable without  
compromises, and overhead that I don't like.  In fact that's where  
some of the comments on Richards' "hardening value" come from.
------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 08 Sep 2006 15:58:11 -0400

On Friday, September 08, 2006 12:18:51 PM -0700 "Henry B. Hotz" 
<[email-masked]> wrote:

> manufacturing the tokens has decided as a matter of policy not to  allow
> the KDC to have it.  I suspect that any other example of an  inaccessible
> password would boil down to a similar policy (not  technical) issue.

Your suspicion is incorrect.  There are existing deployed OTP schemes in 
which the server cannot know the correct password until the client provides 
it.   See, for example, RFC2289.

---

From: "Tim Alsop" <[email-masked]>
Date: Fri, 8 Sep 2006 21:19:33 +0100

Hi,

I think I know what Henry is trying to suggest, so I wanted to explain
it differently and see what reaction it gets ... Or, maybe my
explanation introduces some new ideas to help with OTP/Kerberos issues
???

As we know, with normal userid+password Kerberos authentication the
users password is used by the KDC to derive a key (either during
authentication using a stored password, or using a stored key which is
changed when the user changes their password). The key is used to
encrypt and decrypt messages for the purposes of authentication, and
when the users password changes the key changes.

With a hardware token (e.g. SecurID token) there is no fixed code (like
a password) for a particular device, and the code on the hardware token
changes every minute (or other similar time period). With this in mind,
surely the approach should be to have the KDC accept an authentication
request from a user, where the user enters the passphrase instead of
their password. Then, the KDC could obtain the expected token value for
this user (e.g. from the hardware token auth server via a secure
interface, or using hardware vendor specific code to calculate the
expected value), and then generate a key from this password/code, just
as though it had read the key from the KDC principal database, and is
performing normal userid+password authentication.

I appreciate that it is not always possible to compute the expected
value on a token, since due to time issues the value could be any of a
number of actual values. If this is the case, then the KDC could try
each in turn and if one of the attempts is successful, then it continues
with the authentication message exchange so that the user gets the
initial Kerberos ticket they requested.

Is this explanation clear ? Does it help ? Was it what Henry was
thinking ?

Thanks,
Tim

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey
Hutzelman
Sent: 08 September 2006 20:58
To: Henry B. Hotz
Cc: [email-masked]; Jeffrey Hutzelman
Subject: Re: Really Basic Question(s) about OTP Goals

> manufacturing the tokens has decided as a matter of policy not to
allow

which the server cannot know the correct password until the client
provides 
it.   See, for example, RFC2289.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Sep 2006 15:38:46 -0500

> the market yesterday, why does that change the kerberos protocol?

Not that simple.

Is the OTP system key generating (KG)?  Or can you only verify an OTP?

What about token synchronization?

What about challenge/response tokens, KG and non-KG?

For KG systems, are the generated keys strong enough that no additional
static passwords or other pre-shared keys are needed to protect use of
the token?

Since the market offerings cover a wide swath of token features, which
kinds of offerings should be supported by whatever extensions the WG
considers?  I.e., what are the requirements?

IMO:

 - Non-KG OTPs and non-KG challenge/response tokens add no security to
   the AS exchange vis-a-vis MITMs and eavesdroppers -- a strong
   password or pre-shared key is still needed.  They do add security
   w.r.t. shoulder surfers and the like.

 - KG OTPs and and KG challenge/response tokens that generate short
   (weak) keys add security to the AS exchange but only when
   strengthened by passwords or other pre-shared secret keys.  Passwords
   have to be reasonably strong.

 - Strong KG OTPs and challenge/response tokens require no additional
   passwords or pre-shared keys, but if you want two-factor
   authentication then you still need a password, but the strength
   of the password becomes much less important overall to the security
   of the AS exchange.

 - Challenge/response tokens generally have no synchronization problems,
   so the protocol can be simpler.

   Conversely, OTPs generally have synchronization issues that the AS
   pre-auth protocol would have to address.

We can separate support for KG vs. non-KG tokens into two separate
pre-authentication methods.  Dealing with OTP vs. challenge/response
tokens separately does not make as much sense.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 08 Sep 2006 16:40:52 -0400

> performing normal userid+password authentication.

This approach is workable for securid, modulo the weakness issue that Henry 
bought up and the policy problem that the token vendor will not provide the 
means for the KDC to obtain the expected token value.

However, it does not work for all one-time password schemes, because 
schemes exist (such as the one described by RFC 2289, as mentioned in my 
last message) where it is impossible for the KDC to ever obtain the correct 
value other than by the user supplying it.

Henry's question was, why does support for one-time passwords require 
changes to the protocol.  The answer is that the current protocol assumes 
the KDC has independent knowledge of the user's password, which is often 
not the case when one-time passwords are involved.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Sep 2006 15:49:21 -0500

> it.   See, for example, RFC2289.

Right, you can't always find a way to turn non-key generating token
systems into key-generating ones.

Non-KG tokens can add little or no security to the AS exchange.  They
can still contribute to the security of the overall system, just not the
AS exchange.

KG tokens are much more useful.

(That said, one might construct a new, backwards incompatible KG token
out of non-KG RFC2289 technology where you use two instances of the OTP,
one where the server and the token both know one randomly-generated
passphrase, and one where only the token knows the passphrase.  This
gets you a KG system that does not require the server to store enough
material to impersonate the token.  The manner in which the token and
server agree on the shared secret is another story.)

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 08 Sep 2006 16:50:21 -0400

>    w.r.t. shoulder surfers and the like.

They add security wrt keystroke loggers, which are like shoulder surfers 
but far more insidious.

-- Jeff

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 8 Sep 2006 13:50:32 -0700

I guess I can't argue that RFC2289 isn't a OTP scheme, since the IETF  
says it is.  I, personally, would call it a challenge-response scheme  
and discuss it under case 2) in my original email.  I thought we were  
discussing case 3).

I stand by my comment about conflating different problems/solutions.   
In fact I think our exchange illustrates my point.

> 3) The output from the ID device doesn't have enough bits of  
> entropy to armor the authentication exchange by itself.   
> (SecureID.  Also a user type-in can't get too long or the user  
> makes mistakes.  Human beings don't obey Moore's Law.)
>
> were described in separate sections, and usable separately.  I  
> think that increases the possible applicability of the standards  

On Sep 8, 2006, at 12:58 PM, Jeffrey Hutzelman wrote:

> Your suspicion is incorrect.  There are existing deployed OTP  
> schemes in which the server cannot know the correct password until  
> the client provides it.   See, for example, RFC2289.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Sep 2006 15:56:49 -0500

On Thu, Sep 07, 2006 at 10:32:24AM +0100, Richards, Gareth wrote:
> 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

First, lots of administrators will want an option to use both, tokens
and passwords ("two-factor authentication").

Second, any system that bootstraps a strong pre-shared secret to make up
for the token's weakness needs to provide for securely bootstrapping
that secret (i.e., you can't have the server just send it to the client
in the clear).

Bootstrapping a strong pre-shared secret means you can use non-key
generating OTPs safely, and that's a big plus.

Key generating tokens are even better, of course, if they generate
sufficiently strong keys (and if they contain enough initial entropy) as
using them well wouldn't require securely bootstapping pre-shared
secrets.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Sep 2006 15:58:07 -0500

> They add security wrt keystroke loggers, which are like shoulder surfers 

True.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 8 Sep 2006 14:16:35 -0700

> performing normal userid+password authentication.

For the SecureID case you're at least pretty close.

I would expect that the user types something that includes the token  
readout into a normal password prompt.  The KDC gets a list of  
acceptable values from the token auth server.  It then figures out  
the corresponding keys, and which one (if any) matches the pre-auth  
value in the AS-REQ.  Then proceeds as though that key were read from  
the database.

> Is this explanation clear ? Does it help ? Was it what Henry was

Basically, yes to the last question.  I'm not the one to answer the  
other two.

Note that I listed three problems that the existing "OTP" proposals  
address which are all different from the above example.  None of  
those problems is a necessary consequence of a password not being  
reusable, therefore discussion would be clearer if it was in terms of  
the actual problem that required the protocol change.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 8 Sep 2006 14:52:37 -0700

> Is the OTP system key generating (KG)?  Or can you only verify an OTP?

In my dictionary an OTP is a password that you can use at most once.   
SecureID and S/Key are the obvious examples I can think of.  If you  
were to use S/Key, then the KDC would need to track successful  
authentications and decrement the iteration count, but the protocol  
wouldn't need to change.

> What about token synchronization?

What about it?  Does my exchange with Tim A. answer this question?

> What about challenge/response tokens, KG and non-KG?

Challenge/response exchanges are not what I meant by OTP, though  
apparently that's now covered by the common use of the term.  I would  
have trouble using them in my infrastructure, but I think it's a good  
idea.

Case 2) in my original email.

> tokens separately does not make as much sense.

Why?  (Would it help if I asked which definition of OTP you are using?)

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Sep 2006 17:02:46 -0500

> authentications and decrement the iteration count, but the protocol  

That is my definition of OTP, but it does not indicate whether one can
derive a symmetric encryption key from the one time password.

The KG/non-KG distinction is important w.r.t. the design of the
protocol.  KG OTPs allow you to dispense with additional static
passwords, pre-shared secret bootstrapping, and/or server public keys.
Conversely non-KG OTPs require additional protection for the protocol's
messages (with additional passwords, pre-shared secret bootstrapping,
distribution of KDC/realm public keys or trust anchors, whatever).

> What about it?  Does my exchange with Tim A. answer this question?

I haven't read it yet.  Some OTP tokens have a next PIN state that
involves multiple iterations to get synchronized; surely you want the
protocol to support that if it supports such tokens.

> have trouble using them in my infrastructure, but I think it's a good  

But both exist and for similar purposes (two-factor authentication,
strengthening or doing away with passwords).  And protocol construction
for dealing with either type are similar.

KG-ness vs. non-KG-ness makes more of a difference for protocol design,
methinks.

> Why?  (Would it help if I asked which definition of OTP you are using?)

We're using the same definition of OTP.  My answer to your question is
above.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Sep 2006 17:25:02 -0500

On Fri, Sep 08, 2006 at 05:02:46PM -0500, Nicolas Williams wrote:
> I haven't read it yet.  [...]

I've read it now.  No, it doesn't answer that question.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 8 Sep 2006 16:43:36 -0700

> derive a symmetric encryption key from the one time password.

If it looks like a password and you can type it at a prompt then you  
can feed it to string-to-key() and get a key.  Whether it's a *good*  
key is a different question, of course.  Remember I'm excluding  
challenge/response type "OTP"s.

If I understand what you mean by KG/non-KG systems than a KG token is  
likely to produce a really cumbersome password to copy by hand.   
Eliminating the hand-copy problem requires solution of case 1) from  
my original email.

> distribution of KDC/realm public keys or trust anchors, whatever).

Non-KG passwords require solution to case 3) from my original email.

> protocol to support that if it supports such tokens.

I'm not sure I know all the possibilities here, but my basic comment  
is that if a token requires input (even if just for synchronization)  
then it's probably not what I would call a "password" but a challenge/ 
response system.  Does *that* answer your question.

>>> pre-authentication methods.

Since details would have to be different, I think I agree with you.   
In practice I would expect a KG token to require a hardware interface  
to be practical.

>>> Dealing with OTP vs. challenge/response

If the OTP really looks like and can be typed at a prompt like a  
password, then my original "stupid" question applies, and I maintain  
no protocol changes are needed.

If you're typing challenges into a token and typing responses after a  
prompt then that stipulation isn't met and you need a protocol  
extension to deliver the challenge to the client from the KDC.   
Probably want some modifications to optimize the rest of the exchange  
as well.

If the exchange is to be electronic rather than via typing, then you  
have a device interface on the client involved.  You probably want  
some "device select" field in the message from the KDC.  If you've  
selected a device, then the challenge (the same one mentioned in the  
last paragraph) should be delivered to the device instead of  
presented to the user as a prompt.  If you need the client to prompt  
for a PIN to unlock the device then that's probably another piece of  
device control to come from the KDC.

> Nico

Now you have me starting to define message fields.  I really don't  
have time to write a competing OTP proposal.  I only hope that some  
of my thoughts on organization have been understood and will be used.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Sep 2006 19:03:49 -0500

> challenge/response type "OTP"s.

But the way PA-ENC-TIMESTAMP works the KDC needs to know the result of
applying s2k() to that one time password.

But if the token is a non-KG token then the KDC can't know that one time
password nor the key derived from it until the client has shown it to
the KDC.  And the client can't show it to the KDC because a)
PA-ENC-TIMESTAMP doesn't have a way to do that, b) if it did then it
would be a cleartext password protocol unless it had some other way to
protect the one time password/key, which c) would make it a very
different PA method :)

> Eliminating the hand-copy problem requires solution of case 1) from  

No, that is not what I mean byt KG.

KG -> the token and the server can both derive the next password/key
      independently.

Perhaps "shared secret key generating" would be a better term than KG.

> response system.  Does *that* answer your question.

No.  There are two types of OTP tokens: ones where the next password is
a function of time, in which case you have a clock synchronization
problem (e.g., SecurId tokens have this problem), or it can be computed
only as needed (in which case there's usually a PIN involved a -- matter
that's purely local to the token, mind you) but you can still get out of
sync accidentally.  In both cases you want to give your users a better
method to synchronize the token and the server than "call your
helpdesk."

> In practice I would expect a KG token to require a hardware interface  

Not at all.  Take SecurId.  If the KDC could ask a SecurId server for
the current OTP then both the client and KDC could feed it to
string2key() and use PA-ENC-TIMESTAMP as you suggest.  That would make
SecurId a KG token if the KDC could do this (but it can't), without any
hardware interface to the token in the mix.

Nico
--

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 11 Sep 2006 11:22:55 -0500

> hardware interface to the token in the mix.

As others have hinted at in previous notes, there may be a policy
issue with the KDC being given the current OTP. In this case
consider what it would take to have the KDC send the  PA-ENC-TIMESTAMP
response to the OTP server to do the verification.

An individual OTP token may be used with other protocols and other
applications other then Kerberos, like Radius and the policies may be
that the OTP server does not expose the current OTP to a KDC.

Having the OPT server decode the PA-ENC-TIMESTAMP adds code to the
OTP server, without having to expose the current OTP. (Or what ever
pre-auth method is best suited for OTP.) The user is authenticating
to the OTP server, not to the Kerberos KDC. The KDC is trusting the
OTP server to do the authentication.

This could be very important where the tokens are issued by different
organizations, where there is no cross realm Kerberos trust setup,
but there is federated Radius trust. In this case the OTP from
one organization could still be used with Kerberos at another
organization.

-- 

  Douglas E. Engert  <[email-masked]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Sep 2006 11:27:39 -0500

> response to the OTP server to do the verification.

Yes, the KDC and the OTP server could work together.

Of course, that still leaves OTP schemes like RFC2289 where the OTP
server simply cannot function in this way without also storing the
user's passphrase/PIN/whatever.

A pre-authentication method that works with non-KG tokens will work with
AAA systems that exist today.  Of course, KG tokens are still desirable
(because they can produce decent overall security for the AS exchange
without having to rely on passwords or PK [read: configuration]).

Nico
--

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 11 Sep 2006 11:44:41 -0500

> without having to rely on passwords or PK [read: configuration]).

The point I am trying to make, is the real authentication is between the
OTP token and the OTP server. Kerberos must be able to support this without
requring the privilaged knowledge of the current OTP.

Maybe a new pre-auth method is needed, where Krebeors uses the "hardening value"
or key from the host principal in such a way that the KDC can removed it
and the underlying pre-auth relying only on the OTP can be sent to the
OTP server for verification.

--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Sep 2006 14:51:10 -0500

> requring the privilaged knowledge of the current OTP.

That's certainly a requirement we could agree on: that any OTP
pre-authentication methods MUST NOT require that the KDC be the OTP
server.  Conversely, where we would rely on some secret shared by the
client and the KDC[*] presumably we'd like to not require that the OTP
server share that secret also.

[*]  Please, let's not call it a "hardening value."

For fundamentally non-KG tokens that's an easy requirement to meet :)
That's because all we can do is find a way to get the one time
password/response to the KDC securely -- we can't have the pre-auth
method perform any transformations on or with the otp/response that that
KDC can't undo.

For KG OTPs it may be a bit harder.  E.g., combining keys would be out.
But deriving symmetric keys from the otp/response and encrypting other
things with them would be fine.

Do we know which common OTP systems are fundamentally non-KG (e.g.,
RFC2289) and which are KG in principle but non-KG in their interfaces,
and which are KG?

Nico
--

---

From: "Richards, Gareth" <[email-masked]>
Date: Tue, 12 Sep 2006 12:07:01 +0100

> That's certainly a requirement we could agree on: that any 
> OTP pre-authentication methods MUST NOT require that the KDC 
> be the OTP server.  Conversely, where we would rely on some 
> secret shared by the client and the KDC[*] presumably we'd 
> like to not require that the OTP server share that secret also.
> 
> For fundamentally non-KG tokens that's an easy requirement to 
> meet :) That's because all we can do is find a way to get the 
> one time password/response to the KDC securely -- we can't 
> have the pre-auth method perform any transformations on or 
> with the otp/response that that KDC can't undo.
> 
> But deriving symmetric keys from the otp/response and 
> encrypting other things with them would be fine.
> 
> RFC2289) and which are KG in principle but non-KG in their 
> interfaces, and which are KG?
> 

If we require that the OTP must be sent to the KDC in a form that allows it to be sent to the OTP server for validation then this would require the value to be protect when transmitted from the client to the KDC.  If we use a shared secret to do this then we would need a method of transmitting the secret to the client from the KDC.  There then seems to be a problem of bootstrapping the system.  One possibility would be to require an initial password authentication but this doesn't seem ideal.

Also, wouldn't this effectively rule out using the OTP value in string2key and using it in the encryption of the PA-ENC-TIMESTAMP?  Wouldn't this really be authentication based on knowledge of a shared secret?

Gareth

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Sep 2006 10:28:32 -0500

On Tue, Sep 12, 2006 at 12:07:01PM +0100, Richards, Gareth wrote:
> If we require that the OTP must be sent to the KDC in a form that
> allows it to be sent to the OTP server for validation then this would
> require the value to be protect when transmitted from the client to
> the KDC.

That's not the exact requirement.  The exact requirement would be that
the KDC not be required to be the OTP server (and that the OTP server
not be required to have access to the KDC's other secrets).

For non-KG tokens that does mean that the KDC has to get the otp from
the client and send it to the OTP server, and so the otp from the client
has to be sent encrypted, yes, in some key that the KDC can use to
decrypt it.

>           If we use a shared secret to do this then we would need a
> method of transmitting the secret to the client from the KDC.  There
> then seems to be a problem of bootstrapping the system.  One
> possibility would be to require an initial password authentication but
> this doesn't seem ideal.

Yes, one way is to bootstrap a shared secret.

Another would be to do Diffie-Hellman key agreement to generate a
symmetric session key and use PK to authenticate the KDC/realm to the
client, then the client can send the otp to the KDC encrypted in the
session key.  This requires public key distribution (or PKI trust anchor
distribution; same thing).

> Also, wouldn't this effectively rule out using the OTP value in
> string2key and using it in the encryption of the PA-ENC-TIMESTAMP?

Only for non-KG tokens.

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 12 Sep 2006 11:44:37 -0700

>> possibility would be to require an initial password authentication  

Yes.  That's why I split case 3 from the other two.

> distribution; same thing).

At this point haven't you bought most of the overhead of PKINIT?   
(And maybe you've gotten to the point where PKINIT would be easier to  
use than some new standard?)

>> string2key and using it in the encryption of the PA-ENC- 
>> TIMESTAMP?  Wouldn't this really be authentication based on  
>> knowledge of a shared secret?
>
> Only for non-KG tokens.

This is exactly the issue some of us have with using SAM with SecureID.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 12 Sep 2006 13:47:20 -0500

Richards, Gareth wrote:
> If we require that the OTP must be sent to the KDC in a form that allows it 
 > to be sent to the OTP server for validation then this would require the value
 > to be protect when transmitted from the client to the KDC.  If we use a shared
 > secret to do this then we would need a method of transmitting the secret to the
 > client from the KDC.  There then seems to be a problem of bootstrapping the system.
 > One possibility would be to require an initial password authentication but this
 > doesn't seem ideal.
> 
> Also, wouldn't this effectively rule out using the OTP value in string2key 
 > and using it in the encryption of the PA-ENC-TIMESTAMP?  Wouldn't this really be
 > authentication based on knowledge of a shared secret?

Not sure. There are two possibilities:

   o After the KDC proves to the OTP server that the request came from the OTP token,
     The OTP server could return the OTP used. This would allow for decryption
     of the PA-ENC-TIMESTAMP.

   o It might be possible to have KDC pass the PA-ENC-TIMESTAMP to the OTP server
     that would decrypt it and return the decrypted data to the KDC.

Both of these require some changes to the OTP server and KDC but not the client.
This has some advantages today.

Nico's Diffie-Hellman with PK authentication of the KDC/realm has the advantage of
no changes to the OTP server as the KDC then authneticates to it on behalf of the
user.

--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Sep 2006 14:26:57 -0500

> use than some new standard?)

I was hoping you'd notice :)

---

From: "Richards, Gareth" <[email-masked]>
Date: Wed, 13 Sep 2006 17:52:37 +0100

> That's not the exact requirement.  The exact requirement 
> would be that the KDC not be required to be the OTP server 
> (and that the OTP server not be required to have access to 
> the KDC's other secrets).
> 

I must admit that I am getting confused by this thread.

In the original proposals, the OTP is used in the key derivation and so the assumption was that the KDC could generate the same key.  I believe that these are what you call KG keys.  

I would then think that this effectively required one of the following:

1. The KDC must retrieve the OTP from the server
2. The KDC must be the OTP server
3. The OTP server could generate the key for the KDC (or something else derived from the OTP)	

However, as Henry pointed out, it may not always be possible for the KDC to obtain the OTP value and it was also discussed that it may not be permitted by policy.  I thought that the consensus was that we couldn't assume that this was possible.

If we can't assume that 1. is possible and 2. is ruled out then doesn't this only leave 3. or requiring that the OTP be sent to the KDC?

Gareth

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Sep 2006 11:57:07 -0500

On Wed, Sep 13, 2006 at 05:52:37PM +0100, Richards, Gareth wrote:
> If we can't assume that 1. is possible and 2. is ruled out then
> doesn't this only leave 3. or requiring that the OTP be sent to the
> KDC?

Yes.  But you want that done securely, no?  Merely sending the OTP in
the clear isn't good enough.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Sep 2006 13:04:19 -0500

On Wed, Sep 13, 2006 at 10:57:45AM -0700, Henry B. Hotz wrote:
> On Sep 13, 2006, at 9:57 AM, Nicolas Williams wrote:
> Absoutely true.  However isn't that communication out-of-scope for a  
> Kerberos OTP standard?

It cannot be out of scope.  Sorry.

If there's no password, how is the reply key obtained?  From the OTP?
If so then any eavesdropper now can figure out all of your Kerberos V
session keys, and eavesdrop on all your kerberized traffic, and even act
as a man-in-the-middle.

And if there is a password, then why not encrypt the OTP with it?

Bootstrapping a shared secret to act like a password but which the user
need not remember (i.e., the clients he/she uses remember it) has
similar problems: we don't want eavesdroppers on the bootstrapping
process to compromise all your subsequent communications.

> It should be mentioned in the security considerations section.

I'm afraid that won't do.

You can't wish away the issues with non-KG OTPs.  We have to deal with
them or else rule non-KG OTPs out of scope.  Dealing with non-KG OTPs
means dealing with passwords/PK/shared secret bootstrapping -- all, I'm
sure, somewhat distasteful for you, but also all feasible.

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 13 Sep 2006 10:57:45 -0700

---

From: "Richards, Gareth" <[email-masked]>
Date: Thu, 14 Sep 2006 12:10:50 +0100

> > >session key.  This requires public key distribution (or PKI trust 
> > >anchor distribution; same thing).
> > 

Is it really necessary to authenticate the server? If the client is pre-configured with the D-H base and prime and the server's public key then the OTP could be sent securely encrypted to the server. This would do away with the need of a PKI.

---

From: "Richards, Gareth" <[email-masked]>
Date: Thu, 14 Sep 2006 12:59:47 +0100

> Yes.  But you want that done securely, no?  Merely sending 
> the OTP in the clear isn't good enough.
> 
I totally agree that the OTP must be sent securely to the KDC.  

If we are to support this then we will require two forms of OTP pre-authentication:

1. One where the reply key is not generated from the OTP and so the OTP needs to be sent securely to the KDC.

2. One where the OTP is used in the generation of the reply but does not require the KDC to be the OTP server or to obtain the OTP value from the server.

The first type would be needed for the case where the OTP algorithm does not support the generation of the OTP by the KDC or server (non-KG, e.g. S/Key) or when the KDC cannot obtain the OTP or anything generated from the OTP (effectively non-KG).  

If we want to avoid using the password then a solution seems to require either public key cryptography (e.g. Diffie-Hellman) or a pre-shared secret.  This would then either require pre-configuring the client with the public key, trust anchor or secret or an initial password authentication to allow the information to be securely sent to the client.  If we want to avoid pre-configuring all the clients then maybe the initial password authentication to establish a pre-shared secret is the way to go.  This would then allow the shared secret to be used in random-to-key instead of the password or OTP value.

The second type would be for the case where the algorithm allows an OTP to be generated and the KDC can obtain from the OTP server the OTP value or something derived from the OTP value.

In order to support low entropy tokens, I would think that we would need to generate the reply key from the OTP and a shared secret known by the client and KDC.  If we want to avoid requiring the KDC to obtain the actual OTP value then a possibility would be to have the OTP server return a value generated from the OTP that could be used in random-to-key.   The simplest would probably be a hash, allowing the client to hash OTP obtained from the token.

The reply key could then be generated as follows:

K1 = random-to-key(shared secret)
K2 = random-to-key(otp hash)
R1 = pseudo-random(K1, A1)  // Called until enough bits are generated
R2 = pseudo-random(K2, A2)
Key = random-to-key(R1 ^ R2)

I would think that this would have an advantage over sending the PA-ENC-TIMESTAMP to the OTP server since it would more easily allow support for low entropy OTP values and would not depened on the particular crypto suite being used.  

Does this sound reasonable?

Gareth

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 Sep 2006 08:12:49 -0500

On Thu, Sep 14, 2006 at 12:10:50PM +0100, Richards, Gareth wrote:
> Is it really necessary to authenticate the server? If the client is
> pre-configured with the D-H base and prime and the server's public key
> then the OTP could be sent securely encrypted to the server. This
> would do away with the need of a PKI.

Then you've authenticated the KDC to the client.

---

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

> Then you've authenticated the KDC to the client.
I suppose you are right.  

The only difference is that in this case the trust is in the system that configured the client rather than in the root certificate.  

I suppose it is similar to the PGP model.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 Sep 2006 08:35:50 -0500

On Thu, Sep 14, 2006 at 02:30:54PM +0100, Richards, Gareth wrote:
> The only difference is that in this case the trust is in the system
> that configured the client rather than in the root certificate.  

I've been taking care to say PK rather than PKI for a reason.