Subject: comments on clarifications

From: "Matt Hur" <[email-masked]>
Date: Fri, 15 Nov 2002 22:44:58 -0800

Section 3.1.3 says:
> When responding to an AS request, if there are multiple encryption
keys
> registered for a client in the Kerberos database , then the etype
field from
> the AS request is used by the KDC to select the encryption method to
be used
> to protect the encrypted part of the KRB_AS_REP message which is sent
to the
> client. If there is more than one supported strong encryption type in
the
> etype list, the first valid strong etype for which an encryption key
is
> available is used.

Later (in the last paragraph), it says:
> If all of the above succeed, the server will encrypt ciphertext part
of the
> ticket using the encryption key extracted from the server principal's
record
> in the Kerberos database using the encryption type associated with the
> server principal's key (this choice is NOT affected by the etype field
in
> the request). It then formats a KRB_AS_REP message (see section
5.4.2),
> copying the addresses in the request into the caddr of the response,
placing
> any required pre-authentication data into the padata of the response,
and
> encrypts the ciphertext part in the client's key using an acceptable
> encryption method requested in the etype field of the request, or in
some
> key specified by pre-authentication mechanisms being used.

These two paragraphs don't completely line up.  I assume that the last
paragraph is meant to address something like PKINIT.  We should change
the wording to state that the KDC should use the strongest etype per
policy rather than basing the decision on ordinal value.  For example,
what is the expected behavior if preauth data (encrypted timestamp) uses
an enctype that is different from the first enctype specified in the
etype field (i.e. what if preauth uses 3DES or AES and the first etype
in the list is DES)?

Section 3.2.3 states:
> Unless the application server provides its own suitable means to
protect
> against replay (for example, a challenge-response sequence initiated
by the
> server after authentication, or use of a server-generated encryption
> subkey), the server must utilize a replay cache to remember any
> authenticator presented within the allowable clock skew. Careful
analysis of
> the application protocol and implementation is recommended before
> eliminating this cache. The replay cache will store the server name,
along
> with the client name, time and microsecond fields from the
recently-seen
> authenticators and if a matching tuple is found, the KRB_AP_ERR_REPEAT
error
> is returned [3.7]. If a server loses track of authenticators presented
> within the allowable clock skew, it must reject all requests until the
clock
> skew interval has passed, providing assurance that any lost or
re-played
> authenticators will fall outside the allowable clock skew and can no
longer
> be successfully replayed[3.8].

We should change the wording to state that the replay cache should store
at least the server name, along with the client name, time and
microsecond fields from the recently-seen authenticators...  The current
wording seems a bit too prescriptive (i.e. a replay cache may store more
data than this).  OR we should remove the statement altogether.  The
replay cache should store enough information to detect a replayed
authenticator.

---

From: Sam Hartman <[email-masked]>
Date: Sat, 16 Nov 2002 17:34:50 -0500

>>>>> "Matt" == Matt Hur <[email-masked]> writes:

    >> When responding to an AS request, if there are multiple
    Matt> keys
    >> registered for a client in the Kerberos database , then the
    Matt> field from
    >> the AS request is used by the KDC to select the encryption
    Matt> be used
    >> to protect the encrypted part of the KRB_AS_REP message which
    Matt> to the
    >> client. If there is more than one supported strong encryption
    Matt> the
    >> etype list, the first valid strong etype for which an
    Matt> is

    >> If all of the above succeed, the server will encrypt ciphertext
    Matt> of the
    >> ticket using the encryption key extracted from the server
    Matt> record
    >> in the Kerberos database using the encryption type associated
    >> with the server principal's key (this choice is NOT affected by
    >> the etype field
    Matt> in
    >> the request). It then formats a KRB_AS_REP message (see section
    Matt> 5.4.2),
    >> copying the addresses in the request into the caddr of the
    Matt> placing
    >> any required pre-authentication data into the padata of the
    Matt> and
    >> encrypts the ciphertext part in the client's key using an
    >> acceptable encryption method requested in the etype field of
    >> the request, or in
    Matt> some
    >> key specified by pre-authentication mechanisms being used.

    Matt> These two paragraphs don't completely line up.  I assume
    Matt> that the last paragraph is meant to address something like
    Matt> PKINIT.  

No, the ciphertext part of the ticket is not the same as the
ciphertext part of the AS REP.

The AS_REP uses the etype list; the ticket does not.

    Matt> We should change the wording to state that the KDC
    Matt> should use the strongest etype per policy rather than basing
    Matt> the decision on ordinal value.  For example, what is the
    Matt> expected behavior if preauth data (encrypted timestamp) uses
    Matt> an enctype that is different from the first enctype
    Matt> specified in the etype field (i.e. what if preauth uses 3DES
    Matt> or AES and the first etype in the list is DES)?

We've had this discussion before and I think we failed to reach
consensus on a change.  I think that treating the etype list as
ordered is important and would object to changing those semantics at
this point in the process.

I wouldn't object to adding language clarifying that the KDC can
discard unreasonable enctypes.  For example, if preauth data
influences what reply key is used and the right kind of preauth isn't
present to use some enctype then it is reasonable to ignore that
enctype even if listed.  Similarly if the KDC wants to know that the
client knows the key corresponding to some particular enctype, then
not using that enctype unless the preauth for that enctype is
presented sounds reasonable.  I think coming up with text that says
this would be difficult and I don't think we should hold up the
document on this issue.

    >> Unless the application server provides its own suitable means
    Matt> protect
    >> against replay (for example, a challenge-response sequence
    Matt> by the
    >> server after authentication, or use of a server-generated
    >> encryption subkey), the server must utilize a replay cache to
    >> remember any authenticator presented within the allowable clock
    >> skew. Careful
    Matt> analysis of
    >> the application protocol and implementation is recommended
    >> before eliminating this cache. The replay cache will store the
    >> server name,
    Matt> along
    >> with the client name, time and microsecond fields from the
    Matt> recently-seen
    >> authenticators and if a matching tuple is found, the
    Matt> error
    >> is returned [3.7]. If a server loses track of authenticators
    >> presented within the allowable clock skew, it must reject all
    >> requests until the
    Matt> clock
    >> skew interval has passed, providing assurance that any lost or
    Matt> re-played
    >> authenticators will fall outside the allowable clock skew and
    Matt> longer
    >> be successfully replayed[3.8].

    Matt> We should change the wording to state that the replay cache
    Matt> should store at least the server name, along with the client
    Matt> name, time and microsecond fields from the recently-seen
    Matt> authenticators...  The current wording seems a bit too
    Matt> prescriptive (i.e. a replay cache may store more data than
    Matt> this).  OR we should remove the statement altogether.  The
    Matt> replay cache should store enough information to detect a
    Matt> replayed authenticator.

For interoperability with existing implementations we need to require
that the server name, client name, time and microseconds be unique
among authenticators otherwise some implementations may detect it as a
replay.  So implementations need to store at least these fields.  I
agree that the text should be clarified to allow and possibly
encourage implementations to store more.