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

From: "Linn, John" <[email-masked]>
Date: Tue, 4 Jan 2000 08:50:44 -0500

Denis, all:

The WG position for pursuing advancement of LIPKEY on the standards track
wasn't new as of Washington, but instead dates back to the Minneapolis
meeting. There isn't a procedural requirement for available implementations
to progress to the level of Proposed Standard.  I believe, therefore, that
it's appropriate and consistent for this document to proceed to the IESG
requesting Proposed status. 

--jl

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Monday, January 03, 2000 5:33 AM
> To: Linn, John
> Cc: 'Mike Eisler'; 'CAT-WG List'
> Subject: Re: WG Last-Call: draft-ietf-cat-lipkey-02.txt
> 
> 
> 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: Denis Pinkas <[email-masked]>
Date: Tue, 04 Jan 2000 14:53:21 +0100

> requesting Proposed status.

As far as I understand the response to my previous mail there is at
least one planed implementation. That's fine !

Denis