Subject: Comments on draft-ietf-krb-wg-kerberos-clarifications-03 section 5

From: [email-masked] (Sam Hartman)
Date: Thu, 3 Apr 2003 17:54:09 -0500 (EST)

In 5.2.6.2, the text claims that the same checksum is used as was used
to protect the ticket.  Unfortunately, tickets are not actually
protected by Kerberos checksums so this text is misleading.  The text
should describe what key is used for the checksum (is it the service
key?  Is it the session key? I think either would be secure) and
should probably say that you use the checksum algorithm required to be
implement along with that encription type.  

Later text seems to say server key  That's fine.  I think that will
should be changed to MUST in the following text; the requirement is
important for security and thus I think requirements language is
critical.

    element will be ignored by the application server if this "signature"
    is not present. Further, elements encapsulated within this element
    from a ticket-granting ticket MAY be interpreted by the KDC, and used
    as a basis according to policy for including new signed elements
    within derivative tickets, but they will not be copied to a
    derivative ticket directly. If they are copied directly to a
    derivative ticket by a KDC that is not aware of this element, the
    signature will not be correct for the application ticket elements,
    and the field will be ignored by the application server.
In the following text, the spelling of encapsulates is wrong:

    This element and the elements it encapulates MAY be safely ignored by
    applications, application servers, and KDCs that do not implement
    this element.

Text in 5.2.7.3 and 5.2.7.4 confuses me.  I thought we were moving
away from pa-pw-salt for all uses but the current text seems to imply
it should still be used in AS requests Am I confused about the
direction of the protocol?

Actually, I seem to recall correctly but the text in 5.2.4.5 seems
inconsistent with itself and with the rest of the document:
 It MAY also be sent in an
    AS-REP to provide information to the client about which key salt to
    use for the string-to-key to be used by the client to obtain the key
    for decrypting the encrypted part the AS-REP.

     . . . 

    The preferred ordering of pre-authentication data that modify client
    key selection is: ETYPE-INFO2, followed by ETYPE-INFO, followed by
    PW-SALT. A KDC shall send all of these pre-authentication data that
    it supports, in the preferred ordering, when issuing an AS-REP or
    when issuing a KRB-ERROR requesting additional pre-authentication.

We should also use requirements language (MUST) instead of shall.  We
should clean up the other text dealing with sending elements in as
requests to be consistent with each other and with the text in section
3 that says you should send only etype-info2 (and not etype-info) if
the client request a new enctype.

Text in section 5.6  implies that the s-address is optional; this is wrong.

The s-address seems to have become optional in section 5.8.  This is
wrong.

I object to the assertion in 5.7 that the nonce should be generated
randomly; I would prefer to see that text removed completely and fall
back to the text in section 3.  

I did not confirm the accuracy of the
table in section 5.10.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 03 Apr 2003 19:37:37 -0500

>>>>> "Love" == Love  <[email-masked]> writes:

    Love> [email-masked] (Sam Hartman) writes:
    >> I object to the assertion in 5.7 that the nonce should be
    >> generated randomly; I would prefer to see that text removed
    >> completely and fall back to the text in section 3.

    Love> 5.7 ? 5.7 seq-number refer back to 5.3.2.

    Love> You mean 5.8.1 (KRB-CRED) ?

Yes I do; sorry.

---

From: Tom Yu <[email-masked]>
Date: Thu, 03 Apr 2003 23:35:07 -0500

>>>>> "hartmans" == Sam Hartman <[email-masked]> writes:

hartmans> In 5.2.6.2, the text claims that the same checksum is used
hartmans> as was used to protect the ticket.  Unfortunately, tickets
hartmans> are not actually protected by Kerberos checksums so this
hartmans> text is misleading.  The text should describe what key is
hartmans> used for the checksum (is it the service key?  Is it the
hartmans> session key? I think either would be secure) and should
hartmans> probably say that you use the checksum algorithm required to
hartmans> be implement along with that encription type.

hartmans> Later text seems to say server key  That's fine.  I think that will
hartmans> should be changed to MUST in the following text; the requirement is
hartmans> important for security and thus I think requirements language is
hartmans> critical.

[...]

That seems like the right thing to do.

hartmans> Text in 5.2.7.3 and 5.2.7.4 confuses me.  I thought we were moving
hartmans> away from pa-pw-salt for all uses but the current text seems to imply
hartmans> it should still be used in AS requests Am I confused about the
hartmans> direction of the protocol?

hartmans> Actually, I seem to recall correctly but the text in 5.2.4.5 seems
hartmans> inconsistent with itself and with the rest of the document:

[...]

hartmans>     The preferred ordering of pre-authentication data that modify client
hartmans>     key selection is: ETYPE-INFO2, followed by ETYPE-INFO, followed by
hartmans>     PW-SALT. A KDC shall send all of these pre-authentication data that
hartmans>     it supports, in the preferred ordering, when issuing an AS-REP or
hartmans>     when issuing a KRB-ERROR requesting additional pre-authentication.

This is probably due to failure to update section 5 to match section
3.  Actually, I believe that KRB-ERROR requiring additional preauth
should never include a PA-PW-SALT, since there were implementation
bugs involving that.  Did we agree on whether to include
PA-ETYPE-INFO2 when no "new" enctype gets requested?

hartmans> We should also use requirements language (MUST) instead of
hartmans> shall.  We should clean up the other text dealing with
hartmans> sending elements in as requests to be consistent with each
hartmans> other and with the text in section 3 that says you should
hartmans> send only etype-info2 (and not etype-info) if the client
hartmans> request a new enctype.

Ok, so this is a case where section 5 wasn't updated to match section
3.

hartmans> Text in section 5.6 implies that the s-address is optional;
hartmans> this is wrong.

Agreed.

hartmans> The s-address seems to have become optional in section 5.8.
hartmans> This is wrong.

The KRB-CRED s-address was optional in RFC1510.  One could argue that
it shouldn't be optional, but whether its omission constitutes a
vulnerability to a reflection attack really depend on the application
protocol in question, or, more to the point, all of the application
protocols that might share a service key / session key with the
application protocol using KRB-CRED.

hartmans> I object to the assertion in 5.7 that the nonce should be
hartmans> generated randomly; I would prefer to see that text removed
hartmans> completely and fall back to the text in section 3.

The KRB-CRED nonce language was copied from RFC1510.  It just wasn't
updated when section 3 changed, I think.

hartmans> I did not confirm the accuracy of the
hartmans> table in section 5.10.

It looks correct, though I disagree with the reserving of tag numbers
16 and 17 for user-to-user at this time, given that their usage is in
a non-standards-track extension to RFC1964, and given that we may not
want to use those messages in the exact form used in that extension.

---Tom

---

From: Sam Hartman <[email-masked]>
Date: Fri, 04 Apr 2003 10:53:09 -0500

>>>>> "Tom" == Tom Yu <[email-masked]> writes:

    Tom> Did we agree
    Tom> on whether to include PA-ETYPE-INFO2 when no "new" enctype
    Tom> gets requested?

Yes, I believe we do include pa-etype-info2 in that case.  The text in
section 3 was what we agreed to and that claims send both etype-info2
and etype-info.

    hartmans> The s-address seems to have become optional in section
    hartmans> 5.8.  This is wrong.

    Tom> The KRB-CRED s-address was optional in RFC1510.  One could
    Tom> argue that it shouldn't be optional, but whether its omission
    Tom> constitutes a vulnerability to a reflection attack really
    Tom> depend on the application protocol in question, or, more to
    Tom> the point, all of the application protocols that might share
    Tom> a service key / session key with the application protocol
    Tom> using KRB-CRED.

We claim in section 3 that we explicitly don't care about reflections
of krb-cred.

Since I wrote that text I won't be the one to disagree with it;)

OK, so let's ignore my comment and leave the s-address optional in krb-cred.

    hartmans> I object to the assertion in 5.7 that the nonce should
    hartmans> be generated randomly; I would prefer to see that text
    hartmans> removed completely and fall back to the text in section
    hartmans> 3.

    Tom> The KRB-CRED nonce language was copied from RFC1510.  It just
    Tom> wasn't updated when section 3 changed, I think.
OK, if this text is from RFC 1510 then the whole krb-cred nonce mess
is even more confusing than I thought it was.  Since I already thought
it was too confusing to resolve for clarifications, I hold that
opinion even more strongly.

My preference is to remove this text from section 5 and roll back the
text in section 3 to RFC 1510's text.  I believe that is sufficiently
ambiguous that we can do something reasonable if we ever find out what
it is.  Since no one is currently really using the field, we should be
OK.

I don't want to commit us to behavior now if we don't have to.

    hartmans> I did not confirm the accuracy of the table in section
    hartmans> 5.10.

    Tom> It looks correct, though I disagree with the reserving of tag
    Tom> numbers 16 and 17 for user-to-user at this time, given that
    Tom> their usage is in a non-standards-track extension to RFC1964,
    Tom> and given that we may not want to use those messages in the
    Tom> exact form used in that extension.

Are we sure those are not going to be standards track?