Subject: Re: Last Call - Kerberos Cryptosystem Negotiation Extension

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 11 Jul 2005 23:00:44 -0400

On Wednesday, June 01, 2005 01:06:31 PM -0400 Jeffrey Hutzelman 
<[email-masked]> wrote:

> I am beginning a Last Call on this document, which will expire at the
> close of business (EDT) on June 15, 2005.
>
>
> 	Title		: Kerberos Cryptosystem Negotiation Extension
> 	Author(s)	: L. Zhu, et al.
> 	Filename	: draft-zhu-kerb-enctype-nego-02.txt
> 	Pages		: 7
> 	Date		: 2005-5-27
> 	
> This document specifies an extension by Kerberos to negotiate new
> encryption types between the client-server peers.

There have been NO COMMENTS in response to this.  I can't send this on to 
the IESG when it does not appear to have had any review at all.  This is a 
really short document, and does not take long to read and understand. 
Please, let's see some comments on this.

-- Jeff

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 12 Jul 2005 05:42:39 -0400

On Jul 11, 2005, at 23:00, Jeffrey Hutzelman wrote:
> There have been NO COMMENTS in response to this.  I can't send this on 
> to the IESG when it does not appear to have had any review at all.  
> This is a really short document, and does not take long to read and 
> understand. Please, let's see some comments on this.

Oops, I meant to look at this some time ago.  Okay, here goes.  
Apologies if I've forgotten some previous discussion on technical 
points.

[CLAR] and [GSS-CFX] references should be updated to the proper RFC 
numbers.  (They've been assigned, though not published.  The less work 
we make for the RFC editor, the better.)

Probably should have an Updates: header.  It's updating the enctype 
choice specification, and the ad-type table, in Clarifications.

The introduction should define the term "enctype" before using it.  
Should be sufficient to say something like:  "...KDC must limit the 
ticket session key encryption type (enctype)...."

Abstract: "extension to Kerberos" or "extension to the Kerberos 
protocol" or "extension of...", not "extension by Kerberos".  Might 
expand on the text just a wee bit; one brief sentence doesn't seems 
like enough.

Section 3, second paragraph.  What's "(129)"?  (Yes, *I* know, but the 
text doesn't explain it.)

Section 3, first paragraph.  I think it should be a SHOULD or MAY, not 
a MUST.  (That's kind of fuzzy.  Can we assert that there will be no 
circumstances under which the client implementation might prefer other 
enctypes but for other reasons chooses not to include the 
AD-ETYPE-NEGOTIATION element?  Or is that rolled up in the definition 
of "prefer", which we never really get into?)

In general: See RFC 2119, section 6.  I think our requirements language 
is too strong overall.

Page 4, third paragraph.  Does "SHOULD consider using" make sense here? 
  Shouldn't it be "SHOULD use"?

"Preserve the quality of randomness provided by the KDC...."  How 
about, "to take advantage of"?  And why do we want to do that, by the 
way?  Do we have a reference suggesting a way to do it safely, given 
that we're talking about the session key type possibly being weak?  If 
no reference, at least we should recommend caution in the approach 
chosen, in the Security Considerations section.  (E.g., if it's used 
directly, or used to encrypt some predictable data to get a key, it may 
provide additional fodder for cryptanalysis.  It should be used in 
combination with, not in place of, other randomness sources.)

Section 3, first paragraph.  The client must send a list of all 
enctypes it supports.  Doesn't this give the application server the 
opportunity to choose an enctype *later* in the preference list than 
the KDC-provided session key type?  The client might be better off (in 
its own estimation, if we continue anthropomorphizing our software) not 
invoking this extension at all, in that case.  Perhaps it should (MAY?) 
omit types that it likes less well than the session key type.  If they 
are omitted, do we need to include the session key enctype in the list?

In fact, while the list is sent in preference order, this spec doesn't 
suggest that the server should pay attention to the order.  True, it 
could be buried in the "implementation-specific policy" clause, and the 
policy may be "ignore the client's preferences, pick what the server 
thinks is the best of the types the client supports", but there isn't 
even a hint of a recommendation.  I think a suggestion that the server 
MAY heed (or MAY ignore) the order indicated by the client might be a 
good idea.

And why "an implementation-specific local matter" -- are we suggesting 
that the implementation SHOULD allow local configuration?  That would 
be fine by me, but if so, I think we should say it separately; 
"implementation-specific local" seems a little contradictory to me, 
like the implementation dictates the policy, but wait, no, it should be 
specified locally.

Page 4, first paragraph, "...it MUST be used for subsequent 
communication".  What if the application protocol does something odd, 
like negotiates a subkey for some purpose other than direct 
communication, but uses the session key for communication?  This spec 
as worded isn't compatible with such a protocol, at least not in a way 
that keeps the extension transparent to the application.  The AP-REP 
subkey of the negotiated enctype should be used, well, however your 
application protocol says to use the AP-REP subkey.  Maybe it's for 
encrypting data; maybe it's for randomizing the deck in your Kerberized 
Solitaire game.

Page 4, second paragraph, "MUST NOT be used when the client does not 
expect the subkey in the AP-REP message".  How about "SHOULD NOT", or 
"MAY omit..."?  This requirement means that in, oh, one "typical" 
implementation, the library on the client side will have to be informed 
whether the server is expected to send a subkey, rather than doing the 
exchange and then letting the application look and see if one was 
provided.  (Consider also a protocol where the subkey is used if 
provided, and the server chooses whether to provide it, but in the most 
common case -- perhaps determined by implementation issues -- the 
server does not.  The client could then be said not to expect to 
receive a subkey; must it then not send the list?)  It might be 
desirable sometimes (keeps messages shorter), but do we want to require 
it?

Section 3, paragraph 2, "[X60]" should be "[X690]".

When did "leverage" become a verb?  What does it mean in the title of 
appendix A, and is there a non-ManagerSpeak word that could be used 
instead?  Remember, this is for engineers, not managers or marketers.  
(Yes, one of the online dictionaries I checked did list it as a verb as 
well as a noun.  However, the definitions I ran across didn't seem to 
work here.)

Appendix A can be reduced to a few sentences.  (W2K/XP/2K3 SPNEGO has a 
bug, it's got security impact, it's been fixed, but for backward 
compatibility the fix is turned off unless....  And what's this "SSPI" 
thing anyways? :)  I don't think it's even particularly important to 
this document; at best, if it's kept in this document, it should be 
explicitly marked as informative, not normative.  But I think it should 
probably go.  Maybe get published separately as an informative RFC, if 
you want to discuss Microsoft GSSAPI/Kerberos interoperability issues 
in general.

That's everything I've come up with in the last few hours.  Sorry I 
didn't get to this sooner... :-(

Ken

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Jul 2005 17:22:49 -0400

>>>>> "Ken" == Ken Raeburn <[email-masked]> writes:

    Ken> "Preserve the quality of randomness provided by the KDC...."
    Ken> How about, "to take advantage of"?  And why do we want to do
    Ken> that, by the way?  Do we have a reference suggesting a way to
    Ken> do it safely, given that we're talking about the session key
    Ken> type possibly being weak?  If no reference, at least we
    Ken> should recommend caution in the approach chosen, in the
    Ken> Security Considerations section.  (E.g., if it's used
    Ken> directly, or used to encrypt some predictable data to get a
    Ken> key, it may provide additional fodder for cryptanalysis.  It
    Ken> should be used in combination with, not in place of, other
    Ken> randomness sources.)

Jeff Schiller tends to be the root source of all the recommendations
about reusing KDC entropy.  I tend to agree with his reason.  You know
the KDC has a strong PRNG (or at least you know you're in big trouble
if not).

As such, you want to reuse your KDC key data when generating keys.

We could take the combine keys function from Ken's SAM draft as an
example of how to do this.

--Sam

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 12 Jul 2005 17:48:47 -0400

> As such, you want to reuse your KDC key data when generating keys.

Yes, I know and agree with his argument.  I meant to imply that the 
draft should've answered the question.

> example of how to do this.

(Which draft has expired.)

I just took a look, it looks good to me.  Appendix A, that is, using 
the PRF.

Ken