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

Versions: (draft-pala-eap-cprom) 00 01 02 03 04

Network Working Group                                            M. Pala
Internet-Draft                                                 CableLabs
Intended status: Standards Track                            June 1, 2019
Expires: December 3, 2019


      Credentials Provisioning and Management via EAP (EAP-CREDS)
                        draft-pala-eap-creds-01

Abstract

   With the increase number of devices, protocols, and applications that
   rely on strong credentials (e.g., digital certificates, keys, or
   tokens) for network access, the need for a standardized credentials
   provisioning and management framework is paramount.  The .1x
   architecture allows for entities (e.g., devices, applications, etc.)
   to authenticate to the network by providing a communication channel
   where different methods can be used to exchange different types of
   credentials.  However, the need for managing these credentials (i.e.,
   provisioning and renewal) is still a hard problem to solve.

   This specifications define how to support the provisioning and
   management of authentication credentials that can be exploited in
   different environments (e.g., Wired, WiFi, cellular, etc.) to users
   and/or devices by using EAP together with standard provisioning
   protocols.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on December 3, 2019.








Pala                    Expires December 3, 2019                [Page 1]


Internet-Draft                  EAP-CREDS                      June 2019


Copyright Notice

   Copyright (c) 2019 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview of existing solutions  . . . . . . . . . . . . . . .   4
   4.  Scope Statement . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  EAP-CREDS Protocol  . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  EAP-CREDS as tunneled mechanism only  . . . . . . . . . .   5
     5.2.  Message Flow  . . . . . . . . . . . . . . . . . . . . . .   5
     5.3.  Phase One: Initialization . . . . . . . . . . . . . . . .   6
     5.4.  Phase Two: Provisioning . . . . . . . . . . . . . . . . .   7
     5.5.  Phase Three: Validation . . . . . . . . . . . . . . . . .   8
   6.  EAP-CREDS Message Format  . . . . . . . . . . . . . . . . . .  10
     6.1.  Message Header  . . . . . . . . . . . . . . . . . . . . .  10
     6.2.  Message Payload . . . . . . . . . . . . . . . . . . . . .  11
       6.2.1.  General TLV format  . . . . . . . . . . . . . . . . .  11
       6.2.2.  EAP-CREDS defined TLVs  . . . . . . . . . . . . . . .  12
         6.2.2.1.  The Protocol TLV  . . . . . . . . . . . . . . . .  13
         6.2.2.2.  The Profiles TLV  . . . . . . . . . . . . . . . .  13
         6.2.2.3.  The CredInfo TLV  . . . . . . . . . . . . . . . .  13
         6.2.2.4.  The AuthToken TLV . . . . . . . . . . . . . . . .  14
         6.2.2.5.  The Challenge TLV . . . . . . . . . . . . . . . .  14
         6.2.2.6.  The ChallengeResponse TLV . . . . . . . . . . . .  14
         6.2.2.7.  The Error TLV . . . . . . . . . . . . . . . . . .  14
   7.  EAP-CREDS Messages  . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  The EAP-CREDS-Init Message  . . . . . . . . . . . . . . .  14
       7.1.1.  Version TLV usage . . . . . . . . . . . . . . . . . .  14
       7.1.2.  The ProvProto TLV usage . . . . . . . . . . . . . . .  15
       7.1.3.  The CredsInfo TLV usage . . . . . . . . . . . . . . .  15
       7.1.4.  The IdProvider TLV  . . . . . . . . . . . . . . . . .  15
     7.2.  The EAP-CREDS-ProtoFlow Message . . . . . . . . . . . . .  16
       7.2.1.  The ProvProtoHeader TLV . . . . . . . . . . . . . . .  16
       7.2.2.  The ProvProtoData TLV . . . . . . . . . . . . . . . .  16



Pala                    Expires December 3, 2019                [Page 2]


Internet-Draft                  EAP-CREDS                      June 2019


     7.3.  The ('Validate') Message  . . . . . . . . . . . . . . . .  17
   8.  Error Handling in EAP-CREDS . . . . . . . . . . . . . . . . .  17
   9.  Fragmentation . . . . . . . . . . . . . . . . . . . . . . . .  17
   10. Using EAP-CREDS with EAP-TEAP . . . . . . . . . . . . . . . .  17
   11. Using EAP-CREDS with EAP-TTLS . . . . . . . . . . . . . . . .  18
   12. EAP-CREDS and Simple Provisioning Protocol (SPP)  . . . . . .  19
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     13.1.  Provisioning Protocols . . . . . . . . . . . . . . . . .  20
     13.2.  Token Types  . . . . . . . . . . . . . . . . . . . . . .  20
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  21
   15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  21
   16. Normative References  . . . . . . . . . . . . . . . . . . . .  21
   Appendix A.  EAP-CREDS Example Message Flow for Provisioning
                Standards  . . . . . . . . . . . . . . . . . . . . .  22
     A.1.  EAP-CREDS and CMP . . . . . . . . . . . . . . . . . . . .  22
     A.2.  EAP-CREDS and EST . . . . . . . . . . . . . . . . . . . .  22
     A.3.  EAP-CREDS and CMS . . . . . . . . . . . . . . . . . . . .  22
     A.4.  EAP-CREDS and ACME  . . . . . . . . . . . . . . . . . . .  22
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Requirements notation

   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 [RFC2119].

2.  Introduction

   Many environments are, today, moving towards requiring strong
   authentication when it comes to gain access to networks.  The .1x
   architecture provides the network administrators with the possibility
   to check credentials presented by a device even before providing any
   IP service to it.

   However, the provisioning and management of these credentials is a
   hard problem to solve and many vendors opt for long-lived credentials
   that can not be easily revoked, replaced, or simply renewed.

   This specification addresses the problem of providing a simple-to-use
   and simple-to-deploy conduit for credentials management by extending
   the EAP protocol to support credentials provisioning and management
   functionality.  In particular, the EAP-CREDS method defined here
   provides a generic framework that can carry the messages for
   provisioning different types of credentials.  The method can be use
   as a stand-alone method or it can be used as an inner methods of EAP-
   TTLS, EAP-TEAP, or any other tunnelling method that can provide the
   required encryption and (at minimum) server-side authentication to




Pala                    Expires December 3, 2019                [Page 3]


Internet-Draft                  EAP-CREDS                      June 2019


   deliver server-side generated secrets (e.g., private keys, passwords,
   secret keys, etc.)

3.  Overview of existing solutions

   Currently there are many protocols that address credentials lifecycle
   management.  In particular, when it comes to digital certificates,
   some of the most deployed management protocols are:

   o  Certificate Management Protocol (CMP) [RFC4210]

   o  Certificate Management over CMS (CMC) [RFC5272][RFC6402]

   o  Enrollment over Secure Transport (EST) [RFC7030]

   o  Automated Certificate Management Environment

   However, none of these protocols provide native support for client
   that do not have IP connectivity yet (e.g., because they do not have
   network-access credentials, yet).  The EAP-CREDS provides the
   possibility to use such protocols (i.e., message-based) by defining a
   series of messages that can be used to encapsulate the provisioning
   messages for the specified protocol.  In particular, examples of the
   message flow for the major provisioning protocols are provided in
   Annex Appendix A.

   In addition to these protocols, EAP-CREDS also defines a series of
   simple messages that provide a generic enrollment protocol that
   allows not only certificates but also other types of credentials
   (e.g., username/password pairs or symmetric secrets) to be delivered
   to the client as part of the provisioning and/or renewal process.
   The set of messages that make up the generic provisioning protocol is
   referred to as the CREDS protocol (not to be confused with the EAP-
   CREDS).

4.  Scope Statement

   This document focuses on the definition of the EAP-CREDS method to
   convey credentials provisioning and managing messages between the
   client and the AAA server.  Moreover, the document defines how to
   encode messages for the main IETF provisioning protocols.

   This document, however, does not provide specifications for how and
   where the credentials are generated.  In particular, the credentials
   could be generated directly within the AAA server or at a different
   location (i.e., the Certificate Service Provider or CSP) site.
   Different authentication mechanisms (e.g., TLS, etc.) can be used to
   secure the communication between the server's endpoint and the CSP.



Pala                    Expires December 3, 2019                [Page 4]


Internet-Draft                  EAP-CREDS                      June 2019


5.  EAP-CREDS Protocol

   This section outlines the operation of the protocol and message
   flows.  The format of the CREDS messages is given in Section 6.

5.1.  EAP-CREDS as tunneled mechanism only

   EAP-CREDS requires that an outer mechanism is in place between the
   Peer and the Server in order to provide authentication and
   confidentiality of the messages exchanged via EAP-CREDS.  This choice
   was taken to simplify the message flow and abstract EAP-CREDS from
   the secure-channel establishment mechanism.

   In other words, the method assumes that an appropriate protection
   outer layer has been established to prevent the possibility to leak
   information or to allow man-in-the-middle attacks.

5.2.  Message Flow

   EAP-CREDS message flow is logically subdivided into three different
   phases:

   Phase One (Required).  CREDS Initialization.  During this phase the
      Peer and the Server exchange the information needed to select the
      appropriate credentials management protocol.  In particular, the
      Sever sends its initial message of type ('Init') with the details
      about what protocols are supported, and additional information
      such as the version of EAP-CREDS and the supported profiles
      identifiers.

   Phase Two (Required).  Provisioning Protocol Flow.  In this phase,
      the Peer and the Server exchange the provisioning protocol's
      messages encapsulated in a EAP-CREDS message of type ProtoFlow.
      The messages contain only two TLVs: the first one (optional)
      carries information that might be normally coveyed via the
      transport protocol (e.g., HTTP headers), while the second one
      (required) carries the provisioning protocol's messages.

   Phase Three (Optional).  Credentials Validation.  This optional phase
      can be initiated by the server and it is used to validate that the
      Peer has properly installed the credentials and can use them to
      authenticate itself.  Depending on the credentials' type, the
      messages can carry a challenge/nonce, the value of the secret/
      token, or other information.  The format of the credentials is
      supposed to be known by the provider and the device.






Pala                    Expires December 3, 2019                [Page 5]


Internet-Draft                  EAP-CREDS                      June 2019


5.3.  Phase One: Initialization

   The following figure provides the message flow for Phase One:


   +------------+                                  +--------------+
   |  EAP Peer  |                                  |  EAP Server  |
   +------------+                                  +--------------+
       |                                                  |
       |<----------- Outer Tunnel Established ----------->|
       |                                                  |
       |                                                  |  Phase One
       |                                                  |  Begins
       |<----------[1] EAP-Request/EAP-CREDS -------------|      .
       |       (Type=Init,Ver,Supported Protocols,        |      :
       |                   Providers)                     |      |
       |                                                  |      |
       |-----------[2] EAP-Response/EAP-CREDS ----------->|      |
       |         (Type=Init,Ver,Proto,Provider)           |      v
       |                                                  |      |
       |<-----------[3] EAP-Request/EAP-CREDS ------------|      |
       |             (Type=Init, << Empty >>)             |      v
       |                                                  |  Phase One
       :                                                  :  Ends
       .                                                  .


   During the CREDS initialization, after the establishment of the outer
   mechanism (e.g., EAP-TLS, EAP-TEAP, EAP-TTLS, etc.), the initial the
   server sends the EAP-Request/EAP-CREDS(Type=Init) message with the
   ('Versions') TLV to indicate the supported versions of EAP-CREDS
   (i.e.  a list of all supported version of EAP-CREDS), the
   ('Supported-Protocol') TLV to indicate the list of supported
   provisioning protocols, followed by the ('Providers') TLVs that allow
   the client to pick the credentials' vendor.

   The peer selects the version, the protocol, and optionally the
   provider, and sends back the response in a EAP-Response/EAP-
   CREDS(Type=Init) message to the server which includes the
   ('Versions'), ('Protocols'), and optionally the ('Providers') TLVs
   with only one value each.  If multiple values are detected in the
   message from the Peer, the message shall be discarded and the
   appropriate error message shall be issued by the Server.

   The server checks that the requested protocol and parameters are
   supported and, if not (or if the server detects an error), it sends
   an error message to the peer and notify the outer (tunneling) layer.




Pala                    Expires December 3, 2019                [Page 6]


Internet-Draft                  EAP-CREDS                      June 2019


   In case the server can serve the request from the client, it sends an
   empty EAP-Request/EAP-CREDS(Type=Init) message to indicate that the
   server is ok with the selected parameters and is waiting on the Peer
   to start Phase Two of the protocol.

5.4.  Phase Two: Provisioning

   The following figure provides the message flow for Phase 2:


   +------------+                                  +--------------+
   |  EAP Peer  |                                  |  EAP Server  |
   +------------+                                  +--------------+
       |                                                  |
       :                                                  :
       .                                                  .
       |                                                  |  Phase Two
       |                                                  |  Begins
       |------------ EAP-Response/EAP-CREDS ------------->|      .
       |      (Type=ProtoFlow,ProtoData)                  |      |
       |                                                  |      |
       |<----------- EAP-Request/EAP-CREDS ---------------|      |
       |      (Type=ProtoFlow,ProtoData)                  |      |
       |                                                  |      |
       :                                                  :      :
       .                                                  .      .
       :                                                  :      :
       |                                                  |      |
       |                                                  |      |
       |------------ EAP-Response/EAP-CREDS ------------->|      v
       |      (Type=ProtoFlow,EMPTY)                      |  Phase Two
       |                                                  |  Ends
       :                                                  :


   The server starts phase two of the EAP-CREDS protocol by sending an
   EAP-Request/EAP-CREDS(Type=ProtoFlow) message with the selected
   protocol's details to the Peer.  This indicates that the Server is
   ready to initiate the provisioning protocol.

   Specifically, the Server MUST include the 'Ver' and 'Proto' TLVs to
   indicate the EAP-CREDS version agreed upon by the parties and the
   specific provisioning protocol to use.  The 'provider' TLV is
   optional and MUST be included if a selection was made by the Peer.
   The 'provider' TLV MAY be included in the message even if the Peer
   did not make a selection.





Pala                    Expires December 3, 2019                [Page 7]


Internet-Draft                  EAP-CREDS                      June 2019


   After that, the Peer sends its first message to the Server by sending
   the EAP-Response/EAP-CREDS(Type=ProtoFlow) message.  This message
   contains the selected provisioning protocol's message data and some
   extra fields (e.g., transport-protocol headers).

   The Server replies to the Peer's message with EAP-Request/EAP-
   CREDS(Type=ProtoFlow) messages until the provisioning protocol
   reaches an end (the client will send a 'ProtoFlow' message with an
   empty body) or an error condition (the party that detected the error
   condition will use a 'ProtoFlow' message with an 'Error' TLV to
   convey the issue and terminate the protocol).

   The communication between the client and the server continues until
   the selected protocol and action is correctly performed or a failure
   is detected and reported.

5.5.  Phase Three: Validation

   The following figure provides the message flow for Phase 3:
































Pala                    Expires December 3, 2019                [Page 8]


Internet-Draft                  EAP-CREDS                      June 2019


   +------------+                                  +--------------+
   |  EAP Peer  |                                  |  EAP Server  |
   +------------+                                  +--------------+
       |                                                  |
       :                                                  :

       .                                                  .
       |                                                  |  Phase Three
       |<----------- EAP-Request/EAP-CREDS ---------------|    Begin
       |      (Type=Validate,Challenge)                   |      .
       |                                                  |      |
       |                                                  |      |
       |------------ EAP-Response/EAP-CREDS ------------->|      |
       |      (Type=Validate,ExtraChallenge,              |      |
       |       ChallengeResponse,Challenge)               |      |
       :                                                  :      :
       .                                                  .      :

       :                                                  :      :
       :                                                  |      |
       |                                                  |      |
       |<----------- EAP-Request/EAP-CREDS ---------------|      |
       |      (Type=Validate,ChallengeResponse)           |      |
       |                                                  |      |
       |------------ EAP-Request/EAP-CREDS -------------->|      |
       |      (Type=Validate,EMPTY)                       |      v
       |                                                  |  Phase Three
       |                                                  |  Ends
       |                                                  |
       |<----------- EAP-Success -------------------------|  EAP Success
       |                                                  |


   Phase three is optional and it is used by the server to request the
   client to validate (proof) that the new credentials have been
   installed correctly before issuing the final Success message.

   In order to do that, the server and the client exchange two or three
   EAP-Request/EAP-CREDS(Type=Validate) and EAP-Response/EAP-
   CREDS(Type=Validate) messages where the correctness of the exchanged
   credentials is verified by the server and (optionally) by the client.

   In particular, when the client receives the first Validate message
   from the server, it calculates the response to the challenge (based
   on the type of credentials and the protocol itself - if supported,
   this would be a 'test' authentication) and sends the response back to
   the server.




Pala                    Expires December 3, 2019                [Page 9]


Internet-Draft                  EAP-CREDS                      June 2019


   Optionally, the client can add the ExtraChallenge TLV that carries
   the extra challenge information that was used to calculate the
   ChallengeResponse TLV (if any).  This field can be used to prevent
   the use of the Validate phase as an encryption or validation oracle.

   Optionally, the client can add the Challent TLV to the response.
   When the server receives the EAP-Response/EAP-CREDS(Type=Validate)
   with the Challenge TLV in it, it MUST calculate the response to the
   challenge and send back the response to the client in an EAP-Request/
   EAP-CREDS(Type=Validate) with the ChallengeResponse TLV and,
   optionally, the ExtraChallenge TLV.

   In case of issues with the validation of the newly deployed
   credentials, both the client and the server should consider those
   credentials invalid (or unusable) and should issue the required
   failure message(s).

6.  EAP-CREDS Message Format

   The EAP-CREDS defines the following message types:

      EAP-CREDS/Init

      EAP-CREDS/ProtoFlow

      EAP-CREDS/Validate

   Each of these message types have the basic structure as identified in
   Section 6.1 and in Section 6.2 and contain zero, one, or more TLVs.
   The allowed TLVs for the different types of messages are described in
   Section 7.  The internal structure of the different types of TLVs is
   described in Section 6.2.1.

6.1.  Message Header

   The EAP-CREDS messages consist of the standard EAP header (see
   Section 4 of [RFC3748]), followed by the version of the EAP-CREDS (4
   bits) and a field (4 bits) reserved for future use.  The header has
   the following structure:












Pala                    Expires December 3, 2019               [Page 10]


Internet-Draft                  EAP-CREDS                      June 2019


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Code      |  Identifier   |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      | Flags |  Ver  |         Message Length        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Message Length        |               Data           ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.


   Where the Code, Identifier, Length, and Type fields are all part of
   the EAP header as defined in [RFC3748].

   The Type field in the EAP header is <TBD> for EAP-CREDS.

   The Ver (Version) bitfield (4 bits) identifies the version of the
   EAP-CREDS protocol used for the exchange.  This document defines the
   value to use for this field as '0x1' (0001).

   The Flags bitfield (4 bits) is currently not used and it is reserved
   for future use.  The value of the bitfield shall be ignored when the
   Version ('Ver') field is set to '0x1' (0001).

6.2.  Message Payload

   The Data part of the message is organized as zero, one, or more TLV
   objects whose structure is defined in this section.  In particular,
   the general structure of a TLV is described in Section 6.2.1, while
   the specific structures for the supported TLVs is provided in
   Section 6.2.2.

6.2.1.  General TLV format

   Each TLV object has the same basic structure that is defined as
   follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                TLV Type       |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |          Value...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where:

   TLV-Type



Pala                    Expires December 3, 2019               [Page 11]


Internet-Draft                  EAP-CREDS                      June 2019


      This field is used to indicate the type of data that the TLV
      carries.  The different types of TLVs are described in
      Section 6.2.2.

   Length

      This field carries the size of the value of the TLV.  In
      particular, the overall size of a TLV (i.e., the header plus the
      value) can be calculated by adding the size of the header (6
      octects) to the value of the Length field (i.e., the size of the
      TLV's value).

   TLV Type

      This field carries the type of TLV which determines its internal
      structure.  The supported values for this fields are provided in
      the following table:

            +--------------+----------------------------------+
            | Message Type | Purpose                          |
            +--------------+----------------------------------+
            |      0       | Error TLV                        |
            |      1       | EAP-CREDS Version TLV            |
            |      2       | Provisioning Protocol TLV        |
            |      3       | Provisioning Provider TLV        |
            |      4       | Provisioning Protocol Header TLV |
            |      5       | Provisioning Protocol Data TLV   |
            |      6       | Credentials Information TLV      |
            |      7       | Authorization Token TLV          |
            |      8       | Registration Token TLV           |
            |      9       | Challenge TLV                    |
            |      10      | Challenge Response TLV           |
            +--------------+----------------------------------+

                  Table 1: EAP-CREDS Supported TLVs Types

6.2.2.  EAP-CREDS defined TLVs

   EAP-CREDS messages's payload comprieses zero, one, or more TLVs that
   are encoded in a single EAP-CREDS message.  The values for the TLV
   Type that are supported by this specifications are listed in Table 1.

   This section describes the structure of the different supported TLVs
   and their usage in the different messages.







Pala                    Expires December 3, 2019               [Page 12]


Internet-Draft                  EAP-CREDS                      June 2019


6.2.2.1.  The Protocol TLV

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           TLV Type            |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Protocol ID (uint16)      |        Protocol Version       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type

      <TBD> - Provisioning Protocol TLV

   Length

      4 octets

   Protocol ID

      The Protocol ID field is 2 octets.  The allowed values for this
      field are maintained in a subdirectory by IANA.  The initial
      values for the provisioning protocol identifiers can be found in
      Section 13.1.

   Protocol Version

      The Protocol Version field is 2 octet (uint16).  When no version
      is specified for a protocol (i.e., either it does not support
      multiple versions or it does not matter), the value should be set
      to '0x0'.

6.2.2.2.  The Profiles TLV

6.2.2.3.  The CredInfo TLV

   Type (Int; 1Byte) | HashAlgoId (Int; 1 byte) | Installed On (GMT; 15
   bytes) | ExpiresOn (GMT; 15 bytes) | Salt/Nonce (RND; 32 bytes) |
   id_len (Int; 2 bytes) | id_value | cred_hash_len (Int; 2 bytes) |
   Cred_Hash (Binary; 20-64 bytes)

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |M|S|            TLV Type       |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           32 bit Integer                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Pala                    Expires December 3, 2019               [Page 13]


Internet-Draft                  EAP-CREDS                      June 2019


6.2.2.4.  The AuthToken TLV

6.2.2.5.  The Challenge TLV

6.2.2.6.  The ChallengeResponse TLV

6.2.2.7.  The Error TLV

7.  EAP-CREDS Messages

   This section describes each message and what TLVs are allowed or
   required.  EAP-CREDS defines the following values for the Message
   Type (Type):

   +------------+---------------------+--------------------------------+
   |  Message   | Name                | Description                    |
   |    Type    |                     |                                |
   +------------+---------------------+--------------------------------+
   |     0      | EAP-CREDS-Init      | Initialization Phase           |
   |     1      | EAP-CREDS-ProtoFlow | Carries Provisioning Protocol  |
   |            |                     | Messages                       |
   |     2      | EAP-CREDS-Validate  | Validates newly installed      |
   |            |                     | credentials                    |
   +------------+---------------------+--------------------------------+

                     Table 2: EAP-CREDS Message Types

7.1.  The EAP-CREDS-Init Message

   The EAP-CREDS-Init message type is used in Phase One only of EAP-
   CREDS.  The message flow is depicted in Section 5.3.  This message
   supports the following TLVs: Version, ProvProto, CredsInfo, and
   IdProvider.

   In this section we specify how these TLVs are used in the phase-one
   messages.

7.1.1.  Version TLV usage

   The Version TLV is used to convey the version of EAP-CREDS to be used
   for the current session.

   The Server uses one or more Version TLVs in the EAP-Request/EAP-
   CREDS(Type=Init) message to provide the Peer with the list of EAP-
   CREDS versions supported.  At minimum, the Server must include one
   Version TLV with the value of '0x1'.  If the Server detects multiple
   occurrences of this TLV in the reply from the Peer, an error shall be
   issued and the EAP-CREDS should abort.



Pala                    Expires December 3, 2019               [Page 14]


Internet-Draft                  EAP-CREDS                      June 2019


   The Peer, on the other hand, MUST include only one Version TLV in the
   EAP-Response/EAP-CREDS(Type=Init) message to indicate the version of
   EAP-CREDS that the client wants to use for the session.  The Peer
   MUST pick from the list provided in the message from the server and,
   if no common version is supported by the client, then the client
   shall send an error message (i.e., an EAP-Response/EAP-
   CREDS(Type=Init) with at least one EAP-CREDS-Err TLV).

7.1.2.  The ProvProto TLV usage

   The ProvProto TLV is used to idicate which provisioning protocols are
   are supported by the peer and the server.

   The Server uses one or more ProvProto TLVs in the EAP-Request/EAP-
   CREDS(Type=Init) message to provide the Peer with the list of
   supported provisioning protocol.  At minimum, the Server must include
   one ProvProto TLV with the Simple Provisioning Protocol value (SSP
   MUST be supported by EAP-CREDS servers).  If the Server detects
   multiple occurrences of this TLV in the reply from the Peer, an error
   shall be issued and the EAP-CREDS should abort.

   The Peer, on the other hand, MUST include only one ProvProto TLV in
   the EAP-Response/EAP-CREDS(Type=Init) message to indicate the
   protocol it intends to use in phase two.  The Peer MUST pick from the
   list provided in the message from the server and, if no common
   protocol is supported by the client, then the client shall send an
   error message (i.e., an EAP-Response/EAP-CREDS(Type=Init) with at
   least one EAP-CREDS-Err TLV).

7.1.3.  The CredsInfo TLV usage

   The CredsInfo TLV is used by the peer to convey information to the
   EAP-CREDS server about the installed (if any) credentials for the
   network being accessed.

   The Server does not use this TLV in its EAP-CREDS-Init messages.

   The Peer, on the other hand, MUST include one CredsInfo TLV for each
   installed credentials (that the network is authorized to manage) in
   the EAP-Response/EAP-CREDS(Type=Init) message.  If no credentials are
   available, yet, then the client SHALL NOT include this TLV in its
   EAP-CREDS-Init message.

7.1.4.  The IdProvider TLV

   The IdProvider TLV is used to convey the list of supported providers
   that can be used for managing credentials (e.g., a list of identity
   providers).



Pala                    Expires December 3, 2019               [Page 15]


Internet-Draft                  EAP-CREDS                      June 2019


   The Server uses one or more IdProvider TLVs in the EAP-Request/EAP-
   CREDS(Type=Init) message to provide the Peer with the list of
   supported credentials providers.  The server can omit the set of TLVs
   in case a single provider is supported (or if the selection of the
   provider is done based on different factors - e.g., the authenticated
   credentials via the tunneling mechanism).

   The Peer, on the other hand, MAY include only one IdProvider TLV in
   the EAP-Response/EAP-CREDS(Type=Init) message to indicate which
   provider it wants the Server to use.  The Peer MUST pick from the
   list provided in the message from the server.  If the client does not
   support any of the providers listed in the Server's message or if no
   selection is provided and the Peer requires a specific provider, then
   an EAP-Response/EAP-CREDS(Type=Init) with an EAP-CREDS-Err TLV MUST
   be sent to the server as a response.

7.2.  The EAP-CREDS-ProtoFlow Message

   The EAP-CREDS-ProtoFlow message type is used in Phase Two only of
   EAP-CREDS.  The message flow is depicted in Section 5.4.  This
   message type supports the following TLVs: ProvProtoHeaders and
   ProvProtoData.

   In this section we specify how these TLVs are used in the phase-one
   messages.

7.2.1.  The ProvProtoHeader TLV

   The ProvProtoHeader TLV is used to convey one or more headers (or
   extra information) that add relevant information for the provisioning
   protocol.

   Both on the Peer and on the Server, this TLV should be used to, for
   example, provide HTTP headers that might be required for some
   provisioning protocols that do not properly abstract from the
   transport layer (e.g., ACME and EST are examples of this type of
   protocols).

7.2.2.  The ProvProtoData TLV

   The ProvProtoData TLV is used to transport the body of the messages
   for the provisioning protocol across the Peer and the Server.

   Both on the Peer and on the Server, this TLV is used to carry the
   provisioning protocol's messages.  In particular, the protocols'
   messages are encapsulated in this TLV without further re-encoding of
   the message.  Only one instance of this TLV is allowed in EAP-CREDS-
   ProtoFlow messages.



Pala                    Expires December 3, 2019               [Page 16]


Internet-Draft                  EAP-CREDS                      June 2019


7.3.  The ('Validate') Message

8.  Error Handling in EAP-CREDS

   This section provides a description of the error handling by using
   the CREDS-Error-TLV in a CREDS message.

9.  Fragmentation

   Although EAP does not directly support handling of fragmented
   packets, EAP-CREDS requires that its messages are encapsulated via an
   outer method that MUST provide fragmentation support.

   Because of the outer method requirements in particular, removing any
   support for fragmented messages in EAP-CREDS removes the duplication
   of packets (e.g., Acknowledgment Packets) sent across the Peer and
   the Server, thus resulting in a smaller number of exchanged messages

10.  Using EAP-CREDS with EAP-TEAP
































Pala                    Expires December 3, 2019               [Page 17]


Internet-Draft                  EAP-CREDS                      June 2019


      +--------+             +-------------+
      | Client |             |     AAA     |
      +--------+             +-------------+
          |                         |
          |  ClientHello            |
          |------------------------>|
          |  ServerHello,           |
          |  Certificate(1),        |
          |  ServerKeyExchange,     |
          |  CertificateRequest(2), |
          |  ServerHelloDone,       |
          |<------------------------|
          |  Certificate(3),        |
          |  ClientKeyExchange,     |
          |  CertificateVerify,     |
          |  ChangeCipherSpec,      |
          |  Finished               |
          |------------------------>|
          |  ChangeCipherSpec,      |
          |  Finished               |
          |<------------------------|
          //                        //
          // <---- EAP-CREDS ---->  //
          //                        //
          |  Crypto-Binding TLV     |
          |<------------------------|
          |  Crypto-Binding TLV     |
          |------------------------>|
          |  Result TLV             |
          |<------------------------|
          |  Result TLV             |
          |------------------------>|
          |      EAP-Success        |
          |<------------------------|


11.  Using EAP-CREDS with EAP-TTLS














Pala                    Expires December 3, 2019               [Page 18]


Internet-Draft                  EAP-CREDS                      June 2019


      +--------+             +-------------+
      | Client |             |     AAA     |
      +--------+             +-------------+
          |                         |
          |  ClientHello            |
          |------------------------>|
          |  ServerHello,           |
          |  Certificate(1),        |
          |  ServerKeyExchange,     |
          |  CertificateRequest(2), |
          |  ServerHelloDone,       |
          |<------------------------|
          |  Certificate(3),        |
          |  ClientKeyExchange,     |
          |  CertificateVerify,     |
          |  ChangeCipherSpec,      |
          |  Finished               |
          |------------------------>|
          |  ChangeCipherSpec,      |
          |  Finished               |
          |<------------------------|
          :                         :
          //                        //
          // <---- EAP-CREDS ---->  //
          //                        //
          :                         :
          |      EAP-Success        |
          |<------------------------|


12.  EAP-CREDS and Simple Provisioning Protocol (SPP)

   EAP-CREDS supports a Simple Provisioning Protocol (SPP) which
   comprises a series of messages that enables the management not only
   of certificates, but also of other types of credentials like
   username/password pairs, asymmetric keys, and symmetric keys.

   EAP-CREDS/SSP defines the following flow of messages for requesting
   the provisioning of credentials.

13.  IANA Considerations

   This document uses a new EAP type, EAP-CREDS, whose value (TBD) MUST
   be allocated by IANA from the EAP TYPEs subregistry of the RADIUS
   registry.  This section provides guidance to the Internet Assigned
   Numbers Authority (IANA) regarding registration of values related to
   the EAP-CREDS protocol, in accordance with [RFC8126].




Pala                    Expires December 3, 2019               [Page 19]


Internet-Draft                  EAP-CREDS                      June 2019


   The EAP Method Type number for EAP-CREDS needs to be assigned.

   This document also requires IANA to create new registries as defined
   in the following subsections.

13.1.  Provisioning Protocols

   +-----------------+-------------------------------------------------+
   |   Message Type  | Purpose                                         |
   +-----------------+-------------------------------------------------+
   |        0        | Unspecified                                     |
   |        1        | Simple Provisioning Protocol (SPP)              |
   |        2        | Basic Certificate Management Protocol (CMP-S)   |
   |        3        | Full Certificate Management Protocol (CMP-F)    |
   |        4        | Enrollment over Secure Transport (EST)          |
   |        5        | Certificate Management over CMS (CMC)           |
   |        6        | Automatic Certificate Management Environment    |
   |                 | (ACME)                                          |
   |       ...       | ...                                             |
   | 49141 ... 65534 | Vendor Specific                                 |
   +-----------------+-------------------------------------------------+

               Table 3: EAP-CREDS Inner Protocol Identifiers

   Assignment of new values for new cryptosuites MUST be done through
   IANA with "Specification Required" and "IESG Approval" as defined in
   [RFC8126].

13.2.  Token Types

                     +------------+-----------------+
                     | Token Type | Description     |
                     +------------+-----------------+
                     |     0      | Unspecified     |
                     |     1      | JWT             |
                     |     2      | Kerberos        |
                     |     3      | OAuth           |
                     |  200..254  | Vendor Specific |
                     +------------+-----------------+

                           Table 4: Token Types

   Assignment of new values for new Message Types MUST be done through
   IANA with "Expert Review" as defined in [RFC8126].







Pala                    Expires December 3, 2019               [Page 20]


Internet-Draft                  EAP-CREDS                      June 2019


14.  Security Considerations

   Several security considerations need to be explicitly considered for
   the system administrators and application developers to understand
   the weaknesses of the overall architecture.

   As part of the TLS negotiation, the server presents a certificate to
   the peer.  The peer SHOULD verify the validity of the EAP server
   certificate and SHOULD also examine the EAP server name presented in
   the certificate in order to determine whether the EAP server can be
   trusted.  When performing server certificate validation,
   implementations MUST provide support for the rules in [RFC5280] for
   validating certificates against a known trust anchor.

15.  Acknowledgments

   The authors would like to thank everybody who provided insightful
   comments and helped in the definition of the deployment
   considerations.

16.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
              <https://www.rfc-editor.org/info/rfc3748>.

   [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
              "Internet X.509 Public Key Infrastructure Certificate
              Management Protocol (CMP)", RFC 4210,
              DOI 10.17487/RFC4210, September 2005,
              <https://www.rfc-editor.org/info/rfc4210>.

   [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
              (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
              <https://www.rfc-editor.org/info/rfc5272>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.




Pala                    Expires December 3, 2019               [Page 21]


Internet-Draft                  EAP-CREDS                      June 2019


   [RFC6402]  Schaad, J., "Certificate Management over CMS (CMC)
              Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
              <https://www.rfc-editor.org/info/rfc6402>.

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,
              <https://www.rfc-editor.org/info/rfc7030>.

   [RFC7170]  Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
              "Tunnel Extensible Authentication Protocol (TEAP) Version
              1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
              <https://www.rfc-editor.org/info/rfc7170>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

Appendix A.  EAP-CREDS Example Message Flow for Provisioning Standards

A.1.  EAP-CREDS and CMP

   Describe how to use EAP-CREDS with CMP.

A.2.  EAP-CREDS and EST

   Describe how to use EAP-CREDS with EST.

A.3.  EAP-CREDS and CMS

   Describe how to use EAP-CREDS with CMS.

A.4.  EAP-CREDS and ACME

   Describe how to use EAP-CREDS with ACME.

Author's Address

   Massimiliano Pala
   CableLabs
   858 Coal Creek Cir
   Louisville, CO  80027
   US

   Email: m.pala@openca.org
   URI:   http://www.linkedin.com/in/mpala




Pala                    Expires December 3, 2019               [Page 22]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/