INTERNET-DRAFT S. Farrell
PKIX Working Group SSE
expires in six months R. Housley
Spryus
April 1999
An Internet AttributeCertificate
Profile for Authorization
<draft-ietf-pkix-ac509prof-00.txt>
Status of this memo
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum
of six months and may be updated, replaced, or obsoleted
by other documents at any time. It is inappropriate to
use Internet-Drafts as reference material or to cite them
other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html.
<<Comments are contained in angle brackets like this.>>
Abstract
Authorization support is required for various Internet
protocols, for example, TLS, CMS and their consumers,
and others. The X.509 AttributeCertificate provides a
structure that can form the basis for such services
([X.509], [XPDAM]). This specification defines two
profiles (basic and proxiable) for the use of X.509
AttributeCertificates to provide such authorization
services.
Farrell & Housley [Page 1]
INTERNET-DRAFT April 1999
1. Introduction
The key words "MUST", "REQUIRED", "SHOULD",
"RECOMMENDED", and "MAY" in this document are to be
interpreted as described in [RFC2119].
The provision of authentication, data integrity and
confidentiality services for current Internet protocols
is well understood and many secure transports are defined
(e.g. TLS, IPSEC, etc.). In many applications these
services are not sufficient (or too cumbersome to
administer) to provide the type of authorization services
required.
[RFC2459] specifies a profile for the use of X.509 public
key certificates in Internet protocols. This type of
certificate is typically used as an "identity"
certificate, that is, it contains a certified name and
public key, and any entity that can use the corresponding
private key is treated as the named entity.
When considering authorization, one is often less
interested in the identity of the entity than in some
other attributes, (e.g. roles, account limits etc.),
which should be used to make an authorization decision.
In many such cases, it is better to separate this
information from the identity for management, security,
interoperability or other reasons. However, this
authorization information also needs to be protected in a
fashion similar to a public key certificate - the name
for the structure used is an attribute certificate (an
AC) which is a digitally signed (certified) set of
attributes.
An AC is a structure that is similar to an X.509 public
key certificate [RFC2459] with the main difference being
that it contains no public key. The AC typically contains
group membership, role, clearance and other access
control information associated with the AC owner. The
base syntax for ACs is also defined in the X.509 standard
(making the term X.509 certificate ambiguous!). This
document specifies a profile of the X.509 AC suitable for
authorization purposes in Internet protocols.
Farrell & Housley [Page 2]
INTERNET-DRAFT April 1999
When making an access decision based on an AC, an access
decision function may need to ensure that the appropriate
AC owner is the entity that has requested access. For
example, one way in which the linkage between the request
and the AC can be achieved is if the AC has a "pointer"
to a PKC for the requestor and that PKC has been used to
authenticate the request.
As there is often confusion about the difference between
public key certificates (PKCs) and attribute certificates
(ACs), an analogy may help. A PKC can be considered to be
like a passport: it identifies the owner, tends to last
for a long period and shouldn't be too easy to get. An AC
is more like an entry visa in that it is typically issued
by a different authority and doesn't last as long. As
acquiring an entry visa typically requires presenting a
passport, getting a visa can be a simpler process.
In conjunction with authentication services ACs provide a
means to transport authorization information securely to
applications. However, there are a number of possible
communication paths that an AC may take:
In some environments it is suitable for a client to
"push" an AC to a server. This means that no new
connections between the client and server domains are
required. It also means that no search burden is imposed
on servers, which improves performance.
In other cases it is more suitable for a client simply to
authenticate to the server and for the server to request
("pull") the client's AC from an AC issuer or a
repository. A major benefit of the "pull" model is that
it can be implemented without changes to the client and
client/server protocol. It is also more suitable for some
inter-domain cases where the client's rights should be
assigned within the server's domain, rather than within
the client's "home" domain.
There are a number of possible exchanges that can occur
and three entities involved (client, server and AC
issuer). In addition the use of a directory service or
other repository for AC retrieval MAY be supported.
Farrell & Housley [Page 3]
INTERNET-DRAFT April 1999
The diagram below shows an abstract view of the exchanges
that may involve ACs. This profile does not specify
protocol for all of these exchanges, though a limited
case of client and server acquisition is defined below.
+--------------+ +---------------+
| | | |
| AC Issuer +----+ | Repository |
| | | | |
+--+-----------+ | Server +-------+-------+
| | Acquisition |
|Client | |Server
|Acquisition +----------------------+ |Lookup
| | |
+--+-----------+ +--+----+-------+
| | AC "push" | |
| Client +------------------------+ Server |
| | (part of app. protocol)| |
+--------------+ +---------------+
|
| Client Lookup
+--+-----------+
| |
| Repository | Figure 1: AC Exchanges
| |
+--------------+
The remainder of the document is structured as follows:-
Section 2 defines some terminology
Section 3 specifies the requirements that this profile is
to meet
Section 4 contains the profile of the X.509 AC
Section 5 specifies rules for AC validation
Section 6 specifies rules for AC revocation checks
Section 7 specifies a limited AC acquisition protocol
Section 8 contains a conformance statement
Appendices contain samples, a "compilable" ASN.1 module
for this specification and a list of open issues.
2. Terminology
Term Meaning
AC AttributeCertificate
AC user any entity that parses or processes an AC
AC verifier any entity that checks the validity of an
AC and then makes use of the result
AC issuer the entity which signs the AC
Farrell & Housley [Page 4]
INTERNET-DRAFT April 1999
AC owner the entity indicated (perhaps indirectly)
in the subject field of the AC
Client the entity which is requesting the action
for which authorization checks are to be
made
LAAP Limited AC Acquisition Protocol
LRP LAAP responder
LRQ LAAP requestor
Proxying In this specification, Proxying is used
to mean the situation where an
application server acts as an application
client on behalf of a user. Proxying here
does not mean granting of authority.
PKC Public Key Certificate - uses the type
ASN.1 Certificate defined in X.509 and
profiled in RFC 2459. This (non-standard)
acronym is used in order to avoid
confusion about the term "X.509
certificate".
Server the entity which requires that the
authorization checks are made
3. Requirements
The following are the requirements that the "full"
profile defined here meets.
Time/Validity requirements:
1. Support for short-lived or long-lived ACs is
required. Typical validity periods might be measured in
hours, as opposed to months for X.509 public key
certificates. Short validity periods mean that ACs can be
useful without a revocation scheme.
Attribute Types:
2. Issuers of ACs should be able to define their own
attribute types for use within closed domains.
3. Some standard attribute types should be defined
which can be contained within ACs, for example "access
identity", "group", "role", "clearance", "audit
identity", "charging id" etc.
4. Standard attribute types should be defined so that
it is possible for an AC verifier to distinguish between
e.g. the "Administrators group" as defined by SSE and the
"Administrators group" as defined by Widgets inc.
5. ACs should support the encryption of some, or all,
attributes (e.g. passwords for legacy applications). It
should be possible for such an encrypted attribute to be
Farrell & Housley [Page 5]
INTERNET-DRAFT April 1999
deciphered by an appropriate AC verifier even where the
AC has not been received directly from the AC owner (i.e.
where the AC is proxied).
Targeting of ACs:
6. It should be possible to "target" an AC. This means
that a given AC may be "targeted" at one, or a number of,
servers/services in the sense that a trustworthy non-
target will reject the AC for authorization decisions.
Proxying:
7. It should be possible for a server to proxy an AC
when it acts as a client (for another server) on behalf
of the AC owner.
8. Proxying should be under the AC issuer's control, so
that not every AC is proxiable and so that a given
proxiable AC can be proxied in a targeted fashion.
9. Support for chains of proxies (with more than one
intermediate server) is required.
Push vs. Pull
10. ACs should be defined so that they can either be
"pushed" by the client to the server, or "pulled" by the
server from a network service (whether the AC issuer or
an online repository).
This profile specifically imposes no requirements for:
1. The meaning of a chain of ACs
2. AC translation
Support for such features may be part of some other
profile.
Farrell & Housley [Page 6]
INTERNET-DRAFT April 1999
4. The AC Profile
This section specifies the profile of the X.509 AC which
is to be supported by conforming implementations.
4.1 X.509 AttributeCertificate Definition
X.509 contains the definition of an AttributeCertificate
given below. Types that are not defined can be found in
[RFC2459].
<<This definition is from the PDAM.>>
AttributeCertificate ::= SIGNED {
acinfo AttributeCertificateInfo
}
AttributeCertificateInfo ::= SEQUENCE {
version AttCertVersion DEFAULT v1,
owner CHOICE{
baseCertificateID [0] IssuerSerial,
-- the issuer and serial number of
-- the owner's Public Key Certificate
entityName [1] GeneralNames,
-- the name of the claimant or role
objectDigestInfo [2] ObjectDigestInfo
-- if present, version must be v2
},
issuer CHOICE {
baseCertificateId [0] IssuerSerial,
issuerName [1] GeneralNames
},
--AA that issued the attribute certificate
signature AlgorithmIdentifier,
serialNumber CertificateSerialNumber,
attrCertValidityPeriod AttCertValidityPeriod
attributes SEQUENCE OF Attribute,
issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL
}
AttCertVersion ::= INTEGER {v1(0), v2(1) }
ObjectDigestInfo ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier,
objectDigest OCTET STRING
}
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
Farrell & Housley [Page 7]
INTERNET-DRAFT April 1999
serial CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL
}
AttCertValidityPeriod ::= SEQUENCE {
notBeforeTime GeneralizedTime,
notAfterTime GeneralizedTime
}
4.2 Object Identifiers
The following OIDs are used:
<<
for interop testing purposes the SSE OID sse-ac-tst may
be used instead of ietf-ac.
sse-id OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 1201 }
sse-ac-tst OBJECT IDENTIFIER ::= { sse-id 56 }
>>
ietf-ac OBJECT IDENTIFIER ::= <<tbs>>
ietf-ac-extensions OBJECT IDENTIFIER ::= { ietf-ac 1}
ietf-ac-attributes OBJECT IDENTIFIER ::= { ietf-ac 2}
4.3 Profile of Standard Fields.
For all GeneralName fields in this profile the otherName,
x400Address, ediPartyName and registeredId options MUST
NOT be used unless otherwise specified (e.g. as in the
description of targeting extension).
4.3.1 version
This must be the default value of v1, i.e. not present in
encoding.
<<If we allow objectDigest then the above will have to
change. There's also a comment to the PDAM which may
cause a change here.>>
4.3.2 owner
For any protocol where the AC is passed in an
authenticated message or session, and where the
authentication is based on the use of an X.509 public key
certificate (PKC), the owner field MUST use the
baseCertificateID.
With the baseCertificateID option, the owner's PKC
serialNumber and issuer MUST be identical to the AC owner
Farrell & Housley [Page 8]
INTERNET-DRAFT April 1999
field. The PKC issuer MUST have a non-NULL X.500 name
which is to be present as the single value of the of the
owner.issuerSerial.issuer construct in the directoryName
field. The owner.issuerSerial.issuerUID field MUST only
be used if the owner's PKC contains an issuerUniqueID
field.
The above means that the baseCertificateID is only usable
with PKC profiles (like RFC2459) which mandate that the
PKC issuer field contain a value.
If the owner field uses the entityName option and the
underlying authentication is based on a PKC, then the
entityName MUST be the same as the PKC subject field, or,
if the PKC subject is a "NULL" DN, then the entityName
field MUST be identical to one of the values of the PKC
subjectAltName field extension. Note that [RFC2459]
mandates that the subjectAltNames extension be present if
the PKC subject is a "NULL" DN.
In any other case where the owner field uses the
entityName option then only one name SHOULD be present.
AC's conforming to this profile MUST NOT use the
objectDigest field.
<<Uses of objectDigest are for further study.>>
Any protocol conforming to this profile SHOULD specify
which AC subject option is to be used and how this fits
with e.g. peer-entity authentication in the protocol.
4.3.3 issuer
ACs conforming to this profile MUST use the issuerName
choice which MUST contain one and only one GeneralName
which MUST contain its non-null value in the
directoryName field. This means that all AC issuers MUST
have non-NULL X.500 names.
Part of the reason for the use of the issuerName field is
that it allows the AC verifier to be independent of the
AC issuer's public key infrastructure. Using the
baseCertificateId field to reference the AC issuer would
mean that the AC verifier would have such a dependency.
4.3.4 signature
Contains the algorithm identifier used to validate the AC
signature.
Farrell & Housley [Page 9]
INTERNET-DRAFT April 1999
This MUST be one of the following algorithms defined in
[RFC2459] section 7.2: md5WithRSAEncryption, id-dsa-with-
sha1 or sha-1WithRSAEncryption.
id-dsa-with-sha1 MUST be supported by all AC users. The
other algorithms SHOULD be supported.
4.3.5 serialNumber
For any conforming AC, the issuer/serialNumber pair MUST
form a unique combination, even if ACs are very short-
lived (one second is the shortest possible validity due
to the use of GeneralizedTime).
AC issuers MUST force the serialNumber to be a positive
integer, that is, the topmost bit in the DER encoding of
the INTEGER value MUST NOT be a `1'B - this is to be done
by adding a leading (leftmost) `00'H octet if necessary.
This removes a potential ambiguity in mapping between a
string of octets and a serialNumber.
Given the uniqueness and timing requirements above serial
numbers can be expected to contain long integers, i.e. AC
users MUST be able to handle more than 32 bit integers
here.
There is no requirement that the serial numbers used by
any AC issuer follow any particular ordering, in
particular, they need not be monotonically increasing
with time.
4.3.6 attrCertValidityPeriod
The attrCertValidityPeriod (a.k.a. validity) field
specifies the period for which the AC issuer expects that
the binding between the owner and the attributes fields
will be valid.
GeneralizedTime encoding is restricted as specified in
[RFC2459] for the corresponding fields in a PKC.
Note that AC users MUST be able to handle the case where
an AC is issued, which (at the time of parsing), has its
entire validity period in the future (a "post-dated" AC).
This is valid for some applications, e.g. backup.
4.3.7 attributes
The attributes field gives information about the AC
owner. When the AC is used for authorization this will
Farrell & Housley [Page 10]
INTERNET-DRAFT April 1999
often contain a set of privileges. However, authorization
may also require support for "restrictions" - these are
not carried within the attributes field (though they
"belong" to the AC owner) but in the extensions field.
The attributes field contains a SEQUENCE OF Attribute.
For a given AC each attribute type in the sequence MUST
be unique, that is, only one instance of each attribute
type can occur in a single AC. Each instance can however,
be multi-valued.
AC consumers MUST be able to handle multiple values for
all attribute types.
Note that a conforming AC MAY contain an empty SEQUENCE,
that is, no attributes at all.
Some standard attribute types are defined in section 4.5.
4.3.8 issuerUniqueID
This field MUST NOT be used.
4.3.9 extensions
The extensions field generally gives information about
the AC as opposed to information about the AC owner. The
exception is where restrictions are to be supported. If
one regards a restriction as a qualification on a
privilege then it is clear that restrictions must be
implemented as a critical extension.
Section 4.4 defines the extensions that MAY be used with
this profile. An AC that has no extensions conforms to
the profile. If any other critical extension is used,
then the AC does not conform to this profile. An AC that
contains additional non-critical extensions still
conforms.
4.4 Extensions.
4.4.1 Restrictions
<<The authors solicit comment on whether support for
restrictions is needed. The benefit is that they may
allow the "positive" privilege syntax to be standardised
more widely under the assumption that the corresponding
restriction syntax need only be understood "locally". On
the other hand, we can omit this entirely if not many
people see any benefit.>>
Farrell & Housley [Page 11]
INTERNET-DRAFT April 1999
A restriction is a "negative" privilege, for example an
AC may "state" that the AC owner is a member of the
administrative group except for purposes of backup.
Restrictions would more properly be implemented as a
separate field of the AC, but with the current syntax can
only be supported via the use of a critical extension.
The value of this extension will be a SEQUENCE OF
Attribute. The rule stated above for the AC attributes
field (only one instance of each type etc.) applies here
also.
Each restriction MUST correspond to one attribute present
in the attributes field and must use the same attrType
OID as the related attribute.
name ietf-ac-restrictions
OID { ietf-ac-extensions 1 }
syntax SEQUENCE OF Attribute
criticality MUST be TRUE
4.4.2 Audit Identity
In some circumstances it is required (e.g. by data
protection/data privacy legislation) that audit trails do
not contain records which directly identify individuals.
This may make the use of the owner field of the AC
unsuitable for use in audit trails.
In order to allow for such cases an AC MAY contain an
audit identity extension. Ideally it SHOULD be infeasible
to derive the AC owner's identity from the audit identity
value except with the co-operation of the AC issuer.
The value of the audit identity plus the AC issuer/serial
should then be used for audit/logging purposes. If the
value of the audit identity is suitably chosen then a
server/service administrator can track the behaviour of
an AC owner without being able to identify the AC owner.
The server/service administrator in combination with the
AC issuer MUST be able to identify the AC owner in cases
where mis-behaviour is detected. This means that the AC
issuer MUST be able to map "backwards" from the audit
identity to the actual identity of the AC owner.
Of course, auditing could be based on the AC
issuer/serial pair, however, this method doesn't allow
tracking the same AC owner across different ACs. This
means that an audit identity is only useful if it lasts
Farrell & Housley [Page 12]
INTERNET-DRAFT April 1999
for longer than the typical AC lifetime - how much longer
is an issue for the AC issuer implementation. Auditing
could also be based on the AC owner's PKC issuer/serial
however, this will often allow the server/service
administrator identify the AC owner.
As the AC verifier might otherwise use the AC subject or
some other identifying value for audit purposes, this
extension MUST be critical when used.
Protocols that use ACs will often expose the identity of
the AC owner in the bits on-the-wire. In such cases, an
"opaque" audit identity does not make use of the AC
anonymous, it simply ensures that the ensuing audit
trails are "semi-anonymous".
name ietf-ac-auditId
OID { ietf-ac-extensions 3 }
syntax OCTET STRING
criticality must be TRUE
4.4.3 AC Targeting and Proxying
In order to allow that an AC is "targeted" and to control
proxying, the proxy information extension MAY be used to
specify a number of servers/services. The intent is that
the AC should only be usable at the specified
servers/services - an (honest) AC verifier who is not
amongst the named servers/services MUST reject the AC.
If this extension is not present then the AC is not
proxiable. Any server which receives the AC such that the
owner and the authenticated peer-entity do not match MUST
reject the AC.
When this extension is present we are essentially
checking that the entity from which the AC was received
was allowed to send it and that the AC is allowed to be
used by this recipient.
The targeting information consists of the direct
information (targets field) and an optional set of proxy
information (proxies field). If the "direct check" or any
of the "proxy" checks (see below) pass then the
"targeting check" as a whole is successful.
The effect is that the AC owner can send to any valid
target which can then only proxy to targets which are in
one of the same "proxy sets" as itself.
Farrell & Housley [Page 13]
INTERNET-DRAFT April 1999
The following data structure is used to represent the
targeting/proxying information.
ProxyInfo ::= SEQUENCE {
owner CHOICE {
baseCertificateID [0] IssuerSerial,
subjectName [1] GeneralNames,
objectDigestInfo [2] ObjectDigestInfo
},
targets [0] Targets OPTIONAL,
proxies [1] SEQUENCE OF Targets OPTIONAL
}
Targets ::= SEQUENCE OF Target
Target ::= CHOICE {
targetName [0] GeneralName,
targetGroup [1] GeneralName
}
Where no proxies or targets are present then the entire
field MUST be omitted, that is, a zero-length sequence of
Targets MUST NOT be present. There MUST be at least one
target or one proxy present, that is, one of the targets
or proxies fields MUST be present.
We represent a special target, called "ALL" which is a
wildcard as a targetName with the registeredID choice and
a value of {ietf-ac-extensions 4 1}. This is an exception
to the general rule stated above about the use of
GeneralName choices.
The direct check passes if:
the identity of the client as established by the
underlying authentication service matches the owner
field
and
(
the targets field contains one targetName which
is the "ALL" value
or
the current server (recipient) is one of the
targetName fields in the targets part
or
the current server is a member of one of the
targetGroup fields in the targets part.
)
How the membership of a target within a targetGroup is
determined is not defined here. It is assumed that any
given target "knows" the names of the targetGroup's to
Farrell & Housley [Page 14]
INTERNET-DRAFT April 1999
which it belongs or can otherwise determine its
membership. For example, if the targetGroup were to be a
DNS domain and the AC verifier knows the DNS domain to
which it belongs or it the targetGroup were "PRINTERS"
and the AC verifier "knows" that it's a printer or print
server.
A proxy check succeeds if
(
the identity of the sender as established by
the underlying authentication service matches
the owner field
and
(
the current server "matches" any one of
the proxy sets (where "matches" is as for
the direct check above)
)
)
or
(
the identity of the sender as established by
the underlying authentication service "matches"
one of the proxy sets (call it set "A")
and
(
the current server is one of the targetName
fields in the set "A"
or
the current server is a member of one of the
targetGroup fields in set "A".
)
)
Where an AC is proxied more than once a number of targets
will be on the path from the original client which is
normally, but not always, the AC owner. In such cases
prevention of AC "stealing" requires that the AC verifier
MUST check that all targets on the path are members of
the same proxy set. It is the responsibility of the AC
using protocol to ensure that a trustworthy list of
targets on the path is available to the AC verifier.
name ietf-ac-targeting
OID { ietf-ac-extensions 4 }
syntax ProxyInfo
criticality must be TRUE
Farrell & Housley [Page 15]
INTERNET-DRAFT April 1999
4.4.4 authorityKeyIdentifier
The authorityKeyIdentifier extension as profiled in
[RFC2459] MAY be used to assist the AC verifier in
checking the signature of the AC. The [RFC2459]
description should be read as if "CA" meant "AC issuer".
As with PKCs this extension SHOULD be included in ACs.
name id-ce-authorityKeyIdentifier
OID { id-ce 35 }
syntax AuthorityKeyIdentifier
criticality MUST be FALSE
4.4.5 authorityInformationAccess
The authorityInformationAccess extension as profiled in
[RFC2459] MAY be used to assist the AC verifier in
checking the revocation status of the AC. See section 6
on revocation below for details.
The following accessMethod is used to indicate that
revocation status checking is not provided for this AC:
ietf-ac-norevstat OBJECT IDENTIFIER ::=
{ ietf-ac-extensions 5}
The accessLocation field MUST contain a NULL
directoryName.
name id-ce-authorityInfoAccess
OID { id-pe 1 }
syntax AuthorityInfoAccessSyntax
criticality MUST be TRUE
4.5 Attribute Types
Some of the attribute types defined below make use of the
IetfAttrSyntax type defined below. The reasons for using
this type are:
1. It allows a separation between the AC issuer and the
attribute policy authority. This is useful for situations
where a single policy authority (e.g. an organisation)
allocates attribute values, but where multiple AC issuers
are deployed for performance, network or other reasons.
2. It allows the type of the attribute (privilege,
restriction) to be made explicit which helps server
implementations that provide an API on top of an AC
validation module.
Farrell & Housley [Page 16]
INTERNET-DRAFT April 1999
3. The syntaxes allowed for values are restricted to
OCTET STRING and OID, which reduces some of the matching
complexities associated with GeneralName.
<<The authors solicit comment on whether this flexibility
is required. The alternative would be to encourage the
use of attributes which have a GeneralName syntax and to
mandate this for role/group etc..>>
IetfAttrSyntax ::= SEQUENCE OF {
type INTEGER {
privilege(0),
restriction(1),
other(2)
}
DEFAULT privilege,
policyAuthority[0] GeneralNames OPTIONAL,
values SEQUENCE OF CHOICE {
octets OCTET STRING,
oid OBJECT IDENTIFIER
}
}
4.5.1 Service Authentication Info
This attribute type identifies the AC owner to the
server/service by a name and with optional authentication
information. Typically this will contain a
username/password pair for a "legacy" application (and
hence MAY need to be encrypted).
This attribute type will typically be encrypted if the
authInfo field contains sensitive information (e.g. a
password).
name ietf-ac-authInfo
OID { ietf-ac-attributes 1}
Syntax SvceAuthInfo
values: Multiple allowed
SvceAuthInfo ::= SEQUENCE {
service GeneralName,
ident GeneralName,
authInfo OCTET STRING OPTIONAL
}
Farrell & Housley [Page 17]
INTERNET-DRAFT April 1999
4.5.2 Access Identity
An access identity identifies the AC owner to the
server/service. For this attribute the authInfo field
MUST NOT be present.
name ietf-ac-accessId
OID { ietf-ac-attributes 2}
syntax SvceAuthInfo
values: Multiple allowed
4.5.3 Charging Identity
This attribute type identifies the AC owner for charging
purposes.
name ietf-ac-chargingId
OID { ietf-ac-attributes 3}
syntax IetfAttrSyntax
values: Multiple allowed
4.5.4 Group
This attribute carries information about group
memberships of the AC owner.
<<Might it be more useful to define OS-specific group
attribute types which map to UNIX gids and/or NT SIDs?
Even with that, application defined groups will be needed
- should they use a standard group attribute or should
appX-group attribute types be defined for each?>>
name ietf-ac-group
OID { ietf-ac-attributes 4}
syntax IetfAttrSyntax
values: Multiple allowed
4.5.5 Role
This attribute carries information about role allocations
of the AC owner.
name ietf-ac-role
OID { ietf-ac-attributes 5}
syntax IetfAttrSyntax
values: Multiple allowed
Farrell & Housley [Page 18]
INTERNET-DRAFT April 1999
4.5.6 Clearance
This attribute carries clearance (security labelling)
information about the AC owner.
name { id-at-clearance }
OID { joint-iso-ccitt(2) ds(5) module(1) selected-
attribute-types(5) clearance (55) }
syntax Clearance - imported from [X.5??]
values Multiple allowed
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories
SET OF SecurityCategory OPTIONAL
}
ClassList ::= BIT STRING {
unmarked (0),
unclassified (1),
restricted (2)
confidential (3),
secret (4),
topSecret (5)
}
SecurityCategory ::= SEQUENCE {
type [0] IMPLICIT SECURITY-CATEGORY,
value [1] ANY DEFINED BY type
}
SECURITY-CATEGORY MACRO ::=
BEGIN
TYPE NOTATION ::= type | empty
VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
END
4.5.7 EncryptedAttributes
Where an AC will be carried in clear within an
application protocol or where an AC contains some
sensitive information (e.g. a legacy application
username/password) then encryption of AC attributes MAY
be needed.
When a set of attributes are to be encrypted within an
AC, the cryptographic message syntax, EnvelopedData
structure [CMS] is used to carry the ciphertext(s) and
associated per-recipient keying information.
Farrell & Housley [Page 19]
INTERNET-DRAFT April 1999
This type of attribute encryption is targeted which means
that before the AC is signed the attributes have been
encrypted for a set of predetermined recipients.
The AC then contains the ciphertext(s) inside its signed
data. The "enveloped-data" (id-envelopedData) ContentType is
used and the content field will contain the EnvelopedData
type.
Only one encryptedAttributes attribute can be present in
an AC - however it MAY be multi-valued and each of its
values will contain an EnvelopedData.
Each value can contain a set of attributes (each possibly
a multi-valued attribute) encrypted for a set of
recipients.
The cleartext that is encrypted has the type:
ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName,
acSerial INTEGER,
attrs SEQUENCE OF Attribute
}
The DER encoding of the ACClearAttrs structure is used as
the encryptedContent field of the EnvelopedData, i.e. the
DER encoding MUST be embedded in an OCTET STRING.
The acIssuer and acSerial fields are present to prevent
ciphertext stealing - when an AC verifier has
successfully decrypted an encrypted attribute it MUST
then check that the AC issuer and serialNumber fields
contain the same values. This prevents a malicious AC
issuer from copying ciphertext from another AC issuer's
AC into an AC issued by the malicious AC issuer.
The procedure for an AC issuer when encrypting attributes
is illustrated by the following (any other procedure that
gives the same result MAY be used):
1. Identify the sets of attributes that are to be
encrypted for each set of recipients.
2. For each attribute set which is to be encrypted:
2.1. Create an EnvelopedData structure for the data for
this set of recipients.
2.2. Encode the EnvelopedData as a value of the
EncryptedAttributes attribute
2.3. Ensure the cleartext attribute(s) are not present in
the to-be-signed AC
Farrell & Housley [Page 20]
INTERNET-DRAFT April 1999
3. Add the EncryptedAttribute (with its multiple
values) to the AC
Note that the rule that each attribute type (the OID)
only occurs once may not hold after decryption. That is,
an AC MAY contain the same attribute type both in clear
and in encrypted form (and indeed more than once if the
decryptor is a recipient for more than one
EnvelopedData). One approach would be to merge attributes
following decryption in order to re-establish the "once
only" constraint.
name ietf-ac-encAttrs
OID { ietf-ac-attributes 6}
Syntax ContentInfo
values Multiple Allowed
4.6 PKC Extensions
Public key certificate extensions which assist in AC
handling are defined in this section.
<<just one for now, and hopefully, always!>>
4.6.1 AAControls
During AC validation a relying party has to answer the
question "is this AC issuer trusted to issue ACs
containing this attribute"? The AAControls PKC extension,
intended to be used in CA and AC Issuer PKCs, MAY be used
to help answer the question. The use of AAControls is
further described in section 5.
aaControls EXTENSION ::= {
SYNTAX AAControls
IDENTIFIED BY { ietf-ac-pkcexts-aaControls}
}
AAControls ::= SEQUENCE {
pathLenConstraint INTEGER (0..MAX) OPTIONAL,
permittedAttrs [0] AttrSpec OPTIONAL,
excludedAttrs [1] AttrSpec OPTIONAL,
permitUnSpecified BOOLEAN DEFAULT TRUE
}
AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
The aaControls extension is used as follows:
The pathLenConstraint if present is interpreted as in
[RFC2459], but now restricts the allowed "distance"
between the AA CA, (a CA directly trusted to include
AAControls in its PKCs), and the AC issuer.
Farrell & Housley [Page 21]
INTERNET-DRAFT April 1999
The permittedAttrs field specifies a set of attribute
types that any AC issuer below this AA CA is allowed to
include in ACs. If this field is not present, it means
that no attribute types are explicitly allowed (though
the permitUnSpecified field may open things up).
The excludedAttrs field specifies a set of attribute
types that no AC issuer is allowed to include in ACs. If
this field is not present, it means that no attribute
types are explicitly disallowed (though the
permitUnSpecified field may close things down).
The permitUnSpecified field specifies how to handle
attribute types which are not present in either the
permittedAttrs or excludedAttrs fields. TRUE (the
default) means that any unspecified attribute type is
allowed in ACs; FALSE means that no unspecified attribute
type is allowed.
5. AttributeCertificate Validation
This section describes a basic set of rules that all
"valid" ACs MUST satisfy. Some additional checks are also
described which AC verifiers MAY choose to implement.
To be valid an AC MUST satisfy all of the following:
1. the AC signature must be cryptographically correct
and the AC issuer's PKC MUST be verified in accordance
with [RFC2459]
2. if the AC issuer is not directly trusted as an AC
issuer (by configuration or otherwise), then the AC
issuer's certification path must satisfy the additional
PKC checks described below
3. the time of evaluation MUST be within the AC
validity (if the evaluation time is equal to either
notBeforeTime or notAfterTime then the AC is timely, i.e.
this check succeeds)
4. if an AC contains attributes apparently encrypted
for the AC verifier then the decryption process MUST not
fail - if decryption fails then the AC MUST be rejected
5. the AC targeting check MUST pass (see section 4.4.3
above)
6. if the AC contains any "unsupported" critical
extensions then the AC MUST be rejected.
"Support" for an extension in this context means:
a. the AC verifier MUST be able to parse the extension
value, and,
Farrell & Housley [Page 22]
INTERNET-DRAFT April 1999
b. where the extension value SHOULD cause the AC to be
rejected, the AC verifier MUST reject the AC.
The following additional certification path checks
(referred to in (2) above) MUST all succeed:
1. some CA on the AC's certificate path MUST be
directly trusted to issue PKCs which preceed the AC
issuer in the certification path, call this CA the "AA
CA"
2. all PKC's on the path from the AA CA down to and
including the AC issuer's PKC MUST contain an aaControls
extension as defined below (the PKC with the AA CA's as
subject need not contain this extension)
3. only those attributes in the AC which are allowed
according to all of the aaControls extension values in
all of the PKCs from the AA CA to the AC issuer, may be
used for authorization decisions, all other attributes
MUST be ignored (note that this check MUST be applied to
the set of attributes following attribute decryption and
that in such cases the ietf-ac-encAttrs type MUST also be
checked)
Additional Checks:
1. The AC MAY be rejected on the basis of further AC
verifier configuration, for example an AC verifier may be
configured to reject ACs which contain or lack certain
attribute types
2. If the AC verifier provides an interface that allows
applications to query the contents of the AC, then the AC
verifier MAY filter the attributes from the AC on the
basis of configured information, e.g. an AC verifier
might be configured not to return certain attributes to
certain targets.
Farrell & Housley [Page 23]
INTERNET-DRAFT April 1999
6. Revocation
In many environments, the validity period of an AC is
less than the time required to issue and distribute
revocation information. Therefore, short-lived ACs do
not require revocation support. However, long-lived ACs
and environments where ACs enable high value transactions
MAY require revocation support.
In such cases, AC revocation status MAY be checked using
the methods described in [RFC2459], but substituting the
AC issuer wherever a CA is mentioned.
Note however that this does not impose a requirement for
conformant AC issuers to be able to issue CRLs.
Where an AC issuer does not support revocation status
checks for a particular AC, then an authority information
access extension (id-pe-authorityInfoAccess) MUST be
present and critical in the AC to indicate this. Where no
authority information access is present, then the AC
issuer is implicitly stating that revocation checks are
supported and mechanisms in accordance with [RFC2459]
MUST be provided to allow AC verifiers to establish the
revocation status of the AC.
The accessMethod used to handle this case is described
above.
Farrell & Housley [Page 24]
INTERNET-DRAFT April 1999
7. Limited AC Acquisition Protocol
<<Note that this section is very likely to change and may
be removed, in particular if it is found that CMP or CMC
can be suitably extended to support AC acquisition. If
the WG reaches a consensus that a new protocol is needed
then this section may move to a separate I-D. Even with a
new protocol, it would be appropriate to examine
extending CMP/CMC to handle more general AC management
tasks. Basically, this is a "strawman">>
There is clearly a requirement for an AC management
protocol (or protocols, like [CMP] and [CMC]). Such
management protocols are not specified in this document.
There is also a requirement for a specification of an
LDAP schema, which is also not specified here.
In addition to such protocols, which may be more suited
to management of long-term or more sensitive (i.e. more
"powerful") ACs, there is a requirement for a very
simple, explicitly limited AC acquisition protocol.
This protocol is required for cases where an AC user
wishes to acquire a "current" AC for an entity (possibly
itself) leaving almost all details as to the content of
the AC to the AA or whatever network service acts on its
behalf.
We call this protocol the Limited AC Acquisition Protocol
(LAAP). The are two entities involved, the LAAP requestor
(LRQ) and LAAP responder (LRP). The LR is typically an AC
owner or an AC verifier; the LRP is typically the AA
itself.
LAAP is designed as a single-shot request/response
protocol with no polling, retries, etc.
The one and only feature of this protocol is to request
an AC for a particular entity that may be either the
requestor or some other entity. The response is the
requested AC or an error.
The security of the request and response (e.g. whether
the requestor is authenticated or not) is out of scope
and a matter for LAAP implementers. For example, an LRP
may be configured so that it only ever issues ACs if the
request is received over an authenticated channel (e.g.
TLS with client authentication), or it may only issue
"guest" privileges when the LRQ is not the owner of the
AC.
Farrell & Housley [Page 25]
INTERNET-DRAFT April 1999
The protocol consists of a request message that may
specify the identity of the AC owner (for the third party
case), with an optional "profile". A profile is to be
interpreted as a bilaterally agreed string that is mapped
to a set of AC contents by the LRP.
LACRequestMessage ::= SEQUENCE {
owner [0] CHOICE{
baseCertificateID [0] IssuerSerial,
-- the issuer and serial number of
-- the owner's Public Key Certificate
entityName [1] GeneralNames,
-- the name of the claimant or role
objectDigestInfo [2] ObjectDigestInfo
-- if present, version must be v2
} OPTIONAL,
profile [1] UTF8String OPTIONAL
}
<<Note that this message syntax omits any "proof" that
the LRQ has some valid reason to ask for an AC for the
owner. It would be (at least) nice to be able to include
such "proof", but can't be specified here since it might
depend on the client/server authentication. Other than
via the profile field, the LRQ also cannot specify the
target(s) where the AC will have to be verified. We need
to consider if these are needed or not.>>
Each field is described below.
"owner": when present this specifies that the LRQ wishes
to acquire an AC for this owner. When absent, it means
that the LRQ is requesting an AC for itself (the LRP
should use the identity established from whatever
underlying authentication is available). The rules for
the owner field in the AC apply here (e.g. no use of
objectDigestInfo).
"profile": when present this is an request to the LRP
that an AC matching a certain profile be returned. The
definition of profiles is not in scope for this
specification and is expected to be a local matter. This
field allows some simple switching.
Note that this definition means that the minimal LAAP
request message consists of the octets `3000'H, an empty
sequence. This message means "give me my current default
AC please".
Farrell & Housley [Page 26]
INTERNET-DRAFT April 1999
LACResponseMessage ::= CHOICE {
ac [0] AttributeCertificate,
errorInfo [1] ErrorMsgContent -- from [CMP]
}
When an LRQ receives an AC from an LRP it SHOULD verify
the AC. In addition the LRQ SHOULD ensure that the AC
"matches" the LAAP request issued. The only matching
which applies in general is to ensure that the LAAP
request owner field and the AC owner field are identical.
Implementations may of course include additional checks.
We define the following HTTP based transport for LAAP.
An LRQ should send a HTTP POST request to the LRP, the
POST data should consist of the DER encoding of the
LACRequestMessage. The response is expected to have the
MIME type "application/x-laapmsg" with the message data
containing the DER encoding of the LACResponseMessage.
<<how an LRQ knows the URL for an LRP is TBS>>
Farrell & Housley [Page 27]
INTERNET-DRAFT April 1999
8. Conformance
This specification defines two levels of conformance,
basic and proxy-enabled. For each level the actors
involved must meet different requirements. The intention
is that support for basic conformance should allow for
freely interoperable but fairly inflexible and
"featureless" AC based authorization. Proxy-enabled
conformance requires more effort from implementers, may
not be as widely interoperable and is harder to
administer, but does offer much more flexibility and many
more features.
A proxy-enabled AC issuer MUST be able to produce all of
the attribute types and extensions specified above.
A proxy-enabled AC verifier MUST "support" all of the
attribute types and extensions specified above.
"Support" in the previous paragraph means more than just
parsing. It means that the AC verifier MUST be able to
reject any AC which should not be valid at that target
and MUST be able to make any attributes and extensions
which were not fully processed available to the calling
application.
A proxy-enabled AC issuer is responsible to ensure that
no AC produced could be accepted by a basic AC verifier
in such a way as to cause a security breach.
<<dunno if that can happen but it needs to be checked>>
Basic conformance for an AC issuer means support for
production of ACs which:
1. MUST use the baseCertificateID owner field
alternative
2. MUST NOT be post-dated
3. MAY contain AccessIdentity, Group and/or Role
attributes with multiple values
4. MUST NOT contain any other attributes which cannot
safely be ignored by an AC verifier
5. MAY contain the AuthorityKeyIdentifier extension
6. MUST contain no critical extensions (and hence is
not proxiable) except for authorityInformationAccess
where revocation status checks are not provided
7. MUST NOT contain encrypted attributes
Basic conformance also requires support for the
AAControls PKC extension. A basic AC issuer MUST also
support LAAP as specified in section 7 above.
Farrell & Housley [Page 28]
INTERNET-DRAFT April 1999
Basic conformance for an AC verifier means support for
the validation of ACs which are produced by basic AC
issuers.
A basic AC verifier MAY ignore the presence of any
unsupported attributes or extensions (of course it must
reject all ACs which contain unsupported critical
extensions) and need only make the values of the
remaining attributes available to applications.
A basic AC verifier MUST support the AAControls PKC
extension.
9. Security Considerations
<<tbs>>
10. References
[CMC] Myers, M., et al. "Certificate Management
Messages over CMS",
draft-ietf-pkix-cmc-03.txt, March 1999.
[CMP] Adams, C., Farrell, S., "Internet X.509
Public Key Infrastructure - Certificate
Management Protocols", RFC2510.
[CMS] Housley, R., "Cryptographic Message Syntax",
draft-ietf-smime-cms-12.txt, March 1999.
[ESS] Hoffman, P., "Enhanced Security Services for
S/MIME",
draft-ietf-smime-ess-12.txt, March 1999.
[RFC2459] Housley, R., Ford, W., Polk, T, & Solo, D.,
"Internet Public Key Infrastructure - X.509
Certificate and CRL profile", RFC2459.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119.
[X.509] ITU-T Recommendation X.509 (1997 E):
Information Technology - Open Systems
Interconnection - The Directory:
Authentication Framework, June 1997.
[X.208-88] CCITT. Recommendation X.208: Specification
of Abstract Syntax Notation One (ASN.1).
1988.
[X.209-88] CCITT. Recommendation X.209: Specification
of Basic Encoding Rules for Abstract Syntax
Notation One (ASN.1). 1988.
[X.501-88] CCITT. Recommendation X.501: The Directory -
Models. 1988.
[X.509-88] CCITT. Recommendation X.509: The Directory -
Authentication Framework. 1988.
Farrell & Housley [Page 29]
INTERNET-DRAFT April 1999
[X.509-97] ITU-T. Recommendation X.509: The Directory -
Authentication Framework. 1997.
[XPDAM] ISO 9594-8 Information Technology - Open
systems Interconnection - The Directory:
Authentication Framework - Proposed Draft
Amendment 1: Certificate Extensions,
September 1998.
Author's Addresses
Stephen Farrell,
SSE Ltd.
Fitzwilliam Court,
Leeson Close,
Dublin 2,
IRELAND
tel: +353-1-216-2910
email: stephen.farrell@sse.ie
Russell Housley,
SPYRUS,
381 Elden Street,
Suite 1120,
Herndon, VA 20170,
USA
email: housley@spyrus.com
Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on
or otherwise explain it or assist in its implementation
may be prepared, copied, published and distributed, in
whole or in part, without restriction of any kind,
provided that the above copyright notice and this
paragraph are included on all such copies and derivative
works. In addition, the ASN.1 module presented in
Appendix B may be used in whole or in part without
inclusion of the copyright notice. However, this
document itself may not be modified in any way, such as
by removing the copyright notice or references to the
Internet Society or other Internet organizations, except
as needed for the purpose of developing Internet
standards in which case the procedures for copyrights
defined in the Internet Standards process shall be
Farrell & Housley [Page 30]
INTERNET-DRAFT April 1999
followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns. This document and the information
contained herein is provided on an "AS IS" basis and THE
INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Appendix A: Samples
tbs
Appendix B: "Compilable" ASN.1 Module
<<tbs - will be supplied in '88 format>>
Appendix C: Open Issues
This appendix lists open issues to be resolved (in order
of occurrence in the body of the document).
1. Additional introductory text is required to motivate
the use of ACs
2. The ASN.1 has to be synched with the ISO FPDAM where
necessary
3. An OID for ietf-ac has to be allocated
4. The objectDigest choice for owner has to be a MUST
NOT or else profiled (and explained!)
5. Are "restrictions" needed?
6. Is "IetfAttrSyntax" needed?
7. Should OS-specific group attribute types be defined?
8. More explanatory text for encryptedAttributes is
needed.
9. Is a new AC acquisition protocol required? If not,
how are ACs acquired? If so, should it be part of this
specification?
10. Are different conformance levels needed? If so, are
these the right ones?
11. Security considerations text needed
12. References section to be fixed
13. Compilable ASN.1 and samples are needed
Farrell & Housley [Page 31]