Subject: [Gen-art] Gen art review of draft-ietf-cat-kerberos-pk-init-33.txt

From: Elwyn Davies <[email-masked]>
Date: Thu, 09 Feb 2006 00:27:52 +0000

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

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Wed, 8 Feb 2006 16:35:27 -0800

can also/In addition, if any CA that is trusted to issue KDC
certificates can also
Agreed. This can be handled in the authors' last 48 hours.

-- larry

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]] 
Sent: Wednesday, February 08, 2006 4:28 PM
To: [email-masked]
Cc: Mary Barnes; [email-masked]; Sam Hartman; Liqiang(Larry) Zhu;
[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:

Issues:

Very minor:

Editorial:

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Feb 2006 02:01:33 -0500

>>>>> "Elwyn" == Elwyn Davies <[email-masked]> writes:

    Elwyn> Well, I fear I may be going to provoke another version,
    Elwyn> because although it is IMO almost ready for PS, the IANA
    Elwyn> considerations need some attention.  

But as you will see below, not from this draft.

    Elwyn> I am also unsure if
    Elwyn> the key usage number that is cited in s3.2.3.2 is right
    Elwyn> (see detailed comment below).

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

It's as up to the minute as it can be.

The release of Windows anticipated by appendix C is Vista.

Note that the primary editor is the lead Kerberos developer for Microsoft.

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

*sigh* I suspect that it's too late to change this in all the
implementations.  I agree it should not be the same key usage number.
However since key usage 6 is currently only used with the session key,
there is not a security problem using 6 again with the reply key for
this checksum.  I think several vendors have shipping/almost shipping
code that works this way.  So in order to change things you'd need to
show an actual security problem.  I'm confident no such problem
exists.

I'll confirm with the WG chair and authors and probably end up
preparing an rfc editor note to describe the issue and to confirm 6 is
intended.

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

No, the registries are not set up by RFC 4120.  Kerberos does not yet
use IANA for anything besides encryption types.  RFC 4120 includes a
bunch of constants.  1510ter actually sets up IANA registries and
populates them with a superset of what is in 4120.  The Kink request
was not so much an expert review as a confirmation that the values
Kink is publishing with made it into 1510ter so they make it into the
initial registry.

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

Again, these are not yet handled by IANA.  I'll definitely ask the
1510ter editor to confirm he has all the pkinit changes.

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

XP is not a server OS; 2003 is roughly the same as 2000.  This
appendix is mostly trying to talk about Vista.

In conclusion, I don't think a new version is needed for this issue,
although -34 has been submitted to address comments in the WG.

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 09 Feb 2006 10:51:12 +0000

Jeff's response seems to cover most of the points in my review.  I see 
what is going on with the magic numbers, but I can't say that I 
understand the motivation or justification for the failure to start 
registries from RFC4120... but then I wasn't tracking this wg.

Couple of points in line...

Regards,
Elwyn

> Note that the primary editor is the lead Kerberos developer for Microsoft.
I thought this might be the case ;-)
The text in Appendix C is not going to survive the test of time very 
well.  Jeff's reply indicates that the comments apply to Windows XP at 
least to some extent.  I am not familiar with the Kerberos capabilities 
of Windows in depth, but I understand that Windows XP professional 
implements the KDC since it can function as a domain controller.  Maybe 
Appendix C could both mention XP and make it clear that it is talking 
about the next *server* OS release after Windows 2003 or some other 
appropriate form of words.
> preparing an rfc editor note to describe the issue and to confirm 6 is
I suspected that might be the case.  It also needs to be noted in 
rfc1510ter and the eventual registry  As you say it shouldn't cause an 
actual security problem.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 9 Feb 2006 01:47:41 -0500 (EST)

On Thu, 9 Feb 2006, Elwyn Davies wrote:

> One item which should be carefully checked before final
> and these can only be checked manually.

Noted.

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

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

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

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

> can also/In addition, if any CA that is trusted to issue KDC

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