[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/