Subject: Comments on clarifications

From: "Jacques A. Vidrine" <[email-masked]>
Date: Mon, 18 Nov 2002 11:10:03 -0600

Hello All,

Here are some comments/questions/suggestions on the clarifications.
IMHO this document is in pretty good shape.  Nonetheless, below are
hunks of a diff on the nroff version of the clarifications.  Each hunk
includes explanatory notes.  The entire diff is also attached.  Many
changes are nits --- grammar/spelling/consistency.  If I didn't
comment on the hunk here, it is because it was purely a nit that I
feel requires no explanatation (e.g. missing punctuation).  I put the
most important items at the top, but otherwise the order is just a
result of the document flow.

IMHO most important stuff:
--------------------------
/////////////////////
= Delete text implying that in the future, two names may differ in
  name type only.  If this is supposed to stay, then it needs to be
  noted also in section 6.2.

@@ -2452,7 +2461,6 @@
 for this field are specified in section 7.2. The name-type should be
 treated as a hint. Ignoring the name type, no two names can be the same
 (i.e. at least one of the components, or the realm, must be different).
-This constraint may be eliminated in the future.
 
 .ti3
 name-string

/////////////////////
= It seems the common AuthorizationData elements defined here MUST
  be understood by all implementations.

@@ -2578,7 +2583,7 @@
 .in3
 Each sequence of type and data is referred to as an authorization element.
 Elements may be application specific, however, there is a common set of
-recursive elements that should be understood by all implementations. These
+recursive elements that MUST be understood by all implementations. These
 elements contain other elements embedded within them, and the interpretation
 of the encapsulating element determines which of the embedded elements must
 be interpreted, and which may be ignored.

/////////////////////
= Existing implementations do TCP half-close.  Spell out that is allowed.

@@ -5054,6 +5071,10 @@
 must be prepared to handle the connection being closed after the first
 response.
 
+Either the client or KDC MAY close the TCP connection in only the
+sending direction (half-close) if it does not expect to send any
+further messages.
+
 Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR) sent over
 the TCP stream is preceded by the length of the request as 4 octets in
 network byte order. The high bit of the length is reserved for future

/////////////////////
= Earlier in section 8.1, it says `Implementations SHOULD default to
  requesting addressless tickets'.

@@ -5583,8 +5605,7 @@
 minimum lifetime              5 minutes
 maximum renewable lifetime    1 week
 maximum ticket lifetime       1 day
-empty addresses               only when suitable  restrictions  appear
-                              in authorization data
+empty addresses               Allowed.
 proxiable, etc.               Allowed.
 
 .fi

/////////////////////
= Add a further recommendation to security considerations.

@@ -5654,6 +5675,12 @@
 attackers may try brute force or dictionary attacks against credentials that
 are observed by eavesdropping on the network.
 
+Similarly, it is recommended that principals which have keys derived
+from passwords not be permitted as the target server in a KRB_TGS_REQ,
+since the resulting KRB_TGS_REP will contain material encrypted in the
+principal's secret key suitable for conducting an offline dictionary
+attack.
+
 Each host on the network must have a clock which is loosely synchronized to
 the time of the other hosts; this synchronization is used to reduce the
 bookkeeping needs of application servers when they do replay detection. The

Other stuff:
------------
/////////////////////
= It reads awkwardly to me to say that one `MAY wish to' do something.
  Sure they may :-) I suggest deleting the `wish to' text where it is
  used.

@@ -431,7 +431,7 @@
 
 Implementations of Kerberos, GSSAPI, and SASL [RFC 2222] MUST NOT use DNS to
 canonicalize the host components of service principal names. Application
-authors MAY wish to append a statically configured domain name to
+authors MAY append a statically configured domain name to
 unqualified hosts before passing the name to security mechanisms.
 
 Implementation note: Many current implementations do some degree of

/////////////////////
= It looks like `KDC-issued' is used more often than `kdc-issued' in the
  text to refer to the AD-KDC-ISSUED element.

@@ -460,8 +460,8 @@
 specific access control functions and may utilize files on the application
 server, or on separately issued authorization credentials such as those
 based on proxies [Neu93], or on other authorization services. Separately
-authenticated authorization credentials may be embedded in a tickets
-authorization data when encapsulated by the kdc-issued authorization data
+authenticated authorization credentials may be embedded in a ticket's
+authorization data when encapsulated by the KDC-issued authorization data
 element.
 
 Applications should not accept the mere issuance of a service ticket by the

/////////////////////
= A clause seems to be modifying `Hades' rather than `Kerberos'.
  Reworded to avoid the problem.

@@ -672,9 +672,10 @@
 .ti3
 Kerberos
 .br
-Aside from the 3-headed dog guarding Hades, the name given to Project
-Athena's authentication service, the protocol used by that service, or
-the code used to implement the authentication service.
+The name given to the Project Athena's authentication service, the
+protocol used by that service, or the code used to implement the
+authentication service.  The name is adopted from the three-headed dog
+which guards Hades.
 
 .ti3
 Plaintext

/////////////////////
= I really prefer the construct `X, rather than Y' to `X, and not Y'
  when describing the mutually exclusive conditions X and Y.

@@ -771,8 +772,8 @@
 .ti0
 2.1. Initial, pre-authenticated, and hardware authenticated tickets
 
-The INITIAL flag indicates that a ticket was issued using the AS protocol
-and not issued based on a ticket-granting ticket. Application servers that
+The INITIAL flag indicates that a ticket was issued using the AS protocol,
+rather than issued based on a ticket-granting ticket. Application servers that
 want to require the demonstrated knowledge of a client's secret key (e.g. a
 password-changing program) can insist that this flag be set in any tickets
 they accept, and thus be assured that the client's key was recently

/////////////////////
= The transited field lists realms, not KDCs.

@@ -943,7 +944,8 @@
 In Kerberos, the application server is ultimately responsible for accepting
 or rejecting authentication and should check that only suitably trusted KDCs
 are relied upon to authenticate a principal. The transited field in the
-ticket identifies which KDCs were involved in the authentication process and
+ticket identifies which realms (and thus which KDCs) were involved in the
+authentication process and
 an application server would normally check this field. If any of these are
 untrusted to authenticate the indicated client principal (probably
 determined by a realm-based policy), the authentication attempt must be

/////////////////////
= Section 3.1.1 doesn't describe much about pre-authentication.  5.2.7
  has more info.

@@ -1060,7 +1062,8 @@
 the key is based on a password, this may create a security exposure. So, the
 initial request supports an optional field that can be used to pass
 additional information that might be needed for the initial exchange. This
-field should be used for pre-authentication as described in section 3.1.1.
+field should be used for pre-authentication as described in sections 3.1.1
+and 5.2.7.
 
 Various errors can occur; these are indicated by an error response
 (KRB_ERROR) instead of the KRB_AS_REP response. The error message is not

/////////////////////
= I don't understand why sometimes error conditions are spelled out
  and sometimes just implied.  Should this case be clarified?
= More importantly in this hunk, better describe what to expect in a
  KDC_ERR_PREAUTH_REQUIRED.

@@ -1110,12 +1113,18 @@
 doesn't exist in the KDC's principal database, then an error message with a
 KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.
 
+XXX The behavior when an unknown server is given is not specified
+here.  Is there any possible response other than
+KDC_ERR_S_PRINCIPAL_UNKNOWN ins this case?
+
 If required, the server pre-authenticates the request, and if the
 pre-authentication check fails, an error message with the code
 KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is required, but
 was not present in the request, an error message with the code
-KDC_ERR_PREAUTH_REQUIRED is returned and the PA-ETYPE-INFO
-pre-authentication field will be included in the KRB-ERROR message. If the
+KDC_ERR_PREAUTH_REQUIRED is returned and the METHOD-DATA field of
+the KRB-ERROR message will specify which pre-authentication mechanisms
+are acceptable.  Usually this will include PA-ETYPE-INFO and/or
+PA-ETYPE-INFO2 elements. If the
 server cannot accommodate an encryption type requested by the client, an
 error message with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC
 generates a \'random' session key[3.3].

/////////////////////
= Split a long sentence.

@@ -2116,9 +2125,9 @@
 exchange external to the Kerberos protococl, usually as part of the
 application protocol. This message is shown in the summary above as message
 0. Note that because the ticket granting ticket is encrypted in the KDC's
-secret key, can not be used for authentication without posession of the
-corresponding secret key, and because the verifier does not give out the
-corresponding secret key, providing a copy of the verifiers ticket granting
+secret key, it cannot be used for authentication without posession of the
+corresponding secret key. Furthermore, because the verifier does not reveal the
+corresponding secret key, providing a copy of the verifier's ticket granting
 ticket does not allow impersonation of the verifier.
 
 Once the verifier's ticket granting ticket has been obtained by the client,

/////////////////////
= The present tense seems more appropriate here.

@@ -2230,8 +2239,8 @@
 Note that in several places, there have been changes here from RFC 1510 that
 change the abstract types. This is in part to address widespread assumptions
 that various implementors have made, in some cases resulting in
-unintentional violations of the ASN.1 standard. These will be clearly
-flagged when they occur. The differences between the abstract types in RFC
+unintentional violations of the ASN.1 standard. These are clearly
+flagged where they occur. The differences between the abstract types in RFC
 1510 and abstract types in this document can cause incompatible encodings to
 be emitted when certain encoding rules, e.g. the Packed Encoding Rules
 (PER), are used. This theoretical incompatibility should not be relevant for

/////////////////////
= For consistency, use `US-ASCII' rather than `ASCII'.  (The former was
  the more popular spelling.)

@@ -2437,7 +2446,7 @@
 
 .fi
 Kerberos realm names are encoded as KerberosStrings. Realms shall not
-contain a character with the code 0 (the ASCII NUL). Most realms will
+contain a character with the code 0 (the US-ASCII NUL). Most realms will
 usually consist of several components separated by periods (.), in the style
 of Internet Domain Names, or separated by slashes (/) in the style of X.500
 names. Acceptable forms for realm names are specified in section 7. A

/////////////////////
= Can a message be sent such that the msg-type field differs from the
  application tag number?

@@ -2511,8 +2519,9 @@
 .ti3
 msg-type
 .br
-this integer field usually is identical to the application tag number
+this integer field is usually identical to the application tag number
 of the containing message type.
+XXX Usually?  Not always??
 
 .in3
 .ti0

/////////////////////
= Correct reference.
= Delete text that adds no addition information, and is possibly
  confusing.

@@ -2538,17 +2547,13 @@
 addr-type
 .br
 This field specifies the type of address that follows. Pre-defined
-values for this field are specified in section 8.1.
+values for this field are specified in section 7.1.
 
 .ti3
 address
 .br
 This field encodes a single address of type addr-type.
 
-.in3
-The two forms differ slightly. HostAddress contains exactly one address;
-HostAddresses contains a sequence of possibly many addresses.
-
 .ti0
 5.2.6. AuthorizationData

/////////////////////
= Comments are in the hunk.

@@ -2650,6 +2655,15 @@
 .ti3
 ad-checksum
 .br
+XXX This paragraph says the checksum is over the "elements" field.
+Are the i-realm and i-sname fields not integrity protected?  What
+impact might this have?
+.br
+XXX Strictly speaking, the "key used to protect the ticket" is already
+the result of key derivation (key usage 2).  Is it intended that the
+derived key is then run through key derivation again?  Probably not.
+But I can't think of wording at the moment to clarify this.
+.br
 A checksum over the elements field using a cryptographic checksum
 method that is identical to the checksum used to protect the ticket
 itself (i.e. using the same hash function and the same encryption

/////////////////////
= Reword the description of AD-AND-OR to spell out more explicitly
  that condition-count may be any value from 1..N (N = number encapsulated
  elements), not just 1 or N.  More explicitly spell out the semantics
  in this case as well.

@@ -2708,9 +2722,10 @@
 }
 
 .fi
-When restrictive AD elements are encapsulated within the and-or element are
-encountered, only the number specified in condition-count of the
-encapsulated conditions must be met in order to satisfy this element. This
+When restrictive AD elements are encapsulated within the and-or element,
+the and-or element is considered satisfied if and only if at least the
+number of encapsulated elements specified in condition-count are satisifed.
+Therefore, this
 element may be used to implement an "or" operation by setting the
 condition-count field to 1, and it may specify an "and" operation by setting
 the condition count to the number of embedded elements. Application servers

/////////////////////
= We really mean mandatory-for-kdc here.

@@ -2724,7 +2739,7 @@
 
 AD elements encapsulated within the mandatory-for-kdc element are to be
 interpreted by the KDC. KDCs that do not understand the type of an element
-embedded within the if-relevant element must reject the request.
+embedded within the mandatory-for-kdc element must reject the request.
 
 .ti0
 5.2.7. PA-DATA

/////////////////////
= If an element is absent, it doesn't have any value :-)  I understood
  what was meant after a second read, but reword it for clarity.

@@ -3322,8 +3337,9 @@
 .br
 This field in the ticket specifies the time after which the ticket is
 valid. Together with endtime, this field specifies the life of the
-ticket. If it is absent from the ticket, its value should be treated as
-that of the authtime field.
+ticket. If the starttime field is absent from the ticket, then the
+authtime field should be used in its place to determine the life of
+the ticket.
 
 .ti3
 endtime

/////////////////////
= `zero-address tickets' aren't described as such anywhere else.
  Use `addressless tickets' instead.

@@ -3349,7 +3365,7 @@
 host addresses. These are the addresses from which the ticket can be
 used. If there are no addresses, the ticket can be used from any
 location. The decision by the KDC to issue or by the end server to
-accept zero-address tickets is a policy decision and is left to the
+accept addressless tickets is a policy decision and is left to the
 Kerberos and end-service administrators; they may refuse to issue or
 accept such tickets. The suggested and default policy, however, is that
 such tickets will only be issued or accepted when additional

/////////////////////
= Delete sentence that isn't really true and doesn't matter anyway.

@@ -3537,9 +3553,7 @@
 
 The padata (pre-authentication data) field contains a sequence of
 authentication information which may be needed before credentials can
-be issued or decrypted. In most requests for initial authentication
-(KRB_AS_REQ) and most replies (KDC-REP), the padata field will be left
-out.
+be issued or decrypted.
 
 .ti3
 req-body

/////////////////////
= Is there supposed to be some distinction between UNUSED and RESERVED
  here?  If not, use RESERVED consistently.

@@ -3634,7 +3648,7 @@
                                     after the starttime in the ticket
                                     has been reached.
 
-   7       UNUSED                   This option is presently unused.
+   7       RESERVED                 This option is presently unused.
 
                                     The RENEWABLE option indicates that
                                     the ticket to be issued is to have
@@ -3651,7 +3665,7 @@
    9       RESERVED                 Reserved for PK-Cross
 
                                     These options are presently unused.
-   10-13   UNUSED                   Option 11 is reserved for future is
+   10-13   RESERVED                 Option 11 is reserved for future is
                                     as opt-hardware-auth.
 
    14-25   RESERVED                 Reserved for future use.

/////////////////////
= I believe TGS_REQ was meant here.

@@ -3746,7 +3760,7 @@
 the TGS_REQ form), is an encoding of the desired authorization-data
 encrypted under the sub-session key if present in the Authenticator, or
 alternatively from the session key in the ticket-granting ticket, both
-from the padata field in the KRB_AP_REQ. The key usage value used when
+from the padata field in the KRB_TGS_REQ. The key usage value used when
 encrypting is 5 if a sub-session key is used, or 4 if the session key
 is used.

/////////////////////
= If we need to mention the UNIX epoch, then it should probably just
  be an `Implementation note'.

@@ -3771,7 +3785,7 @@
 This field contains the expiration date requested by the client in a
 ticket request. It is not optional, but if the requested endtime is
 "19700101000000Z", the requested ticket is to have the maximum endtime
-permitted according to KDC policy for. This special timestamp
+permitted according to KDC policy. Implementation note: This special timestamp
 corresponds to a UNIX time_t value of zero on most systems.
 
 .ti3

/////////////////////
= Can the KDC choose not to copy some or all of the addresses?

@@ -3803,8 +3817,9 @@
 ticket-granting server. It specifies the addresses from which the
 requested ticket is to be valid. Normally it includes the addresses for
 the client's host. If a proxy is requested, this field will contain
-other addresses. The contents of this field are usually copied by the
+other addresses. The contents of this field are copied by the
 KDC into the caddr field of the resulting ticket.
+XXX Is any other behavior acceptable (besides copying the addresses)?
 
 .ti3
 additional-tickets

/////////////////////
= Comment is in the hunk.

@@ -4195,6 +4210,10 @@
 and should not transmit an Authenticator with a sequence number of
 zero.
 
+XXX Is this truly desired, that the sequence number be omitted when it
+is zero?  So we get messages with ..., seq-number 2^32-2, seq-number
+2^32-1, no seq-number, seq-number 1, seq-number 2, ...?
+
 .ti3
 authorization-data
 .br

/////////////////////
= Clarify that we don't mean that the Kerberos GSS-API mechanism
  inherently does no encryption of KRB-CRED, but rather that there
  exist implementations of Kerberos GSS-API that do no encryption
  of KRB-CRED.

@@ -4514,7 +4533,7 @@
 used for the enc-part field of the KRB-CRED message.
 
 Implementation note: implementations of certain applications, most
-notably of the Kerberos GSS-API mechanism, do not encrypt the KRB-CRED
+notably certain implementations of the Kerberos GSS-API mechanism, do not encrypt the
KRB-CRED
 message when sending it. In the case of the GSS-API mechanism, this is
 not a security vulnerability, as the KRB-CRED message itself is itself
 encrypted inside an Authenticator.

/////////////////////
= Note that TGT-REQ/TGT-REP are for user2user in this table.

@@ -4718,9 +4737,9 @@
 
  15             AP-REP         PDU
 
- 16             RESERVED16     TGT-REQ
+ 16             RESERVED16     TGT-REQ (user2user)
 
- 17             RESERVED17     TGT-REP
+ 17             RESERVED17     TGT-REP (user2user)
 
  18-19                         unused

/////////////////////
= Delete text referencing AF_* constants, as previously discussed.

@@ -4920,11 +4939,6 @@
 All non-negative values are reserved for officially assigned type fields and
 interpretations.
 
-The values of the types for the following addresses are chosen to match the
-defined address family constants in the Berkeley Standard Distributions of
-Unix. They can be found in with symbolic names AF_xxx (where xxx is an
-abbreviation of the address family name).
-
 .in6
 .ti3
 Internet (IPv4) Addresses

/////////////////////
= Delete obsolete notation (or was a reference intended?).

@@ -4934,7 +4948,7 @@
 type of IPv4 addresses is two (2).
 
 .ti3
-Internet (IPv6) Addresses [Westerlund]
+Internet (IPv6) Addresses
 
 IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The
 type of IPv6 addresses is twenty-four (24). [RFC2373]. The following

/////////////////////
= It sees to me that link-local addresses could be useful in some
  environments.  Why are they not permitted?

@@ -4945,6 +4959,8 @@
    *  the Loopback Address
    *  Link-Local addresses
 
+XXX Why no link-local addresses?
+
 .fi
 IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.

/////////////////////
= We don't seem to use hex constants much, so don't use them here,
  especially if we're not going to distinguish them from decimal constants.
= Be a little more precise.

@@ -4958,8 +4974,9 @@
 Netbios addresses
 
 Netbios addresses are 16-octet addresses typically composed of 1 to 15
-characters, trailing blank (ascii char 20) filled, with a 16th octet of 0x0.
-The type of Netbios addresses is 20 (0x14).
+alphanumeric characters and padded with the US-ASCII SPC character (code
+32).  The 16th octet must be the US-ASCII NUL character (code 0).
+The type of Netbios addresses is twenty (20).
 
 .ti3
 Directional Addresses

/////////////////////
= Arbitrarily assign directional addresses type 3.  Pick something else
  if there is reason, but just pick something.

@@ -4983,7 +5000,7 @@
 where the sending party knows that the receiving party supports the address
 type. This generally means that directional addresses may only be used when
 the application protocol requires their support. Directional addresses are
-type XX (0xXX).
+type three (3).
 
 .in3
 .ti0

/////////////////////
= Mention the appropriate error code.

@@ -5014,7 +5031,7 @@
 sending port at the sender's IP address. The response to a request made
 through UDP/IP transport must also use UDP/IP transport. If the response can
 not be handled using UDP (for example because it is too large), the KDC must
-return an error forcing the client to retry the request using the TCP
+return KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the request using the TCP
 transport.
 
 .ti0

/////////////////////
= Add directional address type.

@@ -5275,6 +5296,7 @@
 Address type                   value
 
 IPV4                             2
+Directional                      3
 ChaosNet                         5
 XNS                              6
 ISO                              7

/////////////////////
= `Public key' does not appear to be a noun in this case, but an
  adjective.  Give it a noun to modify.

@@ -6398,7 +6425,7 @@
 key might be stored on a smart-card, or otherwise obtained independent of a
 password.
 
-The introduction also mentions the use of public key for initial
+The introduction also mentions the use of public key cryptography for initial
 authentication in Kerberos by reference. RFC1510 did not include such a
 reference.

/////////////////////
= pa-etype-info2 was missing.

@@ -6427,7 +6454,7 @@
 A warning regarding generation of session keys for application use was
 added, urging the inclusion of key entropy from the KDC generated session
 key in the ticket. An example regarding use of the sub-session key was added
-to section 3.2.6. Descriptions of the pa-etype-info, and pa-pw-salt
+to section 3.2.6. Descriptions of the pa-etype-info, pa-etype-info2, and pa-pw-salt
 preauthentication data items were added. The recommendation for use of
 preauthentication was changed from "may" to "should" and a note was added
 regarding known plaintext attacks.

Cheers,
-- 
Jacques A. Vidrine <[email-masked]>          http://www.celabo.org/
NTT/Verio SME          .     FreeBSD UNIX     .       Heimdal Kerberos
[email-masked]     .  [email-masked]  .          [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Nov 2002 15:26:47 -0500

>>>>> "Jacques" == Jacques A Vidrine <[email-masked]> writes:

    Jacques> ///////////////////// = Delete text implying that in the
    Jacques> future, two names may differ in name type only.  If this
    Jacques> is supposed to stay, then it needs to be noted also in
    Jacques> section 6.2.

I believe that we agreed to do this and this change should have been
made earlier.

    Jacques> ///////////////////// = Earlier in section 8.1, it says
    Jacques> `Implementations SHOULD default to requesting addressless
    Jacques> tickets'.

Good catch; I missed this when making the earlier changes to default
to addressless tickets.

    Jacques> ///////////////////// = Add a further recommendation to
    Jacques> security considerations.

I don't believe the wg has reached consensus on this and I don't
believe we should be making this change so late in the process.

I'd agree with MAY instead of SHOULD.

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Mon, 18 Nov 2002 15:01:21 -0600

> believe we should be making this change so late in the process.

Perhaps weaker language, then?  I'm not sure what you mean about lack
of consensus ... no consensus that it should be recommended? or no
consensus that it is a security consideration? or something else?

> I'd agree with MAY instead of SHOULD.

and I was unclear of the context.  Did you mean that instead
of `recommend'ing this behavior, that it simply be listed as a
possibility?  That'd be fine with me as well.

I realize that it is late in the game... although I covered this
scenario at IETF 53, I don't think I ever followed up on the mailing
list.  The reason I would like this added is because at least two
implementations that exist today already have mechanisms that
administrators can use to implement such a recommendation.  Other
implementations should (IMHO) be encouraged to also provide such
mechanisms, or at least warned of the consequences of NOT providing
such mechanisms.  For example, for realms that I administer, new
principals are created with a `disallow-server' attribute set by
default.  If it is meant to be a service key, the creator must
manually flip that attribute.

Refersher for others watching:  An attacker with a valid TGT may
request a ticket for a target user's principal.  In response, the
KDC will return a reply containing a Ticket with the EncTicketPart
encrypted in the target user's password-derived secret key.  An
offline dictionary attack can then be used to attempt to recover the
password.  This has the same impact as using no preauthentication
(which is mentioned in this section), and a larger impact than the
attack of an eavesdropper (which is mentioned in this section).

Cheers,

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Nov 2002 16:05:13 -0500

>>>>> "Jacques" == Jacques A Vidrine <[email-masked]> writes:

    Jacques> On Mon, Nov 18, 2002 at 11:10:03AM -0600, Jacques
    Jacques> A. Vidrine wrote:

    >> I'd agree with MAY instead of SHOULD.

    Jacques> and I was unclear of the context.  Did you mean that
    Jacques> instead of `recommend'ing this behavior, that it simply
    Jacques> be listed as a possibility?  That'd be fine with me as
    Jacques> well.

Yes, that's what I meant.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Nov 2002 09:51:07 -0600

I am not concerned about AD-KDC-Issued not protecting the i-realm and
i-sname fields.  Ideally they should be, but the whole point of the
signature is that users can add any authz element they care to to any
ticket, except for AD-KDC-Issued because it needs a separate signature -
that separate signature suffices to prove that it was added by a KDC and
not a user, plus the fact that the ticket itself is encrypted by the KDC
with a key that belongs to the service also guarantees that no user
could have modified the ticket enc part as returned by the KDC.

Therefore I think that applications can fully trust the i-realm/i-sname
fields of AD-KDC-Issued elements provided that the ad-checksum
validates.

Cheers,

Nico