Internet DRAFT - draft-andersson-eap-tls-sasl

draft-andersson-eap-tls-sasl



Internet Draft                                              H. Andersson
                                                            S. Josefsson
                                                            RSA Security
                                                               June 2001


               EAP Mechanism using TLS and SASL (Version 1)
                   draft-andersson-eap-tls-sasl-00.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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

   Distribution of this memo is unlimited.

Abstract

   This document specifies an Extensible Authentication Protocol (EAP)
   mechanism for mutual authentication and session key generation in a
   roaming environment. The server authentication and the negotiation of
   the session key is done using the PPP EAP Transport Layer Security
   Authentication Protocol. The user authenticates using a SASL
   mechanism, the SASL authentication being protected by TLS. An
   important application discussed in this document is to provide a
   strong form of authentication of access points and stations within an
   IEEE 802.11 Wireless Local Area Network (WLAN), but other
   applications such as LAN access over Bluetooth might also be
   considered in the future.

1. Introduction

   The PPP Extensible Authentication Protocol [2] defines a general
   authentication framework. This document specifies an EAP mechanism
   for mutual authentication and session key generation, with support
   for a roaming environment. The connection is made, using EAP
   terminology, between a peer and an authenticator. The (public-key)
   authentication of the authenticator and the negotiation of the


Andersson & Josefsson           Expires December 2001           [Page 1]

Internet Draft             EAP TLS SASL (Version 1)            June 2001


   session key is done using the PPP EAP Transport Layer Security
   Authentication Protocol [1]. The user performs a strong
   authentication using a SASL mechanism, see [6], such as the RSA
   SecurID SASL mechanism [8], the One-Time-Password SASL mechanism [7],
   or one of the original mechanisms defined in [6]. 

   Section 2 defines the model and some terminology. A brief overview of
   the EAP conversation is given in Section 3, and Section 4 gives a
   detailed description of packet formats. In Section 5, the protocol
   is applied to an IEEE 802.11 Wireless Local Area Network (WLAN). 
   Finally, Section 6 discusses security issues.

2. Model and Terminology

   The term peer notifies a client, acting on behalf of a user, that
   requests access to a network. The entity contacted by the peer is
   denoted authenticator. The authenticator is in turn connected to an
   entity called authentication server. In our model, the authenticator
   is acting merely as a passthrough device during the authentication
   phase, forwarding each packet received from the peer to the
   authentication server, and vice versa. In the sequel we will identify
   the authenticator and its corresponding authentication server,
   whenever this can be done without any risk of misunderstandings. The
   realisation of the authentication server and the communication
   between the authenticator and the server is outside the scope of this
   document.


       +---+
       | A | 
       | u |
       | t |
       | h |               +---------------+         +--------+ 
       | e | <-----------> | Authenticator | <-----> |  Peer  |      
       | n |               +---------------+   EAP   +--------+ 
       | t |                                         .
       | i |                                       .
       | c |                                     .
       | a |               +---------------+   .   EAP
       | t | <-----------> | Authenticator | .
       | i |               +---------------+
       | o |                      
       | n |                       
       |   |                       
       | S |               +---------------+ 
       | e | <-----------> | Authenticator |
       | r |               +---------------+
       | v |
       | e |
       | r |
       +---+



Andersson & Josefsson           Expires December 2001           [Page 2]

Internet Draft             EAP TLS SASL (Version 1)            June 2001


   An overview of the assumed environment is found in the figure above.
   The peer initially contacts the authenticator at the top of the
   figure. The dotted line between the peer and the next authenticator
   symbolizes roaming, i.e. the situation where the peer transits from
   one authenticator to another while still maintaining server and user
   authentication. It is assumed that the same authentication server
   sits behind all of the authenticators contacted by the peer.

   This document frequently uses the following abbreviations:

   EAP

      Extensible Authentication Protocol. After a connection link has
      been established between two entities, an authentication phase may
      take place. The PPP EAP protocol [2] is a general authentication
      protocol. The authenticator sends one or more requests to the
      peer, and the peer sends a response in reply to each request. The
      authenticator ends the authentication phase with a success or
      failure message.

   SASL

      Simple Authentication and Security Layer. A method for adding
      authentication support to connection-based protocols and for
      optionally negotiating a security layer for subsequent protocol
      interactions. Defined in [6]. The method is mainly focused on
      authenticating a user to a server. Several SASL mechanisms have
      been defined, such as the SecurID SASL mechanism [8], the
      One-Time-Password SASL mechanism [7], and the original mechanisms
      of [6].

   TLS

      Transport Layer Security. Internet security protocol for
      point-to-point connections (enhancement of Secure Sockets Layer,
      SSL). Defined in [3]. Under this protocol, two entities are able
      to authenticate each other and to establish a secure link. TLS
      operates at the transport layer. The protocol PPP EAP TLS [1]
      describes how to provide for TLS mechanisms within EAP.

3. Overview of the conversation

   A peer wishes to set up a connection with an authenticator, for the
   purpose of authenticating itself to e.g. a wireless infrastructure.
   In our model, the authenticators are in connection with an
   authentication server. The following describes each EAP packet that
   is sent between the authenticator and peer during the EAP connection.

3.1. Initial registration

   The first two steps are described in detail in Section 3.1 of [2], we
   repeat them here for completeness.


Andersson & Josefsson           Expires December 2001           [Page 3]

Internet Draft             EAP TLS SASL (Version 1)            June 2001


   1. The first EAP Request packet sent by the authenticator to the
      peer is of type Identity. The data field may optionally contain a
      displayable message.

   2. The peer responds with an EAP-Response packet of type Identity. 
      The data field containing Identity is not used here (the peer
      identity is transferred under TLS protection by the SASL mechanism
      below) and should be of zero length.

   The entities now initiate an EAP-TLS conversation. The following is
   an example of a TLS handshake within EAP -- the packets are described
   in detail in Section 4 of [1]. Note that the EAP method defined in
   this document does not terminate the TLS connection once the TLS
   handshake is concluded (and thus differs subtly from how TLS is used
   in [1]).

   3. The authenticator sends an EAP-TLS packet of type Start with empty
      data field. The data field of following packets will encapsulate
      TLS Handshake Protocol messages.

   4. Client hello: The peer sends a preferred TLS protocol version
      number, an empty Session ID field, a list of preferred
      cryptographic algorithms, and a random number to initialize the
      TLS handshake.

   5. Server hello: The authenticator responds with a selected TLS
      protocol version number, a new Session ID, a list of selected
      cryptographic algorithms, and another random number. Server
      certificate: The authenticator then sends a chain of X.509v3
      certificates, starting with its own certificate. Server hello
      done: Finally, the authenticator indicates the end of this message
      stream. (Note that the authenticator must NOT send any certificate
      request.)

   6. Client key exchange: The peer generates a premaster secret,
      encrypts it using the public key obtained from the server
      certificate, and sends the result. Client finished: The peer also
      calculates a master secret from the premaster secret, and sends a
      hash of a message consisting of the master secret; all of the data
      from all previous handshake messages; the string "client
      finished".

   7. Server finished: Finally, the authenticator itself generates the
      master secret from the premaster secret and responds with a hash
      of a message consisting of the master secret; all of the data from
      all previous handshake messages; the string "server finished".

   This concludes the TLS handshake and the authentication of the
   authenticator. It remains to perform user authentication.  Note that
   it is not until now that we will deviate from the specification [1].
   The following packets will be sent within the TLS Record Protocol
   (and will therefore be protected by the encryption negotiated by
   TLS).

Andersson & Josefsson           Expires December 2001           [Page 4]

Internet Draft             EAP TLS SASL (Version 1)            June 2001


   8. The authenticator sends a list of supported SASL mechanisms.

   9. The SASL mechanism at the peer gathers information and constructs
      a SASL token that is sent to the authenticator protected by the
      TLS Record Protocol layer. Typically the token consists of user
      name, one time password, PIN code, etc.

  10. The SASL mechanism at the authenticator reads the SASL token, and
      can proceed in one of three ways. The first path, taken upon
      successful verification, returns EAP-Success and finishes the
      authentication phase. The second path is when verification of the
      user credentials has terminally failed, and an error message is
      returned to the peer. The peer may choose to re-start the SASL
      dialogue by resuming at step 9 above (or give up by
      disconnecting). The third path is when the SASL mechanism requires
      additional information from the peer. A new SASL token will then 
      be sent to the peer. The entities resume at step 9, awaiting the
      eventual outcome of either success or failure.

   This concludes the mutual authentication, and upon success both
   authenticator and peer may generate any amount of new key material to
   be forwarded to the underlying transport. This is accomplished within
   the TLS Record Protocol by using the so-called PRF (Pseudo-Random
   Function), see [3].

3.2. Roaming

   We now describe the case where the peer is transiting between two
   authenticators during a session. In order to obtain a seamless
   transition to a connection between the peer and the new
   authenticator, we use the connection re-establishment mechanism
   provided by the TLS Handshake Protocol. Note that the new
   authenticator is assumed to use the same authentication server as the
   old one, hence the old security parameters are still available.

   The steps 1-3 above are repeated without change. Then the following
   condensed TLS handshake follows.

   4. Client hello: The peer sends the TLS protocol version number, the
      Session ID of the old connection, the previously negotiated
      cryptographic algorithms, and a random number.

   5. Server hello: The authenticator responds with the TLS protocol
      version number, the Session ID, the negotiated cryptographic
      algorithms, and another random number. If the old Session ID has
      expired, then a new Session ID is presented to the peer and full
      authentication takes place, as described in Subsection 3.1.

   6. Client finished: The peer sends a hash of a message consisting of
      the previously calculated master secret; data from all previous
      handshake messages; the string "client finished".



Andersson & Josefsson           Expires December 2001           [Page 5]

Internet Draft             EAP TLS SASL (Version 1)            June 2001


   7. Server finished: The authenticator responds with a hash of a
      message consisting of the master secret; data from all previous
      handshake messages; the string "server finished".

   Note that mutual authentication is achieved, since both peer and
   authenticator have to know the old master secret in order to
   successfully complete the protocol. An alternative to TLS resumption
   has been discussed, whereby a "Roaming ID" is used to identify the
   user moving between authenticators. At a new connection, server
   authentication and generation of new security parameters is
   mandatory. The advantage of this approach is that the authentication
   server does not have to store so much key material, since all data
   except the Roaming ID may be deleted when entities are disconnected.
   This can be an important issue if there are many peers to be served.
   On the other hand, having to generate much new key material could
   be very time consuming for the authentication server, and this
   potential danger has led us to choose TLS resumption as described
   above.

   Finally, the length of time that a Session ID is valid should be
   limited. The time of validity is application dependent. In some
   environments it may be desirable that the authenticator notify the
   peer that the Session ID is about to expire. No mechanism is defined
   in this document to handle such a scenario, but note that the
   Session ID validity is checked during connection re-establishment
   (see 5 above).

4. Packet formats

   It is assumed that underlying transport protocols has set up the
   connection so that it is ready to transfer EAP packets.

4.1. TLS in EAP

   The syntax of EAP packets containing TLS messages is per [1], and the
   TLS protocol description is per [3]. Note that [1] does not make use
   of messages in the Record Protocol layer of TLS while this
   specification does, however this does not affect the EAP protocol
   syntax. We include the EAP syntax in the following figure, referring
   to Sections 4.2 and 4.3 of [1] for the definition of the Request and
   Response packets.


    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      |                  Data ...                     /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Andersson & Josefsson           Expires December 2001           [Page 6]

Internet Draft             EAP TLS SASL (Version 1)            June 2001


   Code

      1 - Request
      2 - Response

   Identifier

      The identifier field is one octet and aids in matching responses
      with requests.

   Length

      The Length field is two octets and indicates the length of the EAP
      packet including the Code, Identifier, Length, Type, and Data
      fields.  Octets outside the range of the Length field should be
      treated as Data Link Layer padding and should be ignored on
      reception.

   Type

      TBA - EAP TLS SASL

   Data

      The format of the Data field is determined by the Code field.


4.2. SASL negotiation inside TLS Record Protocol

   We now assume that the TLS handshake has been successfully completed
   and that a secure TLS connection is available within the TLS Record
   Protocol. The following packets (protected by TLS Record Protocol and
   sent inside EAP packets) are used to negotiate a SASL authentication.

   The following figure describes the template packet structure that is
   used during this communication.


    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |                  Data ...                     /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      0  Reserved
      1  SASL greeting
      2  SASL token
      3  Soft error
  4-254  Not used by this specification
    255  Reserved


Andersson & Josefsson           Expires December 2001           [Page 7]

Internet Draft             EAP TLS SASL (Version 1)            June 2001


   We now describe each of the individual packet types.

   SASL greeting

      The data field of this packet contains a list of SASL mechanisms
      supported by the authenticator. Each entry in the list of SASL
      mechanisms is terminated by a NUL octet, and contains a SASL
      mechanism name (from 1 to 20 characters in length).

   SASL token

      The data field of this packet contains the name of the selected
      SASL mechanism, terminated by a NUL octet, together with the SASL
      token.

   Soft error

      This packet (with empty data field) notifies the peer that a soft
      user authentication error has occurred, such as when a user has
      typed her username incorrectly. When this message is received
      during an initial registration, the peer may reset the SASL
      mechanism and re-try (or disconnect). Note that the EAP type
      Notify packet may be used if the authenticator wishes to relay a
      displayable text message to the peer.

5. Example: IEEE 802.11 WLAN

   IEEE 802.11 Wireless Local Area Network (WLAN) is a standard for
   wireless computer networks, see [5]. Any device that contains an
   IEEE 802.11 conformant medium access control and physical layer
   interface to the wireless medium is called a Station (STA). An entity
   that has station functionality and also provides access to the
   distribution services (e.g. a wired LAN) via the wireless medium for
   associated stations is called an Access Point (AP). The
   authentication services defined within IEEE 802.11 are discussed
   below, and the need for higher level authentication is addressed.

   IEEE 802.11 defines two types of authentication methods -- Open
   system authentication and Shared key authentication. Open system
   authentication is essentially a null authentication. The conversation
   is done in clear, no challenge procedure is performed. The purpose of
   Shared key authentication is to check that both parties share a
   pre-negotiated encryption key. The AP sends a challenge and the STA
   responds by encrypting this challenge. If the AP successfully
   decrypts that message, the authentication is finished. In other
   words, the AP is never required to authenticate itself. This opens up
   for a number of attacks, such as denial of service attacks via rogue
   APs. It is thus crucial to achieve mutual authentication.

   The IEEE 802.1X draft [4] specifies a general method for the
   provision of port based network access control. A port in this
   context is an attachment point to the LAN infrastructure, e.g. an


Andersson & Josefsson           Expires December 2001           [Page 8]

Internet Draft             EAP TLS SASL (Version 1)            June 2001


   association between a STA and an AP. The specification describes the
   architectural framework within which the authentication takes place,
   and establishes the requirements for a higher level authentication
   protocol between the station and the access point.

   The IEEE 802.1X draft provides a framework, Extensible Authentication
   Protocol Over Local area networks (EAPOL), that makes it possible to
   send EAP packets between IEEE 802.11 entities. In a WLAN environment,
   the "Authenticator" is the AP, and the "Peer" is a STA. An
   Authentication Server is an entity connected with the AP. The server
   is communicating with the STA during the authentication -- the AP is
   sitting in between, acting merely as a passthrough device. In a
   roaming environment, the STA may connect to several APs during a
   session. All the APs are assumed to be connected to the same
   authentication server. The protocol described in this paper may
   therefore be applied to a WLAN environment, providing authentication
   of the AP, strong authentication of the user of the STA, and session
   key negotiation.

   Note that the present protocol is partly based on [1], which in turn
   assumes PPP EAP and not EAPOL as the underlying protocol. However,
   this minor difference will cause no problems whatsoever, since the
   TLS conversation carries over word by word to the new environment.

   Let us finally comment on the Wired Equivalent Privacy (WEP)
   encryption scheme defined in the IEEE 802.11 standard. WEP uses the
   stream cipher RC4 with key obtained as the concatenation of a 24 bit
   IV and a 40 bit WEP key. Four WEP keys can be prestored, but it is
   also possible to use a session key negotiated during the
   authentication phase, i.e. follow the approach outlined in this work.
   WEP suffers from some serious security weaknesses, e.g. the WEP key
   is too short to withstand a brute force attack. Also, the IV is too
   short -- even if a new random IV is used for each packet, collisions
   will start appearing within a few seconds (according to the birthday
   paradox). XORing messages with the same IV results in plaintext
   difference that can be further analyzed. Finally, there is no real
   data integrity since the integrity check value used is just a linear
   checksum. An active attacker wishing to alter the plaintext can
   easily modify the checksum to be valid for the new plaintext. The
   IEEE 802.11 working group recognizes the need to improve security,
   and is currently working on a revision of the standard.

6. Security considerations

   The Transport Layer Security protocol is presumed to be a strong
   security protocol and it is widely accepted. Here we discuss some
   security issues. The Session ID is sent in clear, so an attacker may
   contact an authenticator, pretending to be the legitimate user.
   However, by sending correct Finished messages, the parties prove to
   each other that they know the correct premaster secret. The attacker
   will not be able to finish the handshake properly (unless the
   protocol has been completely broken).


Andersson & Josefsson           Expires December 2001           [Page 9]

Internet Draft             EAP TLS SASL (Version 1)            June 2001


   An attacker, acting as an active man-in-the-middle, might try to
   influence the choice of encryption algorithm by altering the
   corresponding handshake message. However, this will also be detected
   in the verification of the Finished messages, since each of these
   consists of a hash of all previous messages. The hash functions MD5
   and SHA-1 are used in tandem wherever possible. The TLS designers
   claim that this approach ensures that a serious flaw in one of the
   functions will not lead to failure of the entire TLS protocol.

   Finally, the SASL mechanism typically provides strong user
   authentication. With the approach described here, the SASL tokens
   sent by the peer are not transmitted in clear. This is particularly
   important in a wireless environment where passive eavesdropping is a
   serious threat.

7. Acknowledgements

   We wish to thank Jan-Ove Larsson and Magnus Nystrom for helpful
   discussions and comments on earlier drafts.

References

   [1]  Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol",
        RFC 2716, October 1999.

   [2]  Blunk, L., Vollbrecht, J., "PPP Extensible Authentication
        Protocol (EAP)", RFC 2284, March 1998.

   [3]  Dierks, T., Allen, C., "The TLS Protocol", RFC 2246, January
        1999.

   [4]  IEEE Standards for Local and Metropolitan Area Networks: Port
        based Network Access Control, IEEE Draft 802.1X/D10, January
        2001.

   [5]  Information technology -- Telecommunications and information
        exchange between systems -- Local and metropolitan area
        networks -- Specific requirements -- Part 11: Wireless LAN
        Medium Access Control (MAC) and Physical Layer (PHY)
        Specifications, IEEE Std. 802.11, 1999.

   [6]  Myers, J., "Simple Authentication and Security Layer (SASL)",
        RFC 2222, October 1997.

   [7]  Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
        October 1998.

   [8]  Nystrom, M., "The SecurID SASL Mechanism", RFC 2808, April 2000.






Andersson & Josefsson           Expires December 2001          [Page 10]

Internet Draft             EAP TLS SASL (Version 1)            June 2001


Address of the authors

   Hakan Andersson
   RSA Security
   Box 107 04
   SE-121 29 Stockholm
   Sweden
   E-mail: handersson@rsasecurity.com
   Phone: +46 8 725 9758
   Fax: +46 8 649 4970

   Simon Josefsson
   RSA Security
   Box 107 04
   SE-121 29 Stockholm
   Sweden
   E-mail: sjosefsson@rsasecurity.com
   Phone: +46 8 725 0914
   Fax: +46 8 649 4970



































Andersson & Josefsson           Expires December 2001          [Page 11]