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

[Greg Hudson <[e-mail]>]

On 10/13/2015 02:49 PM, Michiko Short wrote:
> 	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) realms are a mix of password-based and certificates.    

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

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?

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

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.

> 7.  Security Considerations

This looks mostly okay aside from editorial concerns, except:

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