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

From: "Medvinsky, Sasha (SD-EX)" <[email-masked]>
Date: Mon, 20 Nov 2000 15:48:09 -0500

As I replied to Mike's email, this client enrollment would eliminate some of
the disadvantages of the user-to-user mode (e.g. adding user
policy/authorization into the tickets), but would still require a server to
obtain/maintain tickets for its clients.  I also listed benefits of not
having to do that.

Sasha. 

> -----Original Message-----
> From: Jan Vilhuber [mailto:[email-masked]]
> Sent: Monday, November 20, 2000 11:55 AM
> To: Derek Atkins
> Cc: Medvinsky, Sasha (SD-EX); 'Michael Thomas'; [email-masked]'
> Subject: Re: alternative to user-to-user Kerberos in KINK
> 
> 
> As Michael pointed out a few weeks ago, if we assume some 
> sort of enrollment
> protocol, that creates a shared secret between pkinit clients 
> and KDC, then
> the pkinit case becomes the general case, i.e. anyone can 
> initiate to a
> pkinit client, after the pkinit client has 'enrolled' with a 
> KDC (and you
> wouldn't even need u-u).
> 
> Rather than add complexity to KINK, I would prefer we put together an
> enrollment proposal, either within THIS group, or propose it 
> in the kerberos
> WG.
> 
> jan
> 
> 
> 
> 
> On 20 Nov 2000, Derek Atkins wrote:
> 
> > I consider it out of scope because it adds uncesseary complexity to
> > the general KINK protocol.  It is complexity that perhaps 
> PacketCable
> > needs (or, more likely, wants), but it is not complexity that makes
> > sense, IMHO, for a general-purpose IPSec key management 
> protocol.  It
> > either forces us to add options to the protcol (thereby adding
> > complexity), or it forces us to always handoff authentication and
> > design a secure way to doing so (also adding complextity).
> > 
> > The problem is that there is no way to always know a priori 
> whether a
> > peer is a PKINIT peer (where PKINIT peer is one that only 
> has a TGT to
> > work with, which implies normal users as well as PKINIT-based hosts)
> > or a normal peer.  In order to reduce complexity in KINK we have to
> > optimize for either PKINIT or non-PKINIT peers.  I believe that
> > non-PKINIT peers are the "normal" case (namely, hosts with krb5
> > keytabs).
> > 
> > Based upon this assumption (we should probably discuss whether this
> > assumption has merits), we should optimize the protocol for
> > non-PKINIT.  This implies that we should try normal Kerberos, and if
> > we cannot obtain an AP_REQ, then we try U2U.  It means an extra
> > round-trip to the KDC in the case of a PKINIT peer the first time we
> > try to authenticate.  We can always cache U2U tickets.  Alternately,
> > if we optimize for PKINIT peers, we should just use U2U at 
> all times.
> > 
> > However, in neither case do we try to offload 
> authentication from one
> > entity to the other.  The initiator is always the initiator, the
> > responder is always the responder.  Never are we trying to have the
> > initiator tell the responder to initiate authentication.
> > 
> > -derek
> > 
> > "Medvinsky, Sasha (SD-EX)" <[email-masked]> writes:
> > 
> > > What makes this "hand-off of authentication to clients" 
> out of scope for
> > > KINK?
> > > 
> > > Sasha.
> > > 
> > > > -----Original Message-----
> > > > From: Derek Atkins [mailto:[email-masked]]
> > > > Sent: Monday, November 20, 2000 11:11 AM
> > > > To: Medvinsky, Sasha (SD-EX)
> > > > Cc: 'Michael Thomas'; [email-masked]'
> > > > Subject: Re: alternative to user-to-user Kerberos in KINK
> > > > 
> > > > 
> > > > "Medvinsky, Sasha (SD-EX)" <[email-masked]> writes:
> > > > 
> > > > > Derek,
> > > > > 
> > > > > KINK is a peer-to-peer protocol, but Kerberos is not.  A 
> > > > client-server
> > > > > architecture is more commonly used with Kerberos than the 
> > > > user-to-user case.
> > > > > I would say Kerberos looses some of its advantages when it 
> > > > is used in the
> > > > > user-to-user mode.
> > > > > 
> > > > > There is nothing special about the PacketCable 
> > > > architecture, except that it
> > > > > assumes a client-server architecture and I don't think that 
> > > > we should
> > > > > exclude it from KINK.
> > > > > 
> > > > > Sasha.
> > > > 
> > > > The special case of PacketCable is that servers may 
> need to initiate
> > > > IPSec with clients, but you don't want to have the 
> server store keys.
> > > > So, you want to be able to securely "handoff" the 
> authentication to
> > > > the clients, via a wakeup or other mechanism.  What 
> this amounts to is
> > > > the application server telling the application client 
> something like
> > > > "I want to authenticate to you, so initiate an 
> authentication to me".
> > > > This is particularly a problem with PKINIT entities, as 
> you cannot
> > > > obtain an AP_REQ for a PKINIT ID.
> > > > 
> > > > I believe that the latter problem is one that KINK will 
> have to solve
> > > > (most likely by using user-2-user, initiated by either party).
> > > > However, I do believe that the former is out-of-scope 
> for KINK.  I
> > > > don't think KINK should try to worry about forcing the 
> initiator of
> > > > sessions.
> > > > 
> > > > -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
> > > > 
> > 
> > -- 
> >        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
> > 
> 
>  --
> Jan Vilhuber                                            
> [email-masked]
> Cisco Systems, San Jose                                     
> (408) 527-0847
>

---

From: Jan Vilhuber <[email-masked]>
Date: Mon, 20 Nov 2000 13:17:20 -0800 (PST)

On Mon, 20 Nov 2000, Medvinsky, Sasha (SD-EX) wrote:

> obtain/maintain tickets for its clients.

Which gets back to the fact that KINK is for peer-to-peer, so any server is a
client and any client is a server. So they all need to be principals in the
KDC, so we need to enroll them.

Unless you want to do u-u, I guess, which complicates things. I'd prefer to
have them enrolled.

jan

> I also listed benefits of not
> having to do that.
> 
> Sasha. 
> 
> 

 --
Jan Vilhuber                                            [email-masked]
Cisco Systems, San Jose                                     (408) 527-0847

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 20 Nov 2000 16:25:15 -0500

> Unless you want to do u-u, I guess, which complicates things. I'd prefer to

depends on how you measure complexity.  i suspect a new enrollment
protocol would be more complex than just using u-u.

					- Bill

---

From: Jan Vilhuber <[email-masked]>
Date: Mon, 20 Nov 2000 13:31:15 -0800 (PST)

On Mon, 20 Nov 2000, Bill Sommerfeld wrote:

> depends on how you measure complexity.

Agreed. I measure it in terms of added complexity WITHIN the same protocol. A
new enrollment protocol may be somewhat complex, but this complexity is
orthogonal to KINK, thus making KINK easier to analyze for security. Adding
more exchanges for corner-cases certainly doesn't help people analyze it for
weaknesses.

> i suspect a new enrollment
But it may be usefull to other people as well. Two semi-complex protocols are
better than one hyper-complex one. In my opinion, anyway.

jan

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 20 Nov 2000 16:38:42 -0500

> more exchanges for corner-cases certainly doesn't help people analyze it for

true.  i've suggested on numerous occasions that KINK should avoid
this problem by always using user-to-user.

					- Bill

---

From: Jan Vilhuber <[email-masked]>
Date: Mon, 20 Nov 2000 13:46:29 -0800 (PST)

> this problem by always using user-to-user.
I guess that's one way. The other is to never use u-u, and force everyone to
be a principal in the KDC. Not being 100% kerberos-expert, this appeals to me
more, especially in light of the fact that a pkinit-enrollment may be usefull
in other protocols/occasions (I'm guessing).

jan

---

From: Derek Atkins <[email-masked]>
Date: 20 Nov 2000 17:31:13 -0500

> in other protocols/occasions (I'm guessing).

The problem is that this wont work for, a user being the responder.  A
user would be enrolled in the KDC, but they have a password, not a
keytab.  So, the system would only have a TGT credential to work with
(although a foreign system would still be able to get a "valid"
service-key response from the KDC).

Perhaps we just don't care; or perhaps "users" can only be IPSec
initiators.

-derek

-derek

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 20 Nov 2000 17:37:07 -0500

> Perhaps we just don't care; or perhaps "users" can only be IPSec

That won't work in the general case since many possible uses of ipsec
require peer-to-peer keying.  (or, rather, require either end to be
able to initiate rekeying).

					- Bill

---

From: Derek Atkins <[email-masked]>
Date: 20 Nov 2000 17:57:06 -0500

> able to initiate rekeying).

It works for road-warrior VPNs :)

In other cases, you probably aren't authenticating users to users, or
hosts to users, but rather hosts to hosts.  So I don't think it
matters there, either.  The only case I can truly think of where you
might want to have the user authenticate one end is for a road-warrior
VPN solution, and in that case, no, the server WONT be initiating
anything :)

-derek

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 20 Nov 2000 18:00:51 -0500

> It works for road-warrior VPNs :)

that's nice.

> hosts to users, but rather hosts to hosts.  

This is an unwarranted assumption, and the ipsec implementation i'm
working on doesn't make that assumption.

> So I don't think it matters there, either.  

I think it does.

					- Bill

---

From: Derek Atkins <[email-masked]>
Date: 20 Nov 2000 18:04:08 -0500

Well, clearly we disagree. :)

We'll see what the group at large thinks.

-derek

---

From: Jan Vilhuber <[email-masked]>
Date: Mon, 20 Nov 2000 15:07:53 -0800 (PST)

> VPN solution, and in that case, no, the server WONT be initiating
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.

That's not to say that initiation can not be in both directions, but if
someone will be a responder, that host/user MUST be a principal in the KDC.
That covers your road-warrior example, as those users may NOT need to be
principals, assuming they will always initiate and will always initiate a
re-key.

Whether the semantics I propose above are the correct ones, or not, I think
this should be in the draft somewhere to avoid ambuguities in rekeying which
we now have to deal with in IKE (See Jenkins draft).

jan

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 20 Nov 2000 18:22:29 -0500

> 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: Derek Atkins <[email-masked]>
Date: 20 Nov 2000 18:33:20 -0500

> in case the peer might want to send something in the future?  

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.

The user has to reauthenticate themselves to the system anyways;
alternatively they can re-initialize IPSec by hand at the same time
that they get new tickets.

> the initiator doesn't have the session up?

If your user TGT expires, you HAVE to let them drop anyways.  Unless
you're expecting to have a UI violation where the kernel will
asynchronously pop up some UI function to ask the user for
username/password in order to obtain a TGT when it's expired?

So, in the user-auth case, no, I don't care about long-lived
connections.  They can't exist without user intervention.

> able to turn around and reinitiate back to the initiator..

And I think limiting this particular case to host-host authentication
is a reasonable protocol limitation.

-derek

---

From: Jan Vilhuber <[email-masked]>
Date: Mon, 20 Nov 2000 15:36:45 -0800 (PST)

> in case the peer might want to send something in the future?  
I didn't say it was perfect. ;)

> see if there are still open connections or tracking connection state
No. We do none of that. We don't even do what I described above. It's just an
idea. If it doesn't pan out, it doesn't pan out.

> the initiator doesn't have the session up?
If the initiator is a road-warrior, whose dynamic-IP connection went down as
well (due to timeout or whatever), then it might not matter.

Your objection is valid, though.

jan

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 20 Nov 2000 18:36:22 -0500

> as long as your TGT is valid.  

Why?  In many cases, we might have nothing further to send to the peer..

> username/password in order to obtain a TGT when it's expired?

BTW, that would be the key management daemon, not the kernel..

					- Bill

---

From: Derek Atkins <[email-masked]>
Date: 20 Nov 2000 18:50:56 -0500

> BTW, that would be the key management daemon, not the kernel..

It's still a system daemon, not a user app.  So, how do you get the
user's credentials there anyways?  And how do you report to the user
when those tickets expire?

-derek

---

From: Jan Vilhuber <[email-masked]>
Date: Mon, 20 Nov 2000 15:57:55 -0800 (PST)

> Why?  In many cases, we might have nothing further to send to the peer..
So you an idle-timer. Host-to-host probably doesn't want this, but vpn
probably will.

jan

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 20 Nov 2000 18:59:09 -0500

> So you an idle-timer. Host-to-host probably doesn't want this, but vpn

That only detects that we wanted to send something recently, not that
the peer might want to send us something in the future...

						- Bill

---

From: Jan Vilhuber <[email-masked]>
Date: Mon, 20 Nov 2000 16:04:00 -0800 (PST)

> the peer might want to send us something in the future...
As I said: In a dial-up/vpn scenario that doesn't matter. If you have
something to send, and the link has gone away (or the SA's have died, which
amounts to the same thing), you're out of luck anyway.

jan

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 20 Nov 2000 19:10:49 -0500

> user's credentials there anyways?  

I can think of a number of ways, one of which is a per-user
authentication proxy which is connected to the key management daemon
at login time, which can run with a UI.

				- Bill

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Nov 2000 07:37:26 -0800 (PST)

> 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: Michael Thomas <[email-masked]>
Date: Tue, 21 Nov 2000 07:40:10 -0800 (PST)

> this problem by always using user-to-user.

   User-User pretty much forces the normal create
   SA case to be a  two round trip affair. One of
   the goals here is to reduce keying latency, and
   cutting out round trips is an obvious means to
   that goal.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Nov 2000 07:55:13 -0800 (PST)

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Nov 2000 08:04:04 -0800 (PST)

> as long as your TGT is valid.  Once the TGT expires, you can let the

   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.

 > username/password in order to obtain a TGT when it's expired?

   What's wrong with this? That's all that getty is, in some sense.
 
 > connections.  They can't exist without user intervention.

   Is a smart card "user auth"?
 
 > is a reasonable protocol limitation.

   Well, _I_ don't think we should be so limited, but
   fortunately, this looks like an implementation issue,
   not a protocol issue.

	 Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Nov 2000 08:10:18 -0800 (PST)

> when those tickets expire?

   C'mon, Derik. Netscrape manages to figure out how to prompt
   the user for credentials... this doesn't seem like rocket
   science. The important interface is the kernel/user boundary;
   once it's outside of the kernel, it's not very difficult 
   to imagine an event driven this or that that could handle this
   quite cleanly.

		Mike

---

From: Derek Atkins <[email-masked]>
Date: 21 Nov 2000 12:21:44 -0500

>    to imagine an event driven this or that that could handle this

Netscrape is a single application.  I haven't seen it interact
with IPSec.

I'm not saying that we can't register a user-agent with the key
management daemon to ask for user input.  IKE-XAuth certainly requires
something like that.  I'm just pointing out implementation issues.

There's more than just kernel/user boundary, there's also a
daemon(background-process)/UI boundary.  No, it's not insurmountable.
But I also don't think a protocol like this should necessarily mandate
a particular UI requirement.

-derek

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Nov 2000 09:26:15 -0800 (PST)

> a particular UI requirement.

   Well, I don't either but the good news is that nobody's
   mandating anything on that count. Everybody is entitled
   to their own way of getting KINK key(s).

      Mike