Subject: [eap] Re: resolution to issue 161

From: <[email-masked]>
Date: Tue, 21 Oct 2003 11:49:12 +0300

Hi,

I agree with you in that the demultiplexing can't (or at least
shouldn't) be done at the link layer in e.g. PPP, since it would
need to look inside the EAP packets (to check the Code field). 

More likely it's done by "something" between the link layer and
EAP state machines. Would simply changing "lower layer" to
"implementation" be sufficient?

Best regards,
Pasi

> -----Original Message-----
> From: Bernard Aboba
> Sent: Monday, October 20, 2003 9:20 PM
> To: [email-masked]
> Subject: [eap] Re: resolution to issue 161
> 
> > Add to state machine doc, section 2, before the last paragraph:
> >
> >  Some environments where EAP is used, such as PPP, may support
> >  peer-to-peer operation. That is, both parties act as peers and
> >  authenticators at the same time, in two simultaneous and
> >  independent EAP conversations. In this case, the lower layer to
> >  at each node has to perform demultiplexing of incoming EAP 
> >  packets. EAP packets with Code set to Response are delivered 
> >  to the Authenticator state machine, and all other EAP packets 
> >  are delivered to the Peer state machine.
> 
> What are the link layer requirements for support of EAP peer-to-peer
> operation?  I ask this because there is nothing in RFC 2248bis Section
> 2.4 or 3.1 that discusses these requirements.
> 
> For example, if there a requirement for the link layer to be
> able to demultiplex the EAP conversations in each direction,
> wouldn't that imply the need for a field in the link layer
> header with which to do this demultiplexing?  For example,
> IPv4/IPv6 packets are demultiplexed by different EtherType
> values, not really by the IP version number.
> 
> In Section 3.2.1 of RFC 2284bis the PPP Authentication
> Protocol format is defined.  EAP packets are encapsulated with
> an Authentication Protocol value of C227 (Hex).  Similarly, in
> IEEE 802.1X an Ethertype is assigned to 802.1X
> packets. Neither of these encapsulations can demultiplex EAP
> conversations occurring in different directions.  For example,
> there is no different Authentication Protocol value or
> Ethertype for this.
> 
> Since neither of these encapsulations demultiplexes EAP
> conversations in either direction, and the link layer does not
> look at frames deeper in the packet, such as the EAP Code or
> Type fields, I don't think that this explanation can be
> correct. If there is demultiplexing, then this would need to
> occur in the EAP layer, not in the link layer, no?
> 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Oct 2003 10:54:13 -0700 (PDT)

I think this is sufficient for the State Machine spec.  But I think we may
also need to change some text and possibly a figure in RFC 2284bis to
make it more clear.

For example, if multiplexing occurs on the "Code" field then it implies
that an "EAP peer" listener within an EAP implementation will not receive
EAP packets with Code=2 (Response) (but packets for all other Codes,
including 1, 3, 4).  Similarly, the "EAP server" listener will only
recieve EAP packets with Code=2 (Request). The implementation behavior
therefore differs based on whether there is an "EAP peer" or "EAP server"
listener present, or both.

This is a bit different than the behavior implied by RFC 2284bis as
where it is implied that an "EAP peer" will silently discard a
received EAP-Response packet.  If there is no "EAP server" listener
on the receiving host, or if there is but the EAP method only supports
"EAP peer" functionality, then silent discard will occur.  However if
there is an "EAP server" listener, and an EAP method registered with "EAP
server" functionality, then the EAP-Response might be processed.

There is therefore some implied multiplexing that occurs based on the Code
field, prior to the Type multiplexing which occurs later.  This is not
shown on the diagrams.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 26 Oct 2003 18:14:54 +0200

> I think this is sufficient for the State Machine spec.  But I think we may

Agreed.

> listener present, or both.

Right.

I'm happy with your proposed text from yesterday. Some comments inline
though:

> 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.  It is possible for a host to act as both
>        EAP peer and authenticator, and in this case 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 is used 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.

Since the EAP peer/auth listener terms are used in the below text
a number of times, do we need a definition for them?

>    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.
> 
>    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 an authenticator operates as a pass-through, it forwards
>    packets back and forth between the peer and a backend authentication
>    server, based on the EAP layer header fields (Code, Identifier,
>    Length).  This includes performing checks on the Code,
>    Identifier and Length fields, as described in Section 4.1.
> 
>    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.  Pass-through authenticator
>    implementations MUST support forwarding Response (Code=2)
>    packets to the backend authentication server, and receiving
>    EAP Request (Code=1), Success (Code=3) and Failure (Code=4) packets
>    from the backend authentication server.  Implementations  MAY be
>    capable of forwarding Request (Code=1), Success (Code=3) and
>    Failure (Code=4) packets to the backend authentication server, and
>    receiving EAP Response (Code=2) packets from the backend authentication
>    server.
> 
>    Where the pass-through device implements an EAP peer listener,
>    it will not forward to the backend authentication server
>    EAP Request (Code=1), Success (Code=3) or Failure (Code=4)
>    packets in order to act on them locally.  The use of the
>    RADIUS protocol for encapsulation of EAP in pass-through
>    operation is described in [RFC3579].

I had to read the above paragraph a few times to understand
what you are saying. So this is an EAP peer-side passthrough?
Or an EAP passthrough authenticator with an EAP peer side to
the other direction?

Anyway, I don't have any change request. Except maybe that
talking about peer-side passthroughs and RFC 3579 in the
same paragraph may be misleading, given that it only supports
authenticator side passthrough. At least break the last sentence
into its own paragraph.

> 
>               Peer     Pass-through Authenticator  Authentication
>                                                        Server
> 
>          +-+-+-+-+-+-+                             +-+-+-+-+-+-+
>          |           |                             |           |
>          |EAP method |                             |EAP method |
>          |     V     |                             |     ^     |
>          +-+-+-!-+-+-+                             +-+-+-!-+-+-+
>          |     !     |                             |     !     |
>          |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.
> 
>    Although EAP supports peer-to-peer operation, selected EAP 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 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.

Maybe put the EAP-TLS after this paragraph?

>    AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP
>    [DIAM-EAP] only support "passthrough" operation on behalf of an
>    authenticator, not a peer.  As noted in [RFC3579] Section
>    2.6.2, a RADIUS server responds to an Access-Request encapsulating an
>    EAP-Request with an Access-Reject.
> 
>    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.

Otherwise your text looks very good. THanks!

--Jari