Subject: [eap] Issue: New text about conversation phases

From: <[email-masked]>
Date: Wed, 15 Oct 2003 02:02:43 +0300

New text about conversation phases
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: October 14, 2003
Reference: 
Document: Keying framework
Comment type: T
Priority: 1
Section: 1.3
Rationale/Explanation of issue:

Here is a proposed replacement for section 1.3 of the
keying framework (note that this will most likely be 
revised during/after the interim meeting).

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 authentication (phase 2)  

   In the discovery phase (phase 0), the parties locate and
   contact each, and then 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 (later called Authorization Key). 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
   (typically inside some AAA protocol attributes).  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 (Authorization Key), 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), protect at least some
   of these parameters using the Authorization Key, and agree
   about keys used to protect subsequent communication. The goal
   is to ensure that an attacker not knowing the Authorization
   Key cannot modify the protected parameters or calculate the
   keys that will be subsequently used.

   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 authentication (phase 2)
 
1.3.1 A concrete example: IEEE 802.11i ESS

   (Details to be added; this is just a sketch)
 
   o  Phase 0: Typically, the client (peer) discovers the access
      point (authenticator) by listening to Beacon messages, and
      requests access by sending an Assocation Request
      message. 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 an EAPOL frame (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 RADIUS packets are
      authenticated either with RADIUS's own shared secret
      mechanism (Message-Authenticator), or IPsec. The access
      point sends an Access-Request message containing various
      service parameters (such as Service-Type,
      Calling-Station-Id, and Called-Station-Id). When phase 1a
      has finished, the backend authentication server gives
      permission for the service (Access-Accept), and sends
      e.g. Authorization Key and Session-Timeout.

   o  Phase 2 includes the four-way handshake and group key 
      handshake. These exchanges protect various service parameters
      (MAC addresses, RSN IE, selected ciphersuite) and produce
      keys for encrypting the actual traffic.
 
   After phase 2, the parties protect the 802.11 data frames
   with TKIP or CCMP (basically, encryption and MAC using the
   keys negotiated in phase 2, and sequence numbers for replay
   protection).

1.3.2 Second example: IKEv2/IPsec

   This example assumes a "road warrior VPN gateway" type
   situation where the IKEv2 SA is authenticated solely using
   EAP (no certificates are necessary).

   o  Phase 0: IKEv2 doesn't usually use "discovery" in strict
      sense; instead, the client (initiator) is configured with
      the IPsec gateway's address or DNS name. The client
      contacts the gateway and they exchange Diffie-Hellman
      parameters, nonces and select an IKEv2 ciphersuite. The
      client also indicates the willingness to use EAP by
      leaving out the AUTH payload from the third message.
  
   o  Phase 1a is similar as above (although it is likely
      that some other EAP method than EAP-TLS would be used).

   o  Phase 1b is also very similar. Although no "RADIUS
      guidelines for IKEv2" document exists yet, RADIUS could be
      used with very small modifications (perhaps a new value
      for Service-Type and agreement about what to put in
      Calling-Station-Id/Called-Station-Id attributes).

   o  Phase 2: In this phase, the client and the gateway 
      authenticate the IKEv2 SA by using Authorization Key to
      compute a MAC of the Diffie-Hellman parameters and nonces
      (and some other information) exchanged in phase 0. This
      implicitly protects other parameters and the rest of the
      conversation as well.  The service parameters negotiated
      next include details about client IP addresses, what IP
      traffic will be protected, what ciphersuites will be used,
      and so on.

   After this, the traffic is typically protected with ESP or AH.

1.3.3 Repeating the conversation 

   There are several reasons why a service might require new
   phase 1a/1b conversation.
    
   o  The service may require periodic reauthentication (and
      reauthorization): A new phase 1a/1b is used to check that
      the client still has the correct credentials, and the
      authorization granted by the backend authentication server
      is still valid.
 
   o  Service parameters may have changed in a way that requires
      new authorization granted by the backend authentication 
      server.
  
      For instance, suppose that the peer is allowed WLAN access
      with 802.11g physical layer; is the user allowed to switch
      to 802.11b?  In this case, the answer is most likely
      yes--the backend authentication server isn't concerned
      with such small details. The peer and authenticator can
      negotiate this change in service parameters without having
      a new phase 1a/1b exchange.

      However, if the user is accessing SSID "Joe's HotSpot",
      does this authorization also give access to SSID "Example
      Inc. Intranet"? Most likely no--this is a detail the
      backend authentication server would like to know about.
    
      Depending on the service, there are service parameters
      between these two extremes: some of them matter when
      authorizing access, some are small details that can be
      negotiated freely between the peer and the authenticator.
      See Section X.X for more discussion about the authorization
      issues.

   o  The authenticator has lost the state associated with this
      service, or the state is no longer synchronized.  This may
      occur if, for instance, the authenticator is rebooted, or
      if the the service is moved to a different physical
      service element (see Sections X.X.X (TBD: correctness 
      of fast handoff) and 3.3.3 for more discussion
      about this).

1.4 Conversation limitations

   It is worthwhile to point out two important limitations.  The
   first one is rather trivial, and applies only to some phase 2
   protocols. However, the second one is much less obvious, and
   is more a fundamental limitation of the EAP design.

1.4.1 Protection of service parameters in phase 2

   Typically, phase 2 does not protect all parameters about the
   service. That is, even an attacker who does not know the
   Authorization Key can cause the parties to have a different
   idea of some service parameters.

   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,
   IEEE 802.11i does not protect the SSID, capability
   information, data rates and PHY-specific parameters sent in
   Beacon messages.

   Of course, not all parameters necessarily need protection,
   since they are not useful in any practical attacks. Selecting
   what parameters to protect is a design decision in the phase
   2 protocol, not a fundamental property of the EAP design.

1.4.2 Independence of phases 1a and 1b

   Currently, phases 1a and 1b are (almost) independent of each
   other. They are usually carried inside the same RADIUS
   packets, but in an important sense they are still
   independent. (At least in theory, it would be possible to
   have a system where the EAP packets would not go through the
   authenticator at all).

   The most important consequence of this is 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.

   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 ciphersuites it supports. It would probably not be wise to
   require the backend authenticator server to know about these.

   However, there are situations where the backend
   authentication server might want to restrict some particular
   service parameters. For instance, currently a WLAN access
   point offering service for SSID "Joe's Hotspot" could also
   claim to offer service for SSID "Harry's Hotspot" or "Example
   Inc. Intranet". To take a second example, an IKEv2 gateway
   could claim to offer WLAN service, and if the IKEv2 session
   is authenticated solely using EAP (without any certificates),
   a WLAN access point could claim to offer IKEv2 services.

1.4.3 Connecting phases 1a and 1b

   The separation of phases 1a and 1b is a fundamental
   limitation of current EAP design. There have been discussions
   whether this limitation is actually a significant problem or
   not, and if so, how it could be solved.

   It seems that any solution involves three necessary components:

   1) The backend authentication server has to get the values
      for those parameters.

   2) The backend authentication server has to check that 
      the authenticator it is sending the Authorization Key to is 
      actually authorized to use those values. 

      This most likely involves a database on the backend
      authentication server, connecting the authenticated
      identity of the authenticator (AAA SA, see Section 3.4) 
      to the authorized values (such as SSID).
       
   3) The authenticator has to be prevented from telling different
      values to the peer and backend authentication server. 

      a) The values could communicated inside the EAP exchange,
         protected using keys known only to the peer and
         the backend authentication server (EAPv2 or Archie).

      b) The backend authentication server (and the peer) could
         include the values of these parameters when deriving
         the Authorization Key (from keys known only to the
         peer and the backend authentication server).

Best regards,
Pasi
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Oct 2003 18:14:22 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Pasi" == Pasi Eronen <[email-masked]> writes:
    Pasi> o Phase 1b is also very similar. Although no "RADIUS guidelines for
    Pasi> IKEv2" document exists yet, RADIUS could be used with very small
    Pasi> modifications (perhaps a new value for Service-Type and agreement
    Pasi> about what to put in Calling-Station-Id/Called-Station-Id
    Pasi> attributes).

  have you read draft-ietf-ipsec-dhcp-over-ike-radius-00.txt?

] Collecting stories about my dad: http://www.sandelman.ca/cjr/ |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap