Subject: [extensibility 3] details of negotiation and guidelines

From: Sam Hartman <[email-masked]>
Date: Thu, 6 Dec 2001 00:02:02 -0500 (EST)

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: Sam Hartman <[email-masked]>
Date: 06 Dec 2001 11:31:08 -0500

>>>>> "Douglas" == Douglas E Engert <[email-masked]> writes:

    Douglas> What about requesting a forwardable ticket? How does the
    Douglas> client know if the receiving application supports
    Douglas> extensibility?  If you flag this this on a machine basis,

So, you know if the application you are forwarding to supports
extensibility based on what ap-req you sent it which is based on which
ticket you got.  If you have a protocol wher you are forwarding
Kerberos credentials but not using Kerberos authentication, then to be
safe you probably want to assume not extensible at least for the
forseeable future.

The only protocol that comes close to this is SSHv1, but there you
actually are forwarding to a specific principal you just aren't
encrypting the krb_cred message.

    Douglas> you are assuming all applications which use Kerberos on
    Douglas> that machine use the same code base. This may not be the
    Douglas> case if older applications are linked statically. It
    Douglas> might even be the case that the service receiving the
    Douglas> forwarded ticket does, but the application that will use
    Douglas> the ticket can not. Or is this a restriction, that they
    Douglas> must all be upgraded.

Blerg, teaches me to send out a message without double checking
against my open issues list.  You are correct that there are issues if
you have multiple implementations on the same machine or sharing a
credentials cache.

I intended to have a discussion of that in message 3, but failed to
check my notes and forgot to write it up.

We don't actually have a recommended solution to this case, but we do
have two possible alternatives.
I'll grab  text we have describing this and post it shortly.

    Douglas> Any special implications for cross realm tickets? Is this
    Douglas> treated as a service ticket, and the KDC has a floag in
    Douglas> its database indicating if the service can handle
    Douglas> extensibility?

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 06 Dec 2001 10:22:27 -0600

What about requesting a forwardable ticket? How does the client know
if the receiving application supports extensibility? 
If you flag this this on a machine basis, you are assuming all applications which 
use Kerberos on that machine use the same code base. This may not be the case
if older applications are linked statically. It might even be the case that the
service receiving the forwarded ticket does, but the application that will use
the ticket can not. Or is this a restriction, that they must all be upgraded. 

Any special implications for cross realm tickets? Is this treated as a service ticket,
and the KDC has a floag in its database indicating if the service can handle
extensibility?

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 6 Dec 2001 12:34:51 -0500

On Thu, Dec 06, 2001 at 12:24:59PM -0500, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
> 
>     Nicolas> I would say that sysadmins must not allow the use of new
>     Nicolas> Kerberos on hosts that have a mixture of old-only and new
>     Nicolas> Kerberos software support. Easy enough, yes? You just
>     Nicolas> refrain from telling your mixed hosts' KDCs that they are
>     Nicolas> ready for new Kerberos.
> 
> 
> For services, sure, or at least handle it on a principal by principal
> basis.  Really you probably want to have clever tricks in your
> application for updating service keys so sysadmins mostly don't think
> about it.

Key updates are not hard -- if you do nothing special in kadm5.acl any
principal can change its own keys, so it's not hard to cobble a cronjob
to change a host's keys periodically...

> But for clients it is more complex.  It seems desirable to me to be
> able to take advantage of the new features when talking to services
> that support it even if some applications like Oracle use old
> antequated code.

If you have a mixture of old-only and new Kerberos client software
support on one host, and you want to be able to use new Kerberos then
you need to use separate ccaches for the old-only and new Kerberos
clients... no?

If you have old-only services which accept forwarded creds and new
clients on the same host, no big deal -- remote clients will only
forward old creds.

If you have new services and old-only clients on the same host, then
you must not allow new creds to be forwarded to such hosts, which is
probably best done by indicating in the hosts' realm database entries
that they do not support new kerberos.

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: Nicolas Williams <[email-masked]>
Date: Thu, 6 Dec 2001 12:18:03 -0500

> >>>>> "Douglas" == Douglas E Engert <[email-masked]> writes:

[...]

> you have multiple implementations on the same machine or sharing a

I would say that sysadmins must not allow the use of new Kerberos on
hosts that have a mixture of old-only and new Kerberos software
support. Easy enough, yes? You just refrain from telling your mixed
hosts' KDCs that they are ready for new Kerberos.

Sysadmins have to be aware of all software that uses Kerberos on their
hosts so they can test new Kerberos support.

[...]

>     Douglas> its database indicating if the service can handle

That's how it should be, IMHO. As long as ALL KDCs in a given realm all
support new Kerberos or all don't.

Cheers,

Nico

---

From: Sam Hartman <[email-masked]>
Date: 06 Dec 2001 12:24:59 -0500

---

From: Sam Hartman <[email-masked]>
Date: 06 Dec 2001 12:46:39 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Thu, Dec 06, 2001 at 12:24:59PM -0500, Sam Hartman
    >> 
    >> 
    >> For services, sure, or at least handle it on a principal by
    >> principal basis.  Really you probably want to have clever
    >> tricks in your application for updating service keys so
    >> sysadmins mostly don't think about it.

    Nicolas> Key updates are not hard -- if you do nothing special in
    Nicolas> kadm5.acl any principal can change its own keys, so it's
    Nicolas> not hard to cobble a cronjob to change a host's keys
    Nicolas> periodically...

Yeah, kadmin and a cron job is a fine solution if you are using MIT
Kerberos.  You might want to use an implementation of
kerberos-set-password for a more interoperable solution.

    >> But for clients it is more complex.  It seems desirable to me
    >> to be able to take advantage of the new features when talking
    >> to services that support it even if some applications like
    >> Oracle use old antequated code.

    Nicolas> If you have a mixture of old-only and new Kerberos client
    Nicolas> software support on one host, and you want to be able to
    Nicolas> use new Kerberos then you need to use separate ccaches
    Nicolas> for the old-only and new Kerberos clients... no?

Well, that depends on your client implementation; I suspect that MIT
will use CCAPI and have a shared ccache that stores ticket1, tickt2
and krb4 tickets all in one object.

But yes at some level they are distinct.

The question basically boils down to how much protocol support do we
give you?  We could for example let you use a ticket2 TGT to get a
ticket1.  This would allow you to forward ticket1 when appropriate or
if you are using CCAPI and you find that you don't have a ticket1 but
need one then cons one up behind the scenes.

Alternatively we could completely ignore the issue at the protocol
level.  You could either kinit twice or more likely have a kinit that
created two ccaches at once.

    Nicolas> If you have old-only services which accept forwarded
    Nicolas> creds and new clients on the same host, no big deal --
    Nicolas> remote clients will only forward old creds.

    Nicolas> If you have new services and old-only clients on the same
    Nicolas> host, then you must not allow new creds to be forwarded
    Nicolas> to such hosts, which is probably best done by indicating
    Nicolas> in the hosts' realm database entries that they do not
    Nicolas> support new kerberos.

You could do this.   I'm not convinced it is right.

---

From: Sam Hartman <[email-masked]>
Date: 06 Dec 2001 13:16:16 -0500

>> >> >> >> For services, sure, or at least handle it on a
    >> principal by >> principal basis.  Really you probably want to
    >> have clever >> tricks in your application for updating service
    >> keys so >> sysadmins mostly don't think about it.
    >> 
    >>  Yeah, kadmin and a cron job is a fine solution if you are
    >> using MIT Kerberos.  You might want to use an implementation of

    Nicolas> Granted. There is none for MIT KDCs yet, correct?

We implement the original set-password, but few people use that for
servers.

    >> >> But for clients it is more complex.  It seems desirable to
    >> me >> to be able to take advantage of the new features when
    >> talking >> to services that support it even if some
    >> applications like >> Oracle use old antequated code.
    >> 
    >>  Well, that depends on your client implementation; I suspect
    >> that MIT will use CCAPI and have a shared ccache that stores
    >> ticket1, tickt2 and krb4 tickets all in one object.
    >> 
    >> The question basically boils down to how much protocol support
    >> do we give you?  We could for example let you use a ticket2 TGT
    >> to get a ticket1.  This would allow you to forward ticket1 when
    >> appropriate or if you are using CCAPI and you find that you
    >> don't have a ticket1 but need one then cons one up behind the
    >> scenes.

    Nicolas> Well, new Kerberos MUST support using a new TGT to get an
    Nicolas> old service ticket for a principal which does not support
    Nicolas> new Kerberos.

True.

    Nicolas> And if you can make old-AP-REQs with new tickets, then
    Nicolas> old clients can use new tickets to make old TGS-REQs.

That's an open if I believe.  However, even if you want an old ticket
back, you may want a new TGS-REQ.  We may decide we don't care about
this, or we may simply add a flag to KDC-REQ to ask for an old|new
ticket.

    Nicolas> As long as the old client has the ticket encpart, its
    Nicolas> session key and the ticket's target principal name
    Nicolas> (there's the rub, wrt UTF-8 princ names) it should all
    Nicolas> work, even with new tickets.

False as discussed in another message.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 6 Dec 2001 13:05:29 -0500

> kerberos-set-password for a more interoperable solution.

Granted. There is none for MIT KDCs yet, correct?

> need one then cons one up behind the scenes.

Well, new Kerberos MUST support using a new TGT to get an old service
ticket for a principal which does not support new Kerberos.

And if you can make old-AP-REQs with new tickets, then old clients can
use new tickets to make old TGS-REQs.

As long as the old client has the ticket encpart, its session key and
the ticket's target principal name (there's the rub, wrt UTF-8 princ
names) it should all work, even with new tickets.

Now, wrt UTF-8 names -- old [MIT/Heimdal] clients would be unable to use
old Kerberos with new services with non-ASCII names. This is true
regardless of whether the old clients in question have new or old TGTs
in their ccaches...

So, I suspect that even old MIT clients will be able to use new TGTs,
but, tickets with non-ASCII princ names might cause the old clients,
possibly, to crash (I also doubt this, since old MIT clients treat names
as strings of 8-bit chars with no nulls, which is what UTF-8 names would
look like to them).

> created two ccaches at once.

I'd prefer not to use new Kerberos on a given host until all software on
it supports new Kerberos. I say this as a sysadmin.

> You could do this.   I'm not convinced it is right.

Why would it not be right?!

What I suggest amounts to waiting till all software on a given host
supports new Kerberos before using new Kerberos with that host. I mean,
heck, if you have no new Kerberos support on a given host then you must
wait until you do to use new Kerberos.

****

Things will get a bit more interesting with user-to-user exchanges...

KDCs can be asked to know if a given host principal supports new
Kerberos because host principals are associated with hosts which, in
turn host software which in turn can be upgraded and inventoried.

But can KDCs be asked to know whether a user principal supports new
Kerberos, considering that that user principal can be using pretty much
any host any time? Can the KDC be expected to map HostAddresses to host
principals and determine new Kerberos status from that?

Cheers,

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 6 Dec 2001 13:50:16 -0500

> We implement the original set-password, but few people use that for

You also implement password changing via kadmin. Do you have any plans
to implement kerberos-set-password any time soon?

> False as discussed in another message.

Yes. There's other things in the ccache that would break old clients
with new tickets.

As a sysadmin I would simply not allow the use of new Kerberos with a
host which has any old-only sofware still in use. It sounds too
complicated to manage mixed usage.

Cheers,

Nico

---

From: Martin Rex <[email-masked]>
Date: Thu, 6 Dec 2001 22:29:32 +0100 (MET)

> principals and determine new Kerberos status from that?

Didn't user-2-user contain two TGTs (one of each user)?

If the KDC stuffs everything it learns about a user's client feature
into the TGT during the AS-exchange then it should be even easier
than keeping an inventory of the services...

-Martin