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

From: Love Hörnquist Åstrand <[email-masked]>
Date: Sun, 7 Sep 2008 19:12:51 +0100

19 aug 2008 kl. 01.52 skrev Ken Raeburn:

> On Aug 18, 2008, at 14:45, Love Hörnquist Åstrand wrote:
>>> First: Yuck!  That's a horrible abuse of data fields.
>>
>> 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 added and extension to the regular ticket instead and have the
client announce it want the new format as well as the old backward  
compat case.

>>> 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:
>>
>> I didn't see any diffrence, but I took your text and modified to fit
>> your comment below.
>
> 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.
>
>> Change it to this:
>>
>>      Negative ticket extension types (te-type) is private
>>      extensions and MUST only be used for experimentation or
>>      private use.
>
> Looks good, thanks.
>
>> 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.
>
> Also looks good.
>
>>> What does the checksum cover?  Does it have to be separately defined
>>> per type?
>>
>> 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.
>
> 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?

Anything that the extention want to be able to be read by a third party.
One example might be an transpartant proxy that only let out  
authorized requests [1].
Lets not stop people inventing here.

> 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:

The kvno is not used and should be the same kvno as is in the  
Ticket.enc-data, why include the info twice ?
Added this text.

	The content of cipher data and encryption type fields is moved
	inside TBETicket. The kvno field is not moved and have the
	same mening as before.

Or are you saying that the Checksum should have an associated kvno ?  
Maybe it should, I added that too.

>>> 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.)
>>
>> The ticket is for servers, so the channel is not meant for KDC and
>> client communication.
>
> 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....

Added the following:

	Ticket extentions are for communicating between the KDC and
	the service/KDC the ticket is for. Clients and 4th parties can
	read the data, but should do no attempt to modify, remove or
	add extentions.

>> "It is up to the consumers of this interface to make sure its used
>> safely."
>
> 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.

Added some more attacks that the authors needs to care about.

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

Used spellchecker on -02.

> 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.

I've been thinking about it and its a question of stacking. I guess we  
could say
that the signature key is the same key that was used to encrypt the  
enc-data,
but this stops extensions to authenticate the enc-data, for example  
for [1].

I guess we could split the extensions into protected and unprotected  
extensions.
and sign the protected extension using the same key as the enc-data  
was protected with.

TBETicket ::= SEQUENCE {
         etype           [0] krb5int32 -- EncryptionType --,
         cipher          [1] OCTET STRING
         prot-exts       [2] SEQUENCE OF TicketExtension OPTIONAL
         cksum           [3] Checksum,
         unprot-exts     [4] SEQUENCE OF TicketExtension OPTIONAL
}

cksum is always present and is the signature over DER(prot-exts), if  
prot-exts i empty, the checksum is over the empty string.

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

Since I'm already in a dream, I added the pretty version already today.

Will submit -02 when I get your feedback.

Love

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

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 29 Sep 2008 09:28:24 +0200

> Will submit -02 when I get your feedback.

Never got any feedback, so I submitted -02, please review.

Love