Subject: RE: [extensibility 3] details of negotiation and guidelines

From: "John Brezak" <[email-masked]>
Date: Tue, 11 Dec 2001 16:24:41 -0800

What would happen when a client has a username that cannot be expressed
in the IA5String (constrained GeneralString) that must be in a as-req?
The PA-AS-REQ can carry the correct names because it can use Utf8String,
but isn't it a problem if both of the requests are not carrying the
exact same information?

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2001 9:02 PM
To: [email-masked]
Subject: [extensibility 3] details of negotiation and guidelines

The outline of our proposal in the last message left a few important
details unspecified.  This message should fill in all details that are
not tied to a specific ASN.1 type.  The next and likely final message
will  include a krb5 ASN.1 module.

			  Client Negotiation

Clients need to find out whether their KDC supports the extensible
format messages.  The easiest way for this to happen is for a client to
have
cached whether its KDC supports the extensible messages.    If the
client
knows it is talking to a new KDC then the client can simply send a
extensible AS-REQ message (the as-req2 arm of the choice).

As Nico has pointed out several times, we want to allow clients to cache
this state on a per-realm basis rather than per-KDC basis.  This means
that 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.  

However, if a client does not have information about a realm cached it
needs to send an AS-REQ that new KDCs will treat as a extensible message
but old KDCs will treat as an old message.  Our proposed solution is to
introduce PA-AS-REQ, a new padata type that is the encoding of a
extensible
AS-REQ.     This element will be encoded as one of the padata elements
of the old AS-REQ.  

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.

If a KDC receives a new AS-REQ or a PA-AS-REQ in an old AS-REQ, then it
responds with an extensible AS-REP.  Otherwise it responds with an old
AS-REP.

For other messages, we follow the general rule that if you receive an
extensible message you should respond with an extensible message.
Specific per-message rules will be included along with messages but
AS-REQ is the only really interesting case.  As discussed in the
outline, tickets are somewhat special in that they convey information
about the capabilities of the service.  A KDC MUST NOT issue a ticket2
(extensible format ticket) for a service unless the KDC knows that
service supports extensible messages.  However, the encrypted part of
the ticket MAY use an extensible format if the service supports
extensible messages even if the client does not.  This way, if new
extensions are added to the encrypted part of a ticket, then services
supporting extensible messages can take advantage of these extensions
even when talking to old clients.

If multiple services or machines use the same principal, then the KDC
cannot issue ticket2 until all services using a particular principal
support Kerberos extensibility.  Thus, a new KDC MAY return a ticket1
inside an extensible KDC-REP.

		       Authenticated Cleartext

Before we describe how we handle authenticated cleartext, let's look at
how we would structure the ASN.1  ignoring the problem of authenticated
cleartext.  The following is  an example of an extensible AP-REQ that
does not support solving the authenticated cleartext problem:

AP-REQ		::= CHOICE {
	ap-req1		[APPLICATION 14] AP-REQ-COMMON
				(WITH COMPONENTS {
					...,
					extensions ABSENT
					-- also excluding
					-- ASN.1 extensions
				}),
	ap-req2		[APPLICATION 18] AP-REQ-COMMON
}

AP-REQ-COMMON	::= SEQUENCE {
	pvno		[0] INTEGER,
	msg-type	[1] INTEGER,
	ap-options	[2] APOptions,
	ticket		[3] Ticket,
	authenticator	[4] EncryptedData -- Authenticator --,
	extensions	[5] ApReqExtensions OPTIONAL,
	...
}

As discussed  previously  the AP-req becomes a choice with  two
alternatives; one for RFC 1510 compatibility and one that supports
extensibility.  There are two basic approaches  for authenticated
cleartext: types can be wrapped  with a checksum in the wrapping type or
a checksum can be included in the type being checksummed.  Adding
checksums to the typed being checksummed creates significant
implementation complexity and is likely to lead to errors that prohibit
interoperability, so  we do not favor that option.  Instead, we propose
that the AP-REQ choice be as follows:

AP-REQ		::= CHOICE {
	ap-req1		[APPLICATION 14] AP-REQ-COMMON
				(WITH COMPONENTS {
					...,
					extensions ABSENT
					-- also excluding
					-- ASN.1 extensions
				}),
	ap-req2		[APPLICATION 18] Signed{AP-REQ-COMMON}
}

The Signed type is an ASN.1 parameterized type that expands to a
sequence containing an optional checksum and the type in braces.  Using
the parameterized type makes the ASN.1 much easier to read than having a
bunch of sequences for each signed type.  However, if the working group
is uncomfortable with this new ASN.1 syntax we can expand all the
instances of Signed before publication.  At least while actively
discussing the proposal we'd like to keep using Signed notation as it is
simpler to discuss.

All these checksums for wrapped types MUST be keyed checksums.  For each
message we will provide guidelines for when the checksum is included and
for what key is used.  Guidelines on when to include a checksum are
never ambiguous: a particular PDU is never correct both with and without
a checksum.  Implementations MUST reject messages where a checksum is
included and not expected or where a checksum is expected but not
included.

The AS-REQ is not protected by a checksum in a Signed type.  There is
not always a key available for this protection.  Instead, a checksum of
the AS-REQ is included in extensible KDC replies.

		      Extensibility Guidelines

[This part of the message is intended to go directly into the revisions
draft.  As such the tone is somewhat different.  Significant parts of
the rest of this messages and the earlier messages may form basis for
text going into revisions, but those sections will need editing for tone
and content.]

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.

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.

		  x.x.1 Compatibility with RFC 1510

Implementations of RFC 1510 did not use extensible ASN.1 types. Sending
additional fields not in RFC 1510 to these implementations may result in
undefined behavior, including discarded messages with no error
indications.  

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.  

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.

		  x.x.2  Sending Extensible Messages

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.

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.

		 x.x.3 Receiving Extensible Messages

Recipients of message 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.

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.

Many RFC 1510 implementations ignore unknown authorization data
elements.  Depending on these implementations to honor authorization
data restrictions may  create a security weakness.

---

From: Tom Yu <[email-masked]>
Date: 12 Dec 2001 01:15:10 -0500

>>>>> "jbrezak" == John Brezak <[email-masked]> writes:

jbrezak> What would happen when a client has a username that cannot be
jbrezak> expressed in the IA5String (constrained GeneralString) that
jbrezak> must be in a as-req?  The PA-AS-REQ can carry the correct
jbrezak> names because it can use Utf8String, but isn't it a problem
jbrezak> if both of the requests are not carrying the exact same
jbrezak> information?

We could argue that the PA-AS-REQ would be treated as authoritative in
that case.

---Tom

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 12 Dec 2001 20:34:12 -0500

Yes, but this brings up an interesting point: ASCII-only names are
needed for KDC newness probing. Yet the client may be trying to get a
ticket for a user whose name is decidedly non-ASCII.

So it might be useful to define one or more names for probing purposes
only...

Realms with non-ASCII names need not be probed, or, rather, wouldn't have
to be but for and by those implementations that use UTF-8 as
GeneralString now.

Cheers,

Nico

--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

---

From: "Jeffrey Altman [Kermit Project]" <[email-masked]>
Date: Wed, 12 Dec 2001 22:34:27 -0500

The way that Sam described the PA-AS-REQ is that if the PA-AS-REQ is
included that all of the AS-REQ is ignored.

Now if your question is:

    what should a new Kerberos implementation place into the
    GeneralString fields of the AS-REQ for use by old Kerberos
    implementations?

My answer would be:

    exactly what you place into those fields in your current
    implementation.

In other words, if you still have old Kerberos implementations
in use at your site, then you should restrict your use of
principal and service names to IA5Strings.  And if you can't
for whatever reason, then you do so accepting the risks described
in draft-ietf-krb-wg-info-ascii-gen-string-00.txt

- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 13 Dec 2001 02:20:08 -0500

> included that all of the AS-REQ is ignored.

Yes, but only if the KDC supports new Kerberos. If it doesn't then the
outer AS-REQ will not be ignored.

> in draft-ietf-krb-wg-info-ascii-gen-string-00.txt

If you can't then couldn't you use a bogus, but all-ASCII name? Just so
you could probe the KDC? If the result is an error about an unknown
principal, then you know that the KDC does not support new Kerberos.
Hmmm, then you have to be able to distinguish which name is unknown:
the name in the outer AS-REQ or the name in the inner AS-REQ?

This problem comes up only when probing a KDC (realm) to determine
whether it suports new Kerberos AND the user principal name you want to
get a ticket for happens to be a non-ASCII name.

The alternative is to send the non-ASCII name as GeneralString in the
outer AS-REQ and hope for the best.

Cheers,

Nico