Subject: Gen art review of draft-ietf-cat-kerberos-pk-init-33.txt (fwd)

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 09 Feb 2006 19:58:22 -0500

---------- Forwarded Message ----------
Date: Thursday, February 09, 2006 12:27:52 AM +0000
From: Elwyn Davies <[email-masked]>
To: [email-masked]
Subject: Gen art review of draft-ietf-cat-kerberos-pk-init-33.txt

I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Document: draft-ietf-cat-kerberos-pk-init-33.txt
Intended Status: Proposed Standard ((Long Defunct) WG submission)
Shepherding AD: Sam Hartman
Proto Shepherd: [email-masked]
Review Trigger: IETF Last Call (ends 8 Feb 2006)

Summary:
It must be the week for old drafts to finally come in from the cold (see
Scott Brim's comments on draft-ietf-pwe3-fragmentation-10.txt)! I think
this one must hold some sort of record for long gestation: the -00 version
seems to have disappeared from the archives I can get at but the Internet
Report for March 1995 documents its publication and it is mentioned in a
presentation from 13 March 1995. The -01 version was published in June
1996, so it has been on the stocks for almost 11 years and 34 versions!!
Only draft-ietf-dnsext-mdns-45.txt has been through more versions and that
is a mere stripling at 5 years gestation.

Well, I fear I may be going to provoke another version, because although it
is IMO almost ready for PS, the IANA considerations need some attention.  I
am also unsure if the key usage number that is cited in s3.2.3.2 is right
(see detailed comment below).

It would also be good to make Appendix C a little more up to the minute if
it is going to remain in place.

I have to say that this must also count as one of the most information
dense drafts I have encountered but I felt reasonably happy that it was
saying the right things.  Disclaimer: I am assuming that the ASN.1 has been
automatically checked and I am not a security expert so I cannot express an
opinion on the correctness of the algorithms etc although I noted that some
detailed analysis had been carried out and bugs fixed as a result.  One
item which should be carefully checked before final publication: There are
a number of OIDs embedded in comments in the ASN.1 (e.g., the comments to
the definition of PA-PK-AS-REQ in s3.2.1) and these can only be checked
manually.  I don't have the information to verify these items.

Issues:
s3.2.3.2: Key usage magic number 6.  This number is presumably taken from
the list in RFC4120 but I can't tally the usage in this draft with the
specification in RFC4120
>            6.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum,
>                keyed with the TGS session key (Section 5.5.1)
I suspect that this is NOT the same usage as #6 in RFC4120 and rfc1510ter
draft and it needs a new key usage number allocated.

I tried to find the registries apparently set up by RFC4120 but I couldn't
find them!  Maybe I was looking in the wrong place as I did find a message
discussing the expert review for allocating some new key usage numbers for
KINK and there is also a list in draft-ietf-krb-wg-rfc1510ter-02.txt.

s6: 'This document has no actions for IANA.':  This is not correct. At
least s3.1.2 defines new error codes and other items which need to be
registered.  RFC4120 reserves a number of error codes for pkinit but
doesn't give actual meaning, but additional ones have been defined here (#s
77-80).  The authorization data type is new and TD_DH_PARAMETERS is new.
Also RFC4120 reserves two unused pre-authentication data types for pkinit
(..._OLD - #s 14 and 15) - these should probably be noted as deprecated. I
am not sure about the items in s3.1.3.  I also think the key usage number
needs registration (and a name?).

Appendix C: This talks mainly about Windows 2000 and states 'It is
anticipated that the next release of Windows is already too far along to
allow it to support the issuing KDC certificates with id-pkinit-san SAN as
specified in this RFC.  Instead, ...'. I think this appendix is a victim of
the long gestation time of this draft.  Maybe something definite can be
said about Windows XP if this is thought useful?

Very minor:
s3.2.3.1: Derivation of AS reply key, Step 3:  '...K-truncate truncates its
input to the first K bits.'  s/first/leftmost/ possibly.

Editorial:
s1, para 2: s/The corner-stone of Kerberos V5 is/The corner-stones of
Kerberos V5 are/

s1,bullets 1 and 2: the acronyms AS and TGS are slightly overloaded (S
stands for either Service or Server in both cases).

s8,para: s/In addition, if any CA is trusted to issue KDC certificates can
also/In addition, if any CA that is trusted to issue KDC certificates can
also

---------- End Forwarded Message ----------

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 09 Feb 2006 20:01:56 -0500

Nothing like accidentally forwarding the same message three times...

---------- Forwarded Message ----------
Date: Thursday, February 09, 2006 01:47:41 AM -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Elwyn Davies <[email-masked]>
Subject: Re: Gen art review of draft-ietf-cat-kerberos-pk-init-33.txt

On Thu, 9 Feb 2006, Elwyn Davies wrote:

> One item which should be carefully checked before final
> publication: There are a number of OIDs embedded in comments in the
> ASN.1 (e.g., the comments to the definition of PA-PK-AS-REQ in s3.2.1)
> and these can only be checked manually.

Noted.

> Issues:
> s3.2.3.2: Key usage magic number 6.  This number is presumably taken
> from the list in RFC4120 but I can't tally the usage in this draft with
> the specification in RFC4120
> I suspect that this is NOT the same usage as #6 in RFC4120 and
> rfc1510ter draft and it needs a new key usage number allocated.

This is an interesting issue, and one I think I will want to take back to
the working group.  I agree the usage described in PKINIT 3.2.3.2 is not
the same as that described in RFC4120 for this number.  However, it will
never be the case that the same key is used in both situations, and the
data being checksummed in each case cannot be mistaken for each other
(both are checksums of the encodings of distinct ASN.1 types; some bits of
the encoding are constant in each case and cannot be the same).

The main issue is taht there may already be implementations which it is
too late to chnage, in which case we'll have to weigh the benefits of
assigning a unique key usage for this case against the interoperability
cost.

> I tried to find the registries apparently set up by RFC4120 but I
> couldn't find them!

Because they don't exist.  RFC4120 section 9 states:

   ... Until a subsequent RFC specifies otherwise, or the
   Kerberos working group is shut down, allocations of additional
   protocol constants and other defined values required for extensions
   to the Kerberos protocol will be administered by the Kerberos working
   group....

The "subsequent RFC" referred to is the upcoming revision to the Kerberos
spec, which draft-ietf-krb-wg-rfc1510ter-02.txt is intended eventually to
become.  Until then, the namespaces defined in RFC4120 are being managed
by the working group.  Needless to say, this has caused some confusion
during review of documents issued in the interim.

> s6: 'This document has no actions for IANA.':  This is not correct.

Actually, it is.  AD, PA, and TD types and error codes are all in the
category of namespaces being managed by the WG for now.  Key usages are as
well, to the extend that becomes an issue.

Encryption types (defined in RFC3961) are the subject of an IANA registry,
but the values used by PKINIT were pre-assigned when the registry was
created.

> allow it to support the issuing KDC certificates with id-pkinit-san SAN
> as specified in this RFC.  Instead, ...'. I think this appendix is a
> victim of the long gestation time of this draft.  Maybe something
> definite can be said about Windows XP if this is thought useful?

Actually, this appendix is a very recent addition.  To my knowledge, the
behavior described applies to Windows 2000 and all newer versions released
to date.  The "next release of Windows" to which it refers has not in fact
been released.

> Very minor:
> s3.2.3.1: Derivation of AS reply key, Step 3:  '...K-truncate truncates
> its input to the first K bits.'  s/first/leftmost/ possibly.

Possibly.  I will note that bits in a bitstream are ordered, so you can
speak clearly of the first bit.  On the other hand, which bit is leftmost
depends on the order in which you choose to write them down.

> s1, para 2: s/The corner-stone of Kerberos V5 is/The corner-stones of

Yup; this can be fixed in editing.

> stands for either Service or Server in both cases).

Yes; they are, but it's a natural overloading.  RFC4120 is less than
consistent in which term it chooses to use, and in fact defines the terms
"Server" and "Service" somewhat confusingly.

> s8,para: s/In addition, if any CA is trusted to issue KDC certificates
> can also/In addition, if any CA that is trusted to issue KDC
> certificates can also

Yes.

Thanks for your comments.  To my knowledge, yours are the only comments
we received during IETF last call which originated outside the working
group.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Chair, IETF Kerberos Working Group
   Carnegie Mellon University - Pittsburgh, PA

---------- End Forwarded Message ----------

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 09 Feb 2006 20:28:16 -0500

There's nothing like forwarding the same document three times, instead
of forwarding three different documents...

---------- Forwarded Message ----------
Date: Thursday, February 09, 2006 01:47:41 AM -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Elwyn Davies <[email-masked]>
Subject: Re: Gen art review of draft-ietf-cat-kerberos-pk-init-33.txt

Noted.

Yes.

---------- End Forwarded Message ----------