Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00

[Benjamin Kaduk <[e-mail]>]

On Tue, 20 Jan 2015, Benjamin Kaduk wrote:

> http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00

I reviewed this one, and it seems fine.  A few minor (nonsubstantive)
issues below.


The new text says:

   In Section 7, pepper string 2 is corrected to comply with the string
 	   actually used by implementations.

However, the actual body text where the change to this string is made just
refers to it as "pepper2", so it might be better to be consistent and say
"the pepper2 string is corrected".


The introductory text in section 7 and the description of the attack read
almost as if they were originally written for a different context and just
dropped in place here; the terminology used does not match well with the
rest of the document.  For example, what are "channels"?  What does it
mean for a channel to have "a given name"?  The text here could probably
be drastically improved; perhaps we should take the time to do so since we
are already modifying the document.

I think that the attack could be expressed more cleanly, too -- "it is
desirable that neither the KDC nor the client unilaterally determine the
ticket session key" doesn't really say why.  What this extension is doing
is providing a binding between the party which generated the session key
and the DH exchange used to generate the reply key.  Supposing for the
sake of argument that the KDC picks the ticket session key as usual,
absent the use of PA-PKINIT-KX, the client and KDC would perform a DH key
exchange to determine a shared key, and that key would be used as the
reply key.  The KDC generates a ticket with session key as usual, and
encrypts the reply using the result of the DH agreement.  If there is a
MITM, the attacker can just decrypt the session key + ticket using the
DH key from the attacker<-->KDC DH exchange, and reencrypt it using the
key from the attacker<-->client DH exchange, keeping a copy of the session
key and ticket.  By requiring the session key to be a function of the
reply key in a way that can be verified by the client, this extension
binds the ticket to the DH exchange and prevents the MITM attack.



Some nits in the original RFC 6112 text:


In the introduction,

   [...] Note that
   the membership of a realm can imply a member of the community
   represented by the realm.

seems ungrammatical.


At the bottom of page 4, "For example, an anonymous principal that is
identifiable only within a particular group of users can be implemented
using authorization data and such authorization data, if included in the
anonymous ticket, would disclose the client's membership of that group."
is a bit awkward.  I would probably rephrase it as "For example, an
anonymous principal that is identifiable only as being one of a particular
group of users can be implemented using authorization data.  Such
authorization data, if included in the anonymous ticket, would disclose
that the client is a member of the group in question."


In section 4.1:

   The Kerberos client can use the client's long-term keys, the client's
   X.509 certificates [RFC4556], or any other pre-authentication data,
   to authenticate to the KDC and requests an anonymous ticket in an AS
   exchange where the client's identity is known to the KDC.

I think that the final 's' in "requests" is ungrammatical and should be
removed.


At the top of page 6, "According to [RFC4120]" could just as easily be "As
specified by [RFC4120]", since this is just repeating standard Kerberos
behavior.


Two paragraphs later, we could
s/AD-INITIAL-VERIFIED-CAS/AD_INITIAL_VERIFIED_CAS/ (twice), since the
ad-type assigned number uses the underscores and the ASN.1 type uses
hyphens.  (This also appears in section 4.2 on page 9.)


The final paragraph of section 4.1 starts with "The client can use the
client keys"; the phrase "client keys" does not appear anywhere else in
this document, or RFC 4120, or RFC 4556.  Perhaps the intent was "the
client's key" instead.


In the last sentence of page 7, I think that "Anonymity PKINIT" should be
"Anonymous PKINIT".



In section 4.2, there's a missing space in "the anonymous KDC optionSHOULD
be set in the request."


-Ben