Subject: Proposed changes to Kerberos revisions

From: Sam Hartman <[email-masked]>
Date: 18 Feb 2002 10:22:54 -0500

Here are the proposed changes I said I'd make last week.

I'll send these to Cliff early Tuesday.

Some of my changes are for the extensions document, some for
clarifications and some for both.  I've used the <extensions> tag to
mark sections destined only for extensions and the <clarifications>
tag to mark sections only for clarifications.  Hopefully Cliff can
write a simple script to pull these out and create the links he talked
about last week.

--- krbrev1-4.html	2002/02/07 14:12:28	1.1
+++ krbrev1-4.html	2002/02/15 19:37:22
@@ -384,7 +384,225 @@
 options for application authentication (e.g. the PKTAPP proposal) are
 provided.
 
-<H3>1.4.  Environmental assumptions</H3>
+
+<extensions>
+<H3> 1.4. Extensibility Model</h3>
+
+In the past, significant interoperability problems have been caused by
+different assumptions about how the Kerberos protocol can be extended.
+However, as the deployed base of Kerberos implementations grows,
+extending Kerberos becomes more important.  In order to insure that
+vendors and the IETF can extend the protocol while maintaining
+backward compatibility, this specification outlines a framework for
+extending Kerberos.
+<p>
+Kerberos provides two general mechanisms for protocol extensibility.
+Many protocol messages contain typed holes--sub-messages that contain
+an octet-string along with an integer that defines how to interpret
+the octet-string.  The integer types are registered centrally, but can
+be used both for vendor extensions and for extensions standardized in
+the IETF.
+
+<p>
+
+Most messages also contain ASN.1 extension markers.  These markers
+allow fields to be added in future versions of this specification.
+Because tag numbers and order in the sequence need to be agreed on in
+order to maintain interoperability, implementations MUST NOT include
+ASN.1 extensions except when those extensions are specified by IETF
+standards-track documents.
+
+<h3>1.4.1. Compatibility with RFC 1510</h3>
+
+Implementations of RFC 1510 did not use extensible ASN.1 types.
+Sending additional fields not in RFC 1510 to these implementations
+results in undefined behavior.  Examples of this behavior are known to
+include discarding messages with no error indications.
+
+<p>
+
+Where messages have been changed since RFC 1510, ASN.1 choice types
+are used; one arm of the choice provides a message compatible with RFC
+1510 and the other arm provides the current, extensible message.  
+
+<p>
+
+Implementations sending new messages MUST insure that the recipient
+supports these new messages.  Along with each extensible message is a
+guideline for when that message MAY be used.  IF that guideline is
+followed, then the recipient is guaranteed to understand the message.
+
+<p>
+
+<h3> 1.4.2. Sending Extensible Messages</h3>
+
+Care must be taken to make sure that old implementations can
+understand messages sent to them even if they do not understand an
+extension that is used.  Unless the sender knows the extension is
+supported, the extension cannot change the semantics of the core
+message or previously defined extensions.
+
+<p>
+
+For example, an extension including key information necessary to
+decrypt the encrypted part of a KDC-REP could only be used in
+situations where the recipient was known to support the extension.
+Thus when designing such extensions it is important to provide a way
+for the recipient to notify the sender of support for the extension.
+For example in the case of an extension that changes the KDC-REP reply
+key, the client could indicate support for the extension by including
+a padata element in the AS-REQ sequence.  The KDC should only use the
+extension if this padata element is present in the AS-REQ.  Even if
+policy requires the use of the extension, it is better to return an
+error indicating that the extension is required than to use the
+extension when the recipient may not support it; debugging why
+implementations do not interoperate is easier when errors are
+returned.
+
+<h3>1.4.3. Receiving Extensible Messages</h3>
+
+Recipients of  unknown message extensions (either in typed
+holes or ASN.1 types) should preserve the encoding of the extension
+but otherwise ignore the presence of the extension.  If the message is
+used later--for example, when a ticket is later used in an
+AP-REQ--then the unknown extensions MUST be included.
+
+<p>
+
+There is one exception to this rule.  If an unknown authorization data
+element type is received by a server either in an AP-REQ or in a
+ticket contained in an AP-REQ, then the authentication SHOULD fail.
+Authorization data is intended to restrict the use of the ticket.  If
+the service cannot determine whether the restriction applies to that
+service then a security weakness may result if the ticket can be used
+for that service.  Authorization elements that are optional can be
+enclosed in the AD-IF-RELEVANT element.
+
+<p>
+
+Many RFC 1510 implementations ignore unknown authorization data
+elements.  Depending on these implementations to honor authorization
+data restrictions may  create a security weakness.
+</extensions>
+<clarifications>
+<h3> 1.4. Extending Kerberos Without Breaking Interoperability</h3>
+
+In the past, significant interoperability problems have been caused by
+different assumptions about how the Kerberos protocol can be extended.
+However, as the deployed base of Kerberos implementations grows,
+extending Kerberos becomes more important.  This section gives
+							  guidelines
+							  that should
+							  enable
+							  implementers
+							  to extend
+							  Kerberos
+							  while
+							  maintaining
+							  interoperability.
+
+<p>
+
+The primary extension mechanism is typed holes--sub-messages that
+contain an octet-string along with an integer that defines how to
+interpret the octet-string--included in several Kerberos messages.  The
+integer types are registered centrally, but can be used both for vendor
+extensions and for extensions standardized in the IETF.
+
+<p>
+
+For many years it was believed that Kerberos could be extended simply by
+adding fields to the ASN.1 types.  This is not true.  Sending additional
+fields often results in the entire message being discarded with no error
+indication.  Future versions of this specification will provide a
+mechanism for the IETF to add ASN.1 fields without creating an
+interoperability problem.
+
+<p>
+Recipients of unknown message extensions should preserve the encoding of
+the extension but otherwise ignore the presence of the extension.
+Recipients MUST NOT decline a request simply because an extension is
+present.
+
+<p>
+
+There is one exception to this rule.  If an unknown authorization data
+element type is received by a server either in an AP-REQ or in a ticket
+contained in an AP-REQ, then the authentication SHOULD fail.
+Authorization data is intended to restrict the use of the ticket.  If
+the service cannot determine whether the restriction applies to that
+service then a security weakness may result if the ticket can be used
+for that service.  Authorization elements that are optional can be
+enclosed in the AD-IF-RELEVANT element.
+
+<p>
+
+Many RFC 1510 implementations ignore unknown authorization data
+elements.  Depending on these implementations to honor authorization
+data restrictions may  create a security weakness.
+
+<p>
+
+Care must be taken to make sure that old implementations can
+understand messages sent to them even if they do not understand an
+extension that is used.  Unless the sender knows the extension is
+supported, the extension cannot change the semantics of the core
+message or previously defined extensions.
+
+<p>
+
+For example, an extension including key information necessary to
+decrypt the encrypted part of a KDC-REP could only be used in
+situations where the recipient was known to support the extension.
+Thus when designing such extensions it is important to provide a way
+for the recipient to notify the sender of support for the extension.
+For example in the case of an extension that changes the KDC-REP reply
+key, the client could indicate support for the extension by including
+a padata element in the AS-REQ sequence.  The KDC should only use the
+extension if this padata element is present in the AS-REQ.  Even if
+policy requires the use of the extension, it is better to return an
+error indicating that the extension is required than to use the
+extension when the recipient may not support it; debugging why
+implementations do not interoperate is easier when errors are
+returned.
+</clarifications>
+
+<extensions>
+<h3>1.5. Authenticating Cleartext Portions of Messages</h3>
+
+One of the design goals of Kerberos was to avoid encrypting more of
+the authentication exchange that was required.  This reduces the load
+on the KDC and busy servers.  Also, at the time, it helped with
+certain legal export requirements.  Unfortunately, various denial of
+service attacks and downgrade attacks are possible unless this
+plaintext is somehow protected against modification.
+
+<p>
+
+The extensible variants of the messages described in this
+specification wrap the actual message in an ASN.1 sequence containing
+a keyed checksum of the contents of the message.  Guidelines in
+section 3 specify when the checksum MUST be included and what key MUST
+be used.  Guidelines on when to include a checksum are never
+ambiguous: a particular PDU is never correct both with and without a
+checksum.  With the exception of the KRB_ERROR message, receiving
+implementations MUST reject messages where a checksum is included and
+not expected or where a checksum is expected but not included.  The
+receiving implementation does not always have sufficient information
+to know whether a KRB_ERROR should contain a checksum.  Even so,
+KRB_ERROR messages with invalid checksums MUST be rejected and
+implementations MAY consider the presence or absence of a checksum
+when evaluating whether to trust the error.
+
+<p>
+
+This authenticated cleartext protection is provided only in the
+extensible variants of the messages; it is never used whan talking to
+an RFC 1510 implementation.
+
+
+</extensions>
+<H3>1.6. Environmental assumptions</H3>
 
 Kerberos imposes a few assumptions on the environment in which it can
 properly function:
@@ -426,7 +644,7 @@
 
 </UL>
 
-<h3>1.5.  Glossary of terms</H3>
+<h3>1.7.  Glossary of terms</H3>
 
 Below is a list of terms used throughout this document.
 
@@ -599,4 +817,10 @@
 
 Discussion related to Name Canonicalization has been dropped.
 
+<p>
+
+Folded in the introduction to extensibility and the authenticated
+cleartext solution.
+<p>
 
+Added clarifications version of extensibility comments.
--- krbrev2-6.html	2002/02/07 14:12:00	1.1
+++ krbrev2-6.html	2002/02/15 19:45:11
@@ -4,12 +4,35 @@
 indicate attributes of that ticket.  Most flags may be requested by a
 client when the ticket is obtained; some are automatically turned on
 and off by a Kerberos server as required.  The following sections
-explain what the various flags mean, and gives examples of reasons to
-use such a flag.  With the excepttion of the ANONYMOUS and INVALID
-flags clients may ignore ticket flags that are not recognized.
+explain what the various flags mean and give examples of reasons to
+use them.  With the excepttion of the ANONYMOUS and INVALID flags
+clients MUST ignore ticket flags that are not recognized.  KDCs MUST
+ignore KDC options that are not recognized.  Unfortunately some
+implementations of RFC 1510 are known to reject unknown KDC options,
+so clients may need to resend a request without KDC options added
+since RFC 1510 if their request is rejected.
+
+<p>
+
+Since KDCs ignore unknown options, clients MUST confirm that the
+resulting ticket meets their needs.  For example, as discussed in
+section 2.8, a client requiring anonymous communication needs to make
+sure that the ticket is actually anonymous.  A KDC that prohibits
+issuing of anonymous tickets or that does not understand the anonymous
+option would not return an anonymous ticket.
+
+<p>
+
+Note that it is not in general possible to determine whether an option
+was not honored because it was not understood or because it was
+rejected either through configuration or policy.  Designers of options
+should consider whether the distinction is important for their option.
+In cases where it is, a mechanism for the KDC to return an indication
+that the option was understood but rejected needs to be provided in
+the specification of the option.  Often in such cases, the mechanism
+needs to be broad enough to permit an error or reason to be returned.
 
-<H3>2.1.  Initial, pre-authenticated, and hardware authenticated
-tickets</H3>
+<H3>2.1.  Initial, pre-authenticated, and hardware authenticated tickets</H3>
 
 The INITIAL flag indicates that a ticket was issued using the AS
 protocol and not issued based on a ticket-granting ticket.
@@ -234,6 +257,12 @@
 originate from different users.  Users request anonymous ticket by
 setting the REQUEST-ANONYMOUS option in an AS or TGS request.
 
+<p>
+
+If a client requires anonymous communication then the client should check to make sure that the resulting ticket it actually anonymous.  A KDC that does not understand the anonymous-requested flag will not return an error, but will instead return a normal ticket.
+
+
+
 <H3>2.9.  Other KDC options</H3>
 
 There are three additional options which may be set in a client's
@@ -309,3 +338,6 @@
 Name canonicalization was then removed and set aside for a separate
 document.  Section 2.9.2 and .3 were renumbered to .1 and .2.
 
+<p>
+
+Discussion of how extensibility affects ticket flags and KDC options was added to the introduction.
--- krbrev3-4.html	2002/02/07 14:12:00	1.1
+++ krbrev3-4.html	2002/02/17 22:05:02
@@ -2,6 +2,12 @@
 
 The following sections describe the interactions between network
 clients and servers and the messages involved in those exchanges.
+<extensions>
+<p>
+
+As discussed in section 1.4, most messages have an extensible varient.  This section gives guidelines for when the extensible varients should be used and for messages wrapped in integrity checksums, what key is used.
+</extensions>
+
 
 <H3>3.1.  The Authentication Service Exchange</H3>
 
@@ -44,6 +50,11 @@
 in the client's secret key.  The KRB_AS_REP message contains
 information which can be used to detect replays, and to associate it
 with the message to which it replies.  
+<extensions>
+The extensible variant of the
+KRB_AS_REP message also contains a checksum that the client can use to
+determine whether its request was modified in transit.
+</extensions>
 
 <P>
 
@@ -52,25 +63,33 @@
 simply sends a reply without knowing or caring whether they are the
 same.  This is acceptable because nobody but the principal whose
 identity was given in the request will be able to use the reply. Its
-critical information is encrypted in that principal's key.  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 may be used for pre-authentication as described in section
-3.1.1.
+critical information is encrypted in that principal's key.  However,
+an attacker can send a KRB_AS_REQ message to get known plaintext in
+order to attack the principal's key.  Especially if 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.
 
 <P>
 
 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 encrypted.  The KRB_ERROR message contains information which can
-be used to associate it with the message to which it replies.  If
-suitable preauthentication has occurred, an optional checksum may be
-included in the KRB_ERROR message to prevent fabrication or
-modification of the KRB_ERROR message.  When a checksum is not
-present, the lack of integrity protection precludes the ability to
-detect replays, fabrications, or modifications of the message, and the
-client must not depend on information in the KRB_ERROR message for
-security critical operations.
+be used to associate it with the message to which it replies.  
+<extensions>
+The extensible variant of the KRB_ERROR message provides for a
+checksum to protect against fabrication or modification.  As discussed
+in section 1.5, the client may not always have enough information to
+know whether the checksum should have been included by the KDC.  When
+a checksum is not present, the lack of integrity protection precludes
+the ability to detect replays, fabrications, or modifications of the
+message, and the client must not depend on information in the
+KRB_ERROR message for security critical operations.
+</extensions>
+<clarifications>
+The contents of the KRB_ERROR message are not integrity-protected.  As such,  the client cannot detect replays, fabrications or modifications.  A solution to this problem will be included in a future version of the protocol.
+</clarifications>
 
 <H4>3.1.1.  Generation of KRB_AS_REQ message</H4>
 
@@ -88,11 +107,101 @@
 
 The client prepares the KRB_AS_REQ message and sends it to the KDC.
 
+<extensions>
+<p>
+The as-req1 message MUST be used unless the client knows that the
+realm of the KDC supports extensible messages.  If the client receives
+an as-rep2 from a KDC in the realm, then the client can assume that
+the realm supports extensible messages and MAY send as-req2 messages
+in future.
+
+<p>
+
+If any KDC in the realm claims to support extensible messages all
+the KDCs in the realm MUST accept the extensible messages.  For staged
+upgrades realms can first install KDCs that support the new messages
+and after all KDCs are upgraded the realm can then start using the new
+messages.  
+
+<p>
+
+If the client does not have information on the realm's capabilities
+		    cached, it needs to discover whether the realm
+		    supports extensible messages.  Two mechanisms are
+		    provided to do this.
+
+<p>
+
+A client can use the pa-as-req padata type.  This element includes the
+		      encoding of a as-req2 message and is included in
+		      the padata field of an old as-req1 message.
+
+<p>
+
+Old KDCs or new KDCs that are not responding to new messages yet will
+ignore PA-AS-REQ padata elements.  Old KDCs already ignore padata they
+do not understand.  New KDCs must ignore everything in the AS-REQ
+besides the PA-AS-REQ element.  In particular, new KDCs only consider
+the padata elements in the PA-AS-REQ's padata sequence.  They ignore
+any padata elements in the outer AS-REQ other than the  PA-AS-REQ
+element.    Clients MUST NOT send more than one PA-AS-REQ padata
+element, MUST NOT send a PA-AS-REQ element inside another PA-AS-REQ
+element and MUST NOT  send a PA-AS-REQ in a TGS-REQ.
+
+<p>
+
+The second discovery mechanism is provided by the pre-authentication
+			  required error that a KDC returns in
+			  response to an as-req1 message.  A new KDC
+			  that is responding to extensible messages
+			  MUST include a padata element of type
+			  pa-as-req  with no associated data in
+			  pre-authentication required errors.  The
+			  presence of this element indicates
+			  willingness to accept as-req2 messages.
+			  Clients that can entirely specify their
+			  request using the old as-req1 message May
+			  send such a message.  For realms that
+			  require pre-authentication, the client will
+			  receive a pre-authentication required error
+			  that indicates whether new messages are
+			  supported.  Unfortunately clients using this
+			  discovery mechanism rather than directly
+			  sending pa-as-req in the original message
+			  will end up using old messages in realms
+			  that do not require pre-authentication.
+
+<p>
+
+Sometimes a client may not be able to express a principal name or
+			    other option in an as-req1.  Such clients
+			    MUST use the first discovery mechanism.
+			    They SHOULD send an as-req1 with a client
+			    and server principal consisting of a
+			    single question mark (`?').  This request
+			    is guaranteed to generate an error if the
+			    KDC only supports as-req1.  The real
+			    request is encoded in the pa-as-req
+			    element.
+
+
+<p>
+
+The checksum is never included in as-req2 messages.  Instead the
+			    as-rep2 includes a checksum of the as-req2
+			    received at the KDC.  The client SHOULD
+			    verify this checksum against the message
+			    sent to detect modifications.
+</extensions>
+
+
 <H4>3.1.2.  Receipt of KRB_AS_REQ message</H4>
 
 If all goes well, processing the KRB_AS_REQ message will result in the
 creation of a ticket for the client to present to the server.  The
-format for the ticket is described in section 5.3.1.  The contents of
+format for the ticket is described in section 5.3.1.  See section
+			      3.xticket for guidelines on what ticket
+			      format to use.  The contents of
 the ticket are determined as follows.
 
 <H4>3.1.3.  Generation of KRB_AS_REP message</H4>
@@ -118,29 +227,39 @@
 <P>
 
 When responding to an AS request, if there are multiple encryption
-keys registered for a client in the Kerberos database (or if the key
-registered supports multiple encryption types; e.g. DES3-CBC-SHA1 and
-DES3-CBC-SHA1-KD), 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 etype for which an encryption key is
-available is used.  The encryption method used to protect the
-encrypted part of the KRB_TGS_REP message is the keytype of the
-session key found in the ticket granting ticket presented in the
-KRB_TGS_REQ.
+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
+etype for which an encryption key is available is used.  The
+encryption method used to protect the encrypted part of the
+KRB_TGS_REP message is the keytype of the session key found in the
+ticket granting ticket presented in the KRB_TGS_REQ.
 
 <P>
 
-If the user's key was generated using an alternate string to key
-function than that used by the selected encryption type, information
-needed by the string to key function will be returned to the client in
-the padata field of the KRB_AS_REP message using the PA-PW-SALT,
-PA-AFS3-SALT, or similar pre-authentication typed values.  This does
-not affect the encryption performed by the KDC since the key stored in
-the principal database already has the string to key transformation
-applied.
-
+When the user's key is generated from a password or pass phrase, the
+		  string-to-key function for the particular encryption
+		  key type is used, as specified in [KCRYPTO].  The
+		  salt value and additional parameters for the
+		  string-to-key function have default values
+		  (specified by section 6 and by the encryption
+		  mechanism specification, respectively) that may be
+		  overridden by preauthentication data (PA-PW-SALT,
+		  PA-AFS3-SALT, PA-ETYPE-INFO, PA-S2K-PARAMS, etc).
+		  Since the KDC is presumed to store a copy of the
+		  resulting key only, these values should not be
+		  changed for password-based keys except perhaps when
+		  changing the principal's key.
+
+		  <p>
+
+It is not possible to reliably generate a user's key given a pass
+		    phrase without contacting the KDC, since it will
+		    not be known whether alternate salt or parameter
+		    values are required.
+		    
 <P>
 
 When the etype field is present in a KDC request, whether an AS or TGS
@@ -224,17 +343,32 @@
 
 <P>
 
-If all of the above succeed, the server will encrypt ciphertext part
-of the ticket using the encryption key extracted from the server
+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, and sends the
-message to the client.  See section A.2 for pseudocode.
+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.  See section A.2 for
+pseudocode.
+
+<extensions>
+<p>
+
+A KDC responding to an as-req1 MUST use the as-rep1.  A KDC responding
+to an as-req2 or a PA-AS-REQ MUST use the as-rep2 .  Note that a KDC
+supporting extensible messages in a realm where not all KDCs have been
+upgraded to support extensible messages should respond to an as-req1
+(using a as-rep1 response) even if it contains a PA-AS-REQ padata
+element; see Section 3.1.1 for details.  The as-rep2 MUST be
+checksummed in the reply key used to encrypt the enc-part.  The
+checksum of the as-req included in the as-rep should be encrypted in
+the same key.
+</extensions>
 
 <H4>3.1.4.  Generation of KRB_ERROR message</H4>
 
@@ -244,6 +378,13 @@
 values.  The error message contents and details are described in
 Section 5.9.1.
 
+<extensions>
+<p>
+XXX this is filler for the checksumming guidelines.  We have
+	discussion of what  we  want on the list, but I'm focusing on
+	clarifications, so I don't have time to write it up now.
+</extensions>
+
 <H4>3.1.5.  Receipt of KRB_AS_REP message</H4>
 
 If the reply message type is KRB_AS_REP, then the client verifies that
@@ -337,6 +478,13 @@
 end server along with any additional application-specific information.
 See section A.9 for pseudocode.
 
+<extensions>
+<p>
+An extensible ap-req2 MUST be used if a ticket2 is used; an ap-req1 otherwise.
+The ap-req2 MUST be checksummed in the xxx session key of the ticket
+used.
+</extensions>
+
 <H4>3.2.3.  Receipt of KRB_AP_REQ message</H4>
 
 Authentication is based on the server's current time of day (clocks
@@ -385,15 +533,14 @@
 the KRB_AP_ERR_BAD_INTEGRITY error is returned.  The name and realm of
 the client from the ticket are compared against the same fields in the
 authenticator.  If they don't match, the KRB_AP_ERR_BADMATCH error is
-returned (they might not match, for example, if the wrong session key
-was used to encrypt the authenticator).  The addresses in the ticket
-(if any) are then searched for an address matching the
-operating-system reported address of the client.  If no match is found
-or the server insists on ticket addresses but none are present in the
-ticket, the KRB_AP_ERR_BADADDR error is returned.  If the local
-(server) time and the client time in the authenticator differ by more
-than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW
-error is returned.
+returned; this normally is caused by a client error or attempted
+attack.  The addresses in the ticket (if any) are then searched for an
+address matching the operating-system reported address of the client.
+If no match is found or the server insists on ticket addresses but
+none are present in the ticket, the KRB_AP_ERR_BADADDR error is
+returned.  If the local (server) time and the client time in the
+authenticator differ by more than the allowable clock skew (e.g., 5
+minutes), the KRB_AP_ERR_SKEW error is returned.
 
 <P>
 
@@ -481,6 +628,13 @@
 The KRB_AP_REP message is encrypted in the session key extracted from
 the ticket.  See section A.11 for pseudocode.
 
+<extensions>
+<p>
+An ap-rep2 MUST be used to respond to an ap-rep2; ap-rep1 MUST be used
+to respond to ap-req1.  The ap-req2 MUST be checksummed in the xxx
+session key of the ticket used in the AP-REQ.
+</extensions>
+
 <H4>3.2.5.  Receipt of KRB_AP_REP message</H4>
 
 If a KRB_AP_REP message is returned, the client uses the session key
@@ -493,6 +647,8 @@
 
 <H4>3.2.6.  Using the encryption key</H4>
 
+XXX This seems inconsistent with crypto-architecture; we should look
+    at before publication.
 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and
 server share an encryption key which can be used by the application.
 In some cases, the use of this session key will be implicit in the
@@ -602,9 +758,8 @@
 be used to detect replays, and to associate it with the message to
 which it replies.  The KRB_ERROR message also contains information
 which can be used to associate it with the message to which it
-replies, but except when an optional checksum is included in the
-KRB_ERROR message, it is not possible to detect replays or
-fabrications of such messages.
+replies.  The same comments about integrity protection of KRB_ERROR
+      messages mentioned in section 3.1 apply to the TGS exchange.  
 
 <H4>3.3.1.  Generation of KRB_TGS_REQ message</H4>
 
@@ -657,6 +812,15 @@
 Once prepared, the message is sent to a Kerberos server for the
 destination realm.  See section A.5 for pseudocode.
 
+<extensions>
+<p>
+A client MUST use a tgs-req1 with a ticket1 ticket-granting-ticket.  A
+client MUST  use tgs-req2 with a ticket2 ticket-granting-ticket.  The
+tgs-req2 MUST be checksummed in the xxx session key of the ticket used
+to construct the PA-TGS-REQ AP-REQ message.  
+</extensions>
+
+
 <H4>3.3.2.  Receipt of KRB_TGS_REQ message</H4>
 
 The KRB_TGS_REQ message is processed in a manner similar to the
@@ -942,12 +1106,16 @@
 
 When an application wishes to send a KRB_SAFE message, it collects its
 data and the appropriate control information and computes a checksum
-over them.  The checksum algorithm should be a keyed one-way hash
-function (such as the RSA- MD5-DES checksum algorithm specified in
-section 6.4.5, or the DES MAC), generated using the sub-session key if
-present, or the session key.  Different algorithms may be selected by
-changing the checksum type in the message.  Unkeyed or
-non-collision-proof checksums are not suitable for this use.
+over them.  The checksum algorithm should be the keyed checksum
+mandated to be implemented along with the crypto system used for the
+sub-session or session key.  The checksum is generated using the
+sub-session key if present, or the session key.  Some implementations
+use a different checksum algorithm for KRB_SAFE messages but doing so
+in a interoperable manner is impossible.  Implementations should
+accept any checksum algorithm they implement that both has adequate
+security and that has keys compatible with the sub-session or session
+key.  Unkeyed or non-collision-proof checksums are not suitable for
+this use.
 
 <P>
 
@@ -990,7 +1158,8 @@
 and type fields match the current version and KRB_SAFE, respectively.
 A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
 error.  The application verifies that the checksum used is a
-collision-proof keyed checksum, and if it is not, a
+collision-proof keyed checksum that uses keys compatible with the
+sub-session or session key as appropriate, and if it is not, a
 KRB_AP_ERR_INAPP_CKSUM error is generated.  If the sender's address
 was included in the control information, the recipient verifies that
 the operating system's report of the sender's address matches the
@@ -1101,6 +1270,12 @@
 negotiated via subkeys, or the session key if no negotiation has
 occurred).
 
+<p>
+
+xxx Implementation note about unencrypted KRB_CRED messages go here.
+      Need to make sure we  understand what MIT does and reconcile with
+      Microsoft.
+
 <H4>3.6.2.  Receipt of KRB_CRED message</H4>
 
 When an application receives a KRB_CRED message, it verifies it.  If
@@ -1229,3 +1404,19 @@
 7/01 - removed reference to name canonicalization.

+
+<p>
+Changed may preauthenticate to should preauthenticate and included note
+about known plaintext attacks.
+
+<p>
+
+
+Remove text about keys that support multipmle encryption types.  The
+ crypto draft doesn't really define things that way and it is out of
+ scope for the protocol spec anyway.
+
+<p>
+Added some useful text for clarifications.  There are few places where
+      placeholders rather than text have been added.  Once text is
+      agreed on these will be replaced.