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

Versions: 00

     Internet Draft                                           Paal Engelstad
                                                     Telenor R&D, California
     Expires August 2002                                       February 2002
     
     
     
                             EAP over UDP (EAPoUDP)
     
                    <draft-engelstad-pana-eap-over-udp-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.
     
        This document is an Internet-Draft. 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.
     
        This document is an individual submission for the PANA Working Group
        of the Internet Engineering Task Force (IETF). Comments should be
        submitted to the mailing list pana@research.telcordia.com.
     
     
     Abstract
     
        This document specifies the Extensible Authentication Protocol over
        UDP (EAPoUDP) to be used for network access authentication. An
        access domain is represented by one or many PANA Authentication
        Agents (PAAs). Before a PANA Client (PaC) is granted access to the
        domain, a PAA and a PaC MAY use EAPoUDP to authenticate each other.
        EAPoUDP is a variation of the Extensible Authentication Protocol
        (PPP EAP) [2], but runs instead over IP - either IPv4 or IPv6.
        Unlike PPP EAP, EAPoUDP allows authentication over any link layer
        technology. Furthermore, the PAA and the PaC need not be on the same
        link. EAPoUDP uses UDP as its transport protocol.
     
     
     
     
     P. Engelstad             Expires August 2002                 [Page 1]


                                  EAP over UDP                February 2002
     
     
     Table of Contents
     
        1 Introduction.....................................................2
        2 Terminology......................................................3
        3 UDP as transport protocol........................................4
        4 EAPoUDP reuses PPP EAP message formats...........................4
          4.1 EAPoUDP message format.......................................4
          4.2 Types for Request/Response messages..........................6
          4.3 MD-5 Challenge for Re-Authentication.........................6
        5 EAPoUDP authentication schemes...................................9
          5.1 Starting the authentication session..........................9
          5.2 Initial Authentication......................................11
          5.3 Re-authentication...........................................12
          5.4 Disconnect..................................................13
          5.5 Back-end communication......................................13
        6 Further work....................................................14
          6.1 Selection of remaining methods..............................14
          6.2 Retransmission and timeout mechanisms.......................14
        7 Security Considerations.........................................14
        IANA Considerations...............................................14
        Acknowledgements..................................................14
        References........................................................14
        Author's Address..................................................15
     
     
     1 Introduction
     
        This document specifies the Extensible Authentication Protocol over
        UDP (EAPoUDP) to be used for network access authentication.
     
        An access domain is represented by one or many PANA Authentication
        Agents (PAAs). Before a PANA Client (PaC) is granted access to the
        domain, a PAA and a PaC MAY use EAPoUDP to authenticate each other.
     
        EAPoUDP calls for methods for Initial Authentication (I-A), Re-
        Authentication (R-A) and Disconnect Notification (D-N). I-A is for
        mutual authentication, which a PaC and a PAA are expected to perform
        before the PaC is granted access to an access domain. A product of
        the I-A method is a session key established between PaC and PAA.
        This session key can be used for R-A, when a PAA or a PaC wants to
        re-authenticate the other party and validate that it is still
        present and alive. After successful authentication, either the PAA
        or the PaC MAY want to terminate the authentication relationship by
        sending a (D-N) to the other party.
     
        EAPoUDP is a variation of the Extensible Authentication Protocol
        (PPP EAP) [2]. Unlike PPP EAP, EAPoUDP runs over IP - either IPv4 or
        IPv6. Thus, it allows PaCs and PAAs to authenticate each other over
        any link layer technology, and they do not need to be on the same
        link. For a lightweight solution, UDP is chosen as transport
        protocol.
     
     
     P. Engelstad             Expires August 2002                 [Page 2]


                                  EAP over UDP                February 2002
     
        EAPoUDP assumes that prior to authentication the PaC has configured
        a valid IPv4 or IPv6 address for itself. It MAY also have discovered
        an IP-address for at least one PAA in the access domain. PAA
        Discovery mechanisms are proposed and detailed in [1].
     
        Where to locate PAAs (e.g. with a PAA located on each access router
        or with a pool of PAAs located anywhere in the access domain)
        represents an architectural tradeoff. The PANA WG may leave to
        implementers and operators to decide which architecture best fits
        their needs. Alternatively, the PANA WG may mandate that PAAs are
        located on access routers. The scheme presented in this document
        should accommodate all alternative PAA configurations.
     
     
     2 Terminology
     
        This document uses the following terminology same as in [10]:
     
        Device Identifier (DI)
     
           This is the identifier used by the network as a handle to control
           and police the network access of a client. Depending on the
           access technology, identifier might contain any of IP address,
           link-layer address, switch port number, etc. of a device. PANA
           authentication agent keeps a table for binding device identifiers
           to the PANA clients.
     
        PANA Client (PaC)
     
           This is the entity wishing to obtain network access from a PANA
           authentication agent within a network. A PANA client is
           associated with a network device and a set of credentials to
           prove its identity within the scope of PANA.
     
        PANA Authentication Agent (PAA)
     
           This is the entity whose responsibility is to authenticate the
           credentials provided by a PANA client and grant network access
           service to the device associated with the client and identified
           by a DI.
     
     
        In addition, the following terms are introduced:
     
        Initiator
     
           The Initiator (i.e. like a PPP EAP Authenticator [2], [3]) of an
           EAPoUDP authentication method is the entity (i.e. a PaC or a PAA)
           that sends the EAPoUDP Request(s) to a Peer.
     
        Peer
     
     
     P. Engelstad             Expires August 2002                 [Page 3]


                                  EAP over UDP                February 2002
     
           The Peer of an EAP-based authentication method is the entity
           (i.e. a PaC or a PAA) that sends the EAPoUDP Response(s) back to
           an Initiator.
     
        Initial Authentication (I-A)
     
           Initial Authentication is the method for mutual authentication,
           that a PaC and a PAA are expected to perform before the PaC is
           granted access to an access domain. A product of I-A is a session
           key is established between PaC and PAA, which is used for Re-
           Authentication (below).
     
        Re-Authentication (R-A)
     
           After Initial Authentication (I-A), a PAA or a PaC MAY want to
           re-authenticate the other party and validate that it is still
           present and alive. A common method for R-A is that the Initiator
           sends a challenge to the Peer. The Peer computes a hash over the
           challenge, keyed by a session key, and returns the result to the
           Initiator. The Peer and Initiator use the session key established
           during the Initial Authentication to key the hash. This document
           specifies a method for re-authentication (R-A).
     
        Disconnect Notification (D-N)
     
           After successful authentication, either the PAA or the PaC MAY
           want to explicitly terminate the authentication relationship by
           sending a Disconnect-Notification (D-N) to the other party. D-Ns
           alone cannot guarantee disconnect. Due to Denial-of-Service (DoS)
           threats, D-N cannot be guaranteed to reach the other party.
           Disconnect can only be guaranteed by mandatory timeout mechanisms
           implemented in I-A and R-A. Thus, D-N is a function to optimize
           EAPoUDP. D-Ns MUST be integrity protected to avoid being a tool
           for DoS attacks.
     
     
     3 UDP as transport protocol
     
        This document suggests that EAPoUDP uses UDP as its transport
        protocol.
     
        For a lightweight solution, UDP and ICMP are both attractive
        alternatives. UDP is chosen here to allow for application layer
        implementations.
     
        EAPoUDP SHOULD use IANA-assigned port numbers (TBD).
     
     
     4 EAPoUDP reuses PPP EAP message formats
     
     
     4.1 EAPoUDP message format
     
     
     P. Engelstad             Expires August 2002                 [Page 4]


                                  EAP over UDP                February 2002
     
        The EAPoUDP specification follows that of PPP EAP ([2], [3]) unless
        otherwise specified in this document.
     
        The EAPoUDP packet reuses the PPP EAP format ([2], [3]). An EAPoUDP
        packet will be sent as follows:
     
                  +-----------+------------+-------------+
                  | IP header | UDP header | EAP message |
                  +-----------+------------+-------------+
     
        All messages begins with a 32-bit header following the UDP header:
     
        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            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Data ...
        +-+-+-+-+
     
        Code
     
           The Code field is one octet and identifies the type of EAPoUDP
           message. EAPoUDP Codes reuse the following EAP Codes:
     
           1 Request
           2 Response
           3 Success
           4 Failure
     
        Identifier
     
           The Identifier field is one octet and is used - together with
           source and destination IP-addresses (i.e. IP-addresses of
           Initiator and Peer) - to match responses with requests.
     
        Length
     
           The Length field is two octets and indicates the length (in
           octets) of the EAPoIP message including the Code, Identifier,
           Length and Data fields.
     
        Data
     
           The Data field is zero or more octets. The Code field determines
           the format of the Data field.
     
     
        The Data field of Request and Response messages consists of an
        additional Type field of 1 octet followed by Type-Data:
     
         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
     
     P. Engelstad             Expires August 2002                 [Page 5]


                                  EAP over UDP                February 2002
     
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Code      |  Identifier   |            Length             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |  Type-Data ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     
        Type (Request/Response messages)
     
           This Type field of Request/Response messages indicates which
           authentication method is carried in Type-Data.
     
        Type-Data
     
           The Type-Data field is zero or more octets and carries
           information associated with the authentication method. The Type
           field determines the format of the Type-Data field.
     
     
     4.2 Types for Request/Response messages
     
        EAPoUDP reuses some selected PPP EAP methods. However, PPP EAP
        methods cannot blindly be ported into EAPoUDP without taking
        security threats into account. On multi-access links, PPP EAP
        methods that are vulnerable to attacks (including eavesdropping,
        address spoofing, replay attacks and man-in-the-middle attacks),
        MUST NOT be used with EAPoUDP.
     
        EAPoUDP will explicitly specify which PPP EAP methods to be used,
        and assign a type value to the selected method. Other PPP EAP
        methods MUST NOT be used with EAPoUDP.
     
        The following EAPoUDP Types are supported in EAPoUDP:
     
         Type
     
           1    Identity
           2    Notification
           3    NAK
           4    MD-5 Challenge for Re-Authentication
          TBD   Selected method for Initial Authentication
          TBD   Selected method for Disconnect-Notification
     
        Other Types MUST NOT be used.
     
        To ensure correct and secure operation in a multi-access
        environment, EAPoUDP imposes additional requirements on the
        operation of selected PPP EAP methods. Next sub-section summarizes
        the additional requirements imposed on the MD-5 Challenge method
        selected for EAPoUDP re-authentication.
     
     
     4.3 MD-5 Challenge for Re-Authentication
     
     
     P. Engelstad             Expires August 2002                 [Page 6]


                                  EAP over UDP                February 2002
     
     
     4.3.1 MD-5 Challenge/Response format
     
        This document proposes to reuse the PPP EAP MD-5 Challenge/Response
        authentication method for EAPoUDP re-authentication ([2], [3]).
        However, we have modified the Type-Data format of challenges and
        responses to incorporate an optional Device Identifier. The content
        of the Type-Data field is summarized below.
     
            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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           | Value-Length  |  Value ...
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
           |  Name-Length  |  Name ...
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
           |   DI-Length   |  Device Identifier of Peer ...
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     
        Value-Length
     
           This is the length, in octets, of the Value field, which MUST be
           at least one octet.
     
        Value
     
           The Value field contains a challenge in Request messages, and a
           calculated MD-5 hash (Section 4.3.2) in Response messages.
     
        Name-Length
     
           This is the length, in octets, of the Name field, which SHOULD be
           at least one octet.
     
        Name
     
           The Name field contains the Network Access Identifier (NAI) of
           the sender of the message. A request message, for example, would
           contain a NAI of the Initiator, and a response message would
           contain a NAI of the Peer. This field MAY contain a temporary
           NAI, which MAY have been derived during Initial Authentication.
     
        DI-Length
     
           This is the length, in octets, of the Device Identifier field. If
           a Device Identifier is not present in the message, the value is
           set to zero.
     
        Device Identifier
     
           This field contains a Device Identifier of the Peer. The
           Initiator MAY include a Device Identifier in a challenge request
           to confirm that the IP (or MAC) source addresses of packets
     
     P. Engelstad             Expires August 2002                 [Page 7]


                                  EAP over UDP                February 2002
     
           received from the Peer is correct. The Initiator incorporates the
           address(es) into the Device Identifier, generates a random
           challenge, and sends the challenge request message to the Peer.
           The Peer MUST copy the Device Identifier field from the Challenge
           message into the same field of the response message. (Later
           versions of this document MAY open for more extensive
           negotiations of Device Identifier values.) The Peer MUST validate
           that the information in the Device Identifier is correct. The
           Peer MUST NOT return a valid Response message if the information
           is not correct.
     
        The format of the Device Identifier will be specified in a follow-on
        document.
     
     
     4.3.2 MD-5 Hash Calculation
     
        To ensure correct and secure operation in a multi-access
        environment, EAPoUDP imposes requirements on how the MD-5 hash is
        calculated:
     
           The MD-5 hash MUST be calculated over a stream of octets in
           sequence consisting of the Network Access Identifier (NAI) of
           Peer, followed by (concatenated with) Device Identifier of Peer
           (if present), followed by (concatenated with) the Identifier
           octet, followed by (concatenated with) the session key for re-
           authentication, and followed by (concatenated with) the Challenge
           Value. The Device Identifier is copied from the Device Identifier
           field in the MD-5 Response message.
     
        Since the MD-5 hash is calculated over the NAI of the Peer, it will
        protect against reflection attacks, even when Initiator and Peer use
        the same session key for re-authentication in both directions. In
        comparison, the original PPP EAP MD-5 hash is only calculated over
        the Identifier, session key, and Challenge, and requires different
        session keys in each direction.
     
        An Initiator can protect against address spoofing attacks of a
        Peer's IP-address (or MAC-address) by sending a challenge to the
        Peer with the Peer's addresses incorporated into the Device
        Identifier field. The Peer confirms the validity of the addresses by
        returning the hash calculated over both challenge and device
        identifier.
     
     
     4.3.3 Validation of Device Identifier of a Peer
     
        The Initial Authentication method sets up a cache consisting of the
        other party's identifier, session keys and IP-address (and/or MAC
        address). Upon receiving an EAPoUDP packet, a PAA or PaC checks the
        source address, and consults the cache to find the sender's identity
        and session keys.
     
     
     P. Engelstad             Expires August 2002                 [Page 8]


                                  EAP over UDP                February 2002
     
        However, the selected Initial Authentication method may not be
        capable of ensuring that the addresses in the cache are correct, and
        have not been subject to a IP-spoofing attack by a malicious Man-In-
        The-Middle (MITM). In that case, the Initial Authentication MAY be
        followed by Re-authentication where the IP- (and/or MAC-)
        address(es) are incorporated in the Device Identifier. Thus, the re-
        authentication method can be used as a means to verify the
        correctness of addresses in the cache. After one successful re-
        authentication, PAA can safely grant PaC access to the domain.
     
     
     5 EAPoUDP authentication schemes
     
     
     5.1 Starting the authentication session
     
        The specification of EAPoUDP should determine the ways in which
        Initial Authentication (I-A) can be started. There are a number of
        possibilities, and the following three sub-sections describe some
        alternatives.
     
        Without loss of generality, we assume in the following discussion
        that the EAPoUDP I-A method is carried out with PAA as the
        Initiator.
     
     
     5.1.1 Alternative 1: I-A triggered by the access network
     
        The following diagram shows a model, but not details, describing the
        message exchange where the access network triggers PAA to start
        Initial Authentication:
     
           PaC         AP/AR/DHCP/DAD/etc.       PAA
            |                  |                  |
            |                  |                  |
            |                  | 1a) A trigger    |
            |                  |----------------->|
            |                  | (PaC IP-address) |
            |                                     |
            |                                     |
            | 1b) Identity Request                |
            |<------------------------------------|
            | 1c) Idenity Response (PaC-ID)       |
            |------------------------------------>|
            |                                     |
            |                                     |
            | 2a) Initial-Auth.: First Request    |
            |<------------------------------------|
     
        In this alternative, PAA should be co-located with the entity that
        sends the trigger, e.g. with the Access Router or DHCP server.
     
        The messages are described as follows:
     
     P. Engelstad             Expires August 2002                 [Page 9]


                                  EAP over UDP                February 2002
     
     
        PaC Discovery:
     
           1a) Trigger
     
              Initially, PAA receives a trigger indicating the arrival of a
              new and un-authenticated PaC. The trigger may come from DHCP
              (e.g. the DHCP server sends a signal to PAA after having
              assigned an IP-address to a new PaC), or from another protocol
              entity. The trigger SHOULD provide PAA with the IP-address of
              the PaC.
     
           1b) Identity Request
     
              PAA sends an EAPoUDP Identity Request to the given IP-address
              of the PaC to find out the identity of the PaC.
     
           1c) Identity Response
     
              PaC returns its identity in an EAPoUDP Identity Response.
     
        Initial Authentication:
     
           2a) After having obtained PaC's identity, the PAA starts Initial
           Authentication (Section 5.2).
     
     
     5.1.2 Alternative 2: I-A triggered by unsolicited Identity Response
     
        The following diagram shows a model describing the message exchange
        where the I-A is triggered by a PaC. After having discovered a PAA,
        the PaC sends it an unsolicited Identity Request, which triggers the
        PAA to start Initial Authentication:
     
           PaC            AR/DHCP server         PAA
            |                  |                  |
            |                  |                  |
            |1a) PAA Discovery |                  |
            |<---------------->|                  |
            |                  |                  |
            |                                     |
            |                                     |
            |1b) (Unsolicited) Identity Response  |
            |------------------------------------>|
            |                                     |
            |                                     |
            | 2a) Initial-Auth.: First Request    |
            |<------------------------------------|
     
        The messages are described as follows:
     
        1a) PAA discovery [1]:
     
     
     P. Engelstad             Expires August 2002                [Page 10]


                                  EAP over UDP                February 2002
     
           A PaC discovers the IP-address and identity of a PAA (e.g. in a
           DHCP option). PAA Discovery mechanisms are proposed and detailed
           in [1].
     
        1b) (Unsolicited) Identity Response:
     
           If the client can positively determine that it has to
           authenticate, e.g. through successful PAA discovery, it MAY send
           an unsolicited Identity Response to the PAA, containing the PaC's
           Identifier. The PaC is free to pick the Identifier octet value.
           The client MUST NOT send an unsolicited Identity Response if it
           has already received an Identity Request. (The same method has
           been proposed in [7].)
     
        Initial Authentication:
     
           2a) The unsolicited Identity Request triggers the PAA to start
           Initial Authentication (Section 5.2).
     
     
     5.1.3 Alternative 3: I-A triggered by anycasted PAA discovery
     
        The following diagram shows the message exchange where a PaC uses
        anycast to discover PAA. This triggers PAA to start Initial
        Authentication:
     
           PaC                                   PAA
            |                                     |
            |                                     |
            |                                     |
            | 1a) (Anycasted) Identity Request    |
            |------------------------------------>|
            | 1b) (Unicasted) Identity Response   |
            |<------------------------------------|
            |                                     |
            | 1c) Identity Request                |
            |<------------------------------------|
            | 1d) Identity Response (PaC-ID)      |
            |------------------------------------>|
            |                                     |
            |                                     |
            | 2a) Initial-Auth.: First Request    |
            |<------------------------------------|
     
        The anycasted Identity Request triggers PAA to discover PaC's
        Identity (message 1c and 1d), before starting Initial Authentication
        (Section 5.2).
     
     
     5.2 Initial Authentication
     
        PAA is assumed to be the Initiator of Initial Authentication.
     
     
     P. Engelstad             Expires August 2002                [Page 11]


                                  EAP over UDP                February 2002
     
           PaC                                   PAA
            |                                     |
            | 2a) Initial-Auth.: First Request    |
            |<------------------------------------|
            |                                     |
            |  Possible additional Requests and   |               +--------+
            |              Responses:             |               |Local   |
            |------------------------------------>|lookup credent.| storage|
            |<------------------------------------|-------------->|   or   |
            |------------------------------------>|return credent.|AAA-    |
            |<------------------------------------|<--------------| infra- |
            |                                     |               | struct.|
            |                                     |               +--------+
            | 2n) Initial-Auth.: Last Response    |
            |------------------------------------>|
            |                                     |
     
        The messages are described as follows:
     
           2a) The PAA initiates the Initial Authentication (I-A) by sending
           an I-A-Request to the PaC.
     
           The I-A method eventually selected by PANA WG may call for
           additional Request/Response exchanges.
     
           2n) PaC returns the last I-A-Response.
     
        For Initial Authentication, PAA MAY use a local storage, a back-end
        AAA infrastructure, a Certificate Authority or some other kind of
        Trusted Third Party (TTP) to verify credentials of a PaC, and to
        obtain credentials that can be verified by the PaC. The actual
        process for obtaining and verifying credentials is out of scope for
        the EAPoUDP specification.
     
        EAPoUDP Success and Failure messages, which parallel those of PPP
        EAP ([2], [3]), have been omitted here for simplicity.
     
     
     5.3 Re-authentication
     
        A PAA or PaC MAY re-authenticate the other party at any time after
        Initial Authentication.
     
         Initiator                               Peer
        (PAA/PaC)                             (PaC/PAA)
            |                                     |
            | 3a) Re-authentication Challenge     |
            |------------------------------------>|
            |                                     |
            | 3b) Re-authentication Response      |
            |<------------------------------------|
            |                                     |
     
     
     P. Engelstad             Expires August 2002                [Page 12]


                                  EAP over UDP                February 2002
     
        PAA MAY act as an Initiator when re-authenticating PaC as a Peer, or
        PaC MAY act as an Initiator when re-authenticating the PAA as a
        Peer.
     
     
     5.4 Disconnect
     
        A PAA or PaC MAY terminate the authentication relationship by
        sending a Disconnect Notification to the other party any time after
        Initial Authentication.
     
        Initiator                               Peer
        (PAA/PaC)                             (PaC/PAA)
            |                                     |
            |  5) Disconnect Notification         |
            |------------------------------------>|
            |                                     |
     
        One way of ensuring the integrity of a Disconnect Notification is to
        require the Initial Authentication method generate a separate
        Disconnect One-time Password (D-OTP) to integrity-protect the
        Disconnect Notification message.
     
     
     5.5 Back-end communication
     
        There are a number of different ways that a PAA may interact with
        the back-end for authentication to verify credentials of PaCs and to
        obtain credentials that can be used by PaC to authenticate PAA. The
        examples above provide one possible scenario:
     
           PaC            PAA
            |              |                               +--------+
            | EAPoUDP msg. |                               |Local   |
            |------------->|lookup credentials & verifiers | storage|
            |              |------------------------------>|   or   |
            |              |return credentials & verifiers |AAA-    |
            |              |<------------------------------| infra- |
            | EAPoUDP msg. |                               | struct.|
            |<-------------|                               +--------+
            |              |
     
        Another scenario may call for the use of PAA as a pass-through as
        follows:
     
           PaC            PAA
            |              |
            | EAPoUDP msg. |                             +--------+
            |------------->|  Forwarded EAPoUDP message  |        |
            |              |---------------------------->| Auth.- |
            |              |  Returned EAPoUDP message   |        |
            |              |<----------------------------| server |
            | EAPoUDP msg. |   (+ master session keys)   |        |
     
     P. Engelstad             Expires August 2002                [Page 13]


                                  EAP over UDP                February 2002
     
            |<-------------|                             +--------+
            |              |
     
        There might be other possible scenarios. This issue is
        implementation dependent and is out of scope for EAPoUDP.
     
     
     6 Further work
     
     
     6.1 Selection of remaining methods
     
        PANA WG MUST select the specific methods used for Initial
        Authentication and Disconnect Notification. Both EAP AKA [7] and EAP
        SRP-SHA1 [8] are methods that may be considered for Initial
        Authentication.
     
        Algorithms to derive session keys from Initial Authentication should
        also be specified. EAP-independent key-derivation algorithms are
        under development [9].
     
     
     6.2 Retransmission and timeout mechanisms
     
        The EAPoUDP protocol may require specific retransmission and timeout
        mechanisms being used as default for all messages. Specific (i.e.
        non-default) time-out and re-transmission mechanisms MAY be
        specified for selected EAPoUDP message types where user input (e.g.
        a password) is expected.
     
     
     7 Security Considerations
     
        EAPoUDP reuses existing EAP methods, but the multi-access, multi-hop
        environment it MAY operate in raises additional security threats.
        The final EAPoUDP specification MUST therefore further ensure that
        each EAPoUDP method can be used securely in this environment [10].
     
     
     IANA Considerations
     
        IANA need to assign a UDP port number for EAPoUDP.
     
     
     Acknowledgements
     
        ...
     
     
     References
     
     
     P. Engelstad             Expires August 2002                [Page 14]


                                  EAP over UDP                February 2002
     
     [1]  Engelstad, P., "Discovery Mechanism for PANA Authentication
           Agents (PAA-discovery)", <draft-engelstad-pana-paa-discovery-
           00.txt>, January 2002, Work in Progress.
     
     [2]  Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication
           Protocol", RFC 2284, March 1998.
     
     [3]  Blunk, L., Vollbrecht, J., and Aboba, B., "Extensible
           Authentication Protocol (EAP)", <draft-ietf-pppext-rfc2284bis-
           01.txt> (RFC2284bis), November 2001, Work in Progress.
     
     [4]  Aboba, B., Beadles, M. "The Network Access Identifier", RFC 2486,
           January 1999.
     
     [5]  Narten, T., and Draves, R., "Privacy Extensions for Stateless
           Address Autoconfiguration in IPv6", RFC 3041, January 2001.
     
     [6]  Tsirtis, G., "EAP over ICMP", <draft-tsirtis-eap-over-icmp-
           00.txt>, January 2002, Work in Progress.
     
     [7]  Arkko, J., Haverinen, H., "EAP AKA Authentication", <draft-arkko-
           pppext-eap-aka-01.txt>, November 2001, Work in Progress.
     
     [8]  Carlson, J., Aboba, B., Haverinen, H.,"EAP SRP-SHA1
           Authentication Protocol", <draft-ietf-pppext-eap-srp-03.txt>,
           July 2001, Work in Progress.
     
     [9]  Aboba, B., Simon, D. "The EAP Keying Problem", <draft-aboba-
           pppext-key-problem-01.txt>, February 2002, Work in Progress.
     
     [10] Yegin (ed.) et al., "Protocol for Carrying Authentication for
           Network Access (PANA) Requirements and Terminology", <draft-ietf-
           pana-requirements-00.txt>, February 2002, Work in Progress.
     
     
     Author's Address
     
        Paal E. Engelstad
        Telenor R&D (California)
        399 Sherman Ave. Suite #12
        Palo Alto, CA 94306, USA
     
        Tel.: + 1-650- 714 7537
        e-mail: paal@telenorisv.com
     
     
     
     
     
     P. Engelstad             Expires August 2002                [Page 15]
     

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