Subject: Re: WG Last-Call: draft-ietf-cat-lipkey-02.txt

From: Denis Pinkas <[email-masked]>
Date: Mon, 03 Jan 2000 11:32:52 +0100

John,

Back from holidays today.

As you noticed you were the single one raising comments on this
document. You also noticed that Mike advertised that he was changing
position within his company and that he was not sure anymore to be
able to build an implementation of this document.

So I would like to raise the following question: since the situation
has changed form the Washington meeting, does it still make sense to
forward this draft on the Standard Track ?

Would'nt it be safer to progress it on Experimental since there is
no hint at present time that we will get two independent
implementations within a six months time frame, ... maybe not even
one ?

Regards,

Denis

> Thanks, Mike, for the timely update.  I believe that the new
> draft-ietf-cat-lipkey-03.txt responds suitably to the issues identified in
> my message, and no other comments against the draft have so far been posted
> during the WG Last-Call period ending today. Unless other issues are raised
> to the list today, therefore, I'll plan to forward
> draft-ietf-cat-lipkey-03.txt to the IESG on behalf of the WG, requesting
> that it be considered for advancement to Proposed Standard.
> 
> --jl
> 
> > -----Original Message-----
> > From: Mike Eisler [mailto:[email-masked]]
> > Sent: Monday, December 20, 1999 11:59 PM
> > To: 'CAT-WG List'
> > Subject: RE: WG Last-Call: draft-ietf-cat-lipkey-02.txt
> >
> >
> > I've submitted a new i-d (draft-ietf-cat-lipkey-03.txt) with changes
> > incorporating John's feedback. As always,
> >       http://playground.sun.com/~mre/lipkey/
> > archives the latest and previous revisions, with and without
> > change bars.
> >
> >
> > > Date: Wed, 15 Dec 1999 11:05:20 -0500
> > > From: "Linn, John" <[email-masked]>
> > > Subject: RE: WG Last-Call: draft-ietf-cat-lipkey-02.txt
> > > To: "'CAT-WG List'" <[email-masked]>
> >
> > > Sec. 3.2.3.2, 3rd-4th paragraphs: I think there's something
> > missing in this
> > > aspect of the protocol definition.  As described, the
> > initiator LIPKEY
> > > entity has assembled a token containing the provided user
> > name and password
> > > (aka the LIPKEY credentials), called SPKM-3 to GSS_Wrap it,
> > and has returned
> > > GSS_S_CONTINUE_NEEDED along with the GSS_Wrapped token to
> > its caller.  The
> > > 4th paragraph states that "The caller of LIPKEY sends its
> > second token to
> > > the target, and waits for either a GSS_S_COMPLETE response
> > from the target,
> > > indicating that the user name and password was accepted, or an error
> > > indicating rejection..."  I can't find, however, a
> > definition of the LIPKEY
> > > protocol element which is returned from the target to the
> > initiator, which
> > > would enable the initiator-side LIPKEY module to advance
> > the context out of
> > > GSS_S_CONTINUE_NEEDED state and inform its
> > GSS_Init_sec_context caller of
> > > whether a success or failure case occurred.  Absent a
> > returned token, how is
> > > this status information (corresponding to GSS_S_COMPLETE or
> > error returned
> > > on the target side) transferred from target to initiator?
> >
> > I've updated the i-d to define a token that returns relevant
> > status information.
> >
> > > Abstract, 2nd para: "Transport Layer Service" -> "Transport
> > Layer Security".
> >
> > Fixed.
> >
> > > Sec. 1, 5th para: suggest adding comment (consistent with
> > 5.2) that the
> > > client does need  one minimal infrastructure element:
> > knowledge of its
> > > trusted CAs and their public keys.
> >
> > Done.
> >
> > > Sec. 2.3.1, discussion of C-ALG: "set 128 bits" -> "set to
> > 128 bits";
> >
> > fixed.
> >
> > > following paragraph, "mega hertz" -> "megahertz".
> >
> > fixed.
> >
> > >
> > > Sec. 2.4. title: "Context Establish" -> "Context Establishment".
> >
> > fixed.
> >
> > In addition I found and fixed several other editorial errors,
> > and also deleted
> > one entry from the References section that wasn't being
> > refered to (the 3DES
> > algorithm OID). And of course, listed John in the
> > Acknowledgements section.
> >
> > I also made two other non-editorial changes:
> >
> >       In the discussion on initiator credential acquisostion,
> > noted that
> >       the interactive prompting for user name and password can be
> >       defered till GSS_Init_sec_context is called.
> >
> >       Note that the mutual_req_flag parameter to LIPKEY's
> > GSS_Init_sec_context
> >       routine is ignored, and why. I added this after I
> > considered what
> >       effects mutual_req_flag might have on the context token
> > exchanges,
> >       (as it does with Kerberos V5, RFC 1964).
> >
> >               -mre
> >
> >       -mre
> >
> > ==============================================================
> > ============
> > This message was posted through the Stanford campus mailing list
> > server.  If you wish to unsubscribe from this mailing list, send the
> > message body of "unsubscribe ietf-cat-wg" to
> > [email-masked]
> >
> ==========================================================================
> This message was posted through the Stanford campus mailing list
> server.  If you wish to unsubscribe from this mailing list, send the
> message body of "unsubscribe ietf-cat-wg" to [email-masked]
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 03 Jan 2000 10:08:44 -0600

Denis and John,

The current draft of the NFSv4 protocol specifies the LIPKEY
mechanism as mandatory to implement.  The NFSv4 WG has held
one bakeoff so far with another planned testing event during
Connectathon in March of this year.  I fully expect that work on
LIPKEY implementations will occur as a result of the general NFSv4
efforts.

Thanks,
Spencer
(NFSv4 draft editor)