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



Network Working Group                                             Z. Cao
Internet-Draft                                                    Huawei
Intended status: Informational                                    D. Liu
Expires: April 13, 2018                                          Alibaba
                                                                   M. Qi
                                                            China Mobile
                                                        October 10, 2017


                 EAP Authentication Identity Protection
                    draft-zcao-eap-id-protection-00

Abstract

   The EAP framework does not provide an effective way to protect the
   peer's identity.  This creates the risk of identity forgery.  This
   document revisits the EAP identity protection problem, and proposes a
   solution to this problem via the use of Cryptographically Binding
   Identity (CBID).

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 April 13, 2018.

Copyright Notice

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



Cao, et al.              Expires April 13, 2018                 [Page 1]


Internet-Draft           EAP Identity Protection            October 2017


   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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Proposed Solutions  . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Crypto-binding Identity Generation  . . . . . . . . . . .   3
     3.2.  EAP Authentication using Crypto-Binding ID  . . . . . . .   3
     3.3.  Extended EAP-Response/Identity Message Format . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   In the EAP framework [RFC3748], the EAP peer will respond with its
   authentication identity in the EAP-Response/Identity message.  Based
   on the configuration with respect to the peer's identity, the EAP
   Authentication Server will determine which EAP method to start with
   this peer.  But this creates potential security threats towards the
   EAP identity.  For example, suppose user A with identity ID-A is
   configured to be authenticated with EAP-MD5 which is considered to be
   a week authentication method, then an attacker M can 'steal' A's
   identity by responding the EAP-Request/Identity message with IDA, so
   that the server will authenticate M using EAP-MD5.  In this way,
   attackers obtain an easier way to be authenticated to the system and
   then can harm the system in multiple ways.

   Currently there are no direct solutions to conduct EAP identity
   protection.  One way introduced in RFC3748 is to neglect the EAP
   identity exchange and let the server start with the same EAP method
   for every user, and only after a secure tunnel is established can the
   peer informs its identity to the server.  Another common method to
   avoid identity stolen is to use the anonymous identity, e.g., the
   users within the same domain use the same ''anon@example.org'' to
   initiate the EAP authentication.  However, this anonymous identity
   does not prevent the malicious to conduct the identity attack.

   This document introduces an EAP identity protection mechanism.
   Instead of using a native identity such as ''bob'' or
   ''bob@example.org'', the EAP peer should generate a Cryptography-
   Binding Identity (CBID) by hashing its public key so that the used
   EAP identity is bind to the user's public key.  The peer will include



Cao, et al.              Expires April 13, 2018                 [Page 2]


Internet-Draft           EAP Identity Protection            October 2017


   this crypto-binding ID in the EAP-Response/Identity and sign the
   message with its private key.  In this way, an attacker has no way to
   forge a valid public key that maps to the CBID and a valid signature
   representing this public key.  By using the CBID, EAP authentication
   can be kept immune to the EAP identity threat.

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

3.  Proposed Solutions

   We introduce our solution in this section.

3.1.  Crypto-binding Identity Generation

   Suppose the EAP peer has its own RSA public and private key pair (PK,
   SK), it will generate its crypto-binding identity (CBID) as:

   CBID = HASH (PK||OPTIONAL-CONTENT) (1)

   Where the HASH algorithm is an one-way function so that it is
   computational infeasible to do reverse derivation.  The OPTIONAL-
   CONTENT may contain the human readable user id and the domain name
   information ''@example.org''.  The OPTIONAL-CONTENT is configurable
   and synchronized between the EAP Peer and Server

   After the CBID is generated, the user will include this identity in
   the EAP-Response/Identity message, and the server will configure an
   EAP method with this identity.

3.2.  EAP Authentication using Crypto-Binding ID

   In this section, we will show how the proposed solution can prevent
   attackers to forge other peers' identity by using CBID.

   When an EAP peer A receives the EAP-Request/Identity, it will respond
   with its crypto-binding identity CBID-A and a random number Ra
   together with a signature on the whole message using its private key
   SK-A and the RSA signature algorithm.  The detailed message format
   will be shown in Section.3.3.

   The identity exchange procedure is depicted in Figure 1.  The EAP
   Peer, Authenticator and EAP Server definitions are align with RFC
   3748.




Cao, et al.              Expires April 13, 2018                 [Page 3]


Internet-Draft           EAP Identity Protection            October 2017


           +----------+        +-------------+       +----------+
           | EAP peer |        |Authenticator|       |EAP Server|
           +----------+        +-------------+       +----------+
                  |       (1)         |                    |
                  |<------------------|                    |
                  |                   |                    |
                 (2)                  |                    |
                  |       (3a)        |        (3b)        |
                  |------------------>|------------------->|
                  |                   |                   (4)
                  |                   |        (5)         |
                  |                   |<-------------------|

                  Figure 1: Identity Exchange using CBID

   (1) The authenticator sends the EAP-Request/Identity to the peer;

   (2) The EAP peer includes its CBID and generates a random number Ra,
   and then uses the RSA signature algorithm to generate a signature
   Sig.  The peer first prepares a concatenation including the EAP Code,
   Identifier, Length, Type, CBID and Random number, i.e.
   Code||Identifier||Length||Type||CBID||Random.  The peer then
   generates the RSA signature by using the RSASSA-PKCS1-v1_5 [RFC3447]
   signature algorithm with the SHA-1 hash algorithm.  The private key
   (SK) and the concatenation created above are the inputs to the
   generation operation.

   (3) The EAP peer sends the concatenated EAP-Response/Identity message
   (3a) to the EAP authenticator, the logic format of this message is
   as: EAP-Response/ID (CBID||Random||PK||Sig).  The authenticator
   encapsulates this EAP-Response into the AAA message and forwards it
   to the EAP authentication server (Msg 3b).  The authenticator does
   not need to check the validity of CBID.

   (4) The EAP authentication server will check the validity of the
   identity message.  First, it checks if the equation
   CBID=HASH(PK||OPTIONAL-CONTENT) holds true, if not, the server won't
   continue.  Second, it checks if the signature is valid by taking the
   public key PK as the verification key.  Only if the signature is
   valid will the server start the EAP authentication method in (5);

   (5) The EAP authentication server consults its local configuration
   and starts authenticating the peer using the corresponding EAP
   method.

   With the above procedure, attackers cannot intrude the EAP framework
   even if they can eavesdrop the transmitted EAP identity message.
   First, due to the property of one way hash function, attackers are



Cao, et al.              Expires April 13, 2018                 [Page 4]


Internet-Draft           EAP Identity Protection            October 2017


   not able to find another public key which maps to the same CBID.
   Secondly, attackers cannot simply replay another user's identity
   because they do not have access to the corresponding private key to
   generate the valid signature.

3.3.  Extended EAP-Response/Identity Message Format

   Figure 2 depicts the extended EAP-Response/Identity message format.

   o Code.  Code=2, this is an EAP Response message;

   o Identifier.  The Identifier field is one octet, as specified in
   RFC3748;

   o Length.  The Length field is two octets.  The length of the whole
   EAP Response message, in bytes, including the Code (1 byte),
   Identifier(1 byte), and Length (2 byte), and the Type and Type
   data(variable length);

   o Type.  One octet.  This message contains peer identity information,
   so the type value is 1 according to [RFC3748] .

   o CBID: 160 bits, as generated in Equation(1);

   o Random: 24 bits, generated by the peer, the peer should use random
   generator with good enough randomness;

























Cao, et al.              Expires April 13, 2018                 [Page 5]


Internet-Draft           EAP Identity Protection            October 2017


        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=1     |                                               |
       +---------------+                                               |
       |                       CBID (160 bit)                          |
       |                                                               |
       |               +-----------------------------------------------|
       |               |                 Random (24 bit)               |
       |---------------+-----------------------------------------------|
       |                                                               |
       |                  Public Key (variable length)                 |
       ~                                                               ~
       +---------------------------------------------------------------+
       |                                                               |
       ~                  Signature (variable length)                  ~
       |                                                               |
       +---------------------------------------------------------------+

             Figure 2: Extended EAP-Response/ID Message Format

   Public key: This is a variable-length field containing the public key
   of the address owner.  The public key MUST be formatted as a DER-
   encoded ASN.1 structure of the type SubjectPublicKeyInfo, defined in
   the Internet X.509 certificate profile [RFC 3280].  RSA signature
   algorithm is used, so the algorithm identifier MUST be rsaEncryption,
   which is 1.2.840.113549.1.1.1, and the RSA public key MUST be
   formatted by using the RSAPublicKey type as specified in
   Section 2.3.1 of RFC3279 [RFC 3279].  The RSA key length SHOULD be at
   least 384 bits.  The length of this field is determined by the ASN.1
   encoding.

   o Signature: the RSA signature by using the RSASSA-PKCS1-v1_5 [RFC
   3447] signature algorithm with the SHA-1 hash algorithm.

4.  Security Considerations

   TBD

5.  IANA Considerations

   None







Cao, et al.              Expires April 13, 2018                 [Page 6]


Internet-Draft           EAP Identity Protection            October 2017


6.  Acknowledgments

   TBD

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

Authors' Addresses

   Zhen Cao
   Huawei
   Xinxi Rd 3
   Beijing 100085
   China

   Email: zhencao.ietf@gmail.com


   Dapeng Liu
   Alibaba
   Beijing 100022
   China

   Email: max.ldp@alibaba-inc.com


   Minpeng Qi
   China Mobile
   Beijing 100053
   China

   Email: qiminpeng@chinamobile.com










Cao, et al.              Expires April 13, 2018                 [Page 7]

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