Subject: Re: alternative to user-to-user Kerberos in KINK

From: Derek Atkins <[email-masked]>
Date: 20 Nov 2000 10:30:24 -0500

"Medvinsky, Sasha (SD-EX)" <[email-masked]> writes:

> Also, the client should really have an Access Control List of the servers it
> wants to talk to and would not normally respond to a request from a server
> it doesn't know about.  Even if a client did respond to any such server -
> the KDC has only a limited number of them in its database.

This doesn't make sense in the KINK framework.  KINK is meant as a
peer-to-peer protocol.  You cannot expect a KINK Peer to necessarily
know what other peers to expect to talk to it.  I think you are
applying PacketCable architecture requirements to KINK, in a way that
those requirements do not apply.

-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      N1NWH
       [email-masked]                        PGP key available

---

From: "Medvinsky, Sasha (SD-EX)" <[email-masked]>
Date: Wed, 22 Nov 2000 20:47:35 -0500

I agree with Mike.  With Kerberos upgraded to 3-DES or AES, tickets could
safely last for weeks - which improves system scalability, you don't have to
contact the KDC as often.  Tickets may also be used for some purpose other
than IPSec.  The lifetime of SAs should not be tied to the ticket lifetime
(although they can't exceed it).

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, November 21, 2000 8:04 AM
> To: Derek Atkins
> Cc: [email-masked]; Jan Vilhuber; Medvinsky, Sasha (SD-EX);
> 'Michael Thomas'; [email-masked]'
> Subject: Re: alternative to user-to-user Kerberos in KINK
> 
> 
> Derek Atkins writes:
>  > If you're using user-authentication, then yes, you should 
> keep it up,
>  > as long as your TGT is valid.  Once the TGT expires, you 
> can let the
>  > connection drop.
> 
>    I don't think I agree. The current draft has a lifetime of
>    the SA which may be shorter than the length of the service
>    ticket. This is probably useful if your sessions are 
>    plentiful, random and short lived. Using a short lifetime
>    mitigates the need to explicitly delete SA's.

---

From: "Walker, Jesse" <[email-masked]>
Date: Mon, 27 Nov 2000 10:44:29 -0800

Mike,

You have proposed a very good start. Here are some comments.

a. The document needs to specify a way to identify who is indeed the
rekeying initiator in cases of a tie. (IPXWAN totally orders IPX addresses
and then arbitrarily decrees the larger of the two wins; perhaps we employ
something similar.)

b. If KINK rekeying works like IKE rekeying, in that each peer has to
contribute nonces and the like as entropy for computing the new SA keys, it
is not evident that (2) below is correct. This is because the responder does
not know that the initiator can compute the correct SA keys for the new SA
until after it knows the peer has received its CREATE REPLY; it will be
sending traffic into a black hole if the CREATE REPLY is lost. The responder
should indeed receive on both old and new SA as (2) suggests, but perhaps it
may be better to continue sending on the old send SA until the DELETE from
the initiator arrives. Then if its CREATE REPLY never arrives, communication
can at least continue until the SA key expires. (In a two-phase commit
protocol, you don't commit until phase 2.)

c. If you buy (b) above, then the initiator needs a retry timer for its
CREATE (to try to ellicit a CREATE REPLY), and the responder needs a retry
timer for CREATE REPLY (to ellicit a DELETE). I think (3) is correct or
almost correct in the case it actually receives a CREATE REPLY: the
initiator sends on the new SA, but receives on both the old and the new. It
knows the responder knows the keys for the new SAs, because it received the
CREATE REPLY. But it can't do away with the old SA until it receives the
DELETE REPLY from the responder (or key expiry), because it doesn't know
that the responder has comitted to use the new SAs. I do not think this is
optional behavior; I think it is mandatory to make interoperability a
possibility.

d. What seems optional is the responder could send a DELETE REPLY and delete
its old SAs if it receives traffic from the initiator on the new SA; this
says conclusively that the peer received its CREATE REPLAY, because it is
protecting its traffic under the new SPIs and keys associated with the new
SA.

Likewise, the initiator can finally delete its old SAs if it receives
traffic on the new SA. This is conclusive evidence that the responder has
received either its DELETE REPLY or noticed that the new SA is in use.

This optional provision will allow progress if the DELETE/DELETE REPLY
messages are all lost but the IPsec datagrams can still get through. It is
optional because retries of the CREATE REPLY and DELETE messages should
eventually cause convergence if the peers are still reachable to each other.

e. We don't have any behavior for when an expected reply never arrives.
Presumably we want to continue using the old SAs until their keys expire,
but this is counter to the decisions discussed above about when to start
sending on the new SA. So maybe there isn't a retry limit on DELETEs? Or
maybe the reasoning of when to begin sending on the new SA is wrong?

-- Jesse

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Wednesday, November 22, 2000 9:22 AM
To: Walker, Jesse
Cc: 'Michael Thomas'; [email-masked]'
Subject: RE: alternative to user-to-user Kerberos in KINK 

OK, I'm obviously not up to speed on the rekeying
wars and I don't remember the details of the
jenkins draft.  I'm also not sure what, in
particular, was the hole that so many people drove
through. Showing my ignorance, if it's only a
matter in KINK of also describing how the
selectors are processed when you have two
identical ones, could we just say that you
choose the newest one to send on? Does this
actually even matter?

Thus to rekey, the _rekeying_ initiator would
CREATE a new SA on SPI Y, and DELETE the old
SPI on X. During the transition, there are
a few conditions:

0) The CREATE has not been sent; both initiator
   and responder MUST process on the old SPI
   (ie, it's the normal steady state of the
   previous SA).
1) The CREATE REPLY has not arrived; the
   initiator MUST consider only the old SPI for
   sending and receiving traffic.
2) The DELETE has not arrived; the responder
   MUST choose the new SPI if there are two
   flow specs which are identical for outgoing
   traffic and MUST accept incoming traffic on
   the old SPI. The initiator MUST send on the
   new SPI, but accept data on both SPI's.

   The following two are optional; the initiator
   MAY allow the old SPI to time out:

3) The DELETE REPLY has not arrived; same as
   (2) for the responder. For the initiator,
   it MUST accept traffic on either SPI, but
   only send on the new SPI.
4) The DELETE REPLY is received; same as (0).

Am I out in left field here?

	 Mike

Walker, Jesse writes:
 > Mike,
 > 
 > I think sidestepping the issue is a fundamental strategic mistake that
will
 > render KINK far less relevant than it could otherwise be.
 > 
 > Rightly or wrongly, my belief is that one of the justifications for
KINK's
 > existence is a number of interoperability issues could never be resolved
for
 > IKE. In particular, this issue was never fully addressed for the
IKE/IPsec
 > interaction (it is usually referred to as the rekey issue). My
recollection
 > is that by the time Tim Jenkins finally published a reasonable way to
 > resolve the problem, vendors had already implemented 8 conformant but
 > non-interoperable algorithms for accomplishing the coordination, and it
 > thereby became infeasible to get any consensus on how to move forward,
since
 > no one was willing to give up their own approach.
 > 
 > With KINK there is a clean slate, and if the issue is addressed up front,
 > there is a far, far better chance for genuine interoperability. It is not
 > hard to specify an algorithm--the implementation history of the IKE/IPsec
 > interaction gives us at least 8 to choose from! All the spec should do is
 > specify one and decree once and for all that that's how to do it when
using
 > KINK.
 > -- Jesse
 > Sent: Tuesday, November 21, 2000 8:26 AM
 > To: Walker, Jesse
 > Cc: 'Michael Thomas'; [email-masked]'
 > Subject: RE: alternative to user-to-user Kerberos in KINK 
 > 
 > 
 > 
 > Jesse,
 > 
 > Correct me if I'm wrong, but this sure looks like
 > it's out of the scope of the keying protocol per
 > se. It seems like it would be better to have a BCP
 > or something with base IPsec which defines what
 > the expected behavior ought to be when you have 
 > two SA's with the same flow spec.
 > 
 > 	 Mike
 > 
 > Walker, Jesse writes:
 >  > Mike,
 >  > 
 >  > How, when, and if they choose one is precisely the issue. This was
 > something
 >  > left unspecified in the interaction between IKE and IPsec, and as a
 > result
 >  > vendors implemented conformant but non-interoperable solutions to this
 >  > problem.
 >  > 
 >  > -- Jesse
 >  > 
 >  > Sent: Tuesday, November 21, 2000 7:55 AM
 >  > To: [email-masked]
 >  > Cc: Jan Vilhuber; Derek Atkins; Medvinsky, Sasha (SD-EX); 'Michael
 >  > Thomas'; [email-masked]'
 >  > I guess I don't quite grok the dilemma here. Initiator and
 >  > responder only matter when setting up/tearing down the
 >  > SA. Though perhaps not optimal, there shouldn't be a
 >  > problem having two SA's with the same flow spec between
 >  > two hosts -- they just needs to chose one. Assuming
 >  > that either party can tear down an existing SA (which
 >  > now that I think about it may not work in the current
 >  > draft), you have the situation where either side can
 >  > manage the SA's any way they see fit.
 >  > 
 >  > What am I missing?
 >  > 
 >  > 	Mike
 >  > 
 >  > Bill Sommerfeld writes:
 >  >  > > It might also be worthwhile to do what IKE failed to do, which is
to
 >  > spell
 >  >  > > out re-keying behaviour. If we spell out that the original
initiator
 >  > needs to
 >  >  > > be the one to reinitiate a re-key, then problems won't arise.
 >  >  > 
 >  >  > How can that possibly work in a non-VPN, non-connection-oriented
 >  >  > scenario?  Does the initiator *always* recreate an expiring SA,
just
 >  >  > in case the peer might want to send something in the future?  
 >  >  > 
 >  >  > Do you engage in some sort of layering violation, peeking into TCP
to
 >  >  > see if there are still open connections or tracking connection
state
 >  >  > in the IP layer?
 >  >  > 
 >  >  > Or do you not care about long-lived connections, and let them drop
if
 >  >  > the initiator doesn't have the session up?
 >  >  > 
 >  >  > I'm not happy with any of these alternatives.. the responder must
be
 >  >  > able to turn around and reinitiate back to the initiator..
 >  >  > 
 >  >  > 					- Bill
 >  >  > 
 >  > 
 >  > 
 > 
 >

---

From: "Medvinsky, Sasha (SD-EX)" <[email-masked]>
Date: Mon, 27 Nov 2000 18:00:05 -0500

In that draft, it is always the client that specifies the new key or
password.  You can always recommend that the client uses the session key as
a seed into its pseudo-random number generator.

Sasha.

> Sent: Monday, November 27, 2000 2:29 PM
> To: Medvinsky, Sasha (SD-EX)
> Cc: 'Michael Thomas'; [email-masked]; Jan Vilhuber; Derek
> Atkins; [email-masked]'
> I'm all for begging, borrowing or stealing. I only
> scanned the draft over quickly -- is there a way
> for the KDC to specify the password? That seems
> like it would give the best password source since
> by definition the KDC's RNG better be good.
> 
> 		  Mike
> 
> Medvinsky, Sasha (SD-EX) writes:
>  > Mike,
>  > 
>  > I don't think there is a need for an new enrollment 
> protocol - it has been
>  > defined already.  An authenticated PKINIT client would get 
> a service ticket
>  > for an "Change Password Service" and then set its 
> symmetric service key with
>  > an existing protocol in
>  > 
http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-set-passwd-03.tx
 > t.
 > 
 > Despite the title of the draft, it allows updates to service keys as well
as
 > client passwords.  Although the draft was originally intended for updates
to
 > an existing key, there is no reason why it couldn't create a new key as
 > well.
 > 
 > Sasha.
 > 
 > > Sent: Tuesday, November 21, 2000 7:37 AM
 > > Cc: Jan Vilhuber; Medvinsky, Sasha (SD-EX); Derek Atkins; 'Michael
 > >  > > Unless you want to do u-u, I guess, which complicates 
 > > things. I'd prefer to
 > >  > > have them enrolled.
 > >  > 
 > >  > depends on how you measure complexity.  i suspect a new enrollment
 > >  > protocol would be more complex than just using u-u.
 > > 
 > >    We're a little bit afield of KINK here, but...
 > > 
 > >    I've been thinking that the enrollment _protocol_
 > >    doesn't need to be complicated at all: it could
 > >    just be a normal PKINIT Kerberos AS-REQ, perhaps
 > >    with a flag that tells the KDC to enroll the
 > >    principal with the session key that it puts into
 > >    the TGT. Perhaps it can even be done without an
 > >    explicit flag. That would have the nice property
 > >    that you'd also get symmetric key refresh basically
 > >    for free, though it does force the KDC to deal with
 > >    previous and next keys instead of just one key.
 > > 
 > >    That said, I think that the harder problem is
 > >    going to come down to all of the implications of
 > >    distributed database propogation on the KDC's.
 > >    That, of course, is an application problem though.
 > > 
 > > 	    Mike
 > > 
 >

---

From: "Medvinsky, Sasha (SD-EX)" <[email-masked]>
Date: Tue, 28 Nov 2000 20:49:39 -0500

Mike,

The DoS attacks do not apply in the case where clients have a list of
servers that they are talking to, where by client and server I mean Kerberos
client and application server.  In other words, a client will reject a
WakeUp if the server name is not in its ACL.

This works fine in PacketCable and so if it is not generally useful in KINK,
we would leave it as a PacketCable-specific extension that addresses issue
#2 you have listed below.  Or maybe it could be a separate draft under KINK
called something like "client-server profile and extensions to KINK".

Sasha.

> Sent: Tuesday, November 21, 2000 10:05 AM
> Cc: [email-masked]'; 'Derek Atkins'; 'Michael Thomas';
> [email-masked]'
>  > All I was saying is that although you can do peer-to-peer 
> authentication
>  > with Kerberos, you shouldn't require it for an 
> architecture where you don't
>  > have a peer-to-peer relationship.
> 
>    I think client/server and peer-peer is somewhat
>    misleading. Colloquially, client/server means that
>    clients initiate transactions, not servers. Peer
>    to peer means that no such distinction is drawn.
> 
>    I don't think that Kerberos, per se, has much to
>    say on that front because "client" machines can
>    host services and "server" machines can act as
>    clients, so it appears to _mostly_ be a distinction
>    without a difference.
> 
>    There are only two things that I know of which
>    requires me to qualify myself above:
> 
>    1) clients may authenticate using PKINIT which
>       leads to the U-U/enrollment debate
>    2) it may be a worthwhile optimization to allow
>       machines which subtend large numbers of users
>       (let's not call them clients, because that's
>       misleading) to have the abilty to require
>       the high fanout devices to get and maintain
>       tickets, thus avoiding duplication of effort
>       and storage.
> 
>    #1 seems like we may be headed toward consensus
>    that Matt's idea of enrollment may be a reasonable
>    idea to pursue for PKinit. U-U should also be a
>    fallback. The dispute seems mostly
>    over #2. I still feel really uneasy about the
>    inherent DoS attacks. I'm also not convinced that
>    the real-life use of KINK cannot avoid this dilemma
>    for the most part.
> 
>    Given the downside, I think that waiting to see
>    real implementation experience would be a more
>    prudent course of action.
> 
> 		  Mike
>