Internet DRAFT - draft-kaaps-acp
draft-kaaps-acp
KAAPS K. Burda
Internet Draft Brno University of Technology
Intended status: Informational I. Strasil
Expires: June 2012 Brno University of Technology
T. Pelka
Brno University of Technology
P. Stancik
Brno University of Technology
December 5, 2011
Access Control Protocol (ACP)
draft-kaaps-acp-01.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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
This Internet-Draft will expire on June 5, 2009.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Burda Expires June 5, 2012 [Page 1]
Internet-Draft Access Control Protocol (ACP) December 2011
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
Access Control Protocol (ACP) is a protocol for unified implementation
of various methods for computer device access control. The protocol
allows two devices to negotiate required assets, negotiate an
authentication method, do authentication, deliver the access parameters
and do accounting, all within one so called "transaction". Separate
transactions can be joined so that more devices can be added to the
access control operation.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................3
3. Messages of ACP protocol.......................................4
3.1. ACP message structure.....................................4
3.2. ACP message types.........................................8
4. AVP formats and types.........................................10
4.1. AVP formats..............................................10
4.2. AVP types................................................11
4.2.1. Entity names........................................11
4.2.2. Device addresses....................................12
4.2.3. Method codes........................................12
4.2.4. Asset codes.........................................13
4.2.5. Transaction outputs.................................14
4.2.6. Interoperability....................................15
4.2.7. Cryptographic primitives............................16
4.2.8. Supplemental AVPs...................................17
5. ACP protocol transactions.....................................19
5.1. Transaction description..................................19
5.2. Reduced transactions.....................................20
5.3. Principles of communication..............................20
5.4. ACP-VSA protocol.........................................22
5.5. Joining transactions.....................................22
6. Security Considerations.......................................24
7. IANA Considerations...........................................25
8. References....................................................25
9. Acknowledgments...............................................25
Burda Expires June 5, 2012 [Page 2]
Internet-Draft Access Control Protocol (ACP) December 2011
1. Introduction
The ACP is a protocol for unified implementation of various methods
for controlling the access to assets of network devices (such as data
on servers or communication services on Access Points). The ACP is
used for the access control by so called access control (AC) portals
(portals for short). The A portal is a part of a network device which
controls the access of other devices to the assets of that device or
which negotiates the access of applications of the device to other
devices.
The protocol allows any pair of devices to determine required assets,
determine an authentication method, do authentication, deliver
authentication parameters and do accounting. A sequence of messages
related to one concrete asset access control is called a transaction,
the portal of applying device is called a Supplicant and the portal
providing the assets is called a Provider.
The Supplicant and the Provider can communicate directly or through
more portals within one transaction. Different ACP transactions can
be joined in various ways by which means it is possible to
incorporate other portals to the access control process.
The portal is composed of a core and additional optional modules. By
the choice of modules, an administrator of a network device can set
up the portal to enforce an access control policy working with
particular available hardware. The modules are categorized as
communication, authentication and policy modules. The communication
module allows the communication between portals over a chosen
communication channel (for example, UDP channel, TLS, USB, EAPoL
etc.). The authentication module allows the execution of chosen
authentication methods (for example, EAP-MD5, EAP-TLS etc.). The
policy module allows the administrator to define an access control
algorithm for controlling the assets of the device (for example, data
on a hard drive). The portal can have more modules of the same type.
2. Conventions used in this document
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 [1].
Burda Expires June 5, 2012 [Page 3]
Internet-Draft Access Control Protocol (ACP) December 2011
The data types used in our specification are following:
o Octet: a data unit of eight bits.
o Text: a sequence of octets containing UTF-8 encoded characters
[2].
o String: a sequence of octets containing binary data (values 0
through 255 decimal, inclusive).
All lengths are given in octets if not stated otherwise.
3. Messages of ACP protocol
3.1. ACP message structure
The structure of an ACP message is illustrated in Fig. 1. The message
is composed of a header and N attribute-value pairs (AVPs, see Chap.
4), where N = 0, 1, 2, ....The message with N = 0 is called an empty
message.
+----------+-----------+-----------+---------------+-----------+
| HEADER | AVP_1 | AVP_2 | .... | AVP_N |
| 7 | | | | |
+----------+-----------+-----------+---------------+-----------+
Figure 1 ACP message structure.
The message header (see Fig. 2) is composed of CODE, IDENTIFIER and
LENGTH fields.
+------+------------+------------+
| CODE | IDENTIFIER | LENGTH |
| 1 | 3 | 3 |
+------+------------+------------+
Figure 2 ACP header structure.
CODE field (1 octet):
Burda Expires June 5, 2012 [Page 4]
Internet-Draft Access Control Protocol (ACP) December 2011
The CODE field determines the type of the message and indicates that
the message is the ACP protocol message. Such indication enables the
coexistence of the ACP protocol with the EAP [3] protocol in one
channel. The bit structure is shown in Fig. 3.
Burda Expires June 5, 2012 [Page 5]
Internet-Draft Access Control Protocol (ACP) December 2011
+------+------------+------------+
| P | R3 .. R0 | M2 .. M0 |
| 1 b | 4 b | 3 b |
+------+------------+------------+
Figure 3 CODE field structure.
The meaning of CODE field bits is following:
P bit:
The P bit distinguishes the message of the ACP protocol from messages
of the EAP protocol. The value of the P bit MUST be 1.
R3 .. R0 bits:
These bits are reserved for future use. Values of all bits MUST be
set to 0.
M2 .. M0 bits:
These bits determine the type of the message (see chapter 3.2). The
M0 bit also specifies the direction of a transaction. The messages
with M0 = 0 are sent from the Supplicant to the Provider and messages
with M0 = 1 are sent from the Provider to the Supplicant.
IDENTIFIER field (3 octets):
The IDENTIFIER field contains a unique identifier which can be used
to distinguish messages of a particular transaction from messages of
other transactions. The value of the IDENTIFIER field is set within a
channel by the portal which sends the first message, called START
message, over that particular channel. The portals determine the
INDETIFIER value independently from next portals. A possible
collision, where two portals use the same IDENTIFIER value, can be
resolved by the M0 bit as follows.
Fig. 4 illustrates the setting of the IDENTIFIER value. The figure
depicts four portals called A, B, C, and D. In the case of
Burda Expires June 5, 2012 [Page 6]
Internet-Draft Access Control Protocol (ACP) December 2011
transaction T_1, portal A is the Supplicant, portal D is the Provider
and portals B, C are transit nodes. The IDENTIFIER value within the
channel A-B is set by portal A, within the B-C channel by portal B
and within the C-D channel by portal C. In the case of transaction
T_2, portal D is the Supplicant, portal A is the Provider and portals
B, C are transit nodes. The IDENTIFIER value within the channel C-D
is set by portal D, within the B-C channel by portal C and within the
A-B channel by portal B. Therefore, within the B-C channel, the
IDENTIFIER might be for both transactions the same. Nevertheless, the
transactions can be distinguished by the M0 bit value. For our
example and node C, the M0 bit is set to 1 in T_1 transaction because
A is the Supplicant and D is the Provider. In transaction T_2, A is
the Provider and D is the Supplicant, therefore M0 = 0.
T_1, M0=0 T_1, M0=1
+-------> <-------+
+-----+ +-----+ +-----+ +-----+
| A |----| B |-------------------| C |-----| D |
+-----+ +-----+ +-----+ +-----+
T_2, M0=1 T_2, M0=0
+-------> <-------+
Figure 4 IDENTIFIER value setting example.
LENGTH field (3 octets):
The LENGTH field indicates the full length of the message in octets,
including the header. If any portal receives a message with wrong
length, the whole transaction MUST be canceled by the receiving
portal. The cancelation is made by deleting all operational
information related to that transaction. The portal does not react on
further messages of that transaction. Such behavior closes the
connection. The cancelation of the transaction in other portals is
done by the expiration of timers (see 5.3). Also, the Provider can
cancel the transaction by sending an empty message FINISH.
Burda Expires June 5, 2012 [Page 7]
Internet-Draft Access Control Protocol (ACP) December 2011
3.2. ACP message types
The ACP protocol defines 6 types of messages, named START, OFFER,
SPECIFICATION, REQUEST, RESPONSE and FINISH. Using these messages,
transactions are implemented. A transaction is an interchange of
messages between a Supplicant and a Provider who controls the access
of the Supplicant to a concrete asset of the Provider.
In general, the transaction is composed of following stages:
o start of the transaction (message START),
o negotiation of transaction parameters (OFFER and SPECIFICATION
messages),
o authentication (REQUEST and RESPONSE messages),
o termination of transaction (FINISH message).
During the start of a transaction, the connection between the
Supplicant and the Provider is established. In the next phase, the
parameters of the transaction are set (usually the requested asset
and authentication type). The identity of the Supplicant and in some
cases the identity of the Provider are verified during the
authentication phase. In the last phase of the transaction, the asset
(for example, an authentication factor for another transaction) or
access parameters (acceptance/denial of access, given IP) are sent.
The connection between the Supplicant and the Provider is terminated
in this phase.
The transactions are distinguished in each portal by a unique
transaction identifier which is an inner variable of portals. The
transactions are distinguished in each connection by the unique
variable IDENTIFIER in the message header and by the M0 bit (see
3.1).
A more detailed description of message types is given below.
START message (M2 .. M0 = [000]):
The START message is always sent by the Supplicant. The connection
between the Supplicant and the Provider is built based on information
in START. The information needed to establish the connection is
provided by the device administrator for each portal. From the
information in START message and the information given by the device
Burda Expires June 5, 2012 [Page 8]
Internet-Draft Access Control Protocol (ACP) December 2011
administrator, it is possible to choose a next portal and respective
channel for forwarding the START message. By such a technique, the
whole connection between the Supplicant and the Provider is built.
With the arrival of the START message, each participating portal
registers the transaction and fixes the IDENTIFIER value for the
connection to a next portal. All following messages of given
transaction are routed the same way as the START message.
OFFER (M2 .. M0 = [001]) message:
The OFFER message is the first one from the pair used for the
parameter establishment. It is always sent by the Provider, who uses
the message for offering a transaction parameter (an asset, an
authentication type etc.) or for asking for some parameter.
SPECIFICATION (M2 .. M0 = [110]) message:
The SPECIFICATION message is the second one from the pair used for
the parameter establishment. It is always sent by the Supplicant, as
a mandatory response to the OFFER message. The Supplicant sends the
value of the chosen or requested transaction parameter in it.
The interchange of OFFER and SPECIFICATION messages creates the
transaction parameter negotiation phase. There can be more OFFER-
SPECIFICATION pairs sent if the parameters are negotiated one by one.
The parameter negotiation phase can be omitted from the transaction
if only one parameter is available or if the Supplicant specifies
correct parameter values in the START message.
REQUEST (M2 .. M0 = [101]) message:
The REQUEST message is the first one from the pair used for the
authentication phase. It is always sent by the Provider. The message
contains data required for authentication (for example, the EAP
message).
RESPONSE (M2 .. M0 = [010]) message:
The RESPONSE message is the second one from the pair used for the
authentication. It is always sent by the Supplicant, as a mandatory
response to the REQUEST message. The message contains data required
for authentication.
The interchange of REQUEST-RESPONSE messages forms the authentication
phase. There can be more REQUEST-RESPONSE pairs sent, depending on
the type of authentication.
Burda Expires June 5, 2012 [Page 9]
Internet-Draft Access Control Protocol (ACP) December 2011
FINISH (M2 .. M0 = [111]) message:
The FINISH message is always sent by the Provider. The message
contains either an asset (for example, an authentication factor for
another transaction) or access parameters (acceptance/denial of
access, given IP etc.). The FINISH message closes the transaction and
terminates the connection between the Supplicant and the Provider.
4. AVP formats and types
4.1. AVP formats
Attribute-Value Pair (AVP) is a data structure depicted in Fig 5.
+-------+-------+--------------------------+
|Type |Length | Value |
| | | |
|1 |x | |
+-------+-------+--------------------------+
Figure 5 AVP Structure.
Type (1 octet) field:
The Type field defines the meaning of data in the Value field.
Length (x octet) field:
The Length field defines the length of the Value field in octets. For
SAVP (see below), x = 1, and for LAVP and CAVP, x = 2.
Value (< 256^x octet):
The Value field contains the actual data.
There are three AVP formats defined.
o Short AVP (SAVP): contains only one data type shorter than 2^8
octets. This format is defined for the transport of short blocks
of data and for the usage on systems with restricted computational
resources. The Type value of SAVP is in the range 0-127.
Burda Expires June 5, 2012 [Page 10]
Internet-Draft Access Control Protocol (ACP) December 2011
o Long AVP (LAVP): contains only one data type shorter than 2^16
octets. This format is defined for the transport of longer blocks
of data. The Type value of LAVP is in the range 128-191.
o Container AVP (CAVP): contains one or more AVPs of any types. CAVP
can contain various SAVPs, LAVPs and CAVPs in any combination. The
total length of all combined AVPs MUST be shorter than 2^16
octets. CAVP is defined for combining more AVPs to a single AVP.
The common criterion can be the same AVP type, the same
authentication code of a group etc. The Type value of CAVP is in
the range 192-255.
If the Supplicant or the Provider receives an AVP of a type which
cannot be processed, the transaction MUST be canceled. The
cancelation is done by the deletion of all operational information
related to the transaction. The cancelation of the transaction in
other portals is made by the expiration of timers. Also, the Provider
can cancel the transaction by sending an empty message FINISH.
4.2. AVP types
4.2.1. Entity names
Following AVPs allow the transport of names of entities (persons or
devices). Portals can identify Supplicants, Providers, Authenticators
(devices which are able to authenticate the Supplicant) and
Accountants (devices, to which the information about Supplicant
access are sent) from these names. The format of notation of these
AVPs is NAME_AAA_B, where AAA is the abbreviation of an entity role
(SUP = Supplicant, PRO = Provider, AUT = Authenticator, ACC =
Accountant). The letter on B position denotes whether the name is
Local (L) or Global (G). The names can be, for example, of e-mail
type (entity_name@domain_name) or of phone number type
(+xyz123456789).
Name Meaning AVP Type Value Type
NAME_SUP_G Global name of Supplicant 0 Text
NAME_PRO_G Global name of Provider 1 Text
NAME_AUT_G Global name of Authenticator 2 Text
NAME_ACC_G Global name of Accountant 3 Text
NAME_SUP_L Local name of Supplicant 4 Text
Burda Expires June 5, 2012 [Page 11]
Internet-Draft Access Control Protocol (ACP) December 2011
Name Meaning AVP Type Value Type
NAME_PRO_L Local name of Provider 5 Text
NAME_AUT_L Local name of Authenticator 6 Text
NAME_ACC_L Local name of Accountant 7 Text
4.2.2. Device addresses
The following AVPs allow the transport of device addresses. The
format of notation of these AVPs is ADDR_AAA_B, where AAA is the
abbreviation of entity role (SUP = Supplicant, PRO = Provider, AUT =
Authenticator, ACC = Accountant). The address is always numerical and
its type is given by the length of the address. IPv6 is 16 octets
long, MAC is 6 octets long, IPv4 is 4 octets long and TCP/UDP ports
are 2 octets long. The letter on B position denotes whether the
address is Local (L) or Global (G). Local addresses are defined by
the administrator of the location.
Name Meaning AVP Type Value Type
ADDR_SUP_G Global address of Supplicant 16 String
ADDR_PRO_G Global address of Provider 17 String
ADDR_AUT_G Global address of Authenticator 18 String
ADDR_ACC_G Global address of Accountant 19 String
ADDR_SUP_L Local address of Supplicant 20 String
ADDR_PRO_L Local address of Provider 21 String
ADDR_AUT_L Local address of Authenticator 22 String
ADDR_ACC_L Local address of Accountant 23 String
4.2.3. Method codes
The following AVPs allow the transport of authentication method
codes. Globally, the EAP protocol methods are expected to be used,
therefore SAVP of EAP type is defined. In the SAVP, the EAP Type (for
example, 4 for the MD5-Challenge method) is the method code [3]. The
length of the code is usually 1 octet. SAVP of the LAM type is
defined for locally defined authentication methods. In that SAVP, the
codes are defined by the administrator of the location.
Name Meaning AVP Type Value Type
EAP EAP authentication method 32 String
LAM Local authentication method 33 String
Burda Expires June 5, 2012 [Page 12]
Internet-Draft Access Control Protocol (ACP) December 2011
A concrete transcript of ACP messages with the definition of content
of these messages is called a variant of the ACP protocol. The
default variant of the ACP is the Variant of Single Answers (ACP-VSA,
see 5.4). After mutual agreement, it is also possible to choose a
different variant of ACP to get a more efficient protocol. The switch
to a newly agreed variant of the protocol is done by sending and
receiving a SPECIFICATION message, where the Supplicant chooses the
variant.
The variants of the ACP can be global and local. The code of a global
variant is a six digit number. The first four digits represent the
RFC number where the method is defined. The last two digits define
the sequence number of the variant within the RFC. Variants are
numbered starting with 1 according to their order in RFC. The ACP-VSA
code is set to 000000. The local variant of the ACP protocol is
defined by the administrator of the location.
For each of ACP protocol variants, there are AVP types reserved. They
can be used by the variant creators with respect to their needs. The
reserved SAVP types are in the interval 96 - 127, LAVP types are in
176 - 191 and CAVP types are in 240 - 255. The meaning of these AVPs
depends on agreed ACP protocol variant.
Following AVPs allow both sides to negotiate the variant of the ACP
protocol.
Name Meaning AVP Type Value Type
GVP Global protocol variant 34 Text
LVP Local protocol variant 35 Text
4.2.4. Asset codes
The following AVP codes allow the transport of asset codes. The
assets can be encoded globally or locally. For the global asset
encoding, there is no existing standard available and therefore it is
here defined that the Value Type is an octet and assets have
following values:
o 0 = implicit asset. It is an asset implicitly provided by the
Provider (for example, the access of users to a network in the
case of an Access Point device).
Burda Expires June 5, 2012 [Page 13]
Internet-Draft Access Control Protocol (ACP) December 2011
o 1 = entity authentication. The Provider of this asset is able to
authenticate an entity and the result of authentication can be
sent in the FINISH message.
The principle of local encoding is based on a hierarchical tree,
where every node can be forked using a respective octet value into
next 256 nodes. Every asset is linked to one node of the tree;
therefore each asset can be encoded as a string of octets. The
forking should be done by logical criterions. For example, the
administrator can set in the first level that 1 = assets defined for
the access of users and 2 = assets defined for the access of the
administrator (for example, the configuration files of a computer).
Further, the administrator defines that the users can access the
services 1 = web server, 2 = mail server etc. The code for the mail
server access is then 1.2.
The Supplicant usually does not know the codes of assets in the
location, but he or she can learn these codes form the OFFER message.
In each OFFER message, more asset codes can be transferred. All
assets should be from the same hierarchical level and should have a
common parent node. The Supplicant chooses one concrete item from the
SPECIFICATION message. This item can represent a concrete asset or a
group of assets on a hierarchically lower level.
Name Meaning AVP Type Value Type
ASSET_G Global asset code 36 String
ASSET_L Local asset code 37 String
4.2.5. Transaction outputs
The following AVPs are related to the FINISH message. In this
message, the Provider informs the Supplicant about the result of the
transaction, states the parameters for the asset access and
eventually sends the assets. The RESULT code contains the result of
the transaction. Value 0 represents the state where the access is
accepted and value 2 means that the access is denied. Value 1
represent the state, where the transaction is finished but the access
control process is still running. This value is defined for cases
where the final result of the transaction is presented by other
techniques (for example, door opening for an access card owner).
Addresses are parameters required for the access to assets. To
transfer addresses, already defined AVPs are used. The notation is
ADDR_AAA_B, where AAA is the entity role (SUP = Supplicant, PRO =
Burda Expires June 5, 2012 [Page 14]
Internet-Draft Access Control Protocol (ACP) December 2011
Provider, AUT = Authenticator and ACC = Accountant). The letter on B
position denotes whether the address is Local (L) or Global (G). In
the context of the FINISH message type, SUP is the address given to
the Supplicant, PRO is the address of the device providing the access
to assets, AUT is the address of the device which can authenticate
the Supplicant on behalf of other devices and ACC is the address of
the device which is doing the evidence of Supplicant's accesses.
Names, codes and authentication factors needed for other assets are
also the assets of the FINISH message. To transfer names, the already
defined AVPs are used. The notation is NAME_AAA_BC, where AAA is the
entity role (SUP = Supplicant, PRO = Provider, AUT = Authenticator
and ACC = Accountant). Meaning of abbreviations is the same as in the
previous section. Already defined methods and assets are used for the
transport of codes. In the case of further authentication, the
Supplicant would need some secret information to prove his or her
identity (so called proving factor) and eventually information for
the verification of other side (so called verification factor). Both
factors can be in the form of a password, cryptographic key etc. To
transfer the authentication factors, the LAVPs of PROVE and VERIF
types are used.
A specific form of a START message can be required for later
transactions. Therefore, a correctly created START message might be
an asset. To transfer such asset, the CAVP of FORM_START type can be
used.
Name Meaning AVP Type Value Type
RESULT Transaction result 38 String
PROVE Supplicant's proving factor 134 String
VERIF Supplicant's verification factor 135 String
FORM_START START message content 212 -
4.2.6. Interoperability
The following AVPs allow the interoperability between the systems
based on the ACP protocol and the systems based on RADIUS [4, 5],
Diameter [6] or Kerberos [7] protocols. These AVPs contain either
complete messages of those systems (MESS) or their particular AVPs.
The inclusion of the AVPs from the RADIUS and Diameter protocols
Burda Expires June 5, 2012 [Page 15]
Internet-Draft Access Control Protocol (ACP) December 2011
significantly enhances the set of ACP AVPs. Therefore, if there is no
suitable AVP defined in this standard, a respective AVP from the
RADIUS or Diameter standard can be used.
Name Meaning AVP Type Value Type
MESS_RADIUS RADIUS protocol message 128 String
MESS_DIAMETR Diameter protocol message 129 String
MESS_KERBER Kerberos protocol message 130 String
AVP_RADIUS RADIUS protocol AVP 65 String
AVP_DIAMETR Diameter protocol AVP 131 String
4.2.7. Cryptographic primitives
Confidentiality and authenticity of messages transferred by the ACP
protocol can be provided externally or internally. The external
protection is based on the usage of secure connections or encrypted
connections (for example IPSec [8] or TLS [9]). The internal
protection is based on autonomous cryptographic protection of ACP
protocol messages. Such protection is based on cryptographic
primitives from the mandatory cipher suite of the TLS protocol [9].
Name Meaning AVP Type Value Type
INIT Initiation Vector (IV) 48 String
PMS Premaster secret 49 String
CERT Certificate 160 String
AES Cryptogram encrypted by AES 161 String
ENC Cryptogram with IV 224 -
HMAC Hashed MAC 50 String
MAC Data with HMAC 225 -
RSA Cryptogram encrypted by RSA 162 String
PSS Digital signature PSS 163 String
SIG Data with PSS 226 -
CRYPT Cryptographic container 227 -
o INIT (SAVP): contains the initiation vector. In a right context,
it can contain nonce (a non-repeating random value).
Burda Expires June 5, 2012 [Page 16]
Internet-Draft Access Control Protocol (ACP) December 2011
o PMS (SAVP): contains a premaster secret. In a right context, it
can contain AES cryptographic key. This AVP is transported in an
encrypted form in RSA LAVP.
o CERT (LAVP): contains a X.509 certificate [10].
o AES (LAVP): contains data (for example, AVP string) encrypted in
CBC mode by AES cipher with a 128 b key.
o ENC (CAVP): contains INIT AVP followed by the AES AVP. INIT
contains the initiation vector needed for the decryption of data
in AES AVP.
o HMAC (SAVP): contains the authentication code of the chain of all
AVPs which are ahead of this SAVP. HMAC is determined using the
SHA1 function [11].
o MAC (CAVP): contains AVP string followed by a final HMAC AVP. HMAC
contains the authentication code of the AVP string.
o RSA (LAVP): contains AVP string encrypted by the RSA cipher [12].
o PSS (LAVP): contains a digital signature of all AVPs placed ahead,
within a given SIG. PSS is determined by [12].
o SIG (CAVP): contains AVP string followed by a final AVP of PSS
type.
o CRYPT (CAVP): container reserved for future use in complex
cryptographic securing of the ACP protocol.
4.2.8. Supplemental AVPs
If the parameter negotiation phase expects an interaction with a
person, the codes of authentication methods, assets etc. can be
appended by a text description. SAVP of a TXT type, which is designed
for the text description of AVPs standing in front of this AVP, can
be used. To gather the code and its description, CAVP with an
extension _TX can be used. This CAVP type is always composed of two
AVPs. The first AVP contains the code and the second one contains the
text description of the code.
Burda Expires June 5, 2012 [Page 17]
Internet-Draft Access Control Protocol (ACP) December 2011
Name Meaning AVP Type Value Type
TXT Description of previous AVP 64 Text
EAP_TX EAP method code with description 192 -
LAM_TX LAP method code with description 193 -
ASSET_G_TX Global asset code with description 194 -
ASSET_L_TX Local asset code with description 195 -
To make messages containing more SAVPs of the same type shorter, CAVP
of a LIST type is defined.
Name Meaning AVP Type Value Type
LIST List of SAVPs of same type 196 -
If the length (L) of gathered SAVPs is the same, the Value field
structure of this CAVP for the case of N different SAVPs of the same
type T can be depicted as in Fig. 6.
+-----+-----+-------+-------+ +-------+
| T | L | Val_1 | Val_2 | . . . . | Val_N |
+-----+-----+-------+-------+ +-------+
Figure 6 Value field for the CAVP LIST for the case of constant
length of all SAVPs.
The description of fields is following.
o T (1 octet): The field contains the type of gathered SAVPs.
o L (1 octet): The field contains the length of the Value field of
gathered SAVPs.
o Val_x (< 2^8 octet): The field contains the value of the Value th field of x SAVP.
If gathered SAVPs are of different length, then the structure of the
Value field of the LIST type CAVP for N different SAVPs of a same
type T is illustrated in Fig. 7.
Burda Expires June 5, 2012 [Page 18]
Internet-Draft Access Control Protocol (ACP) December 2011
+-----+-----+-----+-----+-----+-----+ +-----+-----+
| T | L |Len_1|Val_1|Len_1|Val_1| . . . . |Len_N|Val_N|
+-----+-----+-----+-----+-----+-----+ +-----+-----+
Figure 7 Value field for LIST CAVP for the case of SAVPs of
different length.
The description of fields is following.
o T (1 octet): The field contains the type of gathered SAVPs.
o L (1 octet): The field contains the value 0. This value signals
the variable-length SAVP list.
o Len_x (1 octet): The field contains the length of the Val_x field. th o Val_x (< 2^8 octet): The field contains the value of x SAVP
Value field.
5. ACP protocol transactions
5.1. Transaction description
The ACP protocol allows the Supplicant and the Provider to negotiate
required assets, negotiate the authentication method, do
authentication, deliver access parameters and do accounting. Both
portals communicate by alternant message sending (so called lock-step
protocol), which means, that the portal can send a new message only
after receiving a message from a partner. Eventual segmentation,
error correction etc. is resolved by a respective communication
module.
The interchange of messages for one transaction is following.
1. The Supplicant sends the START message to the Provider.
2. If the Provider does not know all parameters required for the
transaction execution (typically the required asset and the type
of authentication), then the Provider initiates the parameter
negotiation phase represented by the interchange of OFFER-
SPECIFICATION messages. After establishing all required
parameters, the process continues with the following item.
3. The Provider initiates the authentication phase represented by the
interchange of REQUEST-RESPONSE messages.
Burda Expires June 5, 2012 [Page 19]
Internet-Draft Access Control Protocol (ACP) December 2011
4. Based on the result of the authentication phase, the Provider
finishes the transaction with the FINISH message type.
If the Provider does not receive a SPECIFICATION message after
sending an OFFER message or if the Provider does not receive a
RESPONSE message after sending a REQUEST message, the Provider MUST
interrupt the transaction by sending an empty FINISH message.
5.2. Reduced transactions
A transaction of the ACP can take place in a so called reduced form.
If the Supplicant provides all required parameters in the START
message, then the OFFER-SPECIFICATION message interchange is not
necessary. If the Supplicant and the Provider are the end nodes of a
secure channel (for example, a TLS channel), it is also possible to
eliminate the REQUEST-RESPONSE message interchange. The reason is the
fact that the authenticity of the partner is provided by the secure
channel. In these cases, the ACP transaction can be reduced to a
START - FINISH message interchange. This reduction is convenient for
the communication between devices using a distributed access control
system. The reduced ACP protocol transaction can be used for the
communication between an AAA server (Supplicant) and a network Access
Point (Provider). In that case, the START message contains the order
for the Provider to allow an authenticated user to access a network.
The FINISH message contains the acknowledgement of START message
receiving. The same procedure can be used for accounting as well.
5.3. Principles of communication
The progress of a transaction can be controlled by empty messages and
empty AVPs which are the AVPs with zero length of the Value field
(i.e. with missing Value field). Using an empty message, the
Supplicant can preliminarily terminate the transaction. If the
Supplicant sends an empty message any time after the start of a
transaction (i.e. any time after sending the START message), the
Provider MUST terminate the transaction by sending an empty FINISH
message.
Using an empty AVP, the Provider can ask the Supplicant about any
parameter. For example, by sending an empty NAME_AUT_G type AVP, the
Provider asks for the global name of an authenticator which can
authenticate the Supplicant. If the Supplicant replies with
Burda Expires June 5, 2012 [Page 20]
Internet-Draft Access Control Protocol (ACP) December 2011
forwarding an empty AVP, it means that he or she does not know the
information.
The communication is controlled by the Provider in the ACP protocol.
The Supplicant can request the required asset in the START message,
propose a protocol variant etc., but the Provider can ignore this
information and ask for it during a later phase of communication. The
providing device administrator can also set the device in such a
manner that the portal will react only on a START message with
certain properties.
There can be more assets in every network device. The transit of ACP
messages to other devices, the change of device's configuration file,
provided service, etc. can be all considered assets. The device
administrator can control the access to each asset separately
according to different access control policies. The access control
policy for each asset is defined in a respective Policy Module. The
Policy Module defines the behavior of the portal during the
transaction with conformance to the access control method and
contains information needed for running the transaction (for example,
required authentication methods, routing information etc.). From this
perspective, the ACP protocol can be viewed as a general framework
usable for the realization of a modular access system of any size and
complexity.
The loss of any message or the transmission error should be resolved
by respective communication modules of the portal and the ACP
protocol therefore interprets all transmission errors as potential
attacks. If the portal does not receive a correct answer within a
given time interval, or if it receives multiple answers, the
transaction is canceled. There is a timer started for each
transaction in every portal after receiving a START message. The
timer is reset after receiving next message of a transaction. The
connection of each transaction of every portal is canceled after the
expiration of its timer. The portal does not react on any next
message. If any participating portal cancels the transaction, then
the transaction is also canceled in all remaining portals due to the
expiration of timers. The Provider can cancel the transaction by
sending an empty FINISH message.
Burda Expires June 5, 2012 [Page 21]
Internet-Draft Access Control Protocol (ACP) December 2011
5.4. ACP-VSA protocol
Variant of Single Answers (ACP-VSA) is the default variant of the ACP
protocol. The communication in this variant is following. If the
START message contains all necessary parameters with correct values
and the choice is allowed by the device administrator, the Provider
switches to a transaction phase defined by the administrator, i.e. to
the phase of authentication or to the phase of finish (see 5.2). In
the opposite case, the AVPs from the START message are ignored and
the Provider switches to the phase of negotiation. The communication
is controlled by the Provider in such a manner that the Supplicant
always answers with a single AVP. The procedure is following.
The Provider sends an offer or a request in his OFFER message. The
offer contains N different AVPs of the same type (for example,
authentication methods) from which the Supplicant can choose one. The
request contains one empty AVP and eventually other AVPs if they are
needed to determine the answer. The Supplicant fills the empty AVP
with a correct value in the Value field and sends it back. Therefore,
the Supplicant sends only one AVP in his SPECIFICATION message. The
returning AVP is a choice from a list or Supplicant's answer to a
request. The Provider continues in sending next offers or requests
according to a simple decision diagram, or executes actions.
Provider's decision diagram is defined by the administrator of the
device in the Policy Module. If the Supplicant puts two or more AVPs
in his SPECIFICATION message, the Provider MUST terminate the
transaction by sending an empty FINISH message.
After parameter negotiation, the authentication message interchange
takes place, followed by the FINISH message. The advantage of the
ACP-VSA method is its universality and simplicity. To increase the
security and speed of access control mechanism, it is possible to use
specialized variants of the ACP protocol.
5.5. Joining transactions
Elementary transactions of the ACP protocol can be joined to create
more complex access control schemes with more participating network
devices. The joining of transactions can be done by chaining or
including.
Burda Expires June 5, 2012 [Page 22]
Internet-Draft Access Control Protocol (ACP) December 2011
The chaining of transactions is such joining, where accomplishing a
T_i transaction is a condition or a reason for accomplishing a new
transaction T_(i+1). An example of transaction chaining is a
situation where the Supplicant receives an asset (for example, an
authentication factor) in transaction T_i which allows him or her to
receive another asset in next transaction T_(i+1) (for example access
to data). Another example of transaction chaining is a situation
where the Provider (for example, AAA server) negotiated access
credentials (for example, cryptographic keys necessary for the
network access) with the Supplicant in the transaction T_i and,
through a transaction T_(i+1), these credentials are forwarded to a
different network device (for example, a network Access Point).
The transaction inclusion (see Fig. 8) is such joining where the new
transaction T_(i+1) is started and finished during another
transaction T_i for the reason of finishing the T_i transaction. Data
of related transactions can be transited between these transactions.
The transaction inclusion is typical in cases where the Provider must
use another portal for Supplicant authentication. The transaction
inclusion is depicted in Fig. 8. Portal A asks Portal B for an asset
in the START_1 message. By this, the T_1 transaction is started.
Let's assume that the START_1 message contains all correct
transaction parameters. Under this assumption, it is not necessary to
run the OFFER - SPECIFICATION message interchange and it is possible
to proceed with authentication of Portal A. Portal B does not know
the respective authentication factors and therefore it connects to
Portal C which is able to authenticate Portal A. Let's assume that
the B - C connection is of TLS type, i.e. both portals are
authenticated during the connection set-up. Portal B opens a T_2
transaction within the existing connection. The Provider from the T_1
transaction is now in Supplicant's position and portal C is in
Provider's position. Again, let's assume that the START message
contains all correct transaction parameters needed for the required
asset (i.e. for authentication of A and receiving the result). There
is no need to send the OFFER-SPECIFICATION messages. Therefore,
Portal C begins authentication by sending the message REQUEST_2.
Portal B extracts respective AVPs from this message and places them
to the REQUEST_1 message, which belongs to T_1 transaction. Portal A
sends the RESPONSE_1 message; Portal B extracts the respective AVPs
and puts them to the RESPONSE_2 message. RESPONSE_2 is sent to Portal
C which does the verification check and sends the result of
Burda Expires June 5, 2012 [Page 23]
Internet-Draft Access Control Protocol (ACP) December 2011
authentication in the FINISH_2 message. This message also closes the
T_2 transaction. Portal B decides about the result of T_1 based on
the message FINISH_2 and resends the result to Portal A in FINISH_1
message.
Portal A Portal B Portal C
| | |
|+--Start_1-------->| |
| |+--Start_2--------->|
| | |
|<--Request_1------+|<--Request_2-------+|
| | |
| | |
|+--Response_1----->|+--Response_2------>|
| | |
| | |
| |<--Finish_2--------+|
|<--Finish_1-------+| |
| | |
| | |
| -- transakce_1 -- | -- transakce_2 -- |
| | |
v v v
Figure 8 Transaction inclusion principle.
By joining the transactions, it is possible to create access control
schemes of any complexity with any number of participating devices.
The access of the Supplicant can be, for example, conditioned by his
or her authentication by independent authenticators. By chaining of
elementary transactions, it is also possible to create complex
transactions for a conditional access of more entities to more assets
(for example payment transactions).
6. Security Considerations
A generic access control protocol framework is defined in this
document. This framework allows designing different variants of
Burda Expires June 5, 2012 [Page 24]
Internet-Draft Access Control Protocol (ACP) December 2011
access control protocol from the viewpoint of both security
requirements and security assurances. Therefore, the security aspects
of each of these variants need to be approached individually.
7. IANA Considerations
This document contains no identifiers to be assigned.
8. References
[1] S. Bradner: "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] F. Yergeau: "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[3] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz:
"Extensible Authentication Protocol (EAP)", RFC 3748, June
2004.
[4] C. Rigney, S. Willens, A. Rubens, W. Simpson: "Remote
Authentication Dial In User Service", RFC 2865, June 2000.
[5] C. Rigney: "RADIUS Accounting", RFC 2866, June 2000.
[6] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko:
"Diameter Base Protocol", RFC 3588, September 2003.
[7] C. Neuman, T. Yu, S. Hartman, K. Raeburn: "The Kerberos Network
Authentication Service (V5)", RFC 4120, July 2005.
[8] S. Kent, K. Seo: "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[9] T. Dierks, E. Rescorla: "The Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246, August 2008.
[10] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W.
Polk: "Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 2459, May 2008.
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Burda Expires June 5, 2012 [Page 25]
