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

From: Larry Zhu <[email-masked]>
Date: Tue, 19 Aug 2008 17:18:03 -0700

I would like to echo here that I could not find a reference in the current document how the PIN is used in the user authentication protocol. It seems only referenced in the PIN-change portion of the protocol.

--larry

-----Original Message-----
From: Charlie Kaufman
Sent: Tuesday, August 19, 2008 5:01 PM
To: [email-masked]
Cc: Larry Zhu
Subject: Review of draft-ietf-krb-wg-otp-preauth-05.txt

I hesitate to bring up these issues "at the last minute" on a protocol whose design has clearly been a long time in evolving, but there are a number of places where the specification is at least confusing and I suspect wrong.

Section 1.1 says this protocol is also designed to with tokens that are electronically connected to the user's computer. Are there any motivating examples? Such devices are likely to have strong keys and may live under an interface like PKCS-11 with access to private keys and such. It seems unlikely such devices would want to use this protocol, but might instead use PKINIT or simply supply access to a strong secret to use as a password replacement in the AS-REQ and AS-REP messages.

The design seems incompatible with the stateless nature of KDCs. Any KDC state should be encrypted and passed through the client so that different exchanges could go through different KDCs.

The text makes it difficult to keep track of the various keys being juggled. Section 1.2 refers to three keys: the "standard Reply Key", "a key to encrypt the data sent to the KDC", and "a final key to decrypt the KDC's reply". Section 2.2 refers to two keys: a "Client Key" and a "Reply Key". It says these keys are generated from the (not previously mentioned) "Armor Key". Section 3.6 first says the client and KDC need to generate two encryption keys; the next paragraph talks about the method used to generated the three keys. Section 3.2 refers to the "OTP token key". I suspect some of those terms are synonyms, but I could not figure out which ones.

There is considerable discussion of forcing the user to change the PIN, but no discussion of anywhere the PIN is used in the authentication process. Also, forcing the user to change a PIN will deny service if the password change service (typically the master replica of the KDC) is down or inaccessible. Does Kerberos have a similar mechanism for forcing users to change passwords? If so, perhaps the same mechanism should be used.

Section 3.3 is titled "Client Response", but syntactically this is not a response, but rather a second client request.

The ability of the client to set large iteration counts for hashing operations represents a potential DoS attacks against the KDC. Large iteration counts rarely make sense in a protocol because the incremental cost to the good guys becomes unacceptable long before the incremental cost to the bad guys.

In the UI, if there is no password how does the client know to attempt to log in before the user has entered a password? Is the user expected to know to enter a user name and then click login without entering a password? Or what?

Since one of the primary motivators for this protocol is to support SecurID cards, it would be good to include in appendix B (examples) SecurID cards with and without PINs (including the resync case and acquisition of the armor key). [Appendix B doesn't quite do this because I believe the SecurID token does not report time from the token and SecurID validation requires the unhashed OTP value.] To be evenhanded, it would be good to have an example of something else, like a challenge response device or an OTP password list.

Typos:

Section 2.2, last paragraph: generate->generates; use->uses
Section 2.3, RECOMMENED -> RECOMMENDED
Section 3.2, "key is the be" -> "key is to be"
Section 3.3, 2nd para, no "." at end
Section 3.3, 3rd para, "that that" -> ????
[ZhHa07], "Znu" -> "Zhu"
Section B.1, 2nd para, "the OTP value" -> "the hash of the OTP value"
Section B.3, 1st para, "the KDC determines that the user's PIN has expired and so must be changed" -> ??? [In B.1 and B.2, there is no PIN]

There seemed to be lots of places where SHALL->MUST, but I'm not sure what the semantic distinction is so I can't be sure which is correct.

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

---

From: Charlie Kaufman <[email-masked]>
Date: Tue, 19 Aug 2008 17:01:23 -0700

Typos:

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 20 Aug 2008 17:30:13 +0200

Charlie Kaufman <[email-masked]> writes:

> Section 1.1 says this protocol is also designed to with tokens that
> are electronically connected to the user's computer. Are there any
> motivating examples? Such devices are likely to have strong keys and
> may live under an interface like PKCS-11 with access to private keys
> and such. It seems unlikely such devices would want to use this
> protocol, but might instead use PKINIT or simply supply access to a
> strong secret to use as a password replacement in the AS-REQ and
> AS-REP messages.

The YubiKey generates OTP's and is connected via USB:
http://www.yubico.com/

FWIW, as input to the WGLC process on this document, I have reviewed the
document to be reasonable certain that it is compatible with how the
YubiKey works, and I didn't find any critical problem.  We haven't
implemented the specification though.

/Simon

---

From: Charlie Kaufman <[email-masked]>
Date: Wed, 20 Aug 2008 11:04:37 -0700

You're right. YubiKey is electronically connected to the user's computer, but in such a simple way (motivated by universal compatibility) that it can't do challenge/response authentication with a strong key.

I would think of YubiKey as cryptographically in the same class as SecurID, but with clever hardware that saves the user typing. If that's what the spec had in mind, then it's technically correct but I would still call it somewhat misleading. (At least it misled me).

        --Charlie

-----Original Message-----
From: Simon Josefsson [mailto:[email-masked]]
Sent: Wednesday, August 20, 2008 8:30 AM
To: Charlie Kaufman
Cc: [email-masked]
Subject: Re: Review of draft-ietf-krb-wg-otp-preauth-05.txt

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 20 Aug 2008 15:02:59 -0400

--On Tuesday, August 19, 2008 05:01:23 PM -0700 Charlie Kaufman 
<[email-masked]> wrote:

> I hesitate to bring up these issues "at the last minute" on a protocol
> whose design has clearly been a long time in evolving, but there are a
> number of places where the specification is at least confusing and I
> suspect wrong.

It's not _that_ late, in the grand scheme of things, and I think some of 
your comments relate to things that changed relatively recently.

> The text makes it difficult to keep track of the various keys being
> juggled. Section 1.2 refers to three keys: the "standard Reply Key", "a
> key to encrypt the data sent to the KDC", and "a final key to decrypt the
> KDC's reply". Section 2.2 refers to two keys: a "Client Key" and a "Reply
> Key". It says these keys are generated from the (not previously
> mentioned) "Armor Key". Section 3.6 first says the client and KDC need to
> generate two encryption keys; the next paragraph talks about the method
> used to generated the three keys. Section 3.2 refers to the "OTP token
> key". I suspect some of those terms are synonyms, but I could not figure
> out which ones.

I'll leave it to the draft authors to try to clarify this

> There is considerable discussion of forcing the user to change the PIN,
> but no discussion of anywhere the PIN is used in the authentication
> process. Also, forcing the user to change a PIN will deny service if the
> password change service (typically the master replica of the KDC) is down
> or inaccessible. Does Kerberos have a similar mechanism for forcing users
> to change passwords? If so, perhaps the same mechanism should be used.

Kerberos has such a mechanism, only part of which is standardized. 
Specifically, the KDC can reject a request on the grounds that the client 
principal's key is expired, along with a signalling mechanism to warn a 
client that his key will expire soon.  The nonstandard part is that most 
KDC's provide the ability to make certain service principals exempt from 
this behavior, such that you can get a ticket for the password-changing 
service even when your password is expired.

My recollection is that there is some reason this approach cannot be used 
for OTP tokens, possibly because some external OTP services may not provide 
the KDC with enough information to safely issue a ticket if the PIN is 
expired.

> The ability of the client to set large iteration counts for hashing
> operations represents a potential DoS attacks against the KDC. Large
> iteration counts rarely make sense in a protocol because the incremental
> cost to the good guys becomes unacceptable long before the incremental
> cost to the bad guys.

Really?  I was always of the opinion that the reverse is true -- the cost 
of a few more iterations is fairly low for a legitimate client performing 
only one operation, but high for an attacker trying many guesses.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 20 Aug 2008 15:06:30 -0400

--On Wednesday, August 20, 2008 11:04:37 AM -0700 Charlie Kaufman 
<[email-masked]> wrote:

> You're right. YubiKey is electronically connected to the user's computer,
> but in such a simple way (motivated by universal compatibility) that it
> can't do challenge/response authentication with a strong key.
>
> I would think of YubiKey as cryptographically in the same class as
> SecurID, but with clever hardware that saves the user typing. If that's
> what the spec had in mind, then it's technically correct but I would
> still call it somewhat misleading. (At least it misled me).

Actually, you can get securid tokens that do the same thing -- they're a 
USB device, and you can read the current OTP value on the LCD display or 
via USB.  ISTR that they are also capable of doing something more secure, 
if you use RSA's software (apparently they're actually a Java card, with a 
bunch of applets of unknown purpose).  But this is perhaps getting a little 
off topic.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: [email-masked]
Date: Thu, 21 Aug 2008 06:25:39 -0400

Charlie,

Thanks for the comments.

> 
> 
> Section 1.1 says this protocol is also designed to with 
> tokens that are electronically connected to the user's 
> computer. Are there any motivating examples? Such devices are 
> likely to have strong keys and may live under an interface 
> like PKCS-11 with access to private keys and such. It seems 
> unlikely such devices would want to use this protocol, but 
> might instead use PKINIT or simply supply access to a strong 
> secret to use as a password replacement in the AS-REQ and 
> AS-REP messages.
> 
One example of a connected token is the SID800 from RSA.  This device
could have private keys but this would not always be the case.

There is nothing in this specification that prevents the connected
tokens from using full strength OTP values rather than the reduced
values used for hand-held devices.  Also, with connected tokens, the
client could use a PKCS#11 module to communicate with the device.

> The design seems incompatible with the stateless nature of 
> KDCs. Any KDC state should be encrypted and passed through 
> the client so that different exchanges could go through 
> different KDCs.
> 
Any state that the KDC needs to maintain will be saved using the 
cookie mechanism of FAST.  The KDC will return its state in a 
PA-FX-COOKIE which will be included by the client in any subsequent
requests.

I have added the following text to section 3.2:

In order to allow it to maintain any state
necessary to verify the returned nonce, the KDC SHOULD use
the mechanism described in section 6.3 of [ZhHa08].

> The text makes it difficult to keep track of the various keys 
> being juggled. Section 1.2 refers to three keys: the 
> "standard Reply Key", "a key to encrypt the data sent to the 
> KDC", and "a final key to decrypt the KDC's reply". Section 
> 2.2 refers to two keys: a "Client Key" and a "Reply Key". It 
> says these keys are generated from the (not previously 
> mentioned) "Armor Key". Section 3.6 first says the client and 
> KDC need to generate two encryption keys; the next paragraph 
> talks about the method used to generated the three keys. 
> Section 3.2 refers to the "OTP token key". I suspect some of 
> those terms are synonyms, but I could not figure out which ones.
> 
Most of these issues seem to stem from the fact that there were three
keys in earlier drafts but it seems as if I was sloppy in editing when I
reduced it to two keys.  I will correct these errors.

The sentence in section 1.2 has been corrected and now says 
	"...two keys: the standard Reply Key used to decrypt the KDC's
reply and a
          key to encrypt the data sent to the KDC."

I have also corrected the error in section 3.6

The Armor Key is the key used to set up the encrypted tunnel in FAST and
the OTP token key is the seed data on an OTP token that is used to
generate the OTP value.  I will also add some text to sections 2.2 to
clarify 3.2 to clarify this.

> There is considerable discussion of forcing the user to 
> change the PIN, but no discussion of anywhere the PIN is used 
> in the authentication process. Also, forcing the user to 
> change a PIN will deny service if the password change service 
> (typically the master replica of the KDC) is down or 
> inaccessible. Does Kerberos have a similar mechanism for 
> forcing users to change passwords? If so, perhaps the same 
> mechanism should be used.
> 
Whether or not a PIN is used and how it is used is a property of the OTP
algorithm.
If an OTP uses a PIN then it is encoded in the OTP value that is used to
generate the client key and reply key

I'll add some text to section 2.3 explaining that the PIN is used in the
OTP generation.

The only password change mechanism I found was that described in RFC3244
and draft-ietf-krb-wg-kerberos-set-password and I have tried to base the
method of forcing a PIN change on that.

> Section 3.3 is titled "Client Response", but syntactically 
> this is not a response, but rather a second client request.
> 
It is a response to the KDC's challenge in the PA-OTP-CHALLENGE.

> The ability of the client to set large iteration counts for 
> hashing operations represents a potential DoS attacks against 
> the KDC. Large iteration counts rarely make sense in a 
> protocol because the incremental cost to the good guys 
> becomes unacceptable long before the incremental cost to the bad guys.
> 
The iteration count is required to support the case where the KDC is not
the OTP server and the OTP server will not return OTP values.  

The client can choose the iteration count but as described in section
3.4, the KDC should reject the the client request if the iterationCount
is not 
valid.

          However, the client
          authentication MUST fail if the KDC requires hashed OTP
          values and the hashAlg field was not present in the
          PA-OTP-REQUEST, if the hash algorithm identifier or the
          value of iterationCount included in the PA-OTP-REQUEST do
          not conform to local KDC policy or if the value of the
          iterationCount is less than that specified in the
          PA-OTP-CHALLENGE.

The KDC should therefore reject the request if the interation count is
too large or too small.

> In the UI, if there is no password how does the client know 
> to attempt to log in before the user has entered a password? 
> Is the user expected to know to enter a user name and then 
> click login without entering a password? Or what?
> 
This is up to the implementor, there are several options.

For example, the OTP authentication could be used in conjunction with
password authentication or if the client knows that OTP authentication
should be used then it could prompt for a user name and OTP.

> Since one of the primary motivators for this protocol is to 
> support SecurID cards, it would be good to include in 
> appendix B (examples) SecurID cards with and without PINs 
> (including the resync case and acquisition of the armor key). 
> [Appendix B doesn't quite do this because I believe the 
> SecurID token does not report time from the token and SecurID 
> validation requires the unhashed OTP value.] To be 
> evenhanded, it would be good to have an example of something 
> else, like a challenge response device or an OTP password list.
> 
I was trying to keep the draft generic and not have any token type
specifics.  Appendix B.2 shows a two-pass authentiation using a
hand-held token without the use of hashed OTP values and so could be
used for SecurID.

> Section 2.2, last paragraph: generate->generates; use->uses 
Fixed

> Section 2.3, RECOMMENED -> RECOMMENDED 
Fixed

> Section 3.2, "key is the be" -> "key is to be"
Fixed

> Section 3.3, 2nd para, no "." at end
Fixed

> Section 3.3, 3rd para, "that that" -> ????
Fixed

> [ZhHa07], "Znu" -> "Zhu"
Fixed

> Section B.1, 2nd para, "the OTP value" -> "the hash of the OTP value"
Fixed

> Section B.3, 1st para, "the KDC determines that the user's 
> PIN has expired and so must be changed" -> ??? [In B.1 and 
> B.2, there is no PIN]
This is the PIN used in the generation of the OTP value.  I will add
text to section 2.3 clarifying this.

> 
> There seemed to be lots of places where SHALL->MUST, but I'm 
> not sure what the semantic distinction is so I can't be sure 
> which is correct.
>
I'll check these

--Gareth