| Re: Re: proposed resolution to Issue 161 -- Take Three | <– Date –> <– Thread –> |
From: Bernard Aboba (aboba internaut.com)
|
|
| Date: Mon, 27 Oct 2003 15:37:16 -0600 (CST) | |
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 > > > >
-
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
-
Re: Re: proposed resolution to Issue 161 -- Take Three Nick Petroni, October 27 2003
Results generated by Tiger Technologies using MHonArc.