Subject: RE: Comments on draft-ietf-krb-wg-kerberos-clarifications-00.txt

From: "John Brezak" <[email-masked]>
Date: Fri, 1 Mar 2002 12:54:34 -0800

Another issue to clarify -

17) Section 5.4.1 - etype in KDC-REQ-BODY - The pseudo-code always
selected the first match from the intersecting etypes between client and
server. Without the pseudo-code, this behavior isn't clear. I would also
suggest, that the KDC is able to select from the intersecting set
whatever is appropriate based on KDC policy and not leave the selection
based upon client order.

> -----Original Message-----
> From: John Brezak 
> Sent: Thursday, February 28, 2002 5:44 PM
> To: [email-masked]; [email-masked]
> Subject: Comments on draft-ietf-krb-wg-kerberos-clarifications-00.txt
> 
> 
> A few comments/nits:
> 
> 1) Section 1.4.1 - 3rd paragraph - The server behavior is 
> described, what about the KDC? For the KDC is the SHOULD a MUST?
> 
> 2) Are we leaving anonymous tickets in?
> 
> 3) Section 2.9 - text says "three additional options", but 
> only 2 are enumerated.
> 
> 4) Section 3.1.4 - residual reference to "e-cksum".
> 
> 5) Section 3.6.1 - To remain compatible with MIT and Heimdal, 
> the encrypted part of the KERB-CRED message in a GSSAPI 
> initial context token is encrypted with the null enctype. 
> Microsoft does use the null enctype when either des-cbc-crc 
> or des-cbc-md5 is used to retain compat with other 
> implementations. For rc4-hmac, the encrypted part of the 
> kerb-cred is encrypted with rc4-hmac.
> 
> 6) Section5.2.1 - Is it necessary to suggest the use of 
> CHOICE anymore? I would suggest removing the 4th and 5th paragraphs.
> 
> 7) Section 5.2.1 - Paragraph 8. As I understand it, there is 
> no escape sequence for using UTF-8 in GeneralString at all. 
> So everything beyond the 2nd sentence should be removed.
> 
> 8) Section 5.2.7 - The padata-type for pa-etype-info should be 11 (not
> 10) in the table.
> 
> 9) Section 5.2.7.4 - There is a comment about "not clear 
> whether ETYPE-INFO or PW-SALT should take precedence if they 
> conflict". I do not believe there is currently a case where 
> they conflict. PW-SALT is only included in a pa-data of a 
> AS-REP while ETYPE-INFO is ever only in the e-data of a 
> KRB-ERROR. PW-SALT is only used when preauth is not required. 
> I would like to see use of PW-SALT depricated because it can 
> only tell you about a single salt value per enctype. In this 
> case providing an ETYPE-INFO can be in a non-preauth case of 
> an AS-REP and server the same purpose as the PW-SALT.
> 
> 10) Section 5.3.1 - "authorization-data" - The second 
> paragraph implies that authorization-data carried in the 
> Authenticator is added to the ticket in the case of the 
> TGS-REQ. Is this correct?
> 
> 11) Section 5.4.1 - "CANONICALIZE" flag - How about this 
> description instead - "The CANONICALIZE option indicates that 
> the client will accept the return of a principal name 
> different from the principal names in the request. This can 
> apply to either the cname or sname fields. If the KDC does 
> not support name-canonicalization, the option is ignored and 
> the appropriate KDC_ERR_C_PRINCIPAL_UNKNOWN or 
> KDC_ERR_S_PRINCIPAL_UNKNOWN error is returned.
> 
> 12) Section 5.4.1 - "till" - Since till is no longer 
> optional, the text implying that it is should be removed and 
> the special value used for the time included. I will find out 
> what value Windows2000 uses for "maximum till time allowed by realm".
> 
> 13) Section 5.4.2 - padata - refers to section 6.3.2 - should 
> be 5.2.7.3
> 
> 14) Section 6.2 - Add note about when it is appropriate for 
> the KDC to return a KDC-ERR-BAD-PVNO error. I would recommend 
> that it is never an appropriate error especially given that 
> we agree that the pvno field in the messages is not useful. 
> So anything other than "5" is a badly formed request and 
> should be dropped.
> 
> 15) Section 6.2 - Include a note about a KDC never returning 
> a KRB_AP_ERR_REPEAT. It must always return a response to a 
> request (regardless of transport mechanism).
> 
> 16) Section 7.2 - NT-SMTP-NAME (7) and NT-ENTERPRISE (10) are 
> both defined. NT-ENTERPRISE is used in Kerb-Referrals. What 
> is NT-SMTP-NAME
> (7) used for?
> 
> 
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> John Brezak                       * mailto:[email-masked]
> Microsoft Corporation        * 425-706-2602
> One Microsoft Way
> Redmond, WA 98052
> 
> 
>

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 1 Mar 2002 16:46:52 -0500

> whatever is appropriate based on KDC policy and not leave the selection

Actually, for ticket etype in AS exchanges MIT KDCs select the first
etype in the list resulting from the intersection of the principal's
keys in the KDB record for it, the client's requested etypes and the
KDC etype policy; the order of the keys in the KDB record is preserved.

Thus if a client requests "des-cbc-md5,des3-cbc-sha1" and the principal
has "des3-cbc-sha1,des-cbc-md5,some-other-etype" stored in the KDB in
that order, then the KDC selects "des3-cbc-sha1" (assuming the KDC is
allowed to issue des3-cbc-sha1 tickets).

It's nice that one can influence etype selection per-principal.

I don't think the exact behaviour should be specified - what matters is
that the selected etype be one that the client requested. The client's
given etype order can be a hint, but the KDC should not have to bow to
it. After all, the client is saying it can handle any of the given
etypes, whichever happens to be available, and if only one is available,
that one ought to suffice, so the client has to be prepared to accept an
etype selection algorythm that ignores the order of the clietn's etype
list.

IMHO,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

---

From: Sam Hartman <[email-masked]>
Date: 11 Mar 2002 16:28:59 -0500

>>>>> "John" == John Brezak <[email-masked]> writes:

    John> Another issue to clarify - 17) Section 5.4.1 - etype in
    John> KDC-REQ-BODY - The pseudo-code always selected the first
    John> match from the intersecting etypes between client and
    John> server. Without the pseudo-code, this behavior isn't
    John> clear. I would also suggest, that the KDC is able to select
    John> from the intersecting set whatever is appropriate based on
    John> KDC policy and not leave the selection based upon client
    John> order.

I certainly agree that mandating KDC behavior is not justified and
thus what you propose should be allowed.  The question is do we want
to encourage the KDC tho choose the client order.  I've certainly
found it to be useful to influence preferences for enctypes from the
client--I have a better idea of what my application needs and what
security/performance tradeoffs I'm willing to make than the KDC.

Note that the enctype for the ticket should not be influenced by
client choice, only the enctype for the session key.

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 11 Mar 2002 16:36:00 -0500

>security/performance tradeoffs I'm willing to make than the KDC.

On the other hand .... most (but certainly not all) of the time I'd be
perfectly willing to have this sort of stuff done on the KDC, as that
gives me a central place to manage it (i.e., if a weakness is discovered
in 3DES, I can turn it off in one place).

--Ken

---

From: Sam Hartman <[email-masked]>
Date: 11 Mar 2002 16:40:15 -0500

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

    Ken> On the other hand .... most (but certainly not all) of the
    Ken> time I'd be perfectly willing to have this sort of stuff done
    Ken> on the KDC, as that gives me a central place to manage it
    Ken> (i.e., if a weakness is discovered in 3DES, I can turn it off
    Ken> in one place).

O, everyone involved seems to agree that if a key does not meet KDC
policy the KDC should not use it.  The question is whether among the
set of keys that do meet policy, the KDC or client should specify the
preference order.

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 11 Mar 2002 16:49:46 -0500

>set of keys that do meet policy, the KDC or client should specify the

.... I'm going to have to side with John and vote for the KDC to do that
(even though I know we're not voting).  I understand what you were saying
about an application having better knowledge about it's needs ... but in
the majority of applications I've dealt with, the encryption algorithm
is mostly arbitrary ... any one of them could fit.  Central management
of a preference order would be a huge win for those applications.

(Just my $0.02, of course).

--Ken

---

From: Sam Hartman <[email-masked]>
Date: 11 Mar 2002 16:55:06 -0500

>> O, everyone involved seems to agree that if a key does not meet
    >> KDC policy the KDC should not use it.  The question is whether
    >> among the set of keys that do meet policy, the KDC or client
    >> should specify the preference order.

    Ken> .... I'm going to have to side with John and vote for the KDC
    Ken> to do that (even though I know we're not voting).  I
    Ken> understand what you were saying about an application having
    Ken> better knowledge about it's needs ... but in the majority of
    Ken> applications I've dealt with, the encryption algorithm is
    Ken> mostly arbitrary ... any one of them could fit.  Central
    Ken> management of a preference order would be a huge win for
    Ken> those applications.

You keep asserting this.  Mind justifying the assertion?  Intuitively
I tend to agree with you, but in the few situations I've actually seen
it matter, it was very useful to have the client specify the
preference order.  I can't really think of situations where having the
KDC specify preference order for session keys would ever help me.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Mar 2002 17:05:10 -0500

> set of keys that do meet policy, the KDC or client should specify the

I prefer the MIT krb5 KDC behaviour of giving preference to the order of
the keys as stored in the client principal's KDB record. This way
control of ticket enctypes is in the hands of the KDC admins (the clients
can override this by requesting just one enctype, provided they know
which enctype).

Note that section 3.1.3 of clarifications-00, 3rd paragraph describes
the KRB-AS-REP enc-part enctype selection and is not loose enough. I
don't see any reference in 3.1.3 or 5.4.1 to the manner in which the
session key entype of the resulting ticket should be selected.

Cheers,

Nico

---

From: Sam Hartman <[email-masked]>
Date: 11 Mar 2002 17:21:14 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> I prefer the MIT krb5 KDC behaviour of giving preference
    Nicolas> to the order of the keys as stored in the client
    Nicolas> principal's KDB record. 

Except I don't think the MIT code actually does this.  I believe it
gives preference to client order in the request.

John does bring up an interesting point; the request will be
authenticated in extensions but not in clarifications.  It is not
clear how much that matters, since someone who is trying to perform a
downgrade attack can simply replace the list with the one enctype they
want to downgrade to.

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 12 Mar 2002 00:20:30 -0500

>KDC specify preference order for session keys would ever help me.

One case I can think of is that a policy could come down that all
capable clients should start using a particular encryption or hash
algorithm if they're capable of doing so.  Okay, that would be
rather strange, but it wouldn't be the strangest policy I've seen
:-/  I will agree that's contrived; I'm not sure I can justify my
assertion.  Maybe the best I can come up with is, "my gut says so" :-)

(I was thinking that the KDC could have information about what an
application server supports, but in that case, it simply shouldn't
offer those as choices).

--Ken

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Mar 2002 08:41:33 -0500

> gives preference to client order in the request.

Ah. Right you are. I was stuck thinking of etype-info, which the MIT
krb5 KDC does sort according to the order of the keys in the KDB record;
so if clients start AS exchanges without pre-auth, but their principals
require pre-auth, the end result is that the order of the keys in the
KDB recrods overrides the order of etypes requested in the first AS-REQ.

> downgrade attack can simply replace the list with the one enctype they

All the more reason to leave etype selection to KDC, provided it picks
one that the client did request.

Cheers,

Nico