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

Versions: 00 01 02

Network Working Group                                        G. Selander
Internet-Draft                                               J. Mattsson
Intended status: Informational                               Ericsson AB
Expires: August 9, 2020                                       M. Vucinic
                                                                   INRIA
                                                           M. Richardson
                                                Sandelman Software Works
                                                       February 06, 2020


       Lightweight Authorization for Authenticated Key Exchange.
                    draft-selander-ace-ake-authz-00

Abstract

   This document describes a procedure for augmenting an authenticated
   Diffie-Hellman key exchange with third party assisted authorization
   targeting constrained IoT deployments (RFC 7228).

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 August 9, 2020.

Copyright Notice

   Copyright (c) 2020 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



Selander, et al.         Expires August 9, 2020                 [Page 1]


Internet-Draft     Lightweight Authorization for AKE.      February 2020


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Problem Description . . . . . . . . . . . . . . . . . . . . .   3
   3.  Assumptions . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Device  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Domain Authenticator  . . . . . . . . . . . . . . . . . .   4
     3.3.  AAA Server  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.4.  Lightweight AKE . . . . . . . . . . . . . . . . . . . . .   5
   4.  The Protocol  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Device <-> AAA Server . . . . . . . . . . . . . . . . . .   6
     4.2.  Device <-> Authenticator  . . . . . . . . . . . . . . . .   8
     4.3.  Authenticator <-> AAA Server  . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   For constrained IoT deployments [RFC7228] the overhead contributed by
   security protocols may be significant which motivates the
   specification of lightweight protocols that are optimizing, in
   particular, message overhead (see [I-D.ietf-lake-reqs]).  This
   document describes a lightweight procedure for augmenting an
   authenticated Diffie-Hellman key exchange with third party assisted
   authorization.

   The procedure involves a device, a domain authenticator and a AAA
   server.  The device performs mutual authentication and authorization
   of the authenticator, assisted by the AAA server which provides
   relevant authorization information to the device in the form of a
   "voucher".

   The protocol specified in this document optimizes the message count
   by performing authorization and enrolment in parallel with
   authentication, instead of in sequence which is common for network
   access.  It further reuses protocol elements from the authentication
   protocol leading to reduced message sizes on constrained links.

   The specification assumes a lightweight AKE protocol
   [I-D.ietf-lake-reqs] between device and authenticator, and defines
   the integration of a lightweight authorization procedure.  This
   enables a secure target interaction in few message exchanges.  In



Selander, et al.         Expires August 9, 2020                 [Page 2]


Internet-Draft     Lightweight Authorization for AKE.      February 2020


   this document we consider the target interaction to be "enrolment",
   for example certificate enrolment or joining a network for the first
   time, but it can be applied to authorize other target interactions.

   This protocol is applicable in a wide variety of settings, e.g. an
   enterprise network using EAP [RFC3748].

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Problem Description

   The (potentially constrained) device wants to enrol into a domain
   over a constrained link.  The device authenticates and enforces
   authorization of the (non-constrained) domain authenticator with the
   help of a voucher, and makes the enrolment request.  The domain
   authenticator authenticates the device and authorizes its enrolment.
   Authentication between device and domain authenticator is made with a
   lightweight authenticated Diffie-Hellman key exchange protocol (LAKE,
   [I-D.ietf-lake-reqs]).  The procedure is assisted by a (non-
   constrained) AAA server located in a non-constrained network behind
   the domain authenticator providing information to the device and to
   the domain authenticator.

   The objective of this document is to specify such a protocol which is
   lightweight over the constrained link and reuses elements of the
   LAKE.  See illustration in Figure 1.

                       Voucher
                  LAKE  Info
    +------------+  |    |   +---------------+  Voucher  +------------+
    |            |  |    |   |               |  Request  |            |
    |            |--|----o-->|    Domain     |---------->|    AAA     |
    |   Device   |<-|---o----| Authenticator |<----------|   Server   |
    |            |--|---|--->|               |  Voucher  |            |
    |            |      |    |               |  Response |            |
    +------------+      |    +---------------+           +------------+
                      Voucher



   Figure 1: Overview and example of message content.  Voucher Info and
               Voucher are sent together with LAKE messages.



Selander, et al.         Expires August 9, 2020                 [Page 3]


Internet-Draft     Lightweight Authorization for AKE.      February 2020


3.  Assumptions

3.1.  Device

   The device is pre-provisioned with an identity ID and asymmetric key
   credentials: a private key, a public key (PK_D), and optionally a
   public key certificate Cert(PK_D) issued by a trusted third party
   such as e.g. the device manufacturer, used to authenticate to the
   domain authenticator.  The ID may be a reference or pointer to the
   certificate.

   The device is also provisioned with information about its AAA server:

   o  At least one static public DH key of the AAA server (G_S) used to
      ensure secure communication with the device (see Section 4.1).

   o  Location information about the AAA server (LOC_S), e.g. its domain
      name.  This information may be available in the device certificate
      Cert(PK_D).

3.2.  Domain Authenticator

   The domain authenticator has a private key and corresponding public
   key PK_A used to authenticate to the device.

   The domain authenticator needs to be able to locate the AAA server of
   the device for which the LOC_S is expected to be sufficient.  The
   communication between domain authenticator and AAA server is mutually
   authenticated and protected.  Authentication credentials used with
   the AAA server is out of scope.  How this communication is
   established and secured (typically TLS) is out of scope.

3.3.  AAA Server

   The AAA server has a private DH key corresponding to G_S, which is
   used to secure the communication with the device (see Section 4.1).
   Authentication credentials and communication security used with the
   domain authenticator is out of scope.

   The AAA server provides the authorization decision for enrolment to
   the device in the form of a CBOR encoded voucher.  The AAA server
   provides information to the domain authenticator about the device,
   such as the the device's certificate Cert(PK_D).

   The AAA server needs to be available during the execution of the
   protocol.





Selander, et al.         Expires August 9, 2020                 [Page 4]


Internet-Draft     Lightweight Authorization for AKE.      February 2020


3.4.  Lightweight AKE

   We assume a Diffie-Hellman key exchange protocol complying with the
   LAKE requirements [I-D.ietf-lake-reqs].  Specifically we assume for
   the LAKE:

   o  Three messages

   o  CBOR encoding

   o  The ephemeral public Diffie-Hellman key of the device, G_X, is
      sent in message 1.  G_X is also used as ephemeral key and nonce in
      the ECIES scheme between device and AAA server.

   o  The static public key of the domain authenticator, PK_A, sent in
      message 2

   o  Support for Auxilliary Data AD1-3 in messages 1-3 as specified in
      section 2.5 of [I-D.ietf-lake-reqs].

   o  Cipher suite negotiation where the device can propose ECDH curves
      restricted by its available public keys of the AAA server.

4.  The Protocol

   Three security sessions are going on in parallel (see figure
   Figure 2):

   o  Between device and (domain) authenticator,

   o  between authenticator and AAA server, and

   o  between device and AAA server mediated by the authenticator.

   We study each in turn, starting with the last.

      Device                        Authenticator           AAA Server
        |                                 |                     |
        |--- Message 1 incl. G_X, AD1 --->|--- Voucher Req. --->|
        |                                 |                     |
        |<-- Message 2 incl. PK_A, AD2 --|<-- Voucher Resp. ---|
        |                                 |
        |--- Message 3 incl. AD3 -------->|


                          Figure 2: The Protocol





Selander, et al.         Expires August 9, 2020                 [Page 5]


Internet-Draft     Lightweight Authorization for AKE.      February 2020


4.1.  Device <-> AAA Server

   The communication between device and AAA server is carried out via
   the authenticator protected between the endpoints using an ECIES
   hybrid encryption scheme (see [I-D.irtf-cfrg-hpke]): The device uses
   the private key of its ephemeral DH key G_X generated for LAKE
   message 1 (see Section 4.2) together with the static public DH key of
   the AAA server G_S to generate a shared secret G_XS.  The shared
   secret is used to derive AEAD encryption keys to protect data between
   device and AAA server.  The data is carried in AD1 and AD2 (between
   device and authenticator) and in voucher request/response (between
   authenticator and AAA server).

   TODO: Reference relevant ECIES scheme in [I-D.irtf-cfrg-hpke].

   TODO: Define derivation of encryption keys (k_rq, k_rs) and nonces
   (n_rq, n_rs) for both directions

   AD1 SHALL be the following CBOR sequence containing voucher
   information:

   AD1 = (
       LOC_S:           tstr,
       CC:              bstr,
       CIPHERTEXT_RQ:   bstr
   )

   where

   o  LOC_S is location information about the AAA server

   o  CC is a crypto context identifier for the security context between
      the device and the AAA server

   o  'CIPHERTEXT_RQ' is the authenticated encrypted identity of the
      device with CC as Additional Data, more specifically:

   'CIPHERTEXT_RQ' is 'ciphertext' of COSE_Encrypt0 (Section 5.2-5.3 of
   [RFC8152]) computed from the following:

   o  the secret key k_rq

   o  the nonce n_rq

   o  'protected' is a byte string of size 0

   o  'plaintext and 'external_aad' as below:




Selander, et al.         Expires August 9, 2020                 [Page 6]


Internet-Draft     Lightweight Authorization for AKE.      February 2020


   plaintext = (
       ID:              bstr
    )

   external_aad = (
       CC:              bstr
    )

   where

   o  ID is the identity of the device, for example a reference or
      pointer to the device certificate

   o  CC is defined above.

   AD2 SHALL be a CBOR sequence of one item, the Voucher, defined in the
   next section.

   AD2 = (
       Voucher:        bstr
   )

4.1.1.  Voucher

   The Voucher is essentially a Message Authentication Code binding the
   identity of the authenticator to the first message sent from the
   device in the LAKE protocol.

   More specifically 'Voucher' is the 'ciphertext' of COSE_Encrypt0
   (Section 5.2 of [RFC8152]) computed from the the following:

   o  the secret key k_rs

   o  the nonce n_rs

   o  'protected' is a byte string of size 0

   o  'plaintext' is empty (plaintext = nil)

   o  'external_aad' as below:

   external_aad = bstr .cbor external_aad_arr









Selander, et al.         Expires August 9, 2020                 [Page 7]


Internet-Draft     Lightweight Authorization for AKE.      February 2020


   external_aad_arr = [
       voucher_type:  int,
       PK_A:          bstr,
       G_X:           bstr,
       CC:            bstr,
       ID:            bstr
   ]

   where

   o  'voucher-type' indicates the kind of voucher used

   o  PK_A is a COSE_Key containing the public authentication key of the
      authenticator.  The public key must be an Elliptic Curve Diffie-
      Hellman key, COSE key type 'kty' = 'EC2' or 'OKP'.

      *  COSE_Keys of type OKP SHALL only include the parameters 1
         (kty), -1 (crv), and -2 (x-coordinate).  COSE_Keys of type EC2
         SHALL only include the parameters 1 (kty), -1 (crv), -2
         (x-coordinate), and -3 (y-coordinate).  The parameters SHALL be
         encoded in decreasing order.

   o  G_X is the ephemeral key of the device sent in the first LAKE
      message

   o  CC and ID are defined in Section 4.1

   All parameters, except 'voucher-type', are as received in the voucher
   request (see Section 4.3).

   TODO: Consider making the voucher a CBOR Map to indicate type of
   voucher, to indicate the feature (cf.  Section 4.3)

4.2.  Device <-> Authenticator

   The device and authenticator run the LAKE protocol authenticated with
   public keys (PK_D and PK_A) of the device and the authenticator.  The
   normal processing of the LAKE is omitted here.

4.2.1.  Message 1

4.2.1.1.  Device processing

   The device selects a cipher suite with an ECDH curve satisfying the
   static public DH key G_S of the AAA server.  As part of the normal
   LAKE processing, the device generates the ephemeral public key G_X to
   be sent in LAKE message 1.  A new G_X MUST be generated for each




Selander, et al.         Expires August 9, 2020                 [Page 8]


Internet-Draft     Lightweight Authorization for AKE.      February 2020


   execution of the protocol.  The same ephemeral key is used in the
   ECIES scheme, see Section 4.1.

   The device sends LAKE message 1 with AD1 as specified in Section 4.1.

4.2.1.2.  Authenticator processing

   The authenticator receives LAKE message 1 from the device, which
   triggers the exchange of voucher related data with the AAA server as
   described in Section 4.3.

4.2.2.  Message 2

4.2.2.1.  Authenticator processing

   The authenticator sends LAKE message 2 to the device with the voucher
   (see Section 4.1) in AD2.  The public key PK_A is encoded in the way
   public keys are encoded in the LAKE protocol.

4.2.2.2.  Device processing

   The device MUST verify the Voucher using its ephemeral key G_X sent
   in message 1 and PK_A received in message 2.  If the Voucher does not
   verify, the device MUST discontinue the protocol.

4.2.3.  Message 3

4.2.3.1.  Device processing

   The device sends message 3.  AD3 depends on the kind of enrolment the
   device is requesting.  It may e.g. be a CBOR encoded Certificate
   Signing Request, see [I-D.raza-ace-cbor-certificates].

4.2.3.2.  Authenticator processing

   The authenticator receives message 3.

4.3.  Authenticator <-> AAA Server

   The authenticator and AAA server are assumed to have secure
   communication, for example based on TLS authenticated with
   certificates.

4.3.1.  Voucher Request

   The authenticator sends the voucher request to the AAA server.  The
   Voucher_Request SHALL be a CBOR array as defined below:




Selander, et al.         Expires August 9, 2020                 [Page 9]


Internet-Draft     Lightweight Authorization for AKE.      February 2020


   Voucher_Request = [
       PK_A:            bstr,
       G_X:             bstr,
       CC:              bstr,
       CIPHERTEXT_RQ:   bstr
   ]

   where the parameters are defined in Section 4.1.

4.3.2.  Voucher Response

   The AAA server decrypts the identity of the device and looks up its
   certificate, Cert(PK_D).  The AAA server sends the voucher response
   to the authenticator.  The Voucher_Response SHALL be a CBOR array as
   defined below:

   Voucher_Response = [
       CERT_PK_D:      bstr,
       Voucher:        bstr
   ]

   where

   o  CERT_PK_D is the device certificate of the public key PK_D, issued
      by a trusted third party, intended to be verified by the
      authenticator.  The format of this certificate is out of scope.

   o  Voucher is defined in Section 4.1

   TODO: The voucher response may contain a "Voucher-info" field as an
   alternative to make the Voucher a CBOR Map (see Section 4.1)

5.  Security Considerations

   TODO: Identity protection of device

   TODO: How can the AAA server attest the received PK_A?

   TODO: Use of G_X as ephemeral key between device and authenticator,
   and between device and AAA server

   TODO: Remote attestation

6.  IANA Considerations

   TODO: CC registry

   TODO: Voucher type registry



Selander, et al.         Expires August 9, 2020                [Page 10]


Internet-Draft     Lightweight Authorization for AKE.      February 2020


7.  Informative References

   [I-D.ietf-lake-reqs]
              Vucinic, M., Selander, G., Mattsson, J., and D. Garcia-
              Carillo, "Requirements for a Lightweight AKE for OSCORE",
              draft-ietf-lake-reqs-00 (work in progress), December 2019.

   [I-D.irtf-cfrg-hpke]
              Barnes, R. and K. Bhargavan, "Hybrid Public Key
              Encryption", draft-irtf-cfrg-hpke-02 (work in progress),
              November 2019.

   [I-D.raza-ace-cbor-certificates]
              Raza, S., Hoglund, J., Selander, G., Mattsson, J., and M.
              Furuhed, "CBOR Profile of X.509 Certificates", draft-raza-
              ace-cbor-certificates-03 (work in progress), December
              2019.

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

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
              <https://www.rfc-editor.org/info/rfc8152>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Goeran Selander
   Ericsson AB

   Email: goran.selander@ericsson.com




Selander, et al.         Expires August 9, 2020                [Page 11]


Internet-Draft     Lightweight Authorization for AKE.      February 2020


   John Mattsson
   Ericsson AB

   Email: john.mattsson@ericsson.com


   Malisa Vucinic
   INRIA

   Email: malisa.vucinic@inria.fr


   Michael Richardson
   Sandelman Software Works

   Email: mcr+ietf@sandelman.ca



































Selander, et al.         Expires August 9, 2020                [Page 12]


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