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

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 16 Aug 2015 11:24:58 -0400 (EDT)

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:

https://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-01

Please review the document and send comments to the Working Group mailing
list <[email-masked]> or the co-chairs <[email-masked]>
before the end of the WGLC.  Any and all comments on the document are
sought in order to access the strength of consensus.  Even if you have
read and commented on this or earlier versions of the draft, please feel
free to comment again.  This is particularly important if you found issues
with the previous version.

As a reminder, comments can be anything from "this looks fine" to "this is
a horrible idea"; they can include suggestions for minor editorial
corrections to significant editorial changes.

- Your Kitten Chairs

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 16 Aug 2015 11:31:46 -0400 (EDT)

> https://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-01

One minor thing occurred to me while I was reading through prior to
starting the WGLC: in section 2, bullet 1, the current text has "without
an authenticator which includes the freshness token request to the KDC",
which doesn't seem quite right -- this un-preauthenticated AS-REQ does not
have a freshness token included in it, but it is intended to request a
freshness token from the KDC.  So, it might be better to just say "without
an authenticator that includes a freshness token" [0].  (It would not be
correct to say "with an authenticator that does not include a freshness
token", right?)

-Ben

[0] The RFC Editor would change "which" to "that", since their criterion
is that "which" is used when clarifying a property of all occurrences of
the class being described, whereas "that" is used when the additional
clause is actually adding qualifiers.

---

From: Greg Hudson <[email-masked]>
Date: Mon, 17 Aug 2015 12:25:55 -0400

In section 2.4, I am confused about this passage:

    If the freshness token is not valid, the KDC MUST return
    KDC_ERR_PREAUTH_FAILED with PA_AS_FRESHNESS.

Is this saying that the KRB-ERROR message with code
KDC_ERR_PREAUTH_FAILED should include e-data containing METHOD-DATA
containing a PA-DATA element of type PA_AS_FRESHNESS with a valid
freshness token value?  If so, it is too abbreviated to be clear.
Including METHOD-DATA as e-data for a KDC_ERR_PREAUTH_FAILED is first
specified in RFC 6113, so we might need a normative reference to be
precise about what's going on.

I am also concerned about using KDC_ERR_PREAUTH_FAILED for a retriable
error within a preauth mech.  When I have reasoned about how the MIT
krb5 client preauth framework should be designed (not how it is
currently designed), I generally think of PREAUTH_FAILED as indicating
that the client should move on to a different preauth mechanism, or
retry without optimistic configuration if it was doing optimistic
preauth.  The prior art for retriable arrors within a mechanism has been
to use specific error codes.

One alternative is to use KDC_ERR_PREAUTH_EXPIRED from RFC 6113.  There
is no specification for including METHOD-DATA in such an error, so the
client would have to restart from scratch, without the benefit of a
newly valid freshness token.  But I think that is okay; recovering from
a delay which resulted in a not-so-fresh freshness token should not be a
common scenario.

My remaining comments are editorial.  In the abstract:

* "PKInit" should be "PKINIT".

In the introduction:

* There should be a comma after "(ECDH) key agreement".

* There should be a comma after "with an encryption key".

* There should be a comma after "Section 3.2.1 of [RFC4556]", and
possibly the phrase "specified in Section 3.2.1 of [RFC4556]" should be
in parentheses.

In section 1.1:

* The first paragraph is too complicated for one un-punctuated sentence.
 I suggest:

    Today, password-based AS exchanges [RFC4120] often begin with the
    client sending a KRB_AS_REQ message without pre-authentication.
    The KDC responds with a KRB-ERROR containing information needed to
    complete an AS exchange, such as the supported encryption types and
    salt values.  This message flow is illustrated below:

* The second paragraph is also on the complicated side.  I suggest:

    We can use a similar message flow with PKINIT, allowing the KDC to
    provide a token for the client to include in its KRB_AS_REQ to
    ensure that the PA_PK_AS_REQ [RFC4556] was not pre-generated.

In section 2:

* "KDC provided" should be "KDC-provided".

* The clause structure in item 1 is confusing (as witnessed by Ben's
reply where he misread it).  I suggest:

    The client generates a KRB_AS_REQ as specified in Section 2.9.3 of
    [RFC4120], which contains no PA_PK_AS_REQ, and which includes a
    freshness token request.

* In item 4, there should be a comma after "Section 3.2.2 [RFC4556]".

In section 2.1:

* "PA_AS_FRESHNESS padata type" should be "a padata element with
padata-type PA_AS_FRESHNESS and".

In section 2.2:

* The same substitution as in section 2.1 should be made.

In section 2.3:

* "PA_DATA" should be "PA-DATA" in both places.

In section 2.4:

* "implementation specific" should be "implementation-specific".

In section 2.5:

* This sentence is too complicated.  If there are no changes to the
behavior here, I recommend:

    If a client receives a KDC_ERR_PREAUTH_FAILED KRB_ERROR message
    which includes a PA_AS_FRESHNESS token, it SHOULD generate a new
    PA_PK_AS_REQ and KRB_AS_REQ using the new freshness token.  This
    scenario may occur if there was too much delay between the client
    receiving the freshness token and sending its initial PA_PK_AS_REQ
    message.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 25 Aug 2015 20:27:59 -0400 (EDT)

Reminder: only five days remain in this WGLC.  It would be nice to see
input from more people, whether on the issue raised by Greg or just
general comments.

-Ben

On Sun, 16 Aug 2015, Benjamin Kaduk wrote:

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Wed, 26 Aug 2015 16:49:41 +0000

I'm a little confused as to whether the PA_AS_FRESHNESS field is truly opaque or not. It appears to be, in section 2.3. I take "opaque" to mean that the client is not expected to grok the contents of the field and MUST copy it to the KRB_AS_REQ exactly as received from the KDC. This would imply that in section 2.4, the KDC MUST check to make sure that the field returns matches exactly what was sent. Instead, it is validated in an implementation specific way?  Can you either clarify the circumstances that would lead to the need for "implementation specific" validation (having implications for non-opaquish client behavior), or just simplify to checking for an exact match?

In Section 5, "...contributors to the discover" should be "discovery. "

Thanks,
Bryce

> -----Original Message-----
> From: Kitten [mailto:[email-masked]] On Behalf Of Benjamin Kaduk
> Sent: Tuesday, August 25, 2015 6:28 PM
> To: [email-masked]
> Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01
> 
> Reminder: only five days remain in this WGLC.  It would be nice to see input
> from more people, whether on the issue raised by Greg or just general
> comments.
> 
> -Ben
> 
> > Extension" <draft-ietf-kitten-pkinit-freshness-01>. The WGLC will last
> > two weeks, ending on Sunday, August 30th.  The draft is available at:
> >
> > Please review the document and send comments to the Working Group
> > mailing list <[email-masked]> or the co-chairs
> > <[email-masked]> before the end of the WGLC.  Any and
> > all comments on the document are sought in order to access the
> > strength of consensus.  Even if you have read and commented on this or
> > earlier versions of the draft, please feel free to comment again.
> > This is particularly important if you found issues with the previous version.
> >
> > As a reminder, comments can be anything from "this looks fine" to
> > "this is a horrible idea"; they can include suggestions for minor
> > editorial corrections to significant editorial changes.
> >
> >
> > - Your Kitten Chairs
> >
> >

---

From: Greg Hudson <[email-masked]>
Date: Wed, 26 Aug 2015 13:16:15 -0400

> I'm a little confused as to whether the PA_AS_FRESHNESS field is truly opaque or not. It appears to be, in section 2.3. I take "opaque" to mean that the client is not expected to grok the contents…

KDCs are usually stateless, and therefore don't have a way to directly
verify that the client reflected exactly what the KDC sent.

Instead, the KDC could do something like encrypt a timestamp in a key
known only to the realm's KDCs; to verify the token, it could decrypt it
and check that the timestamp is sufficiently recent.  A client could get
away with replaying a freshness token from a different request within
the allowable time window, but that's not an interesting attack.

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Wed, 26 Aug 2015 18:49:30 +0000

> From: Greg Hudson [mailto:[email-masked]]
> Sent: Wednesday, August 26, 2015 11:16 AM
> To: Nordgren, Bryce L -FS; Benjamin Kaduk; [email-masked]
> KDCs are usually stateless, and therefore don't have a way to directly verify
> that the client reflected exactly what the KDC sent.
> 
> known only to the realm's KDCs; to verify the token, it could decrypt it and
> check that the timestamp is sufficiently recent.  A client could get away with
> replaying a freshness token from a different request within the allowable
> time window, but that's not an interesting attack.

Ah. So this exposes some other unstated assumptions.

Somewhere in this draft, probably section 2.2, it needs to be stated that:

1] The KDC MUST NOT reuse the same freshness token on multiple requests; and 
2] The KDC MUST NOT recognize a freshness token as valid if it is received outside of a specified time window from when it was minted.

I'm on the fence about a third statement: "The KDC SHOULD only recognize the freshness token as valid if it is included in a request from the client principal to which it was issued." It indicates intent without imposing constraint. If you don't have these two...possibly three constraints, you haven't really proven "freshness". 

I do think some wordsmithed variant of Greg's paragraph above ("Instead, the KDC...but that's not an interesting attack.") should be included in the Security Considerations section.

Thanks,
Bryce

---

From: Greg Hudson <[email-masked]>
Date: Wed, 26 Aug 2015 15:10:57 -0400

> 1] The KDC MUST NOT reuse the same freshness token on multiple requests; and

This requirement would have no security or interoperability value.
Reusing the same freshness token on multiple requests is a perfectly
valid implementation strategy, as long as the token only remains valid
for a reasonable length of time.

> 2] The KDC MUST NOT recognize a freshness token as valid if it is received outside of a specified time window from when it was minted.

I have no objection to adding some wording about this, but I would hope
that no implementor would design a "freshness token" which provided no
guarantee of freshness!

> I'm on the fence about a third statement: "The KDC SHOULD only recognize the freshness token as valid if it is included in a request from the client principal to which it was issued." It indicates…

Even as a SHOULD, this advice would have no security or interoperability
value.  All we are trying to do is make the client prove that it has
recent access to its private key.  The only thing we need to know about
the freshness token is that a rogue client could not have concocted or
intercepted one more than a few minutes in the past which appears to be
valid now.

We may be using the term "freshness" more loosely than the general
cryptography community would; I can't easily find a general definition.
 If we are using it loosely, that's a common foible of the Kerberos
community; there are similar examples in RFCs 4120 and 6113.

> I do think some wordsmithed variant of Greg's paragraph above ("Instead, the KDC...but that's not an interesting attack.") should be included in the Security Considerations section.

No objection.  I'm not really worried about anyone implementing this
spec without understanding the architectural reasoning behind it, but
more clarity is never a bad thing.

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Wed, 26 Aug 2015 19:20:35 +0000

> Reusing the same freshness token on multiple requests is a perfectly valid
> implementation strategy, as long as the token only remains valid for a
> reasonable length of time.

Fair enough. I withdraw the comment.

> > 2] The KDC MUST NOT recognize a freshness token as valid if it is received
> outside of a specified time window from when it was minted.
> 
> I have no objection to adding some wording about this, but I would hope that
> no implementor would design a "freshness token" which provided no
> guarantee of freshness!

I have less faith in humanity than most. ;) 

> > I'm on the fence about a third statement: "The KDC SHOULD only recognize
> the freshness token as valid if it is included in a request from the client
> principal to which it was issued." It indicates intent without imposing
> constraint. If you don't have these two...possibly three constraints, you
> haven't really proven "freshness".
> 
> value. ...

I concur and withdraw the suggestion.

> > I do think some wordsmithed variant of Greg's paragraph above ("Instead,
> the KDC...but that's not an interesting attack.") should be included in the
> Security Considerations section.
> 
> No objection.  I'm not really worried about anyone implementing this spec
> without understanding the architectural reasoning behind it, but more clarity
> is never a bad thing.

I think it would be silly to publish a freshness spec which doesn't actually require freshness be proven. ;) 

Bryce

---

From: [email-masked]
Date: Thu, 27 Aug 2015 00:49:08 +0200

From a practical standpoint I have been against the use of timestamps as a check of freshness (although I have no better solution) since whitnessing some services fall over with catestrophic consequenses for their host companies for precisely that reeason. Ok, that was a few year prior to widespread adoption time synchroised servises, but that is not so far behind us. But there is no reason to pre-suppose that the relevant service dialogue is with a service synchronised via a world atomic clock. Although that may be true of the vast majority of cases of current impementations, to build upon this assumption just builds dependecies upon dependencies. That cannot be good for the future.

Gesendet: Mittwoch, 26. August 2015 um 19:16 Uhr

Von: "Greg Hudson" <[email-masked]>

An: "Nordgren, Bryce L -FS" <[email-masked]>, "Benjamin Kaduk" <[email-masked]>, "[email-masked]" <[email-masked]>

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

Kitten mailing list

[email-masked]

---

From: Greg Hudson <[email-masked]>
Date: Wed, 26 Aug 2015 19:31:55 -0400

On 08/26/2015 06:49 PM, [email-masked] wrote:
> From a practical standpoint I have been against the use of timestamps as
> a check of freshness (although I have no better solution) since
> whitnessing some services fall over with catestrophic consequenses for
> their host companies for precisely that reeason. Ok, that was a few year
> prior to widespread adoption time synchroised servises, but that
> is not so far behind us. But there is no reason to pre-suppose that the
> relevant service dialogue is with a service synchronised via a world
> atomic clock. Although that may be true of the vast majority of cases of
> current impementations, to build upon this assumption just builds
> dependecies upon dependencies. That cannot be good for the future.

I don't think this is a concern for the freshness document for three
reasons:

1. Other aspects of Kerberos already require that KDC clocks be loosely
synchronized with other KDCs in the realm, and with application servers
in the realm.  (Clients may have somewhat skewed clocks with minimal
consequences, as they can detect the offset to the KDC during initial
authentication.)

2. As the freshness token is opaque to the client, the use of timestamps
in freshness tokens only requires that KDC clocks within the realm are
synchronized with each other.  It does not add any additional
synchronization requirements between KDCs and clients, and application
servers are not party to the initial authentication exchange in the
first place.

3. The use of timestamps in the freshness token is an implementation
decision, not a requirement of the draft.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 30 Aug 2015 22:58:04 -0400 (EDT)

Time for my own review, with no hats on.

I don't have much to add that wasn't already included in Greg's comments
(and Bryce's note that we should explicitly say that validating the
freshness token should validate it's freshness).  (Okay, I'll put my chair
hat on to thank Greg for the very thorough review -- thanks, Greg!)
Basically, just a touch of wordsmithing.

In section 2, item 3, the wording could probably be more clear in saying
that the freshness token is extracted from the KRB_ERROR message and
included in the construction of a new KRB_AS_REQ message.  Similarly in
section 2.3, indicating that the freshness token goes into a new message
from client to KDC would increase the level of clarity.

-Ben

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 31 Aug 2015 11:22:49 -0400

> weeks, ending on Sunday, August 30th.  The draft is available at:

Someone bugged me one too many times, so now I have to actually read
this. :-)

Looks good overall; the concept is sound, and the specified protocol
seems to achieve the intended goal.  In some ways, this feels more like
a sketch than a detailed protocol spec, but I can't really point to
something specific that's missing.

The introduction goes into quite a bit of detail about reasons the
authors suppose PKINIT's encryption-based exchange is not normally used.
The reality is a bit more complicated(*), and also mostly irrelevant to
this document.  I would cut the second and following sentences of the
first paragraph and the following bullet list, and merge the remaining
sentence into the following paragraph.  That is, the introduction should
focus on this extension and the deficiency it corrects, rather than on
why some other protocol or mode is not used.

The negotiation mechanism is over-complicated.  In order for this
extension to do any good, the KDC must require its use.  Therefore, and
because PA-DATA is non-critical, there is no need for a client to
advertise support for it.  A KDC which supports this extension should
simply send PA-AS-FRESHNESS with any preauth-required response where
PKINIT would be permitted.  Clients which do not support the extension
will ignore it (but won't be able to authenticate with PKINIT, of
course).

Section 2.4 must require the KDC return an error when the freshnessToken
is not present, in addition to when it is missing.

Somewhere (2.3?) it should be made clear that the client MUST NOT
include a freshnessToken if the KDC did not send PK-AS-FRESHNESS.  This
ought to be obvious, since the client has no value to put there, but
IMHO it's better to be specific.

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?

-- Jeff

(*) It's true that we only specify ECDH, but ECDSA wouldn't help you.
It's true that deployed smartcards tend to have only signing keys, but
then, they also tend to have only RSA keys, which makes EC irrelevant to
the discussion.  Also, who says PKINIT is only for smartcards?  When we
were developing what eventually became RFC4556, one of the most notable
use cases involved no smart cards and no keys belonging to users (i.e.
people).

---

From: Greg Hudson <[email-masked]>
Date: Mon, 31 Aug 2015 14:54:37 -0400

> will ignore it (but won't be able to authenticate with PKINIT, of

I agree, but Microsoft's implementation issues (whether they were
arrived at in a justifiable way or not) may trump simplicity on this
point.  There have been earlier conversations on this topic, most
recently in this thread:

http://www.ietf.org/mail-archive/web/kitten/current/msg05458.html

> is not present, in addition to when it is missing.

I don't think we want a hard requirement for this.  Obviously the
extension doesn't improve security until it is required, but KDCs should
be able to measure the level of client support by requesting freshness
tokens without requiring their use.

> requested AD and still expect the freshness token to be valid?

That's an interesting question.  There's no security need for a KDC to
bind a freshness token to any parameter of an AS exchange, but there's
currently no explicit prohibition against doing so.  It's also not
unusual for a client to change some aspects of its AS request,
particularly timestamps, after receiving a PREAUTH_REQUIRED error.