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

From: "Linn, John" <[email-masked]>
Date: Wed, 15 Dec 1999 11:05:20 -0500

Here are a few comments based on a review of this draft; all but one are
editorial. I'll also take this as an opportunity to encourage others to
review and comment within the WG Last-Call period extending through
Thursday, 23 December.

Technical:

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? 

Editorial:

Abstract, 2nd para: "Transport Layer Service" -> "Transport Layer Security".

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. 

Sec. 2.3.1, discussion of C-ALG: "set 128 bits" -> "set to 128 bits";
following paragraph, "mega hertz" -> "megahertz".

Sec. 2.4. title: "Context Establish" -> "Context Establishment". 

--jl

==========================================================================
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: Mike Eisler <[email-masked]>
Date: Mon, 20 Dec 1999 20:58:58 -0800 (PST)

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]>

> 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.
 
> 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