Subject: [Ietf-krb-wg] kerberos ticket extentions

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 13 Aug 2008 17:34:37 +0100

Hello,

To make progress for PK-CROSS we need ticket extensions. Please  
consider adopting

http://www.ietf.org/internet-drafts/draft-lha-krb-wg-ticket-extensions-00.txt

Love

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 18 Aug 2008 12:56:42 -0400

> http://www.ietf.org/internet-drafts/draft-lha-krb-wg-ticket-extensions-00.txt

First: Yuck!  That's a horrible abuse of data fields.

*ahem*

Okay, now that I've got that off my chest, as to the actual specifics  
of the proposal...

In section 2 you distinguish between AS and TGS exchanges, when I  
think the relevant distinction is TGT versus service ticket.  In fact,  
you could say something like:

"The KDC MUST NOT use this extension in an AS or TGS reply unless it  
is known that all instances of the service in question support it.  In  
particular, a (local or cross-realm) TGT MUST NOT include this  
extension unless all of the KDCs to which it may be sent are known to  
support it."

P.4: Why is krb5int32 introduced instead of continuing to use Int32?   
The usual naming for checksum field names in RFC 4120 is "cksum" (or  
"ad-checksum"); it would be good to keep consistency with that and not  
add new abbreviations.

Bottom of page 4, should read something like: "Negative ticket  
extension [singular] types (te-type) are [plural] for private  
extensions..."  For private extensions *and* only for  
experimentation?  If a site has finished experimenting with their new  
private extension and wants to deploy it internally, they are  
(theoretically) not allowed to use negative numbers any more because  
it's no longer experimental?  I think private *or* experimental would  
make more sense.

Page 5 says the KDC should only return "this extension" in the TGS-REQ  
(actually that should have been TGS-REP) for services known to support  
"these extension".  Ignoring the number disagreement, I assume this is  
talking about the use of TBETicket and not specific encapsulated  
extensions?

The document already says unknown types must be ignored by the client  
and server.  But is the criticality question already settled, or might  
we need to add a new magic type later that indicates critical  
extensions to client and/or server?  Actually, we can't add it later,  
because it can be ignored by clients and servers that don't understand  
it.

P.5: "is specificing" -> "specifies"?

What does the checksum cover?  Does it have to be separately defined  
per type?

If the session key of the returned ticket is normally what's expected  
to be used to compute the checksum, then I think the security  
considerations section should highlight that, and the fact that it  
means it's not a safe channel for information between KDC and client,  
if an app server has the service key.  (Using the reply key has  
similar issues in a few cases, as discussed elsewhere.)

I think the Security Considerations should list some of the problems  
in a little more detail, like the potential for a MITM to downgrade to  
a normal ticket, or add or remove specific extensions, or do cut-and- 
paste between different messages (either replies to different  
requests, or different replies to the same request possibly triggered  
by the attacker retransmitting the request to different KDCs).  It  
seems to me we could use a document with special guidance for  
extension designers as to how to protect those ticket extensions or  
preauth data that should be bound to specific requests and/or replies,  
what degree of protection different approaches offer, etc.  I'm  
hoping, even if we don't go forward with FAST, that the preauth  
framework document would at least start to cover some of this, but  
with this draft, ticket extensions may need such a treatment also.

If it's likely that future extensions might be defined that need to  
avoid this sort of attack, perhaps this introduction of ticket  
extensions should provide the framework for it, better integrated than  
it might be as a later add-on.

And, once again, I wonder if we'll ever have a transition scheme from  
hacks like this (and FAST's duplication of messages) to clean,  
efficient, updated, internationalized, integrity-protected versions of  
the messages or exchanges that don't require these hacks.  If we're  
using Kerberos protocol v5.4 in ten years, what will it look like?

Ken

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 18 Aug 2008 19:45:02 +0100

Hello Ken,

Thanks for you comments.

> First: Yuck!  That's a horrible abuse of data fields.

Please propose a better solution that works w/o deploying new clients.

> you could say something like:

I didn't see any diffrence, but I took your text and modified to fit  
your comment below.

> "ad-checksum"); it would be good to keep consistency with that and not

Because I took the asn1 code from an implementation and then failed to  
use search and replace feature of my editor.

> it's no longer experimental?  I think private *or* experimental would

Change it to this:

	Negative ticket extension types (te-type) is private
	extensions and MUST only be used for experimentation or
	private use.

> talking about the use of TBETicket and not specific encapsulated

Changed your text to this:

	The KDC MUST NOT use >>extended tickets<< in an AS or TGS reply
	unless it is known that all instances of the service in
	question support it.  In particular, a (local or cross-realm)
	TGT MUST NOT use >>extended tickets<< unless all of the KDCs to
	which it may be sent are known to support it.

> because it can be ignored by clients and servers that don't understand

I dont like negative constructions.

> P.5: "is specificing" -> "specifies"?

yes.

> What does the checksum cover?  Does it have to be separately defined

Because the key might not be the session key of the ticket, yes.

The ticket extension might tell the server what the actual session key  
is.

> similar issues in a few cases, as discussed elsewhere.)

The ticket is for servers, so the channel is not meant for KDC and  
client communication.

> it might be as a later add-on.

"It is up to the consumers of this interface to make sure its used  
safely."

Added this text to Security Considerations:

	Some of the issues that the exensions need to protect themself
	from are: MITM downgrade to normal ticket, add or remove
	extentions, cut and paste extensions between requests,
	retransmission of requqests to a diffrent KDC.

> using Kerberos protocol v5.4 in ten years, what will it look like?

Yeah, we can all dream about Kerberos 6 where we remove all this cruft.

Ticket ::= [APPLICATION 1] SEQUENCE {
	tkt-vno[0]		krb5int32,
	realm[1]		        Realm,
	sname[2]		PrincipalName,
	enc-part[3]		EncryptedData
	ext-data[4]             SEQ OF TicketExtension OPTIONAL
}

I'm fine to add a flag that tell the KDC that the client supports  
these tickets, so we can deprecate the ugly hack in 10 years or so.

Love

http://www.ietf.org/internet-drafts/draft-lha-krb-wg-ticket-extensions-01.txt

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 18 Aug 2008 21:07:19 +0100

> "It is up to the consumers of this interface to make sure its used

The whole section now looks like this.

Security Considerations

	This document describes how to extend Kerberos tickets to
	include additional data in the ticket. This does have a
	security implications since the extension data in the
	TBETicket is only optionally signed, not encrypted and is not
	replay protected. It is up to the consumers of this interface
	to make sure its used safely.

	Some of the issues that the exensions need to protect themself
	from are: MITM downgrade to normal ticket, add or remove
	extentions, cut and paste extensions between requests,
	retransmission of requqests to a diffrent KDC. The data is
	sent in cleartext, so can should be taken to not send private data.

	The ticket extension is mainly to communicate information from
	the KDC to the server. The information can either be protected
	by the session key, or the key of the server. If its protected
	by the session key they both the client and the server can
	modify the data, and if its protected the servers key is can
	modified by the server. Any extention using Kerberos extention
	needs to define what the data is needs protection from.

Love

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 18 Aug 2008 20:52:57 -0400

> Please propose a better solution that works w/o deploying new clients.

Oh, I don't have one.  If I did, I'd have proposed it earlier; I know  
this approach has been discussed for a while, and I think we're stuck  
with it.  That doesn't mean I have to be happy about it. :-)

Well, there were the attempts we made a while back to have a flag  
indicating "yes I support this massive revision to the base spec to  
include UTF-8 and authenticated plaintext and other stuff" that no one  
wanted to follow through on.  So I guess we do it piecemeal through  
hacks.

> I didn't see any diffrence, but I took your text and modified to fit  

The application-server support requirement should apply if the AS-REQ  
asks for a service ticket and not a TGT.  With your text, it would not  
-- only the KDCs would need to support extensions in order to include  
extensions in the service ticket.

> 	extensions and MUST only be used for experimentation or

Looks good, thanks.

> 	which it may be sent are known to support it.

Also looks good.

> The ticket extension might tell the server what the actual session  
> key is.

Okay, so we can't assume a particular key.

Actually, what uses would there be *other* than to help the server get  
the service key or session key?

If the server can decrypt the ticket without additional info, the  
authorization-data field could carry info, though it's hidden from the  
client.  Additional info from the KDC to the client could be passed as  
preauth data.  Additional data from the KDC to the server, visible to  
(and perhaps modified by) the client could be carried to the server in  
the authorization-data field of the authenticator, *if* the client  
were aware of it; munging the ticket makes it happen by default but  
permits an aware client (or MITM) to change it.

I'm not coming up with any good examples besides key-finding or key- 
setting extensions.  In the abstract you mention referrals.  Early  
referrals drafts used ticket extensions for purposes for which I think  
preauth data is better suited, but server name canonicalization with  
clients not updated to support it is something where I think ticket  
extensions would work nicely.  That still falls under the category of  
"help the server get the right key".

Something I just noticed -- in TBETicket, compared with EncryptedData,  
you've not just added the extensions field, you've also removed the  
kvno field.  If someone comes up with an extension that doesn't simply  
specify the key, we might need to supply it.  Perhaps TBETicket should  
include EncryptedData, for simplicity:

   TBETicket ::= SEQUENCE {
     real-ticket  [0] EncryptedData,
     extensions   [1] SEQUENCE OF TicketExtension OPTIONAL
   }

In a referrals-based ticket extension, it might provide information  
needed to find the correct key, like the server's canonical name, but  
then the key itself would not set by the extension, so the standard  
kvno would be needed.

Or, for example, consider a server that stores a password, and the KDC  
sends a ticket extension incorporating etype-info2 so the server can  
generate the correct service key.  If the server remembers old  
passwords, like we can have normal services remember old keys, the  
kvno is needed.

I suppose the extension type could just incorporate kvno itself, too,  
but we've already got it in EncryptedData.

> The ticket is for servers, so the channel is not meant for KDC and  

It might be good to say that.  It's not really clear whether the  
intent is that clients be able to parse the extension data or modify  
it, or if both options should depend on the specific extension.  I  
assume the latter, but only because the draft fails to tell me  
anything and I have to be conservative.  I'm trying to figure out what  
uses there might be besides PKCROSS, and what their requirements might  
be....

> "It is up to the consumers of this interface to make sure its used  

Yes, but I think making the author of each extension figure out all  
the issues over and over again is a bad idea.  Certainly there can be  
issues applicable to some extensions and not others, but we can give  
some general idea of things to watch out for.

The new text you sent out in -01 looks good, though it could use a  
spell checker.

We could work around the wholesale downgrade attack easily enough, if  
anyone thinks it's an issue.  (Back to the question of what, besides  
PKCROSS, you might use this for.)  Just vary the encrypted data a  
little, maybe a trivial sequence wrapper around EncTicketPart, or a  
few bytes stuck on the front or something.  Tossing in a checksum or  
list of extension type numbers or something would tighten the  
protection further on some or all of the extensions.

> Yeah, we can all dream about Kerberos 6 where we remove all this  

Yep.

Ken