Subject: Re: [Fwd: Re: Submission of draft-ietf-cat-iakerb-08.txt to IESG]

From: Jeffrey Altman <[email-masked]>
Date: Wed, 16 Oct 2002 23:52:13 EDT

> >In response to Martin's most recent complaint, I am send this response 
> >Jonathan Trostle sent to me early this morning before the note from Martin. 
> >As the krb-wg chair, the way I see it, Martin is the only one with complaining,
> >and that draft should move forward.
> >[...]
> 
> Alright, I think I've got to chime in here (not as a document author,
> but as a disinterested third party).

Another disinterested third party ...

> I read Martin's issues.  Since I'm not nearly the GSS-API expert
> that he is, I can't provide good comments on the GSS-API architechture
> issues ... but the more that I think about it, the more I have to
> wonder if doing IAKERB makes sense _in the context of GSS-API_.
> I mean, does GSS-API _really_ add any value here?  It seems to be
> solely used as a transport mechanism, and I personally think it's
> not the best choice as a transport mechanism.  If the goal is to maybe
> use IAKERB, but also maybe use another of GSS-API mechanism, I could
> see where it would make sense ... but I am having a hard time coming up
> with a case where you would want to do IAKERB and _another_ GSSAPI
> mechanism to the same service.
> 
> If the goal is to get SPNEGO, well, shoot ... I think that's adding a
> bunch of baggage that you don't need ... take the features you need from
> SPNEGO and put them in the protocol directly (since I'm not sure you could
> even use an off-the-shelf SPNEGO implementation with this).
> 
> If the goal is to use a standardized API, I think you're going to have
> to provide some IAKERB-specific extension to actually _use_ the dang
> thing, so any value you get from GSS-API goes out the window.
> 
> Just my $0.02.
> 
> --Ken

I have come to trust Martin's expertise when it comes to GSS-API.
Since there are so few real experts with experience in multiple
implementations it becomes difficult to argue with his concerns.

It seems to me that one motivating factor behind the use of SPNEGO
GSSAPI to access KRB5 is to allow a specific implementation to rely on
the existing software architectures provided on a specific platform.
Does this make it wrong to use SPNEGO?  No.  But does it make it right
to require it?  How many implementations of SPNEGO GSSAPI are there in
Kerberos 5 implementations?  Is there any opensource implementation?

It would seem to me that if the likelihood of a second implementation
is next to nil; that the document should go forward as an Experimental
RFC and not Standards Track.  These comments should be taken with a
huge grain of salt because I do not consider myself an expert with
regards to this draft.

 - Jeff