Verified authorization data

[Peter Mogensen]

Hi,

Greg Hudson summes up the situation fine here. I feel the urge to 
comment. (below)

On 2014-06-10 18:30, Greg Hudson wrote:
> In the Kerberos 5 authdata model, the KDC is assumed to blindly pass
> through authdata requested by the client.  If the authdata is to be
> trusted by the target service as something vetted by the KDC, it needs
> to be packaged accordingly.
>
> The traditional method for doing this is a container called
> AD-KDC-ISSUED which contains a checksum for the authdata in a key which
> cannot be known (in advance) by the client.  This container has not seen
> much practical use, and it turns out that RFC 4120 says conflicting
> things about which key to use for the checksum.  To the extent that
> there are implementations, they use the ticket session key.
>
> A more recent container for this purpose is AD-CAMMAC, as specified in:
>
>      http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-01
>
> In addition to not having key ambiguity issues, AD-CAMMAC also contains
> a KDC verifier which allows the authdata to be propagated through an
> S4U2Proxy request.


I did some work to implement RFC6806 AD-LOGIN-ALIAS which requires 
AD-KDC-ISSUED and noticed the ambiguity in RFC4120 regarding which key 
to use for the checksum.
I also noticed that AD-CAMMAC explicitly uses the service-key (and not 
the ticket session key) to do the same.
... and that to embed a ~10 bytes username in a ticket as AD-LOGIN-ALIAS 
I end up increasing the ticket size with about 110 bytes. - which is a 
rather significant increase if you are worried about ticket sizes.

So, I wonder... is this really the optimal way to extend a ticket with 
verified information?
If I just wanted to verify the login-alias to the service it seems like 
a waste of ~100 bytes to checksum it with the service-key (like RFC4120 
also states). If it wasn't for the authdata-model Greg describes above, 
where the DC is assumed to blindly pass through authdata requested by 
the client, then no checksum would have been needed. The ticket it self 
would protect the integrity of the field. (and saving ~100 bytes ticket 
size).

It seems to me that a lot of complexity in verifying authdata originates 
from this authdata model where the client can put anything it likes in 
the authorization-data. This is of course useful for negative 
authorization, but makes things complicated for positive authorization 
data. (like simple info the KDC just want to assert to the service, like 
AD-LOGIN-ALIAS)

The solution in AD-CAMMAC seems very complex too, requiring effectively 
calculating the entire EncTicketPart twice - and once for every present 
AD-CAMMAC present.

Things would have been much simpler if there were an authdata field in a 
ticket outside of the clients control. Now, - I know - there's probably 
very good reasons why extending the EncTicketPart and Ticket definitions 
is difficult, but...

In an ideal world, maybe something like:

EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
         flags                   [0] TicketFlags,
         key                     [1] EncryptionKey,
         crealm                  [2] Realm,
         cname                   [3] PrincipalName,
         transited               [4] TransitedEncoding,
         authtime                [5] KerberosTime,
         starttime               [6] KerberosTime OPTIONAL,
         endtime                 [7] KerberosTime,
         renew-till              [8] KerberosTime OPTIONAL,
         caddr                   [9] HostAddresses OPTIONAL,
         authorization-data      [10] AuthorizationData OPTIONAL
         protected-authdata      [11] AuthorizationData OPTIONAL
}

Where the client can't add to "protected-authdata".
This would make the AD-KDC-ISSUED and svc-verifier of AD-CAMMAC redundant.

( It would also relieve the clients from having to verify every 
AD-KDC-ISSUED element in order to find the one it's interested in - of 
course, this is an API artifact of libkrb5's 
krb5_verify_authdata_kdc_issued(). )

And then:

Ticket          ::= [APPLICATION 1] SEQUENCE {
         tkt-vno         [0] INTEGER (5),
         realm           [1] Realm,
         sname           [2] PrincipalName,
         enc-part        [3] EncryptedData -- EncTicketPart
         kdc-verifier    [4] Verifier-MAC OPTIONAL,
}

Which would solve the S4U2proxy use case mentioned where the KDC needs 
to protect the Ticket from tampering by the service.
Of course this changes some of the binding semantics of the current 
AD-CAMMAC draft. Specically this now binds all authdata together with 
one checksum. But the kdc-verifier cannot be verified without the Ticket 
anyway.

This would also make the need for a special AD-CAMMAC limited to 
providing for "other-verifiers"

I realize that it's non-trivial to extend these ASN.1 definitions, but 
something similar was suggested in draft-ietf-krb-wg-ticket-extensions

To do the above example there will also have to be API-changes. Like 
krb5_find_authdata() needs to know about this.
But it seems AD-CAMMAC will require minor API changes too, since it uses 
the service-key and not the session-key like implementations of 
AD-KDC-ISSUED (as Greg mentioned). Using the session-key is a lot easier 
for client verification. Using the service-key would probably need 
krb5_rd_req() to verify AD-CAMMAC to avoid the application having to 
look up its service-key independently .

So maybe it's worth investigating if there's anyway to provide 
verified/signed AD-DATA in a simpler way, requiring smaller tickets and 
less computation when signing/verifying.

I hope these thoughts are not so naive that the answer is that it will 
require a new protocol version or a new tkt-vno... ;-)

/Peter