| Re: Re: proposed resolution to Issue 161 -- Take Three | <– Date –> <– Thread –> |
From: Nick Petroni (npetroni cs.umd.edu)
|
|
| Date: Mon, 27 Oct 2003 14:22:28 -0600 (CST) | |
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
>
-
Re: proposed resolution to Issue 161 -- Take Three Bernard Aboba, October 26 2003
- Re: Re: proposed resolution to Issue 161 -- Take Three Nick Petroni, October 27 2003
-
Re: Re: proposed resolution to Issue 161 -- Take Three Bernard Aboba, October 27 2003
- Re: Re: proposed resolution to Issue 161 -- Take Three Nick Petroni, October 27 2003
- Re: Re: proposed resolution to Issue 161 -- Take Three John Vollbrecht, October 27 2003
Results generated by Tiger Technologies using MHonArc.