Subject: [HOKEY] preauth problem statement

From: Charles Clancy <[email-masked]>
Date: Thu, 17 Jul 2008 10:47:55 -0700

The second WGLC completed with no comments on the preauth problem 
statement.  Consequently I'd like to move the document forward.  I did 
another read-through of the document and found a number of editorial 
issues (see below).  Yoshi -- please correct them and submit a revised 
document.  Meanwhile I'll work on a proto writeup and get the document 
moved forward for IESG review.

-- 
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland

Abstract

    EAP pre-authentication is defined as the use of EAP to pre-establish
    EAP keying material on a target authenticator prior to arrival of the
    peer at the access network managed by that authenticator.  This draft
    discusses EAP pre-authentication problems in details.

TCC> Spell out EAP the first time it's used.

1. Introduction

    ... Similarly, a streaming application has the
    tolerable packet (SDU) error rates ranging from 0.1 to 0.00001 and
    the transfer delay of less than 300 ms.  Thus, any optimized handoff
    mechanism will need to take care of these factors into consideration
    in order to be able to support a heterogeneous handover that is
    agnostic to link-layer technologies.

TCC> s/the tolerable packet/a tolerable packet/
TCC> s/to take care of these factors/to take these factors/

    This draft discusses EAP pre-authentication problems in details where
    EAP pre-authentication is defined as the utilization of EAP to pre-
    establish EAP keying material on an EAP authenticator prior to
    arrival of the mobile device that acts as an EAP peer, at the access
    network served by that authenticator.

TCC> s/in details/in detail,/

2. Terminology

TCC> For EAP-based terminology, I think you should just site 3748, 
rather than provide your own definitions.

3. Problem Statement

    Basic mechanism of handover is a three-step procedure involving i)

TCC> s/Basic/The basic/

    discovery of candidate network points of attachment and their
    authenticators, ii) network selection procedure to determine the
    ...
    the peer and the target authenticator to derive a new set of link-
    layer ciphering keys from EAP keying material such as MSK.  The third

TCC> s/such as MSK/such as the MSK/

    step may require full EAP authentication in the absence of any
    particular optimization for handover key management.  The handover
    latency introduced by full EAP authentication has proven to be larger
    than that is acceptable for real-time applications scenarios as
    described in [MQ7].  Hence, improvement in the handover latency
    performance due to EAP is a necessary objective for such scenarios.

    There is relevant work undertaken by various standards organizations,
    but these efforts are scoped to a specific link layer technology.
    ...
    authenticator.  IEEE 802.11r [802.11r] defines Fast BSS transition
    mechanisms involving a definition of key management hierarchy and

TCC> s/definition of key/definition of a key/

    setup of session keys before the re-association to the target AP in
    the same 802.11r mobility domain.  These mechanisms, as indicated
    before, are defined for IEEE 802.11 technologies and are only
    applicable for intra-access-domain handovers and fall short when it
    comes to inter-technology handovers.  They also require L2 (e.g.,
    Ethernet) connectivity for transfer of key management signaling to a
    candidate or the target AP.  Especially, a solution is needed to

TCC> s/to a candidate or the target/to the target/
TCC> s/Especially, a/A/

    enable EAP pre-authentication for inter-access-domain or inter-ESS
    handovers in IEEE 802.11.

    As various flavors of wireless technologies are increasingly
    available, there is a growing demand for seamless inter-technology
    mobility and handovers.  This is particularly beneficial in the

TCC> s/and handovers//

    presence of high bandwidth, wireless technologies (e.g., IEEE 802.11)
    with only hotspot-like coverages while the overlay licensed wireless/

TCC> s/coverages/coverage/

    cellular coverages are expensive and relatively low bandwidth.

TCC> s/coverages/coverage/

    Hence, the security optimization mechanisms for better handover
    performance must be looked at from the IP level so as to make it a
    common method over different access technologies.

    Optimized solutions for secure inter-authenticator handovers can be
    largely seen as security context transfer, ERP [I-D.ietf-hokey-erx],

TCC> s/transfer, ERP/transfer: ERP/

    or EAP pre-authentication.  Security context transfer involves
    transfer of reusable key context to the new point of attachment.
    However, the recent AAA key management requirement [RFC4962] does not

TCC> s/requirement [RFC4962] does/requirements [RFC4962] do/

    EAP pre-authentication has general applicability to various
    deployment scenarios of the above handover cases in which proactive

TCC> s/of the above handover cases//

    signaling can take effect.  In other words, applicability of EAP pre-
    authentication is limited to the scenarios where candidate
    authenticators can be discovered, an accurate prediction of movement
    can be easily made.  Also the effectiveness of EAP pre-authentication

TCC> s/discovered, an/discovered and an/

    may be less significant for particular inter-technology handover
    scenarios where simultaneous use of multiple technologies is not a
    major concern.

    Figure 1 shows the functional elements that are related to EAP pre-
    authentication.

    +------+         +-------------+     +------+
    | Peer |---------|   Serving   |    /        \
    |      |         |Authenticator|---/          \
    +------+         +-------------+  /            \
       .                             /              \    +--------------+
       . Move                       +   IP Network   +---|AAA/EAP Server|
       .                             \              /    +--------------+
       v             +-------------+  \            /
                     |  Candidate  |---\          /
                     |Authenticator|    \        /
                     +-------------+     +------+

            Figure 1: EAP Pre-authentication Functional Elements

TCC> This implies a single AAA server for both authenticators.  What 
about multiple AAA servers with different user credentials?

4. Usage Scenarios

    There are two scenarios for how EAP pre-authentication signaling can
    happen among a peer, serving authenticator, candidate authenticator
    and AAA server, depending on how the serving authenticator is
    involved in the EAP pre-authentication signaling.  It is assumed in
    both scenarios that there is no direct L2 connectivity between a peer
    and a CA.  No security association between the serving authenticator

TCC> CA used for the first time here.  Try and use acronyms consistently.

    and the candidate authenticator is required for either pre-
    authentication scenario (see Section 7 for more detailed discussion).

5.2. Context Binding

    There are at least two possible approaches to address the context
    binding issue.  The first approach is based on communicating the link
    layer context as opaque data via pre-authentication signaling.  The
    second approach is based on running EAP over the link layer of the
    candidate authenticator after the peer arrives at the authenticator
    using short-term credentials generated via pre-authentication.  In
    this case, the short-term credentials are shared between the peer and
    the candidate authenticator, and hence the EAP server for the EAP
    performed after the peer arrives at the target authenticator resides

TCC> "EAP performed" is unclear.  Perhaps "EAP method execution 
performed" or something similar would work better.

    in the authenticator.  In both approaches, context binding needs to
    be securely made between the peer and the candidate authenticator.
    Also, the peer is not fully authorized by the candidate authenticator
    until the peer completes the link layer specific secure association
    procedure with the authenticator using the link layer signaling.

6. AAA Issues

    Pre-authentication lifetime:   Currently AAA protocols define
       attributes carrying lifetime information for a normal
       authentication session.  Even when a user profile and the AAA
       server support pre-authentication, the lifetime for a pre-

TCC> s/support/supports/

       authentication session is typically valid only for a short amount
       of time because the peer has not completed its authentication at
       the target link layer.  It is currently not possible for a AAA
       server to indicate to the AAA client or a peer the lifetime of the
       pre-authenticated session unless AAA protocols are extended to
       carry pre-authentication session lifetime information.  In other
       words, it is not clear to the peer or the authenticator when the
       pre-authentication session will expire.

    Completion of network attachment:   Once the peer has successfully
       attached to the new point of attachment, it needs to convert its
       authentication state from pre-authenticated to fully attached and
       authorized.  There may need to be a mechanism within the AAA
       protocol to provide this indication to the AAA server if the AAA
       server needs to differentiate between pre-authentication and
       normal authentication.

TCC> Presumably for billing this would be extremely important.  You 
probably don't want to charge a preauth'd person until they are fully 
attached.

    Session Resumption:   In case the peer cycles between a network N1
       with which it has a normal authentication state to another network
       N2 and then back to N1, it should be possible to simply convert
       the full authentication state to a pre-authenticated state.  The
       problems around handling session lifetime and keying material
       caching needs to be dealt with.

TCC> s/needs/need/

7. Security Considerations

    Since pre-authentication described in this document needs to work
    across multiple authenticators, any solution needs to consider the
    following security threats.

    First, a resource consumption denial of service attack is possible,
    where an attacker that is not on the same IP link as the legitimate
    peer or the candidate authenticator may send unprotected pre-
    authentication messages to the legitimate peer or the candidate
    authenticator.  As a result, they may spend their computational and
    bandwidth resources for processing pre-authentication messages sent

TCC> s/resources for/resources on/

    by the attacker.  This attack is possible for both direct and
    indirect pre-authentication scenarios.  To mitigate this attack, the
    candidate network or authenticator may apply non-cryptographic packet
    filtering so that pre-authentication messages received from only a
    specific set of serving networks or authenticators are processed.  In
    addition, a simple solution for the peer side would be to let the
    peer always initiate EAP pre-authentication and not allow EAP pre-
    authentication initiation from authenticator side.

TCC> s/from authenticator side/from an authenticator/

    Second, consideration for the Channel Binding problem described in
    [I-D.ietf-eap-keying] is needed as lack of Channel Binding may enable
    an authenticator to impersonate another authenticator or communicate
    incorrect information via out-of-band mechanisms (such as via a AAA
    or lower layer protocol) [RFC3748].  It should be noted that it is
    relatively easier to launch such an impersonation attack for pre-
    authentication than normal authentication because an attacker does
    not need to be physically on the same link as the legitimate peer to
    send a pre-authentication trigger to the peer.

TCC> This section specifically covers threats introduced to the EAP 
model by preauthentication.  This should be stated clearly, and 
references should be made to other documents that describe general EAP 
and handover security issues.
_______________________________________________
HOKEY mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hokey