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.
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 }
The Soutei verifier is such a separate application. The Soutei
assertion should be placed into the field authInfo. The
fields service and ident are currently
unused and should be set to the empty value of the type directoryName. We should mention that a Group attribute (Section
4.4.4 of RFC3281) seems also an appropriate attribute to hold Soutei
assertions. We may in the future register an attribute object identifier
specifically for Soutei assertions.
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.
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.
[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>
This site's top page is http://soutei.sf.net/
Converted from SXML by SXML->HTML