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

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

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

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

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

---

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

> show an actual security problem.  I'm confident no such problem

As I noted in my own reply, I don't think there is a security problem here, 
and I do think there are potential interoperability problems resulting from 
a change at this time.  However, I would like to hear from working group 
participants on this issue, particularly with regard to the security 
question.

> preparing an rfc editor note to describe the issue and to confirm 6 is

I would be much happier if someone else were to volunteer to prepare text 
describing this issue and explaining why it is not a problem.  Not only 
does Sam have plenty to do, but someone else doing it would prove to me 
that someone else understands the issue and agrees with our analysis.

> appendix is mostly trying to talk about Vista.

I'd appreciate if Larry could make some comments on the things Sam and I 
have said about Appendix C, even if it's just confirmation.

-- Jeff

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 9 Feb 2006 17:23:27 -0800

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey
Hutzelman
Sent: Thursday, February 09, 2006 5:12 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Gen art review of draft-ietf-cat-kerberos-pk-init-33.txt
(fwd)

Jeff wrote:
> I'd appreciate if Larry could make some comments on the things Sam and
I have said about Appendix C, even if it's just confirmation.

Confirmed. The goal of this text was to help other clients to work with
win2k and ws2k3 KDCs, you should be able to derive the behavior based on
the described behaviors of the win2k and ws2k3 KDCs, win2k/winxp/wins2k3
clients need to talk with all these KDCs. If your KDC either has the
behavior as described in PKINIT-33/-34 or the same behavior of
ws2k3/win2k KDCs (for backward compat reasons), then you should expect
winxp/win2k/ws2k3 clients work with you.

Is this clear?

-- Larry

> show an actual security problem.  I'm confident no such problem 

As I noted in my own reply, I don't think there is a security problem
here, and I do think there are potential interoperability problems
resulting from a change at this time.  However, I would like to hear
from working group participants on this issue, particularly with regard
to the security question.

> intended.

I would be much happier if someone else were to volunteer to prepare
text describing this issue and explaining why it is not a problem.  Not
only does Sam have plenty to do, but someone else doing it would prove
to me that someone else understands the issue and agrees with our
analysis.

-- Jeff

---

From: Tom Yu <[email-masked]>
Date: Tue, 14 Feb 2006 19:38:01 -0500

>>>>> "jhutz" == Jeffrey Hutzelman <[email-masked]> writes:

>> show an actual security problem.  I'm confident no such problem

jhutz> As I noted in my own reply, I don't think there is a security problem
jhutz> here, and I do think there are potential interoperability problems
jhutz> resulting from a change at this time.  However, I would like to hear
jhutz> from working group participants on this issue, particularly with
jhutz> regard to the security question.

>> preparing an rfc editor note to describe the issue and to confirm 6 is

jhutz> I would be much happier if someone else were to volunteer to prepare
jhutz> text describing this issue and explaining why it is not a problem.
jhutz> Not only does Sam have plenty to do, but someone else doing it would
jhutz> prove to me that someone else understands the issue and agrees with
jhutz> our analysis.

I concur that there does not appear to be a significant security
issue, provided that the KDC takes care to not use the same key for
AS-REP encryption and the TGT session key.  Even in that case, it's
not clear that there is a significant exposure.

We probably don't want to encourage this sort of re-use of key usage
numbers in the future, but I think it's safe in this specific case.

---Tom

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 20 Feb 2006 11:29:47 -0800

Here I have a few words w.r.t. the key usage # 6 here.

Point #1, The spirit of using different key usage numbers in RFC4961 is
to make certain type of crypto analysis more difficult. However in this
case, the checksume itself is encrypted, it is unclear whether the key
usage # is actually useful. In addition, if the attacker gets hold of
the checksum, then the base key is in cleartext, it is questionable
there is need of cryptanalysis against the checksum.

Point #2: MIT and MS kerberos implementation do not use key usage # 6,
we are in practice using a unkeyed checksum in PA-TGS-REQ AP-REQ. so the
key usage # is "de-facto" not reused. I submit this point is fairly
weak.

Point #3: the checksum in PA-TGS-REQ AP-REQ is also encrypted, that
should mitigate the threat of cryptanalysis as well.

Point #4: RFC3961 does not require the key usage to be different for
different encryption and checksum operations, so this usage does not
violate the letter of either RFc3961 or RFC4120.

Therefore I suspect it is sufficient to add the following text as the
last paragraph of the security consideration section.

"The key usage number 6 used by the asChecksum field is also used by the
TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum [RFC4120], and this
is 
for historical reasons.  The reuse of key usage numbers is strongly
discouraged:  new protocols defined in terms of the Kerberos encryption
and
 checksum types SHOULD pick unique key usage values for different
encryption or checksum operations, in order to make certain type 
of crypto analysis more difficult."

My only concerns is that this text is in fact stronger or more explicit
than that of RFC3961/RFC4120. I can lower the case of the word "SHOULD",
or state that this RFC updates RFC3961. 

Krb-wg/Ken, what do you think?

Jeff, I would suggest the above change, if approved, can be handled in
the editors' notes, therefore no new revision is necessary for this
change, do you agree?

-- larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tom Yu
Sent: Tuesday, February 14, 2006 4:38 PM
To: Jeffrey Hutzelman
Cc: [email-masked]; [email-masked]
Subject: Re: Gen art review of draft-ietf-cat-kerberos-pk-init-33.txt
(fwd)

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 the 
Elwyn> usage in this draft with the specification in RFC4120
>> >> with the TGS session key (Section 5.5.1)
Elwyn> I suspect that this is NOT the same usage as #6 in RFC4120 and 
Elwyn> rfc1510ter draft and it needs a new key usage number allocated.
>> 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.

jhutz> As I noted in my own reply, I don't think there is a security 
jhutz> problem here, and I do think there are potential interoperability

jhutz> problems resulting from a change at this time.  However, I would 
jhutz> like to hear from working group participants on this issue, 
jhutz> particularly with regard to the security question.

>> preparing an rfc editor note to describe the issue and to confirm 6 
>> is intended.

jhutz> I would be much happier if someone else were to volunteer to 
jhutz> prepare text describing this issue and explaining why it is not a
problem.
jhutz> Not only does Sam have plenty to do, but someone else doing it 
jhutz> would prove to me that someone else understands the issue and 
jhutz> agrees with our analysis.

I concur that there does not appear to be a significant security issue,
provided that the KDC takes care to not use the same key for AS-REP
encryption and the TGT session key.  Even in that case, it's not clear
that there is a significant exposure.

---Tom

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 20 Feb 2006 14:42:29 -0500 (EST)

> or state that this RFC updates RFC3961.

This document should not update RFC3961; I think it is sufficient to note
that we are doing something odd for historical reasons, and that others
should not do the same.  IMHO the text up to "discouraged" is sufficient;
dropping everything after that should be fine.

> the editors' notes, therefore no new revision is necessary for this

Yes; whatever we end up with can go in as an RFC-Editor note.

-- Jeff