Transport of Soutei assertions

This page discusses various ways of making Soutei assertions available to the decision engine: by reading a local configuration file, by querying trusted databases and LDAP servers, or by delivering the assertions in HTTP headers and in Public-key and Attribute X.509 certificates.

X.509 Certificates and Soutei

Soutei assertions may be included in a public-key X.509 certificate (PKC) [RFC3280] or in a X.509 attribute certificate [RFC3281].

There is a distinct advantage of including Soutei assertions in a public-key certificate intended for establishing a TLS (HTTPS, SSL) connection with the application server. In that case, we get certificate transport and validation ``for free'', performed as a part of the TLS handshake. In case of HTTPS, the web server should be configured to request a client certificate during the handshake. The web server will challenge the validity of the certificate, according to the TLS protocol. If the certificate is found valid and authentic, the web server establishes the TLS connection and accepts the HTTP request. The web server will give to the application server (i.e., the Metcast server) the certificate in the PEM-encoded format, as the content of the environment variable SSL_CLIENT_CERT. An option ExportCertData must be included in SSLOptions directive of the SSL engine portion of the Apache configuration file. The Soutei assertion should be placed, as an octet string, in the field authInfo of an Attribute structure SvceAuthInfo of a sequence SubjectDirectoryAttributes of the v3 certificate extensions field. A private v3 certificate extension may also be defined for the purpose of holding assertions. Because the assertion is a part of a signed and validated certificate, we can trust the assertion without any further checks.

Including Soutei assertions in a public-key certificate however can be problematic from the logistic point of view. Certificates issued to an end user (e.g., Common Access Card certificates) typically have restrictions on their usage: the bit cA is turned off and the certificates may be invalid for key encipherment. Therefore, an end user may not issue his own certificates to delegate his privileges to applications or other users via Soutei assertions. The user must ask a Certifying Authority (CA) to issue him a certificate with the appropriate Soutei assertions. The latter is quite an involved process. Furthermore, it is argued in [RFC3281] that CA are wrong entities to issue authorization statements.

The task of issuing authorization statements properly belongs to attribute authorities, as described in [RFC3281]. Authorization statements are placed into attribute X.509 certificates. According to [RFC3281], an attribute certificate is a structure similar to public key certificates. Whereas the latter binds an identity of a subject and his public key, an attribute certificate serves to assign authorization attributes to the certificate holder. The attributes may include group membership, role, security clearance, etc.

Some people constantly confuse public-key certificates (PKC) and attribute certificates (AC). An analogy may make the distinction clear. A PKC can be considered to be like a passport: it identifies the holder, tends to last for a long time, and should not be trivial to obtain. An AC is more like an entry visa: it is typically issued by a different authority and does not last for as long a time. As acquiring an entry visa typically requires presenting a passport, getting a visa can be a simpler process [RFC3281].

Attribute certificates seem therefore appropriate vehicles for Soutei assertions. An end user may issue attribute certificates for his own applications. Attribute certificates are short-lived and ideal for such a delegation purpose. Furthermore, the profile in [RFC3281] explicitly states that an attribute certificate issuer must not be a CA: an attribute certificate issuer's public-key certificate must not contain a basicConstraints extension with the cA boolean set to TRUE. Not only end users may issue attribute certificates -- they are the only entities that may do so.

Before processing an assertion found in an attribute certificate, the server must validate the certificate as described in Section 5 of [RFC3281]. If the field Holder of the certificate identifies the holder by name or by a certificate reference, the identity of the holder must match the identity of the authenticated client; see Section 4.2.2 of RFC3281 for more detail. The holder of the certificate may also be an empty sequence. The assertion found in such a certificate is eligible for caching. Certificates with the empty holder name are employed for delegation.

A Soutei assertion is placed into one attribute of an attribute certificate. The certificate may include other attributes. It seems that the most appropriate attribute for Soutei assertions is SvceAuthInfo, described in Section 4.4.1 or RFC3281: ``This attribute provides information that can be presented by the AC verifier to be interpreted and authenticated by a separate application within the target system.''

     id-aca                     OBJECT IDENTIFIER ::= { id-pkix 10 }
     id-aca-authenticationInfo  OBJECT IDENTIFIER ::= { id-aca 1 }
     SvceAuthInfo ::= SEQUENCE {
           service   GeneralName,
           ident     GeneralName,
           authInfo  OCTET STRING OPTIONAL }

When an attribute certificate is imported into Soutei, the subject identity of the issuer (taken from the field issuerName of the certificate) serves as a context identifier for the imported assertion. The subject identity is generally a SHA-1 hash computed from the name of the issuer or found in the SubjectKeyIdentifier extension of the public-key certificate of the issuer. The extension takes precedence, if it exists.

The problem with attribute certificates is transporting them from a client to the server. Can we still piggy-back on TLS for transporting and validating attribute certificates? It seems that OpenSSL might do that for us. This issue requires further investigation.

HTTP headers and Soutei

Soutei assertions may also be delivered in HTTP headers. The headers take precedence over the TLS-based transport of certificates. We introduce two kinds of headers. Only one kind must be present in a HTTP session.

Attribute-assertion header: X-X509-AC. The contents of the header is an attribute certificate (described above), DER- and Base64- encoded.

Signed-assertion-header: X-BAssertion. The contents of the header is a cryptographically signed message [RFC3369] with the content-type text/x-bassertion. The signer of the message is considered to be the issuer of the assertion.

References

[Binder] J. DeTreville. Binder, a logic-based security language. IEEE Security and Privacy, 2002.
< http://research.microsoft.com/research/pubs/view.aspx?tr_id=545>

[PKI-Tutorial] Peter Gutmann. Everything you never wanted to know about PKI but have been forced to find out.
< http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf>

[RFC3280] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 3280, Standards Track. April 2002.
< http://www.rfc-editor.org/rfc/rfc3280.txt>

[RFC3281] S. Farrell and R. Housley. An Internet Attribute Certificate Profile for Authorization. RFC 3281, Standards Track. April 2002.
< http://www.rfc-editor.org/rfc/rfc3281.txt>

[RFC3369] R. Housley. Cryptographic Message Syntax (CMS). RFC 3369. Standards Track. August 2002.
< http://www.rfc-editor.org/rfc/rfc3369.txt>

[NIST-PKI] NIST PKI Program
< http://csrc.nist.gov/pki/>

[ASN1-Guide] Burton S. Kaliski Jr. A Layman's Guide to a Subset of ASN.1, BER, and DER. An RSA Laboratories Technical Note. Revised November 1, 1993.
< http://citeseer.nj.nec.com/47302.html>

[X509-Style] Peter Gutmann. X.509 Style Guide. October 2000.
< http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt>

Last updated July 23, 2004

Converted from SXML by SXML->HTML

$Id: Auth-transport.scm,v 1.1 2004/07/24 01:34:31 oleg Exp oleg $