Subject: KINK: Call for Presentations and Agenda Items in London

From: Derek Atkins <[email-masked]>
Date: 01 Jul 2001 10:22:17 -0400

If you have any KINK issues that you would like to discuss, or a
presentation about KINK that you would like to make, please send me
mail to get onto the Agenda for London.

Thanks,

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Michael Thomas <[email-masked]>
Date: Thu, 5 Jul 2001 16:41:42 -0700 (PDT)

Hi all,

In implementing the spec, I've found a few things
thus far that are probably worth bringing up. I've
not done any integration with IPsec yet, so that's
still an open question as to how well that part of
the (compromise) spec is holding up.

1) Errors: we have very few protocol level
   errors. I've noticed a lot of things which
   which should generate an error, but the only
   have KINK_PROTOERR, which is sort of a large
   hammer. At the very least, I think we ought to
   have an internal error which means: "I'm screwed
   up, not you". Keeping the unencrypted errors
   rather opaque may be considered a feature
   though, but it's going to make interop's
   somewhat harder. Maybe good loggers is
   sufficient though.

2) Currently there's no restriction on what the
   service principal's name is in the draft. I
   think we probably ought to make up one and
   make it a SHOULD. I don't see any reason why
   this should be a MUST though. How about of the form:

     ipsec/princ.com/@REALM.COM

3) We're not supporting K4, right? If not, we
   should probably be explicit in the draft.

4) In doing the KINK message checksum, I had a 
   question of which keyblock to use for hash.
   In the MIT code, there's:

   auth_context->keyblock

   and several others, which I assume is the 
   keyblock for the service key. I believe that
   this is the intent of the draft, but we should
   probably be specific if it's not already.

5) While doing the KINK_ENCRYPT Payload, I think
   I've got the proper etype, but the MIT encryption
   function (krb5_c_encrypt) has an optional IV. 
   Unfortunately, the spec says nothing about
   IV's, and I suspect that this function is
   adding an 8 byte IV for me (des-cbc).

   Something needs to be done here, probably both
   in the draft and probably my code, and I'm open
   to suggestions. If the krb5_c_encrypt function
   is doing something really standard without an
   IV (sew me, I'm not a crypto d00d) maybe it
   will be sufficient to just add a few words
   about this. Also, the spec needs to make
   mention of the padding issues (see below).

6) Some of the issues around payload alignment
   were not clear. I've fixed them in the draft
   to make the headers always reflect the true
   size of the payload, but that when you add a
   new payload it MUST start on a .long boundary.

   There's only other payload which is screwy
   which is GetTGT Reply payload. Which has two
   variable length strings in it (realm, TGT).
   Should we extend the rule above, or should 
   we try to be a little bit more space conscious
   since this only needs to be .align 2'd? What
   does IKE do in this situation? 

	    Mike

---

From: Ken Raeburn <[email-masked]>
Date: 17 Jul 2001 11:53:42 -0400

>      ipsec/princ.com/@REALM.COM

Nitpicking: The second slash indicates a three-component name, with
the third component empty.  You probably meant
"ipsec/[email-masked]"?  (That still assumes you've got a
hostname and not just an IP address.)

I think SHOULD is probably the right level; use of another principal
like host/foo could be negotiated by the host admins if the
implementations permit.

>    should probably be explicit in the draft.

Discussing krb5 and failing to mention krb4 is probably sufficient,
IMHO, but explicitly stating it wouldn't be a bad thing.

>    probably be specific if it's not already.

That would be the Kerberos "session key".  Generally we recommend use
of the "subsession key" (or "subkey") when appropriate (e.g., on a
per-TCP-stream basis); different attempts at authentication using the
same credentials can yield different subsession keys but only one
session key.  (Note that the terminology used in the Kerberos specs
and documentation is not always consistent.)

The draft does talk about putting stuff into the subkey field, and
that stuff is not a key.  (It's also underspecified -- what "keytype"
value is used when passing around a nonce?)  This strikes me as a poor
idea, since in the existing Kerberos work, it is always a key.  With
this usage, an implementation cannot provide just an on/off flag for
that field (yes, do generate a subkey with as much entropy as
possible, or no, don't use any subkey), or that plus an enctype
parameter, but instead must permit that field to be set arbitrarily
under application control.

I'm unclear on why the nonces are exchanged and key derivation done
from them.  Two subkeys can be sent.  While three keys are generated
(K0, K1, K2), the text only mentions using two of them.  Why not
simply use exchanged subkeys?  If there's a problem with this, should
it be addressed in Kerberos itself?

>    mention of the padding issues (see below).

I think a null pointer will do the right thing for the code, and
something about "default initialization vector for the encryption
algorithm" would be right for the spec.

Ken

---

From: Michael Thomas <[email-masked]>
Date: Wed, 18 Jul 2001 03:05:26 -0700 (PDT)

> hostname and not just an IP address.)

   Yes, typo.

 > and documentation is not always consistent.)

   Since the subsession key is not created by the KDC, and
   we have a mandate to use the entropy generated by the KDC
   when creating keying material, would the appropriate thing
   be to create a subkey based off of some one-way hash on
   the session key? See below too.

 > idea, since in the existing Kerberos work, it is always a key.

   This section has been changed to just use the IKE key derivation
   as was agreed last IETF. It currently states:

"KINK uses the same key derivation mechanisms that
 [IKE] uses in section 5.5, which is:

 KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b [ | Nr_b])

 The following differences apply:

 o SKEYID_d is the session key in the Kerberos
   service ticket from the AP-REQ. 

 o Nr_b is optional

 By optional, it is meant that the equivalent of a
 zero length nonce was supplied."

 > it be addressed in Kerberos itself?

   I believe this is a carryover from IKE. We could either
   have used the Kerberos subkey mechanism, or the IKE
   nonce mechanism; the later was what was agreed to last
   IETF. I don't have a strong preference one way or the
   other. As far as three keys go, I believe that was an
   error in the initial draft which was trying to describe
   that B need not add its nonce. This behavior is still
   present, though the example has been nuked.

   In thinking about your comment above about
   subkeys, it seems that what's currently in 
   the text: session key + IKE nonces is doing
   the same job as a subsession key which is 
   derived in part from the session key. a) do
   you agree, and b) is that OK?

 > algorithm" would be right for the spec.

   I haven't actually looked at the lower layer
   crypto code, but is that clear enough? I know
   that would confuse me as to what the default
   initialization vector would be, but I may not
   be the best RFC crash dummy here.

	  Mike

---

From: Ken Raeburn <[email-masked]>
Date: 18 Jul 2001 17:45:22 -0400

>    the session key? See below too.

Maybe.  The problem, as I see it, is that subkey generation should be,
IMNSHO, done by the Kerberos implementation and treated as a black box
by the application protocols (aside from probably getting to choose
the key type).  That certainly isn't explicit in the Kerberos docs
(since they're all about the protocol), and other Kerberos folks may
well disagree with me on that.  So basically, the entropy handling is
a quality-of-implementation issue, and an implementation that didn't
use the session key in the subkey generation would, well, suck. :-)

IIRC, the Kerberos docs actually leave it up to the application
protocol spec to indicate how the session key and subkeys get used.
So providing real honest-to-goodness keys produced by
implementation-defined means (Kerberos library, random nonce
generation, whatever), and feeding them *and* the session key into the
key generation code, instead of using the subkeys directly, would work
fine.  But with such an approach you wouldn't get the fine control
over the actual bits that you rely on in the current draft.

>    you agree, and b) is that OK?

I thought about that a bit too, and it does seem to be doing the same
job.  What I dislike is (a) having the subkey field sometimes contain
a key, sometimes something else that's underspecified in some ways,
and (b) specifying that "something else" with such precision that the
subkey handling has to be exposed to the application layer.  I'd be
happier if we had (a) a spec for passing around keying material in the
subkey field and producing usable keys (of what type?) from it, that
any application protocol writer could use without identifying the
relevant pieces of the KINK application protocol, and (b) a KINK spec
that said "use foo subkey generation technique".

The KINK approach seems to be "don't require anything new of the
Kerberos folks, we'll build on what they've done", but some of the
ideas being kicked around -- exchanging subkey generation material,
incorporating PFS -- are building blocks others could use as well, so
I think bundling it all into one application protocol spec is also not
necessarily the best approach.  Having separate specs for such things
also means it's easier for implementors to provide these extra
building blocks to application writers.

>    be the best RFC crash dummy here.

In general the Kerberos text doesn't talk much about initial vectors
etc, so any such extra parameters needed by an encryption algorithm
have to have default values described as part of their specs.  In
kerberos-revisions, it's a slightly more abstracted and opaque "cipher
state", which can either be initialized or carried over from a
previous operation, though I think in fact we never do the latter; it
can't be set explicitly.  In RFC 1510, there was at least one place
where IV chaining could be done if specified by the application
protocol (and I don't think it was clear whether it could be *set* to
some specified value), though that's been removed in
kerberos-revisions.

---

From: Jonathan Trostle <[email-masked]>
Date: Wed, 18 Jul 2001 16:22:55 -0700

>happier if we had (a) a spec for passing around keying material in the

I agree with you Ken, but we would need someone to write the spec. (which
should live in the Kerberos WG). And given our goal of moving to WG last
call on the KINK spec. in the near future, we would need to have a spec.
fairly soon. 

Jonathan

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Jul 2001 08:16:32 -0700 (PDT)

> use the session key in the subkey generation would, well, suck. :-)

   Ordinarily, I'd agree but KINK is sort of an odd duck
   since it's an amalgam of IKE'ism with Kerberos both of
   which have a fair amount to say about keying. And I've
   argued that PFS, say, is something that would be much better
   handled by Kerberos itself rather than having each app
   have to deal with it itself, but as Jonathan points out
   it's not a current option, and it's fairly straightforward
   how we can inherit it from IKE.

 > over the actual bits that you rely on in the current draft.
 
   Actually, the current draft doesn't need fine control
   at all. It's directly feeding the authctx->keyblock->contents
   into the IKE key derivation as a substitute for the IKE
   main mode SKEYID. This is very straightforward.

 > that said "use foo subkey generation technique".

   The current approach doesn't use the subkey at all,
   favoring the IKE nonces Ni, Nr instead.
 
 > building blocks to application writers.

   Yes, I agree. The Packetcable IPsec and SNMP keying used
   the subkey and it would have probably been a lot more 
   straightforward if there were an RFC to point to which
   has been well thought out rather than having to roll
   your own and wonder whether it was secure. I know that
   we spent a *lot* of time talking about key derivation
   considerations.

 > some specified value), though that's been removed in

   OK. Like I said, it wasn't clear when I was implementing
   this with the MIT code what I should do for the IV. Maybe
   a mention in the spec that "if an initialization vector is
   required for the cipher, the initialization vector must be
   randomly chosen by the KINK encyption routine and added
   in a cipher depended way to the ciphertext"?

	Mike