Subject: Re: Last Call: 'Kerberized Internet Negotiation of Keys (KINK)' to Proposed Standard (fwd)

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 Nov 2005 12:41:38 -0600

Comments:

 - Rekeying

"
3.6.  Rekeying Security Associations

   KINK requires the initiator of an SA to be responsible for rekeying
   the SA.  ...
"

   First, "requires" isn't proper RFC2119 terminology, and proper
   RFC2119 terminology in this regard is missing in that section.  This
   would be fine, except that...

   ...second, since KINK allows for user-to-user Kerberos V exchanges I
   see no reason that responders couldn't, if they wanted to, act as
   initiators, so there's a question, I think, as to whether responders
   are simply not allowed to do that or merely expected to not do that.
   Or did I miss something else?

   Third, even if responders typically could not act as initiators (say,
   for implementation-specific issues), one might still want some
   notification that an SA has expired and traffic needs it to be
   rekeyed.

   Looking at the minutes from IETF62 I see that there was concern about
   having servers do the u2u dance, but when re-keying the server knows
   that it's had an SA with a particular peer and so I think the DoS
   concern goes away.

 - Section 5.3 limits the IDs that can be used with KINK to
   address/subnet/address range IDs.  I think this is too limited, it
   seems likely to make KINK very difficult to use.

   I'd rather that a new ID type be defined that corresponds to Kerberos
   V principal names and/or that ID_FQDN and ID_RFC822_ADDR be allowed
   and a simple algorithm be recommended for matching principals and
   such IDs.

   In any case, much too little is said about IDs, and while what is
   said may be appropriate for a doc defining a KE protocol, unless a
   profile doc is to follow it that specifies such details...  how is
   one to use this KE?  Local/distributed configuration of
   principal<->IDs seems hard to deal with and prone to usability and/or
   interop problems, if not even to security problems (e.g., using DNS,
   not DNSSEC to map host principals to IP addresses to match to
   asserted IDs).

   Perhaps there should be a new principal name type hint for IP address
   based names.  That would push some complexity from implementation to
   host administration, while creating a separate problem (how to
   determine the realm name of a given address), but it seems possibly
   worthwhile.

 - Section 4.2.4.  How does cross-realm user-to-user work?

   Also, this doesn't make sense:

   "
                                 ...  When the requested principal is
   "principal@REALM", ...
   "

   Isn't "principal@REALM" pretty much the only form that the requested
   principal name can take?  Or are there other forms?  Where are those
   described?

 - Section 4.2.4.  How are the values of PrincName constructed?  Are
   they DER encodings of

      SEQUENCE { pname PrincipalName, realm, RealmName}?

   Or are they an "unparsed" representation of principal names following
   rules similar to those listed in RFC4121?

   This is very simply dealt with by saying that the contents of
   PrincName is given by section 2.1.3 of RFC1964, but without the
   GSS-API exported name token header.

 - Key derivation.  IKEv2 has different orders for the concatenation of
   the prf input data than KINK does.  You might want to double check
   with a cryptographer that KINK is doing the right thing here
   (particularly in light of the NIST KDF work).

 - Sub-session key generation.

   Section 3.2.1 says that "... KINK takes advantage of the fact that
   the KDC provides a reliable source of randomness which is used in key
   derivation."  But there's no prescribed mechanism by which Kerberos V
   clients are to include KDC-provided entropy into the sub-session key
   generation, nor is there any text saying that clients MAY/SHOULD/MUST
   do this in some, presumably, implementation dependent manner.

   RFC4120 does not, I think, rescue KINK here either, for it only says
   that "[if] the client selects a sub-session key, care must be taken
   to ensure the randomness of the selected sub-session key."

   I think it's better that KINK say that clients which do not have
   local, reliable sources of entropy SHOULD make use of KDC-provided
   entropy (in the form of ticket session keys and/or KDC-REP enc part
   nonces).

Thanks,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 29 Nov 2005 15:40:19 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas>  - Section 5.3 limits the IDs that can be used with KINK
    Nicolas> to address/subnet/address range IDs.  I think this is too
    Nicolas> limited, it seems likely to make KINK very difficult to
    Nicolas> use.

    Nicolas>    I'd rather that a new ID type be defined that
    Nicolas> corresponds to Kerberos V principal names and/or that
    Nicolas> ID_FQDN and ID_RFC822_ADDR be allowed and a simple
    Nicolas> algorithm be recommended for matching principals and such
    Nicolas> IDs.

Nico, these are phase 2 IDs.  I.E. they describe the SA, not the
parties involved.

I'm afraid you are living in an IKEV2 world where terminology makes
sense.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 Nov 2005 15:39:04 -0600

On Tue, Nov 29, 2005 at 03:57:40PM -0500, Chaskiel M Grundman wrote:
> --On Tuesday, November 29, 2005 12:41:38 -0600 Nicolas Williams 
> <[email-masked]> wrote:
> 
> > [...]
> kink actually proscribes the use of sub-session keys:
> 
> 4 KINK Message Format[....]
>  o  Cksum (variable) -- Kerberos keyed checksum over the entire
>      message excluding the Cksum field itself.[...] The key used
>      MUST be the session key in the ticket.
> 
> 7 ISAKMP Key Derivation [....]
> 
> o  SKEYID_d is the session key in the Kerberos service ticket from
>      the AP-REQ.  Note that subkeys are not used in KINK and MUST be
>      ignored if received.
> 
> This issue has been discussed in the past (multiple times even), and 
> bringing it up again will probably not result in anything other than wasted 
> time.

*nod*

> I did notice that section 4.2.7 KINK_ENCRYPT does not specify what key is 
> used, only that it
> "is encrypted using the encryption algorithm specified by the etype of the 
> session key"

Hmmm, mumble, mumble, reflection attacks, mumble, mumble.

Shouldn't KINK derive separate keys for each direction for the "cksum"
and KINK_ENCRYPT payload fields?  Or is there inherent protection from
reflection attacks in the actual message flow?

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 Nov 2005 15:56:31 -0600

> I'm afraid you are living in an IKEV2 world where terminology makes

Ah, sorry.

Ok, so I will assume that authorization is out of scope for KINK.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 Nov 2005 17:31:37 -0600

On Tue, Nov 29, 2005 at 06:01:15PM -0500, Chaskiel M Grundman wrote:
> >4.2.3.  KINK_KRB_ERROR Payload [...]
> >
> >  KINK implementations MUST make use of a KINK Cksum field when
> >  returning KINK_KRB_ERROR and the appropriate service key is
> >  available.  In particular, clock skew errors MUST be integrity
> >  protected.
> 
> The kerberos API, such as it is, does not guarantee that the application 
> will have access to the ticket session key if KRB5KRB_AP_ERR_SKEW is 
> returned from krb5_rd_req. neither mit krb5 nor heimdal return the 
> decrypted ticket if krb5_rd_req fails. (current releases of heimdal do not 
> check for clock skew in krb5_rd_req! This will be corrected in a future 
> release) It does not appear that either implementation updates the keyblock 
> stored in the auth_context until after all authenticator checks are 
> complete, so that copy of the key is not available to the application 
> either.

There is no standard krb5 API...

> While implementation concerns like this are not usually critical, in this 
> case, I think they should be considered, since it is far more likely that 
> this part of the spec will be ignored than the kerberos implementations be 
> extended to make it possible for kink implementations to conform to it.

...but I tend to agree.

Ultimately some error notifications simply cannot be integrity
protected, so initiators must be prepared to receive such notifications
and deal with them, either by giving up early or retrying with a
timeout.  Attempting to do better than Kerberos V itself does for error
messages seems likely to create API problems.

The value of protecting skew error messages is this: clients can work
around server-side skew when otherwise they could not.

Such a feature too would require API work: krb5_rd_rep*() would need a
way to output skew between the client and server, and krb5_mk_req*()
would need a skew input (that would have to be used very, very
carefully).

Is it wise for Kerberos V applications to be doing this sort of thing?

And should Kerberos V clients ever correct for skew other than that
between the client and the KDC?

Why can't the servers do their own KDC exchanges to discover server-side
skew?  (Why, for u2u they'd be engaging in such KDC exchanges anyways...)

I'm convinced, I think.  This feature should be removed.

Nico
--

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Wed, 30 Nov 2005 11:42:00 +0900

At Tue, 29 Nov 2005 15:39:04 -0600,
> reflection attacks in the actual message flow?

The KINK_ENCRYPT payload is tied with AP-REQ (or AP-REP) with the
Cksum field.
I thought it is enough to prevent reflection.  Isn't it?

-- 
KAMADA Ken'ichi <[email-masked]>

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Wed, 30 Nov 2005 12:34:46 +0900

At Tue, 29 Nov 2005 17:31:37 -0600,
> Is it wise for Kerberos V applications to be doing this sort of thing?

When I was implementing this part of the spec using MIT krb5 and
Heimdal (when I was not yet involved with editing the draft), it was
much of a bother, though not impossible with accessing the library
internals.  The code is included in
ftp://ftp.kame.net/pub/racoon2/racoon2-20051102a.tgz, but is very
dirty, over-familiar with the library, and fragile with library
upgrades.

On the other hand, rfc1510ter will have checksummed KRB-ERROR.
Doesn't that mean we need API work anyway when rfc1510ter is
standardized, in order to extract key on the failure of krb5_rd_req()?

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Nov 2005 11:07:35 -0600

> reflection attacks in the actual message flow?

Well, I also note stuff like: "[The XID] is not used for replay
protection because that functionality is provided by Kerberos."

But KINK isn't using KRB-SAFE or KRB-PRIV, it's using raw KCRYPTO!

So the only place that KINK gets replay protection for free from
Kerberos V is in the AP exchange.  So, how exactly does KINK get "replay
protection of key management messages," a goal stated in the first
paragraph of the introduction?  Did I miss something?

Another problem is that there seems to be no way of tying a particular
KINK message, making use of a Kerberos V key, to a given AP exchange/
Ticket.  This might be fine for a KE that follows the IKEv1/RFC2401
model, but it seems to me that it isn't fine in an IKEv2/RFC2401bis
world.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 30 Nov 2005 12:24:13 -0500

>>>>> "KAMADA" == KAMADA Ken'ichi <[email-masked]> writes:

    KAMADA> The KINK_ENCRYPT payload is tied with AP-REQ (or AP-REP)
    KAMADA> with the Cksum field.  I thought it is enough to prevent
    KAMADA> reflection.  Isn't it?

I believe so.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Nov 2005 12:59:11 -0600

> paragraph of the introduction?  Did I miss something?

Yes, I missed something: every KINK message has an AP-REQ or AP-REP (or
KRB-ERROR).

The KINK "checksum" field and KINK_ENCRYPT payload use keys derived from
the session key of the Ticket, which would normally mean that Ticket
reuse implies key reuse which brings replay protection into question.
But the presence of an AP-REQ or AP-REP in the KINK message that is part
of the checksum input means that key reuse is not enough to lead to
replays, and the presence of timestamps in the Authenticator and AP-REP
enc part means that the inputs to the checksum cannot be replayed unless
time goes backwards, and the requirement that the AP-REP timestamps
match the AP-REQ timestamps provides replay protection to the client.

This also answers my question about reflection attacks.

Is this analysis correct?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Nov 2005 16:20:13 -0600

>     KAMADA> reflection.  Isn't it?

Yes, I had not noticed that all KINK messages have an AP-REQ, AP-REP or
KRB-ERROR.

Nico
--

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Nov 2005 16:23:15 -0800

> Is this analysis correct?

That's pretty much how I remember it.

		Mike

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Thu, 01 Dec 2005 13:14:31 +0900

Thank you for your review.

At Tue, 29 Nov 2005 12:41:38 -0600,
>    Or did I miss something else?

A responder can become an initiator (with U2U if necessary) and it's
possible to rekey from the responder, but it is not expected in my
opinion.

KINK could disallow the responder to rekey, but still, the responder
can make new SAs (pretending independent of rekeying) and delete old
ones, and it cannot be distinguished from rekeying from the initiator.
So I don't think "disallowing" and "expecting-not-to-do" have much
difference in this case.

>    notification that an SA has expired and traffic needs it to be

KINK is based on IKE(v1) and negotiates SA lifetime (see the first
paragraph of section 3.2 of kink-10), so the initiator should notice
SA expiration and rekey it.

>    and a simple algorithm be recommended for matching principals and

Section 5.3 says that IDs in KINK identify traffic to be protected
(like TSs in IKEv2).  Peer's identifiers are pricnipal names provided
in AP exchange.  (Note that AP_REQ and AP_REP are always exchanged
when negotiating SAs.)

>    principal name can take?  Or are there other forms?  Where are those

That paragraph is poorly worded, sorry.  The string "principal" and
"REALM" in the quoted sentence correspond to the same strings in that
sentence.  So, what I wanted to say was:
  - The returned TGT MUST be a non-inter-realm TGT of the requested
    realm, and
  - The cname/crealm of the TGT MUST match the requested principal.

I'd propose to change the paragraph with this one:

   o  PrincName -- The name of the principal which the initiator want to
      communicate with.  It is assumed that the initiator knows the
      responder's principal name (including the realm name) in the same
      way as the non-User-to-User case.  The returned TGT MUST NOT be an
      inter-realm TGT and it's cname and crealm MUST match the requested
      principal name, so that the initiator can rendezvous with the
      responder at the responder's realm.

For comparison, here is the old one:

   o  PrincName -- The name of the principal which the initiator want to
      communicate with.  It is assumed that the initiator knows the
      responder's principal name (including the realm name) in the same
      way as the non-User-to-User case.  When the requested principal is
      "principal@REALM", the responder MUST return a ticket whose server
      and client principals are "krbtgt/REALM@REALM" and
      "principal@REALM" respectively, so that the initiator can obtain a
      User-to-User service ticket at the KDC of the responder's realm.

>    GSS-API exported name token header.

I don't have noticed it wasn't defined.  Thank you for pointing it
out.  I assumed "unparsed" representation, so your deal sounds good
to me.