Subject: RE: I-D ACTION:draft-ietf-cat-kerberos-pk-init-08.txt

From: "Linn, John" <[email-masked]>
Date: Thu, 3 Jun 1999 08:45:45 -0400

This seems a reasonable request to me, and I'll hereby open a WG Last-Call
on draft-ietf-cat-kerberos-pk-init-08 to extend through Friday, 18 June.  If
anyone objects to this draft being recommended from the WG to the IESG, to
be considered there for advancement to Proposed Standard, please make their
objections known to the list by 18 June.

--jl

> -----Original Message-----
> From: Matt Hur [mailto:[email-masked]]
> Sent: Tuesday, May 25, 1999 12:04 PM
> To: [email-masked]'
> Subject: RE: I-D ACTION:draft-ietf-cat-kerberos-pk-init-08.txt
> 
> 
> This draft incorporates all of the refinements that we have previously
> discussed.  We would like to see this move to working group 
> last call prior
> to the Oslo meeting.  Does this seem reasonable to everyone?
> 
> Matt Hur
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, May 18, 1999 4:27 AM
> > To: IETF-Announce; @ns.cnri.reston.va.us; @cybersafe.com
> > Cc: [email-masked]
> > Subject: I-D ACTION:draft-ietf-cat-kerberos-pk-init-08.txt
> > 
> > 
> > A New Internet-Draft is available from the on-line 
> > Internet-Drafts directories.
> > This draft is a work item of the Common Authentication 
> > Technology Working Group of the IETF.
> > 
> > 	Title		: Public Key Cryptography for Initial 
> > Authentication in Kerberos
> > 	Author(s)	: C. Neuman, J. Wray, B. Tung, J. 
> > Trostle, M. Hur, A. Medvinsky, S. Medvinsky
> > 	Filename	: draft-ietf-cat-kerberos-pk-init-08.txt
> > 	Pages		: 18
> > 	Date		: 17-May-99
> > 	
> > This document defines extensions (PKINIT) to the Kerberos protocol
> > specification (RFC 1510 [1]) to provide a method for using public
> > key cryptography during initial authentication.  The methods
> > defined specify the ways in which preauthentication data fields and
> > error data fields in Kerberos messages are to be used to transport
> > public key data.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk
> -init-08.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-cat-kerberos-pk-init-08.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-cat-kerberos-pk-init-08.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> ==============================================================
> ============
> 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: Wed, 9 Jun 1999 13:51:47 -0400

Here are a few questions and comments based on review of pkinit-08.  Most
are editorial; I believe that only the first constitutes a discussion point.

As I understand the approach proposed for Diffie-Hellman, it's being used
uniformly in static-static mode with certificates for both sides.  If this
is true, I'm not sure where and how the necessary client-provided
per-message variant data (partyAInfo in X9.42 terms) is being represented.
S/MIME's draft-ietf-smime-x942-07, by comparison, declares ephemeral-static
mode as its MUST with static-static a MAY, partly because of intellectual
property issues that had been identified with static-static mode;
smime-cms-13 mentions only ephemeral-static mode.  Should pkinit adopt this
precedent or cite rationale for use of static-static? More generally,
draft-ietf-smime-x942-07 has been approved for RFC publication along with
draft-ietf-smime-cms-13, and both have received fairly extensive review and
discussion including cryptographic perspectives and resolution of
interoperability details such as key wrapping specifics.  In the interests
of uniformity, should we consider citing and adopting any material from
smime-x942-07 concerning specifics of Diffie-Hellman processing and
representations?

In sec. 0, last paragraph, the text identifies the document as pkinit-09.
If there's another I-D submission, it should adjust (or refrain from
adjusting) the value cited there so as to avoid version number skew. 

At the beginning of  3.1, PA-PK-KEY-REQ is defined with value 18 and
PA-PK-KEY-REP with value 19.  In kerberos-revisions-03, these values are
defined as 17 and 18 respectively.  Which document needs to be realigned?
The error type values appear  to match kerberos-revisions-03, but some of
their associated strings diverge (e.g., KDC_ERR_CLIENT_NOT_TRUSTED vs.
KDC_ERROR_CLIENT_NOT_TRUSTED). 

In at least a couple of places, footnotes cite the X.509 recommendation as
[9].  Presumably, this should be [10] instead?

Editorially, a large part of the document's most important content is within
Section 3.2, which runs without subsections for about six pages.
Suggestion: subdivide into subsections for client request and KDC reply. 

Per sec. 4, 2nd paragraph, I don't think the phrase "Standard Public Key
Authentication" is now defined, and the first sentence deserves repair to
remove the "either the" before it. 

Per reference [11], the current version of CMS as approved for RFC
publication is cms-13. 

--jl