Subject: [extensibility 5] per-message guidelines

From: Sam Hartman <[email-masked]>
Date: Fri, 7 Dec 2001 10:44:34 -0500 (EST)

This message contains two sets of guidelines for each message.  I
describe when extensible messages can be used, when the checksum of
Signed messages is to be included and what key is to be used.

I envision this text being folded into section 5 or section 3
depending on where people think it best goes.

These guidelines have not been reviewed by anyone else, so it is
likely that there are errors.  We have discussed the basic guidelines
and the tricky cases at length, so any errors are likely to be small.
However I thought that getting these out was more important than
waiting an extra day for Tom and Ken to review.

			    KerberosString

The general arm of the choice MUST be used in non-extensible (RFC
1510) messages.  As other arms of the choice are added to support
UTF8, clear rules for when they may be used will be included.  

				Ticket

A KDC must return a ticket1 in response to an AS-REQ1 or  tgs-req1
message.  If the KDC knows that the service supports extensible
messages it SHOULD return a ticket2 in response to a as-req2, tgs-req2
or PA-AS-REQ padata item. Se section xxx for details.

If a ticket2 is returned, the ticket MUST be checksummed using the
service key in which the ticket is encrypted.

			    EncTicketPart

[xxx We need to have some discussion on whether clients should be able
to downgrade a ticket2 to a ticket1.  Currently for simplicity we
assume not, but as discussed yesterday that may not be how we want to
structure the protocol.]

The KDC SHOULD use the encTicketPart2 arm of the choice if the service
is known to support extensible messages.  Otherwise, the
encTicketPart1 choice SHOULD be used.

				AS-REQ

The as-req1 arm of the choice 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.  See section xxx
for information on how to discover if a realm supports extensible
messages if not already known.  The checksum in the Signed wrapper
MUST NOT be included for as-req2

			       TGS-REQ

[Here we run into the first case where we have to choose which key to
sign ap-req messages in.  It really could be either session key or
subsession key; we're not sure it matters which option is picked so
long as we pick something and are consistent.]

A client MUST use a tgs-req1 with a ticket1 ticket-granting-ticket.  A
client SHOULD 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.  

				AS-REP

A KDC responding to an as-req1 MUST use the as-rep1 arm of the choice.
A KDC responding to an as-req2 or a PA-AS-REQ MUST use the as-rep2 arm
of the choice.  Note that a KDC supporting extensible messages in a
realm where not all KDCs have 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 xxx for
details.  The as-rep2 MUST be checksummed in the reply key used to
encrypt the enc-part.

			       TGS-REP

A KDC MUST respond to a tgs-req1 with a tgs-rep1 and a tgs-req2 with a
tgs-rep2.  The tgs-rep2 MUST be checksummed in the key used to encrypt
the enc-part.

				AP-REQ

[xxx do we allow ticket1 in ap-req2?; you certainly shouldn't send it
but shoulds vs must]

An ap-req2 SHOULD 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.

				AP-REP

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.

			       KRB-SAFE

ASN.1 extensions MUST NOT be used unless the sender knows that the
receiver supports extensibility.

			       KRB-PRIV

ASN.1 extensions MUST NOT be used unless the sender knows that the
receiver supports extensibility.

			       KRB-CRED

A krb-cred1 MUST be used
unless the sender knows that the receiver supports extensibility;
normally this is known because the sender received a ticket2 for the
receiver.  All the credentials in the encrypted part of a krb-cred1
MUST be ticket1 not ticket2.  The krb-cred2 MUST be checksummed in the
key used to encrypt the encrypted part of the message.  Some RFC 1510
implementations do not always encrypt KRB-CRED messages; since no key
is available for checksumming in such cases, krb-cred2 SHOULD NOT be
used.

			      KRB-ERROR

[xxx I actually want to run this by review before sending it out; want
to make sure I've covered all the tricky cases]