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

From: [email-masked] (Sam Hartman)
Date: Thu, 3 Apr 2003 15:52:12 -0500 (EST)

The following transition across paragraph breaks does not work:

    format for the ticket is described in section 5.3. The contents of
    the ticket are determined as follows.

    Because Kerberos can run over unreliable transports such as UDP, the
    KDC MUST be prepared to retransmit responses in case they are lost.

In section 3.2.2 there is a reference to the old section 6.  I think
the entire parenthetical should be removed as the crypto draft is very
clear on this point.

    modification of the ticket (each encryption system MUST provide
    safeguards to detect modified ciphertext; see section 6), the
    KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that

Later, decisions is used instead of decision:

    Applications MUST make a separate authorization decisions based upon
    the authenticated name of the user, the requested operation, local
    access control information such as that contained in a .k5login or
    .k5users file, and possibly a separate distributed authorization
    service.

I'm fairly certain I've commented on this in the past, but I still
find the description of subkey usage in section 3.2.6 both wrong from
a security design standpoint and incompatible with the Kerberos crypto
framework.  IN the interest of getting something published I propose
that the discussion of subkey stop just before the phrase "To make
this example more concrete."  We should cut from that phrase to the
paragraph beginning "With both the one way".  I would appreciate
either explicit agreement or disagreement with this recommendation
from other WG participants as I'm not sure how others feel about this
issue.

In section 3.3.3, it seems like text from when realm referals were
merged in still exists.  While we've agreed we want to do this
eventually I think this text should be deferred until extensions.  The
other option is to merge in all the other supporting text about realm
referals and I don't think we want to do that during a last call.  I
do understand that clarifications allows for referals for cross-realm
tgt lookup, but that is handled previously in the same paragraph.

 If the requested server cannot be
    found in the TGS database, then a TGT for another trusted realm MAY
    be returned instead of a ticket for the service. This TGT is a
    referral mechanism to cause the client to retry the request to the
    realm of the TGT.  

In section 3.5.2, the text is confusing.  Perhaps replace and with or
and remove comma?

         The checksum is generated using
   the sub-session key if present, and the session key. 

In section 3.3.2, the text claims that the checksum in the TGS request
needs to be keyed.  Our implementation does not do this.  Since I see
no security justification for this requirement (it's encrypted after
all) I propose dropping keyed from the following text:

    Once the accompanying ticket has been decrypted, the user-supplied
    checksum in the Authenticator MUST be verified against the contents
    of the request, and the message rejected if the checksums do not
    match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum
    is not keyed or not collision-proof (with an error code of
    KRB_AP_ERR_INAPP_CKSUM). 

I'd like to ask that the nonce text in 3.6 be reverted to the 02 draft
version.  There has been some off-list discussion and I don't
think that the issue I raised which presumably lead to the change will
be resolved in the appropriate time frame for clarifications.  I
prefer the 02 text but do not specifically object to the 03 text.to

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Apr 2003 14:21:05 -0400

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

    Sam> I'm fairly certain I've commented on this in the past, but I
    Sam> still find the description of subkey usage in section 3.2.6
    Sam> both wrong from a security design standpoint and incompatible
    Sam> with the Kerberos crypto framework.  IN the interest of
    Sam> getting something published I propose that the discussion of
    Sam> subkey stop just before the phrase "To make this example more
    Sam> concrete."  We should cut from that phrase to the paragraph
    Sam> beginning "With both the one way".  I would appreciate either
    Sam> explicit agreement or disagreement with this recommendation
    Sam> from other WG participants as I'm not sure how others feel
    Sam> about this issue.

I still have heard no comments either in favor or against this change;
I will work on cornering individuals.

    Sam> I'd like to ask that the nonce text in 3.6 be reverted to the
    Sam> 02 draft version.  There has been some off-list discussion
    Sam> and I don't think that the issue I raised which presumably
    Sam> lead to the change will be resolved in the appropriate time
    Sam> frame for clarifications.  I prefer the 02 text but do not
    Sam> specifically object to the 03 text.to

I have also not heard any comments on this except for Love's
correction to the section number.

Do other people agree with reverting this text?

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Apr 2003 11:46:35 -0700

> I will work on cornering individuals.

Er, I've always been bothered by that text myself.  It isn't that it's
wrong, it's that it leaves the specification of the sub-session keys out
of the draft.

I would like to see an implementation note describing the common use.

IIRC the MIT implementation uses the client proposed sub-session as the
session key for client-to-server messages and the server-proposed key,
or, if not given, the client-proposed key, as the key for
server-to-client messages.

I don't think there's any way to fix this other than to: a) describe
what implementations do today and b) either stop there or declare that
implementors should give applications a hook for providing a different
sub-session key derivation function with the behaviour from (a) as the
default.

It would be nice to have a survey of all the ways in which sub-session
key negotiation have been implemented.

> Do other people agree with reverting this text?

Er, can you post the -02 text in question?

Thanks,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Apr 2003 14:53:08 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
    Nicolas> Er, can you post the -02 text in question?

I believe thas it was the same as RFC 1510:

   sequence in the encrypted part of the KRB_CRED message.  The current
      time and, if specifically required by the application the nonce, s-
         address, and raddress fields, are placed in the encrypted part of the
            KRB_CRED message which is then encrypted under an encryption key
               previosuly exchanged in the KRB_AP exchange (usually the last key
                  negotiated via subkeys, or the session key if no negotiation has
                     occured).

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Apr 2003 14:56:22 -0400

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

    Nicolas> Er, I've always been bothered by that text myself.  It
    Nicolas> isn't that it's wrong, it's that it leaves the
    Nicolas> specification of the sub-session keys out of the draft.

I think the explicit details are sufficiently incompatible with the
crypto framework as to be wrong.

    Nicolas> I would like to see an implementation note describing the
    Nicolas> common use.

I b believe the text already describes the client proposes, server
replaces model.

Do you believe that the text with my proposed removal does not hmeet
your needs?

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Apr 2003 12:14:35 -0700

> I believe thas it was the same as RFC 1510:

Ah, ok.  I agree - put it back.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Apr 2003 12:16:32 -0700

> Do you believe that the text with my proposed removal does not hmeet

No.  Your proposed deletion of section 3.2.6, paragraph 3 is fine.

Cheers,

Nico
--