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]