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

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

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.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, November 21, 2000 7:37 AM
> To: [email-masked]
> Cc: Jan Vilhuber; Medvinsky, Sasha (SD-EX); Derek Atkins; 'Michael
> Thomas'; [email-masked]'
> Subject: Re: alternative to user-to-user Kerberos in KINK
> 
> 
> Bill Sommerfeld writes:
>  > > 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: Michael Thomas <[email-masked]>
Date: Mon, 27 Nov 2000 14:28:57 -0800 (PST)

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