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

This looks very nice to me as well.  -- john
--On Monday, October 27, 2003 5:13 PM -0500 Nick Petroni 
<npetroni [at] cs.umd.edu> wrote:
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
>
_______________________________________________
eap mailing list
eap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/eap

Re: Re: proposed resolution to Issue 161 -- Take Three	<– Date –> <– Thread –>
From: John Vollbrecht (jrvumich.edu)
Date: Mon, 27 Oct 2003 16:18:37 -0600 (CST)

eap Mailing List
View Index by: Date - Thread - Author