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

["Medvinsky, Sasha (SD-EX)" <SMedvinsky@xxxxxx>]

Ken,

I am sorry if my email was confusing in that regard - I probably said that
it is easier to implement a "server", which definitely did not mean the KDC.
I agree that what I proposed has no effect on the development of the KDC.  I
would say that a general-purpose KDC should implement U2U regardless.

I was talking about a Kerberized service, not a KDC.  This is a Kerberized
service that accepts AP Requests and responds with AP Replies.  I was
proposing that a Kerberized service is able to initiate Kerberized key
management without the need to obtain (U2U) tickets for its clients.

Sasha.


> -----Original Message-----
> From: Ken Hornstein [mailto:kenh@xxxxxxxxxxxxxxxx]
> Sent: Monday, November 13, 2000 8:28 AM
> To: Medvinsky, Sasha (SD-EX)
> Cc: 'ietf-kink@xxxxxxxx'
> Subject: Re: alternative to user-to-user Kerberos in KINK
> 
> 
> >This includes both AS_REQ and TGS_REQ.  In my proposal, a 
> Kerberized server
> >would not have to generate either.  The key management 
> protocol between the
> >IPSec peers is not Kerberos anyway - it just utilizes 
> Kerberos objects for
> >authentication.
> 
> I understand that, but one of your justifications is that it's easier
> to develop a KDC that doesn't have to implement U2U tickets.  My point
> is:
> 
> a) I'm not convinced it's significantly easier
> b) Such a KDC couldn't claim to implement the Kerberos protocol
> 
> So I don't think this is a very good argument.
> 
> --Ken
>