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

[Michiko Short <[e-mail]>]

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:[e-mail]] 
Sent: Sunday, October 4, 2015 4:31 PM
To: Michiko Short <[e-mail]>
Cc: [e-mail]
Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01

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