PKIX Working Group S. Farrell
INTERNET-DRAFT Baltimore Technologies
Expires in six months D.W. Chadwick
University of Salford
October 1999
Limited AttributeCertificate Acquisition Protocol
<draft-ietf-pkix-laap-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.
Abstract
The PKIX working group is profiling the use of X.509 attribute
certificates. This document specifies a deliberately limited
protocol for requesting an attribute certificate from a server. It
is intended to be complementary to the use of LDAP for AC retrieval,
covering those cases where use of an LDAP server is not suitable due
to the type of authorization model being employed. For many other
cases, the use of LDAP is preferred.
Table Of Contents
Status of this Memo.............................................1
Abstract........................................................1
Table Of Contents...............................................1
1. Introduction.................................................2
2. LAAP.........................................................3
2.1 Message Types..........................................3
2.1.1 Object Identifiers...............................3
2.1.2 LAAP Request Message.............................4
2.1.3 LAAP Response Message............................6
Farrell & Chadwick [Page 1]
INTERNET-DRAFT October 1999
2.2 Encapsulation in CMP...................................6
2.3 Authentication.........................................7
2.4 Error Handling.........................................7
3. Transport Mechanisms.........................................7
3.5 UDP....................................................7
3.6 TCP & HTTP.............................................8
4. Security Considerations......................................8
5. References...................................................8
Author's Addresses..............................................9
Full Copyright Statement........................................9
Appendix A: "Compilable" ASN.1 module..........................10
Appendix B: Samples............................................11
Appendix C: Changes this version / Open Issues.................11
1. Introduction
<<Comments are in angle brackets like this. Note that since this is
effectively a first draft of this protocol, many changes are to be
expected, possibly including significant re-design based on PKIX WG
review.>>
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in [RFC2119].
[ACPROF] specifies the Internet profile of the X.509 attribute
certificate (AC) for authorization purposes. This document specifies
a deliberately limited protocol for requesting such an AC from a
server.
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 to allow retrieval of ACs from LDAP
servers, which is specified in [LDAP-SCHEMA].
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. We call this protocol the Limited AC
Acquisition Protocol (LAAP).
LAAP consists of a simple request/response protocol encapsulated in
[CMP] messages. The entity which issues the request is called the
LAAP requestor (LRQ), the entity which issues the response is called
the LAAP responder (LRP). The LRQ is typically an AC owner or an AC
verifier; the LRP is typically the AC issuer itself.
Farrell & Chadwick [Page 2]
INTERNET-DRAFT October 1999
The situations in which LAAP may be more suitable for use than LDAP
include:
- where ACs are very short lived and the latency involved in writing
to the LDAP servers is relatively long (e.g. if a complex X.500
deployment is behind the LDAP server),
- where a least privilege style of AC use is required, the LRP can
modulate the AC content based on the context of the LAAP request,
for example, if the LRQ is authenticated and the LRP is the AC
issuer, then the LRP may choose to include only the minimal set of
attributes (administered to be) required by that LRQ,
- where there are potentially numerous ACs, many of which are never
actually used during their lifetime (in which case they should
only be generated if needed) e.g. many entities have permission to
access some data, but only a subset of them actually do access it,
- where ACs contain encrypted attributes and it may not be possible
to search the LDAP directory for ACs with attributes of a specific
type.
LAAP is only intended to be used for cases where an LRQ wishes to
acquire a "current" AC for an entity (possibly itself) leaving
almost all details as to the content of the AC to the LRP.
2. LAAP
The LAAP protocol consists of two new message types which are
embedded in the PKIMessage structure, GenMsgContent field defined in
[CMP]. Future specifications MAY enhance the request and/or response
types defined here - any such enhancement MUST use a different
object identifier to identify the GenMsgContent.
The one and only feature of this protocol is to request an AC for a
particular entity that may be either the LRQ or some other entity.
The response is the requested AC or an error.
2.1 Message Types
2.1.1 Object Identifiers
This section lists the object identifiers defined in this
specification.
The following object identifiers are inherited from [RFC2459] and
[CMP].
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }
id-it OBJECT IDENTIFIER ::= { id-pkix 4 }
The following new ASN.1 module identifier is defined:
id-mod-laap OBJECT IDENTIFIER ::= { id-mod <<tbs>> }
Farrell & Chadwick [Page 3]
INTERNET-DRAFT October 1999
<< probably { id-mod 13 }>>
The LAAP message types are defined as follows:
id-laap OBJECT IDENTIFIER ::= { id-it <<tbs>> }
<< probably { id-it 7 } >>
id-laap-req OBJECT IDENTIFIER ::= { id-laap 1 }
id-laap-rep OBJECT IDENTIFIER ::= { id-laap 2 }
2.1.2 LAAP Request Message
The request 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 may be mapped to a
set of AC contents by the LRP. In the third party case, the LRQ, MAY
also include some evidence that the AC owner has requested the LRQ
to retrieve an AC belonging to the AC owner.
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,
ownerAuth [2] SEQUENCE {
authMethod OBJECT IDENTIFIER,
authInfo ANY
} OPTIONAL
}
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 authentication is available). The rules
for the owner field specified in [ACPROF] apply here (e.g.
constrained use of entityName).
"profile": when present this is a request to the LRP that an AC
matching the supplied profile is returned. The definition of
profiles is not in scope for this specification and is expected to
be a local matter. There are two main uses envisaged for this field:
- Where an LRQ requests its own AC, then the profile field can be
used for those entities which require a non-default AC. The typical
case here is where a user requests her AC in order to "push" it to a
Farrell & Chadwick [Page 4]
INTERNET-DRAFT October 1999
relying party via some protocol (like CMS). In most such cases, the
user can use a default AC whose content has been selected for her by
an administrator. Occasionally, such users will require a different
AC, perhaps for use in some application environment that is seldom
used. In such cases the profile field can contain a value provided
to the user by the AA administrator. It is often the case that a
profile maps well to a role in this scenario.
- When a relying party requests an AC for another entity it needs
the AC to contain a set of attributes which will enable the relying
party to make a "good" authorization decision. In most such cases,
the identity of the relying party will determine (for the AA) the
set of attribute types required. However, in cases where the
identity of the relying party is not known, or where a single
relying party makes "different" types of authorization decision,
(say where two applications run from a single account), then the
profile allows the relying party to specify which "type" of
authorization decision it wishes to make. It is often the case that
the profile maps well to an application or function in this
scenario.
Where it is desirable that the profile contain a globally unique
value, the profile string MAY contain a string encoded object
identifier as specified in LDAP [RFC2252], for example, "1.2.5.5.2"
is a valid string encoded object identifier. Conformant
implementations MUST be able to accept profiles containing such
string encoded object identifiers.
One possible implementation model which can usefully use this string
encoded OID is for the profile to contain the OID of an LDAP or
X.500 object class ([X.501], [RFC2526]) and for the LRP to produce
an AC containing the relevant attribute values specified by that
object class.
Note that in all cases where a profile is specified by an LRQ, the
resulting AC may or may not meet the LRQ's expectation for ACs which
"match" the requested profile. The LRQ MUST check the resulting AC,
if it needs to check this "matching". Note also, that in addition to
selecting the "attributes" field, an LRP MAY also use the profile to
determine other AC fields, e.g. validity or extensions.
<<The use of OIDs for the profile and the rules that an LRP
MUST/SHOULD/MAY follow on receipt of a profile field specifying an
object class are for further study. The mapping between an object
class OID and a set of AC extensions (or e.g. validity) is also for
further study.>>
"ownerAuth": this field provides an indirect mechanism for the owner
to authenticate the AC request to the LRP (via the LRQ). This is
intended to handle the third party case, but where the LRP also
requires some proof that the AC should be issued/delivered. For
example, authInfo could contain a signature from the owner over the
LRQ name and a timestamp. Since the types of authentication which
Farrell & Chadwick [Page 5]
INTERNET-DRAFT October 1999
can be used will depend on the client/server protocol in use between
the owner and LRQ, no authentication methods are defined here.
Protocols which make use of LAAP and which allow the use of
ownerAuth MUST specify the details of the authentication which is
allowed.
<<Is ownerAuth really needed? Since we're not defining anything for
the octet hole, it should probably disappear. We could however,
define some sort of capability, that an owner could give to an LRQ.
Prospective implementers should note: It is *very* likely that this
field will disappear or change dramatically in later versions.>>
Note that this definition means that the minimal LAAP request
structure consists of the octets æ3000ÆH, an empty ASN.1 sequence.
This means "give me my current default AC please".
2.1.3 LAAP Response Message
The response message consists of an AC (errors are handled at the
CMP level).
LACResponseMessage ::= AttributeCertificate
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, i.e. that the owner in the AC matches that in the
request (if present). Implementations may of course include
additional checks.
The AC in the response MUST conform to the profile specified in
[ACPROF].
<<do we need the LRQ to indicate its support for optional features
from [ACPROF] in the request??>>
2.2 Encapsulation in CMP
LAAP requests and responses are carried within a PKIMessage, as
defined in [CMP].
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX)
OF Certificate OPTIONAL
}
The GenMsgContent CHOICE of the PKIBody contains the LAAP request or
response. Each GenMsgContent consists of an OID and an ANY. We use
separate OIDs for LAAP requests and responses.
Errors are handled using the ErrorMsgContent form of PKIBody.
Farrell & Chadwick [Page 6]
INTERNET-DRAFT October 1999
A conformant implementation is NOT REQUIRED to be able to handle any
other form of PKIBody. Of course, an LRQ or LRP MAY also handle
other forms of PKIBody, e.g. the mandatory profile specified in
[CMP].
The fields of the PKIHeader MUST be used as specified in section
3.1.1 of [CMP]. <<may need more specification here.>>
2.3 Authentication
Though the PKIMessage construct supports the use of various forms of
authentication, the security required for a specific LAAP request or
response is not specified here. In order to provide a basic level of
interoperability LRPs MUST be able to handle requests authenticated
with either the PasswordBasedMac or signature methods described in
[CMP] section 3.1.3. LRPs MUST also be able to handle requests which
contain no PKIProtection (though they MAY always return an error).
LRQs MAY implement either PKIProtection method, but MUST support
one, and MUST also support production of requests without any
PKIProtection (for cases where the transport provides
authentication).
2.4 Error Handling
If an LRP receives any CMP message which it does not support (e.g. a
public key certification request), then it MUST respond with an
error containing "rejection" as the PKIStatus, and "badRequest" as
the PKIFailureInfo. The status string MAY contain any implementation
specific value (though note that this field is intended to be human
readable).
For all other error conditions the PKIStatus MUST be "rejection".
For example, an LRP MUST NOT respond with a "waiting" PKIStatus.
LAAP is not intended to handle cases where production of an AC
requires operator intervention.
3. Transport Mechanisms
LAAP can be carried via a number of transport mechanisms. We define
three. Firstly, directly over UDP, secondly directly over TCP,
thirdly by encoding within HTTP.
LRQ implementations MUST support the TCP transport and SHOULD
support the UDP transport. LRP implementations MUST support both the
TCP and UDP transports. Either MAY support the HTTP transport.
3.5 UDP
<<The UDP transport is basically TBS. UDP seems attractive for
performance reasons, given that an LRP may have to process many
Farrell & Chadwick [Page 7]
INTERNET-DRAFT October 1999
requests. One approach is to allow the LRP to tell the LRQ to switch
to TCP is the response is too big.>>
3.6 TCP & HTTP
[CMP] already defines TCP and HTTP transports. These MAY also be
used for LAAP. Some changes based on implementation experience have
been developed in [CMP-TCP] and [CMP-HTTP]. These changes supercede
the equivalent transports defined in [CMP] and MUST be supported by
compliant implementations.
LRQs and LRPs are NOT REQUIRED to support polling, as either an AC
or an error is expected to be produced immediately in response to a
request. This means that even if an LRP does support other forms of
[CMP] requests, it cannot use the polling mechanism in response to a
LAAP request.
4. Security Considerations
The LRQ MUST verify the AC using the rules given in [ACPROF] before
making an authorization decision based on the AC.
LAAP (like all such protocols) is vulnerable to denial-of-service
attacks, this should be taken into account before deployment.
If the LRP is the actual AC issuer, then it should be very careful
about handing out ACs in response to unauthenticated requests. One
model would be to manage the authentication "strength" required
before issuing a given (type of) AC.
5. References
[ACPROF] Farrell, S., Housley, R. "An Internet
AttributeCertificate Profile for Authorization",
draft-ietf-pkix-acprof-01.txt, September 1999.
[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.
[CMP-TCP] Tschalar, R. et al, "Using TCP as a Transport Protocol
for CMP", draft-ietf-pkix-cmp-tcp-00.txt, September
1999, work-in-progress.
[CMP-HTTP] Tschalar, R. et al, "Using HTTP as a Transport Protocol
for CMP", draft-ietf-pkix-cmp-http-00.txt, August 1999,
work-in-progress.
[LDAP-SCHEMA]Chadwick, D., "Internet X.509 Public Key Infrastructure
Operational Protocols - LDAPv3" draft-pkix-ldap-v3-
01.txt, August 1999, work-in-progress.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, BCP 9, October 1996.
Farrell & Chadwick [Page 8]
INTERNET-DRAFT October 1999
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119.
[RFC2459] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet
Public Key Infrastructure - X.509 Certificate and CRL
profile", RFC2459.
[RFC2252] Wahl, M., et al., " Lightweight Directory Access
Protocol (v3): Attribute Syntax Definitions", RFC2252.
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for
use with LDAPv3", RFC2256.
[X.501] ITU-T Recommendation X.501 : Information Technology -
Open Systems Interconnection - The Directory: Models,
1993.
Author's Addresses
Stephen Farrell,
Baltimore Technologies,
61/62 Fitzwilliam Lane,
Dublin 2,
IRELAND
tel: +353-1-647-3000
email: stephen.farrell@baltimore.ie
David Chadwick
IS Institute
University of Salford
Salford
England
M5 4WT
email: d.w.chadwick@salford.ac.uk
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
followed, or as required to translate it into languages other than
English.
Farrell & Chadwick [Page 9]
INTERNET-DRAFT October 1999
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: "Compilable" ASN.1 module
PKIXLaap {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
-- temporary, still tbs -- id-mod-laap(13)}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
IssuerSerial, ObjectDigestInfo, AttributeCertificate
FROM
PKIXAttributeCertificate {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5)
pkix(7) id-mod(0) id-mod-attribute-cert(12)}
id-pkix
FROM
PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5)
pkix(7) id-mod(0) id-pkix1-explicit-88(1)}
GeneralNames
FROM
PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5)
pkix(7) id-mod(0) id-pkix1-implicit-88(2)};
-- this is referenced, but not defined in [CMP]
id-it OBJECT IDENTIFIER ::= { id-pkix 4 }
id-laap OBJECT IDENTIFIER ::=
{ id-it -- temporary, still tbs -- 7 }
-- these OIDs are used as the infoType of the respective
-- GenMsgContent PKIBody fields
id-laap-req OBJECT IDENTIFIER ::= { id-laap 1 }
id-laap-rep OBJECT IDENTIFIER ::= { id-laap 2 }
Farrell & Chadwick [Page 10]
INTERNET-DRAFT October 1999
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,
ownerAuth [2] SEQUENCE {
authMethod OBJECT IDENTIFIER,
authInfo ANY
} OPTIONAL
}
LACResponseMessage ::= AttributeCertificate
END
Appendix B: Samples
<<tbs>>
Appendix C: Changes this version / Open Issues
Changes this version:
1. This is the first issue, previously LAAP was specified as part
of the AC profile [ACPROF]
2. Changed LAAP so its now encapsulated in [CMP]
3. Added more definition of profile field
4. Added ownerAuth field (probably temporarily)
5. Added requirement for UDP transport
6. Added compiled ASN.1 module
Open issues:
1. register new OIDs
2. Use of profile, esp. OIDs & mapping to AC content
3. ownerAuth: leave in or delete?
4. CMP encapsulation: use or not?
5. Does the LRQ need a way to tell the LRP how much of [ACPROF] it
supports? (Probably yes, & include this as an optional field in
the request structure.)
6. UDP transport: needed? define where?
7. Samples.
Farrell & Chadwick [Page 11]