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

From: "Linn, John" <[email-masked]>
Date: Thu, 9 Dec 1999 08:50:41 -0500

CAT-WG:

Per prior discussion and this message, I'll now place
draft-ietf-cat-lipkey-02.txt into a 2-week WG Last-Call, to extend through
Thursday, 23 December.  If anyone wishes to comment on this draft, with
respect to its prospective recommendation to the IESG on behalf of the
CAT-WG for advancement to Proposed Standard, please do so within this
period.

--jl

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Tuesday, December 07, 1999 12:55 PM
To: [email-masked]
Subject: update to lipkey i-d

I've submitted draft-ietf-cat-lipkey-02.txt to the internet drafts editor.

If you'd like to see now what was submitted (including an i-d with change
bars), see:

	http://playground.sun.com/~mre/lipkey/

I've made the following significant changes:

- removed 3DES as the mandatory confidentiality algorithm. It's simply
	too slow, and I consider it encumbered, given that the ANSI
	standard for it isn't online and costs $80 a copy. 
- Instead, cast5CBC is used. RC4 would be better, AES best, but
	the former has encumberances, and the latter doesn't exist. cast5CBC
	has decent speed, is royalty free, and as far as I can tell, is
	considered secure. With respect to the last, it has had several
	years to be cryptanalyzed. At any rate, cast5CBC is a good interim
	algorithm until AES arrives.

- added HMAC-MD5 as the mandatory integrity MAC. This was instead of
HMAC-SHA1.
	Again, speed is the issue, and while md5 has weaknesses, HMAC-MD5
	is apparently not affected. The i-d has references to
	the paper by Dobbertin attesting to this.

- moved the md5withRSA signature algorithm 
	from mandatory to recommended, due to encumbrances with the RSA
	algorithm.

- added the sha1withRSA signature algorithm as recommended.

- added DSA as the mandatory integrity signature algorithm. DSA is
unencumbered.

- added sha1 as a mandatory one way function for deriving subkeys, because
	md5 has weaknesses.

Another data point is that I won't be able to prototype this i-d as I'd
planned, due to a job change within my employer, and I don't expect the
prototype to get finished by my replacement anytime soon. 

The other remaining task is to assign OIDs for SPKM-3, LIPKEY, and the
NULL-MAC algorithm. I've sent repeated requests to iana for these
assignments,
to no avail. However, the i-d has plenty of whitespace in the right places
to
let the RFC editor add the OID assignments.

Thus I think we should proceed with the process to propose lipkey as a
proposed standard, starting with a WG last call.

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

---

From: "Linn, John" <[email-masked]>
Date: Thu, 23 Dec 1999 08:52:15 -0500

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

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