Subject: Re: [kitten] I-D Action: draft-ietf-krb-wg-cammac-06.txt

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 5 Nov 2013 11:29:33 -0500 (EST)

On Mon, 21 Oct 2013, [email-masked] wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.
>
> 	Title           : Kerberos Authorization Data Container Authenticated by Multiple MACs
> 	Author(s)       : Simo Sorce
>                          Tom Yu
>                          Thomas Hardjono
> 	Filename        : draft-ietf-krb-wg-cammac-06.txt
> 	Pages           : 9
> 	Date            : 2013-10-21
>
> Abstract:
>   Abstract: This document specifies a Kerberos Authorization Data
>   container that supersedes AD-KDC-ISSUED.  It allows for multiple
>   Message Authentication Codes (MACs) or signatures to authenticate the
>   contained Authorization Data elements.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-krb-wg-cammac
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-06

I think the new text in "Motivations" covers a lot of things that should 
be covered, but unfortunately it doesn't seem very well structured as a 
piece of prose.  I might propose the following reordering/rewording:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

A Kerberos ticket may frequently contain some extra authorization data in 
addition to just the client identity and similar necessities.  A client 
may request that certain authorization data be included in its tickets, 
but sometimes a service may want to verify that the authorization data 
has been vetted in some way by (or generated by!) the KDC.  The existing 
AD-KDC-ISSUED container suits this purpose well, allowing a service to 
verify that the KDC had issued the contained authorization data.  This is 
allowed by virtue of the shared symmetric key between the KDC and the 
service, which is used to copute the MAC for the AD-KDC-ISSUED container.

This existing setup works well when the flow of authorization data is 
always from the KDC to the application service.  However, there are 
extensions to the Kerberos protocol such as Constrianed Delegation 
(S4U2Proxy [MS-SFU]) which involve having an application service send a 
ticket (and its concordant authorization data) to the KDC as part of 
receiving a new ticket for a different service on behalf of the client. 
The service takes an existing ticket to itself and presents it to the KDC 
as evidence that it received a user request, and consequently asks the KDC 
to issue a new ticket on behalf of the same user to perform operations 
against a different service.  This is, in effect, a flow of authorization 
data from the application service to the KDC, and for this purpose the 
AD-KDC-ISSUED container is insufficient.  This deficiency is precisely due 
to the fact that the symmetric key used for the MAC is shared between the 
KDC and the application service -- the application service could use the 
key to generate a forged MAC on an AD-KDC-ISSUED container which was in 
fact not issued by the KDC.

The new AD-CAMMAC authorization data container specified in this document 
improves upon the situation by introducing a MAC using a symmetric key 
known only to the KDC (in the form of the kdc-verifier MAC), in addition 
to a MAC in a key shared between the KDC and the application service (in 
the form of the svc-verifier MAC, analogous to the MAC for the 
AD-KDC-ISSUED container).  When an application service presents data
in an AD-CAMMAC container to the KDC, the KDC can use the kdc-verifier to 
validate that the authorization data was in fact issued by the KDC. 
(Note, however, that just the MAC is insufficient to confirm that the 
CAMMAC was issued along with the ticket it is attached to, see [Security 
Considerations].)  In this way the KDC can verify that the service named 
in the ticket did not tamper with the contained authorization data without 
having to (re)compute all of the contained authorization data, an 
operation which might not always be possible when the data contains 
ephemeral information such as the strength or type of authentication 
method used to obtain the original ticket.

In addition to the kdc-verifier and svc-verifier, the AD-CAMMAC also 
includes a provision for additional other-verifiers.  These allow the 
CAMMAC to be validated by a separate, trusted, service other than the KDC. 
An example of such a case would be when a lesser-privileged service on a 
host may receive an authentication from a client, and might then ask a 
higher-privileged service (the "trusted service") on the same host to act 
on behalf of the client.  To demonstrate that the client has authenticated 
to it, the lesser-privileged service can extract the AD-CAMMAC container 
from the ticket and submit it to the trusted service.  The trusted service 
can either ask a specialized service (not yet specified) on the KDC to 
validate the AD-CAMMAC container, or use verify the optional additional 
verifiers (the other-verifiers field) that are part of the AD-CAMMAC. The 
presence of the new kdc-verifier and other-verifier fields in the CAMMAC 
enable several new use cases for the Kerberos protocol which the 
AD-KDC-ISSUED container does not accomodate.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

I also don't see any text to address my request for more guidance about 
what the AD_CAMMAC_BINDING element would contain -- was this an oversight 
or a deliberate choice?

Thanks,

Ben