eap Mailing List: Re: Re: proposed resolution to Issue 161 -- Take Three

[Nick Petroni (npetroni]

sounds like a plan.

Thanks,
nick

Nick L. Petroni, Jr.
Graduate Student, Computer Science
Maryland Information Systems Security Lab
University of Maryland
http://www.cs.umd.edu/~npetroni

On Mon, 27 Oct 2003, Bernard Aboba wrote:

> Yes, I think your diagram says it best.  Mind if I steal it? :)
>
> On Mon, 27 Oct 2003, Nick Petroni wrote:
>
> > Thanks Bernard. I think this makes more sense and I like this more. The
> > diagram I was trying to describe previously looks something like the
> > following, but I am happy with yours as it reads.
> >
> > thanks,
> > nick
> >
> >
> >            Peer        Pass-through Authenticator    Authentication
> >                                                          Server
> >
> >       +-+-+-+-+-+-+                                   +-+-+-+-+-+-+
> >       |           |                                   |           |
> >       |EAP method |                                   |EAP method |
> >       |     V     |                                   |     ^     |
> >       +-+-+-!-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-!-+-+-+
> >       |     !     |   |EAP  |  EAP  |             |   |     !     |
> >       |     !     |   |Peer |  Auth.| EAP Auth.   |   |     !     |
> >       |EAP  ! peer|   |     | +-----------+       |   |EAP  !Auth.|
> >       |     !     |   |     | !     |     !       |   |     !     |
> >       +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
> >       |     !     |   |       !     |     !       |   |     !     |
> >       |EAP  !layer|   |   EAP !layer| EAP !layer  |   |EAP  !layer|
> >       |     !     |   |       !     |     !       |   |     !     |
> >       +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
> >       |     !     |   |       !     |     !       |   |     !     |
> >       |Lower!layer|   |  Lower!layer| AAA ! /IP   |   | AAA ! /IP |
> >       |     !     |   |       !     |     !       |   |     !     |
> >       +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
> >             !                 !           !                 !
> >             !                 !           !                 !
> >             +-------->--------+           +--------->-------+
> >
> >
> >
> > On Sun, 26 Oct 2003, Bernard Aboba wrote:
> >
> > > Nick --
> > >
> > > Thought about this a bit more.  Given that the Code field allows the EAP
> > > layer to demultiplex packets destined to an authenticator versus peer
> > > listener, a "pass-through authenticator" will only receive EAP
> > > packets destined for the authenticator listener, that is, packets
> > > with Code=2 (Response). Unless the NAS also has a peer listener,
> > > it will silently discard packets with other Code values.  Since
> > > RADIUS and Diameter do not support a "pass-through peer", there
> > > is no way in practice that EAP packets of Codes other than 2 can be
> > > forwarded to the backend authentication server.
> > >
> > > Here is another pass at the text in an attempt to get this straight.
> > >
> > > Bernard
> > >
> > >
> > > 2.2 EAP multiplexing model
> > >
> > >    Conceptually, EAP implementations consist of the following
> > >    components:
> > >
> > >    [a] Lower layer.  The lower layer is responsible for transmitting and
> > >        receiving EAP frames between the peer and authenticator.  EAP has
> > >        been run over a variety of lower layers including PPP; wired IEEE
> > >        802 LANs [IEEE-802.1X]; IEEE 802.11 wireless LANs [IEEE-802.11];
> > >        UDP (L2TP [RFC2661] and IKEv2 [IKEv2]); and TCP [PIC]. Lower
> > >        layer behavior is discussed in Section 3.
> > >
> > >    [b] EAP layer.  The EAP layer receives and transmits EAP packets via
> > >        the lower layer, implements duplicate detection and
> > >        retransmission, and delivers and receives EAP messages to and
> > >        from the EAP peer and authenticator layers.
> > >
> > >    [c] EAP peer and authenticator layers.  Based on the Code field, the
> > >        EAP layer demultiplexes incoming EAP packets to the EAP peer and
> > >        authenticator layers.  Typically an EAP implementation on a given
> > >        host will support either peer or authenticator functionality,  but
> > >        it is possible for a host to act as both an EAP peer and
> > >        authenticator.  In such an implementation both EAP peer and
> > >        authenticator layers will be present.
> > >
> > >    [d] EAP method layers.  EAP methods implement the authentication
> > >        algorithms and receive and transmit EAP messages via the EAP peer
> > >        and authenticator layers.  Since fragmentation support is not
> > >        provided by EAP itself, this is the responsibility of EAP methods,
> > >        which are discussed in Section 5.
> > >
> > >    The EAP multiplexing model is illustrated in Figure 1 below. Note
> > >    that there is no requirement that an implementation conform to this
> > >    model, as long as the on-the-wire behavior is consistent with it.
> > >
> > >          +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
> > >          |           |           |  |           |           |
> > >          | EAP method| EAP method|  | EAP method| EAP method|
> > >          | Type = X  | Type = Y  |  | Type = X  | Type = Y  |
> > >          |       V   |           |  |       ^   |           |
> > >          +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
> > >          |       !               |  |       !               |
> > >          |  EAP  ! Peer layer    |  |  EAP  ! Auth. layer   |
> > >          |       !               |  |       !               |
> > >          +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
> > >          |       !               |  |       !               |
> > >          |  EAP  ! layer         |  |  EAP  ! layer         |
> > >          |       !               |  |       !               |
> > >          +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
> > >          |       !               |  |       !               |
> > >          | Lower ! layer         |  | Lower ! layer         |
> > >          |       !               |  |       !               |
> > >          +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
> > >                  !                          !
> > >                  !   Peer                   ! Authenticator
> > >                  +------------>-------------+
> > >
> > >                     Figure 1: EAP Multiplexing Model
> > >
> > >    Within EAP, the Code field functions much like a protocol number in
> > >    IP.  It is assumed that the EAP layer demultiplexes incoming EAP
> > >    packets according to the Code field.  Received EAP packets
> > >    with Code=1 (Request), 3 (Success) and 4 (Failure) are
> > >    delivered by the EAP layer to the EAP peer listener, if
> > >    present.  EAP packets with Code=2 (Response) are delivered
> > >    to the EAP authenticator listener, if present.
> > >
> > >    Within EAP, the Type field functions much like a port number in UDP
> > >    or TCP.  It is assumed that the EAP peer and authenticator layers
> > >    demultiplex incoming EAP packets according to their Type, and deliver
> > >    them only to the EAP method corresponding to that Type.  An
> > >    EAP method implementation on a host may register to receive
> > >    packets from the peer or authenticator listener, or both.
> > >
> > >    Since EAP authentication methods may wish to access the Identity,
> > >    implementations SHOULD make the Identity Request and Response
> > >    accessible to authentication methods (Types 4 or greater) in addition
> > >    to the Identity method.  The Identity Type is discussed in Section
> > >    5.1.
> > >
> > >    A Notification Response is only used as confirmation that the peer
> > >    received the Notification Request, not that it has processed it, or
> > >    displayed the message to the user.  It cannot be assumed that the
> > >    contents of the Notification Request or Response is available to
> > >    another method.  The Notification Type is discussed in Section 5.2.
> > >
> > >    Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes
> > >    of method negotiation.  Peers respond to an initial EAP Request for
> > >    an unacceptable Type with a Nak Response (Type 3) or Expanded Nak
> > >    Response (Type 254). It cannot be assumed that the contents of the
> > >    Nak Response(s) are available to another method.  The Nak Type(s) are
> > >    discussed in Section 5.3.
> > >
> > >    EAP packets with codes of Success or Failure do not include a Type
> > >    field, and are not delivered to an EAP method.  Success and Failure are
> > >    discussed in Section 4.2.
> > >
> > >    Given these considerations, the Success, Failure, Nak Response(s) and
> > >    Notification Request/Response messages MUST NOT be used to carry data
> > >    destined for delivery to other EAP methods.
> > >
> > > 2.3 Pass-through behavior
> > >
> > >    Where operating as a "pass-through authenticator"  an
> > >    authenticator forwards EAP packets destined to its authenticator
> > >    listener to the backend authentication server, and forwards
> > >    packets received from the backend authentication server to the
> > >    peer.
> > >
> > >    The forwarding decision is based on examination of the
> > >    Code, Identifier and Length fields.  Since a "pass-through
> > >    authenticator" only forwards EAP packets destined for its
> > >    authenticator listener, pass-through authenticator
> > >    implementations MUST forward Response (Code=2) packets
> > >    to the backend authentication server.  They also MUST be
> > >    capable of receiving and forwarding to the peer Request
> > >    (Code=1), Success (Code=3) and Failure (Code=4) packets.
> > >
> > >    Since pass-through authenticators rely on a backend authenticator
> > >    server to implement methods, the EAP method layer header fields
> > >    (Type, Type-Data) are not examined as part of the forwarding
> > >    decision, except where the authenticator implements one or more
> > >    authentication methods locally.  In this case, the authenticator
> > >    may examine the Type field to determine whether to act on the
> > >    packet itself or forward it.
> > >
> > >    The forwarding model is illustrated in Figure 2. Compliant
> > >    pass-through authenticator implementations MUST by default
> > >    forward EAP packets of any Type.
> > >
> > >    Since EAP packets received with Code=1 (Request), Code=3 (Success),
> > >    and Code=4 (Failure) are demultiplexed by the EAP layer and
> > >    delivered to the peer listener,  unless a NAS implements
> > >    an EAP peer listener, these packets will be silently
> > >    discarded.  Since the behavior of a "pass-through peer" is
> > >    undefined, where an EAP peer listener is implemented, the
> > >    NAS will typically act on these packets locally.
> > >
> > >    The use of the  RADIUS protocol for encapsulation of EAP in
> > >    pass-through operation is described in [RFC3579].
> > >
> > >
> > >               Peer     Pass-through Authenticator  Authentication
> > >                                                        Server
> > >
> > >          +-+-+-+-+-+-+                             +-+-+-+-+-+-+
> > >          |           |                             |           |
> > >          |EAP method |                             |EAP method |
> > >          |     V     |                             |     ^     |
> > >          +-+-+-!-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-!-+-+-+
> > >          |     !     |  |           |           |  |     !     |
> > >          |     !     |  |EAP Auth.  | EAP Auth. |  |     !     |
> > >          |EAP  ! peer|  |     +-----------+     |  |EAP  !Auth.|
> > >          |     !     |  |     !     |     !     |  |     !     |
> > >          +-+-+-!-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-!-+-+-+
> > >          |     !     |  |     !     |     !     |  |     !     |
> > >          |EAP  !layer|  |EAP  !layer| EAP !layer|  |EAP  !layer|
> > >          |     !     |  |     !     |     !     |  |     !     |
> > >          +-+-+-!-+-+-+  +-+-+-!-+-+-+-+-+-!-+-+-+  +-+-+-!-+-+-+
> > >          |     !     |  |     !     |     !     |  |     !     |
> > >          |Lower!layer|  |Lower!layer| AAA ! /IP |  | AAA ! /IP  |
> > >          |     !     |  |     !     |     !     |  |     !     |
> > >          +-+-+-!-+-+-+  +-+-+-!-+-+-+-+-+-!-+-+-+  +-+-+-!-+-+-+
> > >                !              !           !              !
> > >                !              !           !              !
> > >                +-------->-----+           +------->------+
> > >
> > >                   Figure 2: Pass-through Authenticator
> > >
> > >    For sessions in which the authenticator acts as a pass-through, it
> > >    MUST determine the outcome of the authentication solely based on the
> > >    Accept/Reject indication sent by the backend authentication server;
> > >    the outcome MUST NOT be determined by the contents of an EAP packet
> > >    sent along with the Accept/Reject indication, or the absence of such
> > >    an encapsulated EAP packet.
> > >
> > > 2.4 Peer-to-Peer Operation
> > >
> > >    Since EAP is a peer-to-peer protocol, an independent and simultaneous
> > >    authentication may take place in the reverse direction (depending on
> > >    the capabilities of the lower layer).  Both peers may act as
> > >    authenticators and authenticatees at the same time;  in this case it
> > >    is necessary to both peers to implement both EAP authenticator and
> > >    peer listeners.  In addition, the EAP method implementations on
> > >    both peers must support both authenticator and peer functionality.
> > >
> > >    Although EAP supports peer-to-peer operation, some EAP
> > >    implementations, methods, AAA protocols and link layers may not
> > >    support this.  For example, EAP-TLS [RFC2716] is a client-server
> > >    protocol requiring a different certificate profile for the client and
> > >    server.  This implies that a host supporting both the EAP-TLS peer and
> > >    authenticator roles would need to implement both peer and
> > >    authenticator listeners;  would need to support both the peer and
> > >    authenticator roles in the EAP-TLS implementation;  would need to be
> > >    provisioned with two distinct certificates, one appropriate for each
> > >    role.
> > >
> > >    Some EAP methods may support asymmetric authentication, with one type
> > >    of credential being required for the peer and another type for the
> > >    authenticator.  Hosts supporting peer-to-peer operation with such a
> > >    method would  need to be provisioned with both types of credentials.
> > >
> > >    AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP
> > >    [DIAM-EAP] only support "passthrough authenticator" operation.
> > >    As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an
> > >    Access-Request encapsulating an EAP-Request, Success or Failure
> > >    packet with an Access-Reject.  There is therefore no support for
> > >    "passthrough peer" operation.
> > >
> > >    Link layers such as IEEE 802.11 may only support uni-directional
> > >    derivation and transport of transient session keys.  For example, the
> > >    group-key handshake defined in [IEEE-802.11i] is uni-directional,
> > >    since in IEEE 802.11 only the Access Point (AP) sends multicast
> > >    traffic.  This means that in ad-hoc operation where either peer may
> > >    send multicast traffic, two uni-directional group-key exchanges are
> > >    required.  Due to constraints imposed by the 4-way unicast key
> > >    handshake state machine, this also implies two 4-way handshake and
> > >    EAP method exchanges.
> > >
> > >    Link layers such as IEEE 802.11 adhoc also do not support "tie
> > >    breaking" wherein two hosts initiating authentication with each other
> > >    will only go forward with a single authentication.  This implies that
> > >    even if 802.11 were to support a bi-directional group-key handshake,
> > >    then two authentications, one in each direction, might still occur.
> > > _______________________________________________
> > > eap mailing list
> > > eap [at] frascone.com
> > > http://mail.frascone.com/mailman/listinfo/eap
> > >
> >
> >
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>