Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 4 Oct 2015 19:31:15 -0400 (EDT)

Hi Michiko,

On Sun, 16 Aug 2015, Benjamin Kaduk wrote:

> This message begins the Working Group Last Call (WGLC) of "Public Key
> Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness
> Extension" <draft-ietf-kitten-pkinit-freshness-01>. The WGLC will last two
> weeks, ending on Sunday, August 30th.  The draft is available at:

Looking over the traffic from the WGLC period, it seems that some
revisions to the document are required.  Going over the list's archive:

Greg noted that there was some ambiguity in section 2.4 regarding the
contents of the KRB-ERROR message in the case when a supplied freshness
token is not valid, in his message at
http://www.ietf.org/mail-archive/web/kitten/current/msg05783.html .

That message also raised the question of using KDC_ERR_PREAUTH_FAILED for
a retriable answer, which does not seem to have been resolved yet.  With
no hat on, I'm inclined to avoid KDC_ERR_PREAUTH_FAILED for retriable
errors.

Greg also made some editorial comments in that same message.

Bryce Nordgren also found an editorial change in
http://www.ietf.org/mail-archive/web/kitten/current/msg05794.html (the
content question in that message seems to have been resolved in subsequent
list traffic).

Bryce also notes in a later message that the document should say that the
implementation-defined validation procedure must actually guarantee
freshness.  Something similar to Greg's explanation in
http://www.ietf.org/mail-archive/web/kitten/current/msg05795.html might be
reasonable, say, in the security considerations.

I also supplied a couple editorial comments in
http://www.ietf.org/mail-archive/web/kitten/current/msg05801.html

jhutz made some (mostly) editorial suggestions in his review,
http://www.ietf.org/mail-archive/web/kitten/current/msg05802.html (some of
the non-editorial comments are mitigated by Greg's follow-up in
http://www.ietf.org/mail-archive/web/kitten/current/msg05803.html )

This question from jhutz's message remains unresolved:
"Do we need to call out that a client MUST use a freshness token it got
during an earlier iteration of the same AS exchange?  So, for example,
it can't change its mind about principal names or KDC options or
requested AD and still expect the freshness token to be valid?"  I don't
think this is a particularly critical issue, so it may suffice to just
note that a KDC implementation MAY bind the freshness token to parameters
in the AS-REQ, so the client implementation should use the freshness token
it got during an earlier iteration of the same AS exchange or be prepared
to handle failures resulting from the KDC validation failure for the
binding to the AS-REQ parameter(s).

Can you please generate a revised I-D addressing these comments (i.e.,
including proposed resolutions to the as-yet-unresolved questions)?
Depending on the scope of the changes, another WGLC may be needed; if the
changes are minor and uncontroversial, we might be able to skip it.

Thanks,

Ben

---

From: Michiko Short <[email-masked]>
Date: Tue, 13 Oct 2015 18:49:32 +0000

Sorry for the delay in responding, but before I published the next draft, I wanted to review all the feedback from the beginning since a couple of things keep coming back. Hoping we can get closure in email rather than having another discussion after the next draft. I did not provide the editorial changes since I do not think they are controversial. 

There was feedback to tightening up the intro:

Previous version
1.  Introduction
The Kerberos PKINIT extension [RFC4556] defines two schemes for using asymmetric cryptography in a Kerberos preauthenticator.  One uses Diffie-Hellman key exchange and the other depends on public key encryption.  The public key encryption scheme is less commonly used for two reasons:
o  Elliptic Curve Cryptography (ECC) Support for PKINIT [RFC5349] only specified Elliptic Curve Diffie-Hellman (ECDH) key agreement, so it cannot be used for public key encryption.
o  Public key encryption requires certificates with an encryption key, that is not deployed on many existing smart cards.

In the Diffie-Hellman exchange, the client uses its private key only to sign the AuthPack structure (specified in Section 3.2.1 of [RFC4556]), that is performed before any traffic is sent to the KDC. Thus a client can generate requests with future times in the PKAuthenticator, and then send those requests at those future times. Unless the time is outside the validity period of the client's certificate, the KDC will validate the PKAuthenticator and return a TGT the client can use without possessing the private key.

As a result, a client performing PKINIT with the Diffie-Hellman key exchange does not prove current possession of the private key being used for authentication.  It proves only prior use of that key. Ensuring that the client has current possession of the private key requires that the signed PKAuthenticator data include information that the client could not have predicted.

Proposed revision
1.  Introduction
The Kerberos PKINIT extension [RFC4556] defines two schemes for using asymmetric cryptography in a Kerberos preauthenticator.  In the Diffie-Hellman exchange, the client uses its private key only to sign the AuthPack structure (specified in Section 3.2.1 of [RFC4556]), that is performed before any traffic is sent to the KDC. Thus a client can generate requests with future times in the PKAuthenticator, and then send those requests at those future times. Unless the time is outside the validity period of the client's certificate, the KDC will validate the PKAuthenticator and return a TGT the client can use without possessing the private key.

As a result, a client performing PKINIT with the Diffie-Hellman key exchange does not prove current possession of the private key being used for authentication.  It proves only prior use of that key. Ensuring that the client has current possession of the private key requires that the signed PKAuthenticator data include information that the client could not have predicted.

Client requesting freshness behavior discussions:

We have the client request freshness for multiple reasons
	1. RFC 4120 Section 1.5.2 specifies that the KDC should only use new extensions if the padata element is present in the AS-REQ.
	2. KDC performance impact. The KDC cannot tell the difference between an AS ping for a password-based client vs certificate if the client does not explicitly ask for the token. Many (maybe most) realms are a mix of password-based and certificates.    
	3. In Windows Active Directory, accounts configured with AltSecID can receive a principal not found error and fail logon when the normal password AS ping is sent since the cname is not in the global catalog. By requesting the freshness token, the KDC can choose to return the preauth failure with the token when the account cannot be found.  

KDC_ERR_PREAUTH_FAILED vs KDC_ERR_PREAUTH_EXPIRED 
The first thing I can think of is that currently the draft only requires RFC 4120 & 4556 and FAST is just an informative reference (not to mention that the error is MAY and not in all implementations of FAST). Not sure what the precedence is for pulling just the error behavior from an RFC.

We choose KDC_ERR_PREAUTH_FAILED because it was supported already and "Pre-authentication information was invalid" seemed accurate for the situation. 

KDC validation behavior:
Every time I release a version this comes up. :) There already is a precedent in IETF for not standardizing the KDC-only elements. The consensus is that there are lots of ways to do this and the standard will not specify it. 

How about the following to cover KDC requirements and upgrade advice:

7.  Security Considerations
A freshness token can prove recent possession of the key only if:
1.  The freshness token cannot pre-generated.
2.  The KDC can determine authenticity and prevent tampering.
       Kerberos error messages are not integrity protected unless
       authenticated using Kerberos FAST [RFC6113].  Even if FAST is
       required to provide integrity protection, a different KDC would
       not be able to validate freshness tokens without some kind of
       shared database which is unlikely as most KDCs are stateless.
       Signing, encrypting or sealing data SHOULD be used.
3.  Reuse of a freshness token is only valid within the allowable
       time window.  Freshness tokens are not required to be single use
       tokens or bound to specific AS exchanges, simply to guarantee
       that the client had the key during the allowable time window.
       Part of the reason the token is opaque is to allow KDC
       implementers the freedom to add additional functionality as long
       as the "freshness" guarantee remains.
4.  The client returns the freshness token.  Since upgrading clients
       takes time, implementers may consider allowing both unproven
       and fresh authentications.  As long as freshness tokens are not
       required then pre-generated PKAuthenticators can be used.

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: Sunday, October 4, 2015 4:31 PM
To: Michiko Short <[email-masked]>
Cc: [email-masked]
Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01

Hi Michiko,

On Sun, 16 Aug 2015, Benjamin Kaduk wrote:

> Extension" <draft-ietf-kitten-pkinit-freshness-01>. The WGLC will last 
> two weeks, ending on Sunday, August 30th.  The draft is available at:

Looking over the traffic from the WGLC period, it seems that some revisions to the document are required.  Going over the list's archive:

Greg noted that there was some ambiguity in section 2.4 regarding the contents of the KRB-ERROR message in the case when a supplied freshness token is not valid, in his message at http://www.ietf.org/mail-archive/web/kitten/current/msg05783.html .

That message also raised the question of using KDC_ERR_PREAUTH_FAILED for a retriable answer, which does not seem to have been resolved yet.  With no hat on, I'm inclined to avoid KDC_ERR_PREAUTH_FAILED for retriable errors.

Bryce Nordgren also found an editorial change in http://www.ietf.org/mail-archive/web/kitten/current/msg05794.html (the content question in that message seems to have been resolved in subsequent list traffic).

Bryce also notes in a later message that the document should say that the implementation-defined validation procedure must actually guarantee freshness.  Something similar to Greg's explanation in http://www.ietf.org/mail-archive/web/kitten/current/msg05795.html might be reasonable, say, in the security considerations.

I also supplied a couple editorial comments in http://www.ietf.org/mail-archive/web/kitten/current/msg05801.html

jhutz made some (mostly) editorial suggestions in his review, http://www.ietf.org/mail-archive/web/kitten/current/msg05802.html (some of the non-editorial comments are mitigated by Greg's follow-up in http://www.ietf.org/mail-archive/web/kitten/current/msg05803.html )

This question from jhutz's message remains unresolved:
"Do we need to call out that a client MUST use a freshness token it got during an earlier iteration of the same AS exchange?  So, for example, it can't change its mind about principal names or KDC options or requested AD and still expect the freshness token to be valid?"  I don't think this is a particularly critical issue, so it may suffice to just note that a KDC implementation MAY bind the freshness token to parameters in the AS-REQ, so the client implementation should use the freshness token it got during an earlier iteration of the same AS exchange or be prepared to handle failures resulting from the KDC validation failure for the binding to the AS-REQ parameter(s).

Can you please generate a revised I-D addressing these comments (i.e., including proposed resolutions to the as-yet-unresolved questions)?
Depending on the scope of the changes, another WGLC may be needed; if the changes are minor and uncontroversial, we might be able to skip it.

Thanks,

Ben

---

From: Greg Hudson <[email-masked]>
Date: Tue, 13 Oct 2015 16:56:32 -0400

> 	1. RFC 4120 Section 1.5.2 specifies that the KDC should only use new extensions if the padata element is present in the AS-REQ.

I'm not asking to get rid of the request, but I want to reiterate that I
don't think this is a correct reading of RFC 4120 section 1.5.2.  We
know exactly what an old client will do with a PA-AS-FRESHNESS value in
METHOD-DATA: ignore it.  We have relied on this client behavior numerous
times in the past, such as when we added PA-ETYPE-INFO and PA-ETYPE-INFO2.

> 	2. KDC performance impact. The KDC cannot tell the difference between an AS ping for a password-based client vs certificate if the client does not explicitly ask for the token. Many (maybe most) r…

There are other ways to address any performance impact such as reusing
freshness tokens, but I understand the desire for simplicity.

> 	3. In Windows Active Directory, accounts configured with AltSecID can receive a principal not found error and fail logon when the normal password AS ping is sent since the cname is not in the glob…

I don't understand this.  What is the message sequence?  Do you want to
return a freshness token in a KDC_ERR_C_PRINCIPAL_UNKNOWN error?

> The first thing I can think of is that currently the draft only requires RFC 4120 & 4556 and FAST is just an informative reference (not to mention that the error is MAY and not in all implementatio…

I don't think there is any problem with making RFC 6113 a normative
reference just to use the error code.  We would not be requiring KDCs or
clients to implement FAST; RFC 6113 describes a general framework for
pre-authentication, with FAST as one component.

> We choose KDC_ERR_PREAUTH_FAILED because it was supported already and "Pre-authentication information was invalid" seemed accurate for the situation. 

In MIT krb5, would be rather difficult for us to perform a retry of the
same preauth mechanism after KDC_ERR_PREAUTH_FAILED without creating
unfortunate edge cases.  (For example, we definitely don't want to retry
encrypted timestamp after KDC_ERR_PREAUTH_FAILED, because of password
lockout.)  Most likely we would wind up ignoring that part of the spec
and fail out when a freshness token expired due to prompting delay.

In contrast, we already (in 1.14) perform a retry from scratch on
KDC_ERR_PREAUTH_EXPIRED, so we would not need to make any changes to the
core preauth code.

> 2.  The KDC can determine authenticity and prevent tampering.

Discussing FAST here seems confusing than helpful.  FAST protects
against some kinds of tampering by a network attacker, but wouldn't even
begin to protect against a rogue client tampering with the contents of
the freshness token (e.g. changing a timestamp to make an old token look
new).