]> Red Hat

ssorce@redhat.com

MIT Kerberos Consortium

tlyu@mit.edu

MIT Kerberos Consortium

hardjono@mit.edu

Network Working Group Internet Engineering Task Force Kerberos Abstract: This document proposes a Kerberos Authorization Data container similar to AD-KDC-ISSUED, but that allows for multiple MACs or signatures on the contained Authorization Data elements.

This draft proposes a Authorization Data container for Kerberos that identifies a base set of MAC and other elements necessary to authenticate the authorization data being carried in such a way that not only the KDC but also services can independently verify that the data has been authenticated by the KDC and has not been tampered with.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Authorization data is highly sensitive and must be validated to insure no tampering has occured. In order to validate any information the receiving client need to be able to cryptographically verify the data. This is done by introducing a new AuthorizationData element called AD-CAMMAC that contains enough information to bind the contents to a principal in a way that a receiving client can verify autonomusly without further contact with the KDC. The following information is needed: The KDC signature. The Service Signature. Optional Trusted Service Key Signature. Optional PUBKEY KDC Signature. The KDC signature is required to allow the KDC to validate the data withouth requiring to recompute the contents at every TGS request. The SVC signature is required so that the Service can verify that the authorization data has been validated by the KDC. Both the Trusted Service Checksum and the asymmetric KDC Signature are useful to verify the authenticity of the contents on the same host, when the data is received by a less trusted service and passed to a more trusted service on the same host without the need for additional roundtrips to the KDC. The ad-type for AD-CAMMAC is (TBD).

The Kerberos protocol is defined in [RFC4120] using Abstract Syntax Notation One (ASN.1) [X680]. As such, this specification also uses the ASN.1 syntax for specifying both the abstract layout of the AD-CAMMAC attributes, as well as its encoding.

@REALM or the administratively configured service is not found in the KDC database this cheksum can be omitted. Checksum type TBD. pubkey-signature A name identifying the asymmetric key-pair used. A checksum computed over the encoding of the elements field using the Private Key identified in the Name field. If an asymmetric key is not available this checksum MUST be omitted. Signature type TBD. elements A sequence of authorization data elements issued by the KDC. ]]>

TBD

TBD.

Although generally authorization data are conveyed within a ticket and are thereby protected using the existing encryption methods on the ticket, some authorization data requires the additional protection provided by the CAMMAC.

TBD.

&RFC4120; &RFC3961; &RFC3962; &RFC2119; &RFC3552; &RFC1510; ISO

This becomes an Appendix.