Subject: [kitten] Comments requested on draft-short-pkinit-freshness-00

From: Michiko Short <[email-masked]>
Date: Mon, 27 Oct 2014 20:56:16 +0000

Debated email vs draft on this. Since I wasn't going to make the MIT or IETF meetings (thus someone else will be there), it seemed like a draft would easier to discuss via email.

A few years back there was a discussion about the DH freshness issue, so this is a proposal transmitting data to ensure freshness:

https://datatracker.ietf.org/doc/draft-short-pkinit-freshness/

Thanks,
Michiko Short | Program Manager | OS Security

---

From: Greg Hudson <[email-masked]>
Date: Mon, 27 Oct 2014 22:10:47 -0400

> https://datatracker.ietf.org/doc/draft-short-pkinit-freshness/

Thanks for working on this issue.  I think the working group should
adopt this draft.  I have a few specific comments, which are editorial only:

* I stumbled on the reference to "kdcToken" in section 2.2 as the
concept had not yet been introduced.  Some kind of indication that this
is a forward reference might help.

* While I don't think we have to standardize the freshness token, I have
heard of realms including both MIT and Heimdal KDCs.

* The first two paragraphs of the security considerations section seem
to say very similar things.

* The draft doesn't mention the upgrade process.  I assume the plan is
that KDC implementors and/or operators will just have to decide when it
is reasonable to drop support for old clients which don't implement this
standard.

---

From: Michiko Short <[email-masked]>
Date: Tue, 28 Oct 2014 16:29:46 +0000

Thanks for reviewing so quickly.

Can you expand on your second point? Are you saying that MIT and Heimdal already have something called a freshness token? 

Agreed on the security considerations. I figured after discussions that we would merge some of the content there, but in this first draft I wanted to be specific.

In regards to upgrade, is there something specific you were looking for in the standard? 

-----Original Message-----
From: Greg Hudson [mailto:[email-masked]] 
Sent: Monday, October 27, 2014 7:11 PM
To: Michiko Short; [email-masked]
Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00

> https://datatracker.ietf.org/doc/draft-short-pkinit-freshness/

Thanks for working on this issue.  I think the working group should adopt this draft.  I have a few specific comments, which are editorial only:

* I stumbled on the reference to "kdcToken" in section 2.2 as the concept had not yet been introduced.  Some kind of indication that this is a forward reference might help.

* While I don't think we have to standardize the freshness token, I have heard of realms including both MIT and Heimdal KDCs.

* The first two paragraphs of the security considerations section seem to say very similar things.

* The draft doesn't mention the upgrade process.  I assume the plan is that KDC implementors and/or operators will just have to decide when it is reasonable to drop support for old clients which don't implement this standard.

---

From: Greg Hudson <[email-masked]>
Date: Tue, 28 Oct 2014 12:40:22 -0400

> Can you expand on your second point? Are you saying that MIT and Heimdal already have something called a freshness token? 

Oh, definitely not.  The draft says "Since the freshness tokens are
validated by KDCs in the same realm, standardizing the contents of the
freshness token is not a concern for interoperability."  I think there
are occasionally interoperability concerns within a realm, but this is
rare enough that the IETF doesn't need to solve those issues.

> In regards to upgrade, is there something specific you were looking for in the standard? 

I think it would be good to put a note in security considerations that
this extension only solves the problem when the KDC requires the client
to implement it.

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Oct 2014 11:48:45 -0500

> heard of realms including both MIT and Heimdal KDCs.

Like Michiko don't know what this means ^^.

> is reasonable to drop support for old clients which don't implement this

That seems like a reasonable plan to me.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Oct 2014 11:54:09 -0500

On Tue, Oct 28, 2014 at 12:40:22PM -0400, Greg Hudson wrote:
> > Can you expand on your second point? Are you saying that MIT and
> > Heimdal already have something called a freshness token? 
> 

Oh, but the freshness token is just an opaque OCTET STRING that the KDC
gives to the client for the client to repeat back to the KDC (in the
AuthPack, so that it gets signed, forcing the client to make a fresh
signature).

There's no need to say much about the contents of the freshness token.
Just that it has to be nonce-like (not repeat).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Oct 2014 11:58:30 -0500

> Just that it has to be nonce-like (not repeat).

Oh, actually, no, the KDCs in a realm need to be able to validate each
others' freshness tokens.  So they must have structure, something like
{nonce, HMAC(realm_secret_key, nonce)}.

Now I get Greg's comment: there are realms running a mixture of KDC
implementations (Heimdal and MIT, for example).  If the token is not
standardized then some implementations might use an informal standard
anyways.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Oct 2014 14:22:11 -0500

{nonce, [kvno], Checksum} seems reasonable.

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Oct 2014 15:08:17 -0500

Better: {index, {nonce, kvno, checksum}}, or {index, {nonce, cname,
realm, kvno, checksum}} (and, because of the PKCROSS work, we might
want to make that cname, crealm, and srealm), where the index is an
index into a cache of tokens that can be used to speed up the check
when the client uses the same KDC.

Is this worth standardizing?  Separately, sure.  Microsoft might not
implement it, but MIT and Heimdal might want to.  Emphasis on 'might'.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Oct 2014 15:25:22 -0500

I obviously need more caffeine today.  A timestamp would also be
needed, otherwise there'd be no stateless way to ensure that the token
used by a client is fresh (not taken from an earlier AS exchange).

---

From: Michiko Short <[email-masked]>
Date: Tue, 28 Oct 2014 21:38:08 +0000

Ah, so then having a mix of KDC implementations is supported other than with Windows AD domains? 

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: Tuesday, October 28, 2014 9:59 AM
To: Greg Hudson
Cc: Michiko Short; [email-masked]; Andrei Popov
Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00

> Just that it has to be nonce-like (not repeat).

Oh, actually, no, the KDCs in a realm need to be able to validate each others' freshness tokens.  So they must have structure, something like {nonce, HMAC(realm_secret_key, nonce)}.

Now I get Greg's comment: there are realms running a mixture of KDC implementations (Heimdal and MIT, for example).  If the token is not standardized then some implementations might use an informal standard anyways.

Nico
--

---

From: Michiko Short <[email-masked]>
Date: Tue, 28 Oct 2014 21:41:34 +0000

Windows uses the AD for its account database, so we cannot use an index/shared database method. We were thinking something time bound with something unique. 

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: Tuesday, October 28, 2014 1:08 PM
To: Greg Hudson
Cc: Michiko Short; [email-masked]; Andrei Popov
Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00

Better: {index, {nonce, kvno, checksum}}, or {index, {nonce, cname, realm, kvno, checksum}} (and, because of the PKCROSS work, we might want to make that cname, crealm, and srealm), where the index is an index into a cache of tokens that can be used to speed up the check when the client uses the same KDC.

Is this worth standardizing?  Separately, sure.  Microsoft might not implement it, but MIT and Heimdal might want to.  Emphasis on 'might'.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Oct 2014 16:44:33 -0500

> Ah, so then having a mix of KDC implementations is supported other than with Windows AD domains?

FWIW, there have been alternative implementations of Windows DCs too,
though I don't know if any of them have supported mixed
implementations for the same domain.

I would favor an optional standard for the freshness token's structure.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Oct 2014 16:53:43 -0500

> Windows uses the AD for its account database, so we cannot use an index/shared database method. We were thinking something time bound with something unique.

The index would be into a local cache, so that if the same client goes
back to the same AS, then the AS can save itself the work of
cryptographically verifying the freshness token, instead doing an
octet-wise comparison of the token to that in the cache and checking
that the timestamp in the token is "fresh".

Clearly the token must notionally include a timestamp, whether it's
encrypted or MACed.  It may or may not need a link to the client
requesting a ticket as well (cname, crealm, subjectPublicKey (if not
anon), subjectPublicKeyInfo (if using DH)).

We should say something about what "freshness" means.  Within the last
30 seconds?  Within the last minute?  Clearly it should be a matter of
local configuration, for some advice would help.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 28 Oct 2014 18:24:44 -0400 (EDT)

> adopt this draft.  I have a few specific comments, which are editorial only:

I also think the working group should adopt this draft (with my individual
hat, so far) -- it's a simple way to resolve a weakness of the existing
standard.

I'm happy that we're considering potential implementations for the
freshness token, but am still undecided whether this document should say
anything concrete about the contents of the kdcToken.  From what I've seen
so far (both on-list and on IRC), it seems like just a timestamp encrypted
in a key derived from the krbtgt key of the local realm should provide the
needed properties.

Brainstorming out loud, once a given realm gest to a state where the KDCs
require freshness tokens in PKINIT AS-REQs, an attacker could cause a
denial of service if it could modify the KRB-ERROR responses to remove
valid freshness tokens from them.  This probably doesn't matter, because
such an attacker could deny service in other ways (by corrupting the
AS-REP's ciphertext or blocking it entirely, etc.).

Figure 1 includes a column for traffic involving the "appliication
server", which is not used, so it could probably be removed.

There are some grammar nits floating around; let me know if you want me to
write them up and send them to you (off-list, presumably).

-Ben

---

From: Greg Hudson <[email-masked]>
Date: Tue, 28 Oct 2014 18:31:25 -0400

> Ah, so then having a mix of KDC implementations is supported other than with Windows AD domains? 

"Supported" may be an overstatement.  People have done it, and basic
functionality works, and we (MIT krb5 and Heimdal) have coordinated on
some KDC-only protocol elements such as AD-SIGNTICKET in the past.

However, there is also precedent in the IETF for not standardizing
KDC-only elements--most notably, the contents of PA-FX-COOKIE are
totally non-standardized.  Whichever project implements the freshness
token can make a non-IETF document describing the format

As for what goes into the freshness token, I don't see any need to put
in more than the minimum, which is an encrypted or checksummed
timestamp.  (And a kvno if we use a checksum, since Checksum doesn't
identify which key version was used.)  That should be sufficient to
prevent the threat described in the draft.

I should note that there is an unbounded delay between the
preauth-required error and the preauthenticated AS request, since the
user can take arbitrarily long to respond to authentication prompts.  We
can't really avoid this problem without introducing state in the KDC, so
clients will just have to deal with the possibility that authentication
might fail in this case; it can retry, or it can make the user retry.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 28 Oct 2014 18:34:24 -0400 (EDT)

> might fail in this case; it can retry, or it can make the user retry.

The draft should probably mention explicitly that clients shouldu be
prepared to retry in cases like this.

-Ben

---

From: Michiko Short <[email-masked]>
Date: Wed, 29 Oct 2014 21:41:19 +0000

For Windows we publish more detailed specifications via the protocol technical documents which is where I planned to publish our version of the structure. I just don't think it is required for the standard. 

We can have a separate standard(s) for the data structure. It was not clear if you thought there would need to be another version for PKCross.

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: Tuesday, October 28, 2014 2:45 PM
To: Michiko Short
Cc: Greg Hudson; [email-masked]; Andrei Popov
Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00

> Ah, so then having a mix of KDC implementations is supported other than with Windows AD domains?

FWIW, there have been alternative implementations of Windows DCs too, though I don't know if any of them have supported mixed implementations for the same domain.

Nico
--

---

From: Michiko Short <[email-masked]>
Date: Wed, 29 Oct 2014 21:44:08 +0000

I am open to suggestions. Previously, Kerberos used 5 minutes for clock skew. Are we thinking that is too much time? The clock skew danger here would be between two DCs in the same realm.

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: Tuesday, October 28, 2014 2:54 PM
To: Michiko Short
Cc: Greg Hudson; [email-masked]; Andrei Popov
Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00

> Windows uses the AD for its account database, so we cannot use an index/shared database method. We were thinking something time bound with something unique.

The index would be into a local cache, so that if the same client goes back to the same AS, then the AS can save itself the work of cryptographically verifying the freshness token, instead doing an octet-wise comparison of the token to that in the cache and checking that the timestamp in the token is "fresh".

Clearly the token must notionally include a timestamp, whether it's encrypted or MACed.  It may or may not need a link to the client requesting a ticket as well (cname, crealm, subjectPublicKey (if not anon), subjectPublicKeyInfo (if using DH)).

We should say something about what "freshness" means.  Within the last
30 seconds?  Within the last minute?  Clearly it should be a matter of local configuration, for some advice would help.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Oct 2014 17:04:43 -0500

> I am open to suggestions. Previously, Kerberos used 5 minutes for clock skew. Are we thinking that is too much time? The clock skew danger here would be between two DCs in the same realm.

I think something like "a small fraction of the would-be lifetime of
the ticket to be issued" will do, since that matches the intent (no
pre-minting of AS-REQs ahead of time).  I'd make it 30 seconds, since
by this point in the protocol there's no skew issues for any remotely
sane clocks, and 30 seconds seems like plenty of time to complete an
AS exchange.

Nico
--