eap Mailing List: Issue 180: SA Descriptions

[Bernard Aboba (aboba]

Submitter name: Pasi Eronen
Submitter email address: pasi.eronen [at] nokia.com
Date first submitted: October 2, 2003
Reference:
Document: Keyframe-07
Comment type: T
Priority: S
Section: 1.3, 1.4, 1.5, 1.6, 1.7
Rationale/Explanation of issue:

I've rewritten the following sections to improve clarity:

1.3. Conversation Overview

   Where EAP key derivation is supported, EAP authentication is
   typically a component of a four phase exchange:

      Discovery (phase 0)
      EAP authentication (phase 1a)
      Access authorization (phase 1b)
      Service association (phase 2)

   In the discovery phase (phase 0), the parties locate each
   other and exchange some information about the service to be
   provided. For instance, one of the parties may indicate its
   willingness to provide a service (and to perform the EAP
   authenticator role), and the other party requests access to
   that service (assuming the EAP peer role).

   Next, the EAP peer and backend authentication server
   authenticate each other (phase 1a) and derive a shared
   session key (AAA-Key/MSK). In this phase, the authenticator
   just forwards EAP packets between the peer and backend
   authentication server (note that in some cases, the
   authenticator and backend authentication server can be
   colocated in the same physical node). This feature of EAP
   enables deployment of new authentication methods without
   requiring development of new code on the authenticator.

   Partially overlapping with this exchange is a second exchange
   (phase 1b), between the authenticator and the backend
   authentication server. In this exchange, the authenticator
   and backend authentication server authenticate each other
   (using some other mechanism than EAP), and authenticator
   sends information about the service requested by the
   peer. When the phase 1a has finished, the backend
   authentication server sends the authenticator information
   about whether the service should be provided or not, a key
   for protecting service communication (AAA-Key/MSK), and
   optionally more detailed instructions about the service to be
   provided.

   After both phases 1a and 1b are complete, the authenticator
   signals the peer it will allow access to the service (phase
   2). Next, the peer and authenticator typically exchange more
   parameters about the service to be provided (most likely some
   were already exchanged during phase 0).  These parameters
   also include details of how the subsequent communication
   between them will be protected and what keys will be used
   (the keys to be used are either derived from AAA-Key or
   authenticated using it, ensuring that an attacker not knowing
   AAA-Key cannot have these keys). During this phase, some or
   all of the parameters exchanged can also be protected using
   the AAA-Key (typically, at least the keys and selected
   ciphersuites are protected).

   The phases and the relationship between the parties is
   illustrated below.

   EAP peer                 Authenticator              Auth. Server
   --------                 -------------              ------------
     <---------------------------->
         Discovery (phase 0)
     <------------------------------------------------------>
                     EAP authentication (phase 1a)
                                  <------------------------->
                                Access authorization (phase 1b)
     <---------------------------->
     Service assocation (phase 2)

1.4 A concrete example: WPA

   (Details to be added; this is just a sketch)

   o  Phase 0: Beacon, Association Request, Association Response.

      The client and access point already know what EAP roles
      they will use. The service parameters exchanged in phase 0
      include the SSID, data rates, supported ciphersuites, hop
      patterns (and other PHY parameters).

      The AP initiates phase 1a by sending an EAP Identity
      Request, encapsulated inside EAPOL (though in some cases,
      the AP requests the backend authentication server to send
      this).

   o  In phase 1a, the client and backend authentication server
      authenticate each other. For instance, if EAP-TLS is used,
      they both exchange certificates, verify that the certificates
      are valid and belong to the expected party, and prove
      that they know the corresponding private keys. This exchange
      also generates a shared key between them.

   o  Phase 1b typically uses RADIUS. The packets are
      authenticated either with RADIUS's own shared secret
      method (Message-Authenticator), or IPsec. The access point
      sends e.g.its own identity and various service
      parameters (e.g. MAC addresses). When phase 1a has
      finished, the backend authentication server gives
      permission for the service (Access-Accept), and sends
      e.g. AAA-Key and Session-Timeout.

   o  Phase 2: four-way handshake and multicast key handshake.
      Protects some service parameters (MAC addresses, RSN IE,
      selected ciphersuite) and negotiates keys.

   After phase 2, the parties protect the .11i frames with
   e.g. TKIP or CCMP (basically, encryption and MAC using the
   keys negotiated in phase 2, and sequence numbers for replay
   protection)

1.5 Second example: IKEv2

   "Road warrior VPN gateway with IKEv2, authenticated only using EAP"

   (Details to be added; this is just a sketch)

   o  Phase 0: Client is maybe configured with gateway's IP address.
      The parties exchange Diffie-Hellman parameters, nonces,
      selects IKEv2 ciphersuite.

   o  Phase 1a: similar as above.

   o  Phase 1b: Has not been specified yet, but presumably RADIUS
      could be used in similar fashion as with WPA.

   o  Phase 2: Authenticates the Diffie-Hellman parameters and
      nonces (exchanged in phase 0). This implicitly authenticates
      other parameters exchanged and the rest of the conversation:
      this involves negotiating what IP traffic will be protected
      with what ciphers, and so on. Also can involve assigning
      a new IP address to the client.

   After this, the traffic is typically protected with ESP.

1.6 Third example: PPP with MPPE

   To be written.

1.7 Limitations

   At this point, it is worthwhile to point out two important
   limitations. The first one applies to typical phase 2
   protocols, while the second one is more a fundamental
   limitation of the current approach.

   o  Typically, phase 2 does not protect all parameters about
      the service. For instance, MPPE [RFC3078] does not protect
      the selected ciphersuite, potentially allowing a
      "downgrade attack" in which an attacker causes a weaker
      ciphersuite to be selected than would have been
      otherwise. To take a second example, 802.11i does not
      protect the SSID, so the peer (STA) and authenticator (AP)
      can have a different idea about what service is being
      provided.

   o  Currently, phases 1a and 1b are (almost) independent of each
      other.  This means that the backend authentication server
      cannot restrict the service parameters used by the
      authenticator.  A malicious or compromised authenticator
      (that is trusted by the backend authentication server) can
      present any set of service parameters it wants to the
      peer. The parameters can be protected at phase 2, but at this
      point they are protected using a key known to the authenticator.

      For instance, if using IKEv2 authenticated solely using
      EAP, the IKEv2 gateway can claim to offer WLAN service, or
      a WLAN access point can claim to offer IKEv2 service. To
      give an another example, a WLAN access point offering
      service for SSID "Joe's Hotspot" can claim to offer
      service for "Harry's Hotspot".

      It should be pointed out that leaving the service
      parameters to the authenticator actually makes sense in
      many situations. For instance, in WLANs the authenticator
      (AP) knows best what data rates, hop patterns or
      ciphersuite sit supports.

----------------------------------------------------------------