Issue 200: Endpoint verification
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: Nov 17, 2003
Reference: http://mail.frascone.net/pipermail/public/eap/2003-November/001845.html
Document: RFC2284bis-06
Comment type: T
Priority: S
Section: 5, 7
Rationale/Explanation of issue:

The Security Claims section doesn't include a claim for
a solution to the "Lying NAS" problem, and this attack
is not included in the threat model either.

Add to sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 the following
security claim:

Endpoint verification: No

Add to Section 7.1:

[10] An attacker acting as an authenticator may provide
inconsistent information to the EAP peer
and server. This includes impersonating another
authenticator, or communicating incorrect information
via out-of-band mechanisms such as via
a AAA or lower layer protocol.

Add Section 7.15:

7.15 Endpoint Verification

It is possible for a compromised or poorly implemented EAP
authenticator to communicate inconsistent information to
the EAP peer and server. This may enable an authenticator
to impersonate another authenticator or communicate
incorrect information via out-of-band mechanisms such as via a
AAA or lower layer protocol.

Where EAP is used in passthrough mode, the EAP peer typically
does not verify the identity of the authenticator, it
only verifies that the authenticator is trusted by the EAP
server. This lack of endpoint verification creates a potential
security vulnerability.

While [RFC3579] Section 4.3.7 describes how an EAP authenticator
providing incorrect information to a AAA server
(such as forged NAS-Identifier, NAS-IP-Address or NAS-IPv6-Address
attributes) can be detected, it is possible for the authenticator to provide
correct information to the AAA server while communicating
incorrect information to the EAP peer via a lower layer
protocol.

For example, it is possible for an authenticator to utilize another
authenticator's Called-Station-Id in communicating with
the EAP peer via a lower layer protocol, or for the authenticator to provide an incorrect
peer Calling-Station-Id to the AAA server via the AAA protocol.

In order to address this vulnerability, EAP methods may support
a protected exchange of endpoint identifiers, including
(but not limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
[RFC2865][RFC3580], NAS-Identifier, [RFC2865], NAS-IP-Address [RFC2865], and
NAS-IPv6-Address [RFC3162].

Using such an exchange, the EAP peer and server can match parameters
provided by the authenticator (such as endpoint identifiers) against those exchanged
within the EAP method. Where discrepancies exist, these SHOULD be logged.

Add to non-normative references:

[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.

[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IP6",
RFC 3162, August 2001.

[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J.
Roese, "IEEE 802.1X Remote Authentication Dial In User
Service (RADIUS) Usage Guidelines", RFC 3580,
September 2003.

Add the following definition to section 7.2.1:

Endpoint verification
The verification within an EAP method of endpoint
identifiers communicated out of band, such as via
a AAA or lower layer protocol.

[Joe Salowey] I'm a little worried about the usage of EAP server and AAA server
terminology.  I don't think that these two entities are the same thing.
An EAP-Server is typically embedded within the AAA server, but I don't
think that this has to be the case.  In particular the EAP-Server knows
how to execute EAP mechanisms, but it knows little or nothing about the
underlying application using EAP.  The underlying application is the
domain of the AAA server.

Also if discrepancies exist in the data provided to the AAA may it be
appropriate to take action beyond logging?

Replace:

"allowing the EAP server to match it against the
equivalent information provided by the authenticator via the
AAA protocol."

With

"allowing the EAP server to provide this information to the AAA
server to match it against the equivalent information provided
by the authenticator via the AAA protocol."

[Bernard Aboba] Here are the proposed fixes:

Add to sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 the following
security claim:

Channel Binding: No

Add the following definition to section 7.2.1:

Channel binding
The communication within an EAP method of integrity-protected channel properties
such as endpoint identifiers which can be compared to values communicated via out
of band mechanisms (such as via a AAA or lower layer protocol).

Add to Section 7.1:

[10] An attacker acting as an authenticator may provide incorrect
information to the EAP peer and/or server via out-of-band mechanisms
(such as via a AAA or lower layer protocol). This includes impersonating
another authenticator, or providing inconsistent information to the peer
and EAP server.

Add Section 7.15:

7.15 Channel binding

It is possible for a compromised or poorly implemented EAP
authenticator to communicate incorrect information to the EAP
peer and/or server. This may enable an authenticator
to impersonate another authenticator or communicate
incorrect information via out-of-band mechanisms (such as via a
AAA or lower layer protocol).

Where EAP is used in pass-through mode, the EAP peer typically
does not verify the identity of the pass-through authenticator, it
only verifies that the pass-through authenticator is trusted by the EAP
server. This creates a potential security vulnerability.

[RFC3579] Section 4.3.7 describes how an EAP pass-through authenticator
acting as a AAA client can be detected if it attempts to impersonate
another authenticator (such by sending incorrect NAS-Identifier [RFC2865],
NAS-IP-Address [RFC2865] or NAS-IPv6-Address [RFC3162] attributes
via the AAA protocol). However, it is possible for a pass-through
authenticator acting as a AAA client to provide correct information to
the AAA server while communicating misleading information to the EAP peer
via a lower layer protocol.

For example, it is possible for a compromised authenticator to utilize
another authenticator's Called-Station-Id or NAS-Identifier in
communicating with the EAP peer via a lower layer protocol, or for a
pass-through authenticator acting as a AAA client to provide an incorrect
peer Calling-Station-Id [RFC2865] [RFC3580] to the AAA server via the AAA protocol.

In order to address this vulnerability, EAP methods may support
a protected exchange of channel properties such as endpoint identifiers,
including (but not limited to): Called-Station-Id [RFC2865][RFC3580],
Calling-Station-Id [RFC2865][RFC3580], NAS-Identifier, [RFC2865],
NAS-IP-Address [RFC2865], and NAS-IPv6-Address [RFC3162].

Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. Where discrepancies are found,
these SHOULD be logged; additional actions MAY also be taken, such as
denying access.

Add to non-normative references:

[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.

[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IP6",
RFC 3162, August 2001.

[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J.
Roese, "IEEE 802.1X Remote Authentication Dial In User
Service (RADIUS) Usage Guidelines", RFC 3580,
September 2003.

Proposed resolution: Accept

Issue 201: Some NITs
Submitter name: Jose Puthenkulam
Submitter email address: jose.p.puthenkulam@intel.com
Date first submitted: Nov 17, 2003
Reference: http://mail.frascone.net/pipermail/public/eap/2003-November/001814.html
Document: RFC2284bis-06
Comment type: E
Priority: 1
Section: 7.2, 7.4
Rationale/Explanation of issue:

In section 7.2 [c]

Replace "acknowledged result indications" with "protected result
indications". It makes more sense to have the EAP method indicate its
result in a protected manner than making sure the result is
acknowledged.

Also for section 7.4 Man-in-the-middle attacks would it not be
appropriate to add an informative reference to the EAP Binding Draft and
the Nokia Mitm paper.

[Jose Puthenkulam] The resolution and changes look good.

[Jari Arkko]

Ok. The term is defined in 7.2.1, and the text already requires protection,
I agree that the name "protected result indications" would be appropriate.
Need to change the name then in both 7.2 and 7.2.1 as well as in a few
other places in the document...

> Also for section 7.4 Man-in-the-middle attacks would it not be
> appropriate to add an informative reference to the EAP Binding Draft and
> the Nokia Mitm paper.

Yes, this would be appropriate.
 

[BA] Proposed resolution:

Replace "acknowledged result indications" with "protected result indications" throughout the document.

In Section 7.4, change:

To:

Change:

[b] Requiring cryptographic binding between the EAP tunneling protocol and the tunneled EAP methods. Where cryptographic binding is supported, a mechanism is also needed to protect against downgrade attacks that would bypass it.

Proposed resolution: Accept

Issue 202: Peer-to-peer cleanup
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: Nov 19, 2003
Reference:
Document: RFC2284bis-06
Comment type: E
Priority: 1
Section: 2.2, 2.3, 2.4, 7.2.1
Rationale/Explanation of issue:

This is an issue to cleanup wording on peer-to-peer topics.  This responds to issues raised by Jari Arkko relating to the term "peer listener" and "authenticator listener".  On rethinking the terminology it appears to me that the terms "peer layer" and "authenticator layer" serve just as well.

In Section 2.2, change:

"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."

To:

"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 layer, if implemented. EAP packets with Code=2 (Response) are delivered to the EAP authenticator layer, if implemented.

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 layers, or both, depending on which role(s) it supports."

In Section 2.3, change:

"When operating as a "pass-through authenticator", an authenticator performs checks on the Code, Identifier and Length fields as described in Section 4.1. It forwards EAP packets received from the peer and destined to its authenticator listener to the backend authentication server; packets received from the backend authentication server destined to the peer are forwarded to it.

The forwarding decision is based on examination of the Code, Identifier and Length fields. Since a "pass-through authenticator" only forwards to the backend authentication server EAP packets received from the peer and destined for its authenticator listener, pass-through authenticator implementations MUST be capable of forwarding to the backend authentication server EAP packet received from the peer with Code=2 (Response). They also MUST be capable of receiving EAP packets from the backend authentication server and forwarding EAP packets of Code=1 (Request), Code=3 (Success), and Code=4 (Failure) to the peer.

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. Compliant pass-through authenticator implementations MUST be default forward EAP packets of any Type. The forwarding model is illustrated in Figure 2.

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 host implements an EAP peer listener, these packets will be silently discarded. The behavior of a "pass-through peer" is undefined within this specification, and is unsupported by AAA protocols such as RADIUS[RFC3579] and Diameter[DIAM-EAP]. "

To:

"When operating as a "pass-through authenticator", an authenticator performs checks on the Code, Identifier and Length fields as described in Section 4.1. It forwards EAP packets received from the peer and destined to its authenticator layer to the backend authentication server; packets received from the backend authentication server destined to the peer are forwarded to it.

A host receiving an EAP packet may only do one of three things with it: act on it, drop it, or forward it.  The forwarding decision is typically based only on examination of the Code, Identifier and Length fields.  A pass-through authenticator implementation MUST be capable of forwarding to the backend authentication server EAP packets received from the peer with Code=2 (Response). It also MUST be capable of receiving EAP packets from the backend authentication server and forwarding EAP packets of Code=1 (Request), Code=3 (Success), and Code=4 (Failure) to the peer.

Unless the authenticator implements one or more authentication methods locally which support the authenticator role, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision.  Where the authenticator supports local authentication methods, it MAY examine the Type field to determine whether to act on the packet itself or forward it. Compliant pass-through authenticator implementations MUST by default forward EAP packets of any Type.

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 layer.  Therefore unless a host implements an EAP peer layer, these packets will be silently discarded.  Similarly, EAP packets received with Code=2 (Response) are demultiplexed by the EAP layer and delivered to the authenticator layer. Therefore unless a host implements an EAP authenticator layer, these packets will be silently discarded.  The behavior of a "pass-through peer" is undefined within this specification, and is unsupported by AAA protocols such as RADIUS[RFC3579] and Diameter[DIAM-EAP].

The forwarding model is illustrated in Figure 2."

In Section 2.4, change:

"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."

To:

"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 which case it is necessary for both peers to implement EAP authenticator and peer layers. 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.  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.

For example, EAP-TLS[RFC2716] is a client-server protocol with a different certificate profile for the client and server. This implies that a host supporting peer-to-peer authentication with EAP-TLS would need to implement both the EAP peer and authenticator layers; support both peer and authenticator roles in the EAP-TLS implementation;  and provision two distinct certificates, one appropriate for each role."

Proposed resolution: Accept

Issue 203: Peer SM Comments
Submitter name: Joe Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted: 11/20/2003
Reference:  http://mail.frascone.net/pipermail/public/eap/2003-November/001869.html
Document:  State Machine
Comment type: E/T
Priority: 1
Section: 4.x
Rationale/Explanation of issue:

1. portEnabled

portEnabled seems very .1x/PPP specific.  EAP is being used in cases
such as IKE and PANA where this concept may a bit more abstract.
Perhaps we can change the name of the variable and/or expand its
definition to include other cases. 

Suggestion:
Perhaps "indicates that a lower layer communcation channel has been
established".

[npetroni] this is fine for me. the name is not really of importance to me
so I would just as soon leave it the same. If others think a name change
is necessary it's fine. I like the definition change.

2. EAPTunneled

The behavior inside tunnels needs to be defined by the tunnel as there
are several ways you can handle EAP within a tunnel.  I think we decided
to remove this variable at the meeting, but I want to mae sure we track
it.  In PEAPv2 we started out with a behavior similar to what is
described in the state machine,  but in order to make sure the policy on
the peer and authenticator stayed in sync we introduced itermediate
result indicators which I think change the state machine a little.

Suggestion:
Remove variable.  We could explore this in an apppendix or a separate
document.

[npetroni] previously disussed. I agree it should be removed.

3. Interface to method

The interface to the method seems too complicated. 

First I don't think that intCheck should be a different process.
Integrity checking is done as part of the method processing.  Also
methods aren't required to ingore packets, some methods with ignore some
problems and return errors on others.  I think this behavior should be
incorporated into m.process.

[npetroni] intCheck is needed because SOMETIMES a method will decide not
to use the packet at all. in this case, intCheck is the way the method
tells the SM it will not be using that packet. Methods with other ways of
dealing with this will just not set intCheck to be true.

On a separate but related note it seems that the method state and
decision is very complex. I don't really see the need for the
independent methodState and decision variables.  M.process() should
return one of serverl possible results: IGNORE, CONTINUE, COND_SUCCESS,
SUCCESS, FAILURE.  MethodState should be able to take on CONTINUE,
COND_SUCCESS, SUCCESS, FAILURE.  I don't think a separate decision
variable is necessary.

[npetroni] This is meant to show that a method really has its own state
machine and that these states are separate from the final decision. I
think it provides nice way of separating the two, but I am willing to
discuss this alternative notation.

Suggestion

In method:

methodResult = m.process(eapRespData)
If (methodResult != IGNORE)
{
   methodState = methodResult
   allowNotifications = TRUE|FALSE
   eapRespData = m.buildResponse(reqID)
   if (methodState == SUCCESS || methodState == COND_SUCCESS)
   {
eapKeyData = NONE|m.getKey()
   }
}

Transition to discard: (methodResult == IGNORE)
Combine methodState and decision transition conditions

4. Idle timer

It seems that there is a problem with the idle timer.  It would be
possible for the peer to never time out if it keeps on receiving packets
that it discards.  This is not so good. 

[npetroni] hmm, that seems like a trivial DoS, no? Send enough bad packets
to the Peer and it goes away for a while?

Suggestion:

Perhaps the client timeout should be set outside the IDLE state in the
INITIALIZE state and in the METHOD or SEND_RESPONSE state.

5.  rxSuccess and rxFailure

Shouldn't rxSuccess and rxFailure check to see if (reqId == lastReqID)?

[npetroni] probably so. I think this should be added.

[Joe Salowey] Int check should be internal to the method.

[Nick Petroni] intCheck IS set by an internal method, m.integrityCheck().

[Joe Salowey] It should be possible for the method to signal that a packet should be ignored.  I think
breaking it out like this is misleading. 

[npetroni] I would say it IS possible for the method to signal that a
packet should be ignored just by setting intCheck. Perhaps it's the name
you just don't like? I don't see how this is any different from how it
works now

[Joe Salowey] I agree that a method has its own state machine, however I think
exposing it here creates some problems.  First it complicates the EAP
state machine and second the internal state machine of the method will
vary from method to method. 

[npetroni] This is not exposing the ACTUAL method state machine (IMHO),
just a minimal set of signals that need to be exported. There could be
more.

[Joe Salowey] I think it would be best to make the method
opaque as possible and use the minimal interface between method and EAP
state machines.

[npetroni] Perhaps the notation is confusing to some, I don't think it is
overly complex. Author's bias perhaps? I am open to changing it, but I
guess I still don't understand the argument completely. I would love to
get additional input- any consensus from the group would be great.
 

>  It seems that there is a problem with the idle timer.  It would be
> possible for the peer to never time out if it keeps on receiving
> packets that it discards.  This is not so good.
> [npetroni] hmm, that seems like a trivial DoS, no? Send
> enough bad packets to the Peer and it goes away for a while?
[npetroni] I guess I am responding to my own comment here, but I went back
and read your original thoughts on this and I think I see your point now.
I misread where you thought the timer should be set. I think there could
be a good argument for moving the idleWhile setting to INITIALIZE and
SEND_RESPONE. I don't think it should be in METHOD just for abstraction.
Besides, you would have to do it conditionally in METHOD anyway. Are
there other opinions on this? The problem comes down to bad packets
resetting the client timeout such that the peer can still go
ClientTimeout without receiving a good packet and yet not timeout. I
guess the question is does the timeout go between GOOD packets or just
packets? I see no reason why this is explicitly a peer problem. Wouldn't
the authenticator work the same?

Thanks for the feedback- anything that helps make the document more
understandable (and more correct :) ) is a good thing.
 

[Yoshi Ohba] On the other hand, the other role of the EAP state machines
document is to help implementers understand how RFC2284bis
works.  I think describing the peer state machine by using
the two variables (i.e., methodState and decision) helps us
understand Implementation Note in Section 4.2 of RFC2284bis
pretty well.

[Joe Salowey] I find it more confusing than enlightening.  I think the two
variables introduce a lot of complexity.  If you want to describe the
internal workings of the EAP-Method you should have a different state
machine for that. 

[Yoshi Ohba]

> So, I would suggest keeping the currnet state machine as it
> is (i.e., use methodState and decision variables), but adding
> the following statement in "Implementation Consideration" section:
>
>   "In the peer state machine, implementations may integrate
>   methodState and decision variables into a single variable that
>   may be obtained as a return value of m.process() method procedure."
>
[Joe Salowey] I would rather see the EAP state machine simple and have text
describe how a method may implement its internal state machine.  I also
think m.intCheck should be integrated into m.process() as well. 

[Yoshi Ohba]

> I agree that in both peer and authenticator state machines it
> is not good to reset the timer value when the received
> message is discarded.
>
> On the other hand, the peer idle timer should be set only
> once in INITIALIZE state and should not be reset anywhere
> else.  This is because (correct me if I am wrong) the idle
> timer for authenticator and the idle timer for peer are used
> for different purposes.  The former timer is message
> retranmission timer and the latter timer is authentication
> session timeout timer.
>

[Joe Salowey] I think I agree, I haven't had a chance to take a close look at
the authenticator side of the state machine, but I think you are
correct.

Proposed resolution: Discuss

Issue 204: Peer-to-peer operation
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 11/24/2003
Reference:  https://mail.windows.microsoft.com/exchweb/bin/redir.asp?URL=http://www.ieee802.org/1/files/private/x-REV-drafts/d7/802-1X-rev-d7-1-dis.pdf (See disposition of comment 15)
Reference: http://mail.frascone.net/pipermail/public/eap/2003-November/001896.html
Document: SM-01
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

As noted in the IEEE 802.1XD7.1 ballot resolution, comment 15, the current
EAP SMs do not fully support peer-to-peer operation.

The current EAP Peer SM does not provide a mechanism for the EAP method to
signal to EAP and the lower layer that mutual authentication has been
achieved.

In addition, the EAP authenticator SM does not provide a mechanism for the
EAP layer to indicate to the lower layer that a protected result
indication has been received from the peer, indicating that the peer has
authenticated the authenticator.

Similarly, the EAP Peer SM does not provide a mechanism for the EAP layer
to indicate to the lower layer that a protected result indication has been
received from the authenticator, indicating that the Authenticator has
authenticated the peer.

As a result of these missing indications, it is not possible for EAP to
provide for mutual opening of the 802.1X controlled ports for use in
peer-to-peer operation, even where a method providing for protected result
indications is in use.

[Nick Petroni] > As noted in the IEEE 802.1XD7.1 ballot resolution, comment 15, the current
> EAP SMs do not fully support peer-to-peer operation.

I am not completely convinced of this. It seems to me what you are asking
for here is for EAP to provide two signals indicating the success of
authentication in each direction. This is not how I read the model of
2284bis. I would argue that the use of a method providing mutual
authentication still requires EAP to provide only one answer to
the conversation. It is possible to require mutual authentication before
Success and even to guarantee that answer with protection, but I do not
see a reason for the lower layer to get an explicit "mutual
authentication" signal. If mutual authentication is required and it was
not obtained then success (the signal, not the packet) will never follow
for a properly configured peer.

> The current EAP Peer SM does not provide a mechanism for the EAP method to
> signal to EAP and the lower layer that mutual authentication has been
> achieved.
I disagree. If you require mutual authentication then EAP Success is this
indication.

> In addition, the EAP authenticator SM does not provide a mechanism for the
> EAP layer to indicate to the lower layer that a protected result
> indication has been received from the peer, indicating that the peer has
> authenticated the authenticator.
hmm, this one is slightly more interesting, but I have no idea how the
backend would ever alert the passthrough of this. Still, I think it is
possible to say that if mutual authentication is required and not
achieved then the decision will be fail.

> Similarly, the EAP Peer SM does not provide a mechanism for the EAP layer
> to indicate to the lower layer that a protected result indication has been
> received from the authenticator, indicating that the Authenticator has
> authenticated the peer.
I disagree with  this too. 2284bis states that the only thing which can
follow a protected success/failure is an unprotected version of the same.
The EAP Success indication is therefore sufficient to indicated succes. If
a protected indication is required the peer policy should reflect this and
the SUCCESS state will not be reached until it comes.

I disagree that peer-to-peer is not supported. I would agree that the
specific interface is not provided for two signals, but I would like to
understand better why those signals are needed. Also, a suggestion for
where these signals would go and who sets them might help me understand
this issue better.

[Bernard Aboba]

> > As noted in the IEEE 802.1XD7.1 ballot resolution, comment 15, the current
> > EAP SMs do not fully support peer-to-peer operation.
>
> I am not completely convinced of this. It seems to me what you are asking
> for here is for EAP to provide two signals indicating the success of
> authentication in each direction. This is not how I read the model of
> 2284bis. I would argue that the use of a method providing mutual
> authentication still requires EAP to provide only one answer to
> the conversation. It is possible to require mutual authentication before
> Success and even to guarantee that answer with protection, but I do not
> see a reason for the lower layer to get an explicit "mutual
> authentication" signal. If mutual authentication is required and it was
> not obtained then success (the signal, not the packet) will never follow
> for a properly configured peer.

That makes sense to me, because the peer would not accept the access
offered by the authenticator otherwise.  However, the response to IEEE
802.1X D7.1 comment 15 suggests that something further is needed. I'm not clear
what this is, but I'm suggesting that we need to be clear on why this is
not required (and note this explicitly in the SM document).

> > The current EAP Peer SM does not provide a mechanism for the EAP method to
> > signal to EAP and the lower layer that mutual authentication has been
> > achieved.
> I disagree. If you require mutual authentication then EAP Success is this
> indication.

The resolution of IEEE 802.1X D7.l comment 15 states explicitly that this
indication is insufficient for peer-to-peer operation, potentially because
of the issue with protected result indications below.

> > In addition, the EAP authenticator SM does not provide a mechanism for the
> > EAP layer to indicate to the lower layer that a protected result
> > indication has been received from the peer, indicating that the peer has
> > authenticated the authenticator.
> hmm, this one is slightly more interesting, but I have no idea how the
> backend would ever alert the passthrough of this. Still, I think it is
> possible to say that if mutual authentication is required and not
> achieved then the decision will be fail.

I think the issue is the following:

a. The authenticator figures out whether it wants to offer access to the
peer or not.  In the case of pass-through this is communicated in the
Access-Accept.

b. The authenticator communicates it desire to offer access to the peer.
This occurs via a protected result indication.

c. The peer figures out whether it wants to accept that access. This is
communicated to the authenticator via a protected result indication
and communicated to the peer lower layer via eapSuccess.

c. This creates a situation where the peer has full knowledge of each
side's decision (peer knows the authenticator is offering access, and that
it wants to use the access), but the authenticator may not (authenticator
knows that it wants to offer access, but in the case of pass-through
operation it may not know if the peer has accepted it).

To fix this, the authenticator SM could have a variable that says that
the peer has provided a protected result indication to it, indicating that
it will accept the offered access.  In terms of AAA, this
could result in a new attribute indicating "peer-to-peer auth achieved" or
something of that nature, so that another EAP authentication need not be
rerun in the opposite direction.

> I disagree that peer-to-peer is not supported. I would agree that the
> specific interface is not provided for two signals, but I would like to
> understand better why those signals are needed. Also, a suggestion for
> where these signals would go and who sets them might help me understand
> this issue better.

Have a look at the IEEE 802.1X D7.1 resolutions to comment 15.  They're
available here:

http://www.ieee802.org/1/files/private/x-REV-drafts/d7/802-1X-rev-d7-1-dis.pdf

[Nick Petroni] > I think the issue is the following:
>
> a. The authenticator figures out whether it wants to offer access to the
> peer or not.  In the case of pass-through this is communicated in the
> Access-Accept.
This does not come until the conversation is over, no? That is, all
protected messages will be finished before the Access-Accept, right?

> b. The authenticator communicates it desire to offer access to the peer.
> This occurs via a protected result indication.
yes, but this would be in an access-challenge, right? Protected success
cannot be the last message in the protocol since a response is required
from the peer even if it's just "ACK".

> c. The peer figures out whether it wants to accept that access. This is
> communicated to the authenticator via a protected result indication
> and communicated to the peer lower layer via eapSuccess.
these do not happen in the same step. the result will come as the final
EAP response, which will be communicated as an Access-request. The peer
will then wait for an unprotected success or timeout and go to SUCCESS.

> c. This creates a situation where the peer has full knowledge of each
> side's decision (peer knows the authenticator is offering access, and that
> it wants to use the access), but the authenticator may not (authenticator
> knows that it wants to offer access, but in the case of pass-through
> operation it may not know if the peer has accepted it).
not in the case you describe above where a protected response is given.
this will make it back before the Accept-success is ever sent (at least
according to my understanding of RADIUS/EAP interraction).

> To fix this, the authenticator SM could have a variable that says that
> the peer has provided a protected result indication to it, indicating that
> it will accept the offered access.  In terms of AAA, this
> could result in a new attribute indicating "peer-to-peer auth achieved" or
> something of that nature, so that another EAP authentication need not be
> rerun in the opposite direction.
I am not a AAA expert so I do not completely understand what you mean by
this, but it seems plausible that such an indication could be set in the
current system.

> Have a look at the IEEE 802.1X D7.1 resolutions to comment 15.  They're
> available here:

I have read it and did so before my last post, but I find the discussion
vague and unclear. Perhaps someone who participated in that comment
resolution can elighten me? I will re-read it in case I am just slow this morning ;)

[Nick Petroni]

> Yes. So the peer knows that it will be offered access by the
> authenticator.  I say "will be" because the pass-through authenticator
> does not know this yet, because it hasn't gotten the Access-Accept. And
> until it gets the Access-Accept it can't actually provide the access.
yes, but until it gets the Access-Accept it won't send the EAP Success
either so the peer won't try to have access. In this case all is still
well.

Do we agree there is no problem on the peer side? If so, let's turn to the
authenticator...

> Yes. The peer communicates to the backend authentication that it will
> accept the access, but the pass-through authenticator does not know this.
> I think the point of this is that as a result, it might have to rerun an
> EAP authentication in the other direction in order to be sure that it has
> been granted access to the peer.
It seems to me what you are saying is that even after recieving and
Accept-Accept, the passthrough does not know it is allowed to have access
even though it is allowed.

There are two possible solutions I see-
1. make Access-Accept mean that BOTH things are ok and that mutual auth
is known to have succeeded or
2. make Access-Accept strictly mean the Peer is to be given access, and
make some other AAA signal/message provide the other information.

If mutual auth is required, the server can tie the auth directly to the EAP
aaaEapSuccess signal. That is, both must be authenticated for
aaaEapSuccess to be true. This only works for case 1 above, as the AAA layer can't separate these two if
it is only given binary input. I believe THIS is the missing variable you
describe?

I am really having trouble with the model for why the passthrough needs
this information. when using a peer and a passthrough authenticator, it's
tough for me to see the true peer-to-peer relationship we are describing
in any real-world scenario. That being said, this does not mean we
shouldn't handle the situation. My understanding of all passthrough
implemenations is that if there was to be mutual authentication, but the
peer failed to authenticate the authenticator the peer will just go away
(or try again) anyway.

Additionally, I understand the argument that we want
passthrough and standalone to have the same semantics, but I think even
in the peer and standalone statemachines it is policy that is tying
together the two authentication decisions into a single signal. The method
should be set to only succeed in the case of mutual authentication if
mutual auth is required.

> Yes, I also found it vague (I wasn't at the IEEE 802 meeting, since it
> conflicted with IETF).  Perhaps someone who was there can enlighten us
> both :)
I look forward to it :).

My current position is that I don't see why you need two answers. If you
know you are using a method with mutual authentication, then you should be
able to tie the outcome of that method to a two-way relationship.

comments welcome.

nick

[Nick Petroni]

> [3] Support for protected result indications.  When an EAP method
> supporting mutual authentiation and protected result indication is
> in use,  the EAP peer and server will typically be aware of each other's
> access decision, as well as their own.  For example, the EAP server will
> indicate to the peer whether the peer has successfully authenticated to
> it, and the peer will indicate to the EAP server whether the server has
> successfully authenticated to the peer. As a result, the EAP peer and
> server can determine whether an authentication is required in the
> opposite direction.  However, where the authenticator operates as a
> pass-through, it will not be aware whether the peer has
> accepted the access offered to it by the EAP server unless this
> information is provided to it via the AAA protocol.  As a result, two
> authentications, one in each direction, may still need to occur."

based on this text, a proposed change to the state machine doc would
(roughly) look something like this:

In Figure 5 "EAP Backend Authenticator State Machine", change the
METHOD_RESPONSE state to read

  m.process(aaaEapRespData)
  if (m.isDone()) {
     Policy.update(<...>)
     aaaEapKeyData = m.getKey()
     aaaEapPeerDecision = m.getPeerDecision()
     methodState = END
  } else
    methodState = CONTINUE

aaaEapPeerDecision would take values UNKNOWN, KNOWN_ACCEPT and
KNOWN_REJECT and be exported to the lower layer.

thoughts? any other required changes?

Proposed resolution: Discuss

Issue 205: Peer-to-peer operation
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 11/24/2003
Reference: http://mail.frascone.net/pipermail/public/eap/2003-November/001913.html
Document: RFC 2284bis-06
Comment type: T
Priority: S
Section: 2.4
Rationale/Explanation of issue:

This issue relates to asymmetries that exist between pass-through and non-pass-through authenticators in peer-to-peer operation.

Replace the last two paragraphs in Section 2.4, with the following text:

"Lower layer considerations may dictate whether two EAP authentications,
(one in each direction) are required, rather than a single EAP
method supporting mutual authentication and protected result indications.
These include:

[1] Support for bi-direction session key derivation.  Lower 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 infrastructure mode
only the Access Point (AP) sends multicast/broadcast traffic. In IEEE 802.11 ad-hoc
mode where either peer may send multicast/broadcast traffic, two uni-directional
group-key exchanges are required.  Due to limitations of the design, this implies
two unicast key derivations and EAP method exchanges.

[Joe Salowey] Where is the use of multicast/broadcast defined in the case of an
ad-hoc network? Is it defined in 802.11i?

[2] Support for tie-breaking.  Lower layers such as IEEE 802.11 adhoc
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.

[3] Support for protected result indications.  When an EAP method
supporting mutual authentication and protected result indications is
in use,  the EAP peer and server will typically be aware of each other's
access decision, as well as their own.  For example, the EAP server will
indicate to the peer whether the peer has successfully authenticated to
it, and the peer will indicate to the EAP server whether the EAP server has
successfully authenticated to the peer. As a result, the EAP peer and server
can determine whether an authentication is required in the
opposite direction.  However, where the authenticator operates as a
pass-through, it will not be aware whether the peer has
accepted the access offered to it by the EAP server unless this
information is provided to it via the AAA protocol.  As a result, two
authentications, one in each direction, may still need to occur."

[Joe Salowey] Here is a suggestion. It may need a little work, but I think it is
more characteristic of the scenario. 

[3] Peer Policy is not satisfied. It is possible that the EAP Peer's
access policy was not satisfied during the EAP-Method exchange, for
example the peer may not have satisfactorily authenticated the
authenticator.  In this case the peer may wish to open another
authentication exchange with the authenticator in the reverse direction.
It is possible for an EAP mechanism to allow the Peer to return a
protected result indicator to indicate that it successfully
authenticated the authenticator.  However, where the authenticator
operates as a pass-through, it will not be aware whether the peer has
accepted the credentials offered to it by the EAP server unless this
information is provided to it via the AAA protocol.  As a result, two
authentications, one in each direction, may still need to occur.  It is
also possible for the peer to require additional authentication in the
reverse direction even if the protected result indicator from the peer
indicated success.  

[Bernard Aboba] Here is the proposed fix: 

Replace the last two paragraphs in Section 2.4, with the following text:

"Even where a method is used which supports mutual authentication
and protected result indications, several considerations may dictate 
that two EAP authentications, (one in each direction) are required.
These include:

[1] Support for bi-directional session key derivation in the lower layer.  Lower 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 infrastructure mode
only the Access Point (AP) sends multicast/broadcast traffic. In IEEE 802.11 ad-hoc
mode where either peer may send multicast/broadcast traffic, two uni-directional
group-key exchanges are required.  Due to limitations of the design, this also implies
the need for unicast key derivations and EAP method exchanges to occur in each direction. 

[2] Support for tie-breaking in the lower layer.  Lower layers such as IEEE 802.11 adhoc
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.

[3] Peer policy satisfaction. EAP methods may support 
protected result indications, enabling the peer to indicate 
to the EAP server that it successfully authenticated the EAP server.
However, a pass-through authenticator will not be aware that the peer 
has accepted the credentials offered by the EAP server, unless 
this information is provided to the authenticator via the AAA protocol. 
As a result, two authentications, one in each direction, may still be needed.  

It is also possible that the EAP peer's access policy was not satisfied 
during the EAP method exchange. For example, the authenticator may 
not have successfully authenticated to the peer, or may not have 
demonstrated authorization to act in both peer and server roles. 
For example, in EAP-TLS [RFC2716], the authenticator may have 
authenticated using a valid TLS server certificate, but not using 
a valid TLS client certificate.  As a result, the peer may require 
an additional authentication in the reverse direction, even if 
the peer provided a protected result indication to the EAP server 
indicating that the server had successfully authenticated to it. 

Proposed resolution: Accept

Issue 206: Identity-Request
Submitter name: Nagi Reddy Jonnala
Submitter email address: mailto:Nagi_Reddy.Jonnala@alcatel.be
Date first submitted: 12/7/2003
Reference: http://mail.frascone.net/pipermail/public/eap/2003-December/001979.html
Document: RFC 2284bis-07
Comment type: T
Priority: S
Section: 5.1
Rationale/Explanation of issue:

I understand that RFC2284bis-07 Section 5.1 conflicts with the RFC2284
Section 3.1

See the text from 2284-bis.

"
      This field MAY contain a displayable message in the Request,
      containing UTF-8 encoded ISO 10646 characters [RFC2279].  Where
      the Request contains a null, only the portion of the field prior
      to the null is displayed.  If the Identity is unknown, the
      Identity Response field should be zero bytes in length.  The
      Identity Response field MUST NOT be null terminated.  In all
      cases, the length of the Type-Data field is derived from the
      Length field of the Request/Response packet.
"

See the text from 2284 Section 3.1 - Identity Type-Data field.

   "This field MAY contain a displayable message in the Request.  The
      Response uses this field to return the Identity.  If the Identity
      is unknown, this field should be zero bytes in length.  The field
      MUST NOT be null terminated.  The length of this field is derived
      from the Length field of the Request/Response packet and hence a
      null is not required."

Particularly, the last sentence (of 2284)  means that the Request cannot
have a NULL. I guess the intention was to recommend the use of length
rather than a NULL.

Though I don't have any objections to use the space after NULL,  I would
like to know if that causes any issues. At the same time, I propose to
explicitly mention the same thing in the 2284-bis.

Regards
Nagi.

[Jari Arkko] We discussed this in issue 142, see

   http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20142

and the mail archives. The working group agreed at that time,
do we have some new information at this time that would make
us reconsider this? I'm not sure there is.

Having said that, I think Appendix A of RFC 2284bis is misleading
because it just talks about the ISO character set clarifications
in 5.1 and 5.2, but does not mention this issue. Perhaps we should
add the following text to Appendix A, right after the item that
talks about 5.1:

    o  The null character is forbidden in the Type-Data field of an
       Identity Response message, as it is in RFC 2284. But the this rule
       has been relaxed for Identity Requests, and it is now required
       that if the Type-Data field of an Identity Request contains a
       null character, only the part before the null is displayed.

Would this work for you?
 

[Nagi] Yes, it is perfect if you add the text to Appendix A.

[Henrik Levkowetz]

A version of the document (-08.a) updated according to the text below is
available at http://ietf.levkowetz.com/drafts/eap/rfc2284bis/

I guess that formally we'll supply this as an RFC editor note during the
Author's 48 hours?

Proposed resolution: Accept

Issue 207: Miscellaneous Comments
Submitter name: Russ Housley
Submitter email address: housley@vigilsec.com
Date first submitted: 12/15/2003
Reference: http://mail.frascone.net/pipermail/public/eap/2003-December/002003.html
Document: RFC 2284bis-07
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

DISCUSS

   1.  In section 4.3, paragraph [a], the document says: "These MUST
   be pseudo-random, generated by a PRNG seeded as per [RFC1750]."
   While I like RFC 1750 very much, I do not think that a MUST
   statement ought to reference it.  An informative reference is
   better in this case than a normative reference.

   2.  In section 7.2.1, the definition of 'key strength' is not
   correct.  In a perfect symmetric cipher, the brute force attack is
   the best possible attack.  That is, the attacker must attempt to
   decrypt with each possible key value until the correct one is found.
   On average, half of the key values need to be tried to locate the
   correct one to decrypt a particular ciphertext.  So, on average,
   2^(N-1) operations are needed to attack a key with N bits of
   effective strength.

COMMENT

   1.  Please pick one spelling and use it throughout the document:
     - either 'passthrough' or 'pass-through'
     - either 'ad-hoc' or 'ad-hoc' or 'ad hoc'

   2.  In section 1.2, please add the definition of supplicant and
   slightly revise the definition of EMSK as follows:

     supplicant
           The end of the link that responds to the authenticator in
           [IEEE-802.1X].  In this document, this end of the link is
           called the peer.

     Extended Master Session Key (EMSK)
           Additional keying material derived between the EAP client
           and server that is exported by the EAP method.  The EMSK is
           at least 64 octets in length.  The EMSK is not shared with
           the authenticator or any other third party.  The EMSK is
           reserved for future uses that are not defined yet.

   3.  In section 1.3, I find the last sentence of the 4th paragraph
   awkward.  I propose the following rewording:

     As a result, it may be necessary for an authentication algorithm
     to add one or two additional messages (at most one roundtrip)
     between the client and authenticator in order to run over EAP.

   4.  In section 2.4, 1st paragraph, last sentence, the term
   'authenticatees' is introduced.  I think that 'peers' should be used
   instead.  This leads to a problem because 'peers' is used elsewhere
   in the sentence.  Proposal:

     Both ends of the link may act as authenticators and peers at
     the same time.

   5.  In section 3.2, 1st paragraph, 1st sentence: s/must/MUST/

[BA] This sentence refers to PPP, and making the statement normative
would in effect be a change to RFC 1661.  This seems inappropriate to me.

   6.  In section 7.11, 2nd paragraph, last sentence:
   s/recommended/RECOMMENDED/

Move the following paragraph from Section 7.10 to Section 7.5, after the fourth paragraph:

"It is RECOMMENDED that methods providing integrity protection of EAP
packets include coverage of all the EAP header fields, including the
Code, Identifier, Length, Type and Type-Data fields."

Proposed resolution: Accept

Issue 208: Physical Security
Submitter name: Steve Bellovin
Submitter email address: smb@research.att.com
Date first submitted: 12/17/2003
Reference:  http://mail.frascone.net/pipermail/public/eap/2003-December/002013.html
Document:  RFC 2284bis-07
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

I'm not at all happy with the stress on "physical security" of links.
The concept isn't defined in terms of properties, nor is the threat
model clear. Many wired Ethernets, even switched ones, are not secure
enough to meet what I believe to be the requirements here.

[BA] It would appear that the term "physical security" adds little value
to the document.  What if we eliminated use of the term entirely?

The option of cryptographic "security" as an alternative is very hard
-- you can't do crypto without at least one end authenticating itself
first. When I'm sitting in my favorite 802.11 hotspot, how do I know
if I'm authenticating (at the pre-EAP level) to the hotspot or to the
laptop on the table next to me? The implications here are that the
requirements need to be spelled out much more carefully.

5.1 says that identity messages are "not protected". Again, what are
the precise security requirements for the lower layers?

[BA] It would appear that the term "not protected" is used synonymously
with "cleartext" here.

5.2: there are no numeric codes, which creates internationalization
problems.

[BA] Not sure what is meant here;  the Text-Data field uses UTF-8
encoding.

Here is a proposed resolution:

In Section 3.1, change:

" [3] Lower layer security. EAP assumes that lower layers either
provide physical security (e.g., wired PPP or IEEE 802 links) or
support per-packet authentication, integrity and replay
protection. EAP SHOULD NOT be used on physically insecure links
(e.g., wireless or the Internet) where subsequent data is not
protected by per-packet authentication, integrity and replay
protection."

To:

" [3] Lower layer security. Lower layer support for per-packet
authentication, integrity and replay protection
and confidentiality of data traffic is RECOMMENDED. Where
this is available, EAP methods supporting Key Derivation
(see Section 7.2.1) can be used to provide dynamic keying
material. This makes it possible to protect against
security threats such as data modification and spoofing
(see Section 7.1 for details)."

In Section 3.4, change:

" After EAP authentication is complete, the peer will typically
transmit data to the network via the authenticator. In order to
provide assurance that the peer transmitting data is the same entity
that successfully completed EAP authentication, the lower layer needs
to bind per-packet integrity, authentication and replay protection to
the original EAP authentication, using keys derived during EAP
authentication. Alternatively, the lower layer needs to be
physically secure. Otherwise it is possible for subsequent data
traffic to be hijacked or replayed.

As a result of these considerations, EAP SHOULD be used only when
lower layers provide physical security for data (e.g., wired PPP or
IEEE 802 links), or for insecure links, where per-packet
authentication, integrity and replay protection is provided."

To:

" After EAP authentication is complete, the peer will typically
transmit data to the network via the authenticator. In order to
provide assurance that the peer transmitting data is the same entity
that successfully completed EAP authentication, the lower layer needs
to bind per-packet integrity, authentication and replay protection to
the original EAP authentication, using keys derived during EAP
authentication. Otherwise it is possible for subsequent data
traffic to be hijacked or replayed."

In Section 5.1, change:

"Identity Requests and Responses are not protected, so
from a privacy perspective it is preferable for an EAP method to
include its own protected identity exchange."

To:

"Identity Requests and Responses are sent in cleartext, so
from a privacy perspective it is preferable for an EAP method to
include an identity exchange that supports authentication,
integrity and replay protection and confidentiality."

Change Section 7 to:

"7. Security Considerations

This section defines the threat model and security terms and
describes the security claims section required in EAP method
specifications. We then discuss threat mitigation."

In Section 7.1, change:

"On physically insecure networks, it is possible for an attacker to
gain access to the physical medium. This enables a range of attacks,
including the following:"

To:

"EAP was developed for use with dialup PPP [RFC1661] and was later
adapted for use in wired IEEE 802 networks [IEEE-802] in
[IEEE-802.1X].  Subsequently EAP has been proposed for use on wireless
LAN networks, and over the Internet.  In all these situations it is
possible for an attacker to gain access to the link.  For example,
attacks on telephone infrastructure are documented in
[DECEPTION].

An attacker with access to the link may carry out a number of attacks,
including:"

In Section 7.1, change:

" Where EAP is used over wired networks, an attacker typically requires
access to the physical infrastructure in order to carry out these
attacks. However, where EAP is used over wireless networks, EAP
packets may be forwarded by authenticators (e.g., pre-authentication)
so that the attacker need not be within the coverage area of an
authenticator in order to carry out an attack on it or its peers.
Where EAP is used over the Internet, attacks may be carried out at an
even greater distance."

To:

"Depending on the lower layer, these attacks may be carried out
without requiring physical proximity. where EAP is used
over wireless networks, EAP packets may be forwarded by
authenticators (e.g., pre-authentication) so that the attacker
need not be within the coverage area of an authenticator in
order to carry out an attack on it or its peers. Where EAP is
used over the Internet, attacks may be carried out at an
even greater distance."

In Section 7.2, delete:

" [a] Intended use. This includes a statement of whether the method is
intended for use over a physically secure or insecure network, as
well as a statement of the applicable lower layers."

In Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 delete the Intended Use
claim.

In Section 7.5, change:

" In the case of PPP and IEEE 802 wired links, it is assumed that such
attacks are restricted to attackers who can gain access to the
physical link. However, where EAP is run over physically insecure
lower layers such as wireless (802.11 or cellular) or the Internet
(such as within protocols supporting PPP, EAP or Ethernet Tunneling),
this assumption is no longer valid and the vulnerability to attack is
greater.

To protect EAP messages sent over physically insecure lower layers,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
SHOULD be used."

To:

"To protect EAP messages against modification or spoofing,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
SHOULD be used."

In Section 7.6, change:

"In order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2)
SHOULD be used where EAP runs over lower layers which are not physically
secure."

To:

"In order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2)
SHOULD be used."

In Section 7.7, change:

"With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator. Where the lower
layer is not physically secure (such as where EAP runs over wireless
media or the Internet), the peer is vulnerable to a rogue
authenticator. As a result, where the lower layer is not physically
secure, a method supporting mutual authentication is RECOMMENDED."

To:

" With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator, making the
peer vulnerable to attack by a rogue authenticator.  To address this
vulnerability, it is RECOMMENDED to use a method supporting mutual
authentication."

In Section 7.11, change:

" As a result, as noted in Section 3.1, where EAP is used over a
physically insecure lower layer, per-packet authentication, integrity
and replay protection SHOULD be used, and per-packet confidentiality
is also recommended."

To:

"In order to address this vulnerability, lower layers providing per-packet
authentication, integrity and replay protection, as well as
confidentiality are RECOMMENDED."

Change Section 7.12 to:

"There are reliability and security issues with link
layer indications in PPP, IEEE 802 LANs and IEEE 802.11 wireless LANs:

[a] PPP. In PPP, link layer indications such as LCP-Terminate (a
link failure indication) and NCP (a link success indication) are
not authenticated or integrity protected. They can therefore be
spoofed by an attacker with access to the link.

[b] IEEE 802. IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames
are not authenticated or integrity protected. They can therefore
be spoofed by an attacker with access to the link.

[c] IEEE 802.11. In IEEE 802.11, link layer
indications include Disassociate and Deauthenticate frames (link
failure indications), and the first message of the 4-way
handshake (link success indication). These messages are not
authenticated or integrity protected, and although they are not
forwardable, they are spoofable by an attacker within range.

In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 3
unicast data frames, and are therefore forwardable. This implies
that while EAPOL-Start and EAPOL-Logoff messages may be
authenticated and integrity protected, they can be spoofed by an
authenticated attacker far from the target when
"pre-authentication" is enabled.

In IEEE 802.11 a "link down" indication is an unreliable
indication of link failure, since wireless signal strength can
come and go and may be influenced by radio frequency interference
generated by an attacker. To avoid unnecessary resets, it is
advisable to damp these indications, rather than passing them
directly to the EAP. Since EAP supports retransmission, it is
robust against transient connectivity losses."

In Section 7.13, change:

" [c] Where EAP is used over lower layers which are not physically
secure, after completion of the EAP conversation, a secure
association protocol SHOULD be run between the peer and
authenticator in order to provide mutual authentication;
guarantee liveness of the TSKs; provide protected ciphersuite and
capabilities negotiation; synchronize key usage."

To:

" [c] After completion of the EAP conversation, where the
lower layer supports security services such as
per-packet authentication,  integrity and replay protection
and confidentiality, a secure association protocol
SHOULD be run between the peer and authenticator
in order to provide mutual authentication;
guarantee liveness of transient session keys;
provide protected ciphersuite and
capabilities negotiation; and synchronize key usage."

In Section 7.14, change:

"   EAP does not support cleartext password authentication.  This
   omission is intentional.  Where EAP is carried over physically
   insecure lower layers, including wireless LANs [IEEE-802.11] or the
   Internet, use of cleartext passwords would allow the password to be
   captured by an attacker with access to the lower layer.

   Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
   provide confidentiality, even where the lower layer is physically
   secure, EAP frames may be subsequently encapsulated for transport
   over the Internet where they may be captured by an attacker."

To:

"  EAP does not support cleartext password authentication.  This
   omission is intentional.  Use of cleartext passwords would allow the
   password to be captured by an attacker with access to the link.

   Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
   provide confidentiality, EAP frames may be subsequently encapsulated
   for transport over the Internet where they may be captured by an
   attacker."

[Alper Yergin] > I'm not at all happy with the stress on "physical security" of links.
> The concept isn't defined in terms of properties, nor is the threat
> model clear. Many wired Ethernets, even switched ones, are not secure
> enough to meet what I believe to be the requirements here.
> 
> [BA] It would appear that the term "physical security" adds little value
> to the document.  What if we eliminated use of the term entirely?




Does this mean that we are eliminating the concept of physical security in
the context of EAP, and tighten the requirements accordingly? I think this
is not the intention, but I hope the modified language change does not
suggest that... At the end, I should still be able to use EAP-MD5 over my
DSL networks or wired Ethernet and not violate the spec.

> In Section 7.5, change:
> 
> " In the case of PPP and IEEE 802 wired links, it is assumed that such
> attacks are restricted to attackers who can gain access to the
> physical link. However, where EAP is run over physically insecure
> lower layers such as wireless (802.11 or cellular) or the Internet
> (such as within protocols supporting PPP, EAP or Ethernet Tunneling),
> this assumption is no longer valid and the vulnerability to attack is
> greater.
> 
> To protect EAP messages sent over physically insecure lower layers,
> methods providing mutual authentication and key derivation, as well
> as per-packet origin authentication, integrity and replay protection
> SHOULD be used."
> 
> To:
> 
> " To protect EAP messages against modification or spoofing,
> methods providing mutual authentication and key derivation, as well
> as per-packet origin authentication, integrity and replay protection
> SHOULD be used."

...

> 
> In Section 7.6, change:
> 
> " In order to protect against dictionary attacks, an authentication
> algorithm resistant to dictionary attack (as defined in Section 7.2)
> SHOULD be used where EAP runs over lower layers which are not physically
> secure."
> 
> To:
> 
> "In order to protect against dictionary attacks, an authentication
> algorithm resistant to dictionary attack (as defined in Section 7.2)
> SHOULD be used."

> In Section 7.13, change:
> 
> " [c] Where EAP is used over lower layers which are not physically
> secure, after completion of the EAP conversation, a secure
> association protocol SHOULD be run between the peer and
> authenticator in order to provide mutual authentication;
> guarantee liveness of the TSKs; provide protected ciphersuite and
> capabilities negotiation; synchronize key usage."
> 
> To:
> 
> " [c] After completion of the EAP conversation, a secure
> association protocol SHOULD be run between the peer and
> authenticator in order to provide mutual authentication;
> guarantee liveness of the TSKs; provide protected ciphersuite and
> capabilities negotiation; synchronize key usage."

The current text in the above segments suggest one does not have to obey the
requirement if EAP is run over physically secured links. The new text is
removing this condition. But I don't think the situation is any different,
right? It's just that we don't have a text saying that now...

I think working out the details of what physical security means and keeping
the term in the draft is a better approach.

> The current text in the above segments suggest one does not have to obey the
> requirement if EAP is run over physically secured links. The new text is
> removing this condition. But I don't think the situation is any different,
> right? It's just that we don't have a text saying that now...
>
> I think working out the details of what physical security means and keeping
> the term in the draft is a better approach

[BA] I believe that Steve's point (which I agree with) is that "physical
security" is a term that is very hard to define.  For example, which of
the networks below is "physically secure":

* The Ethernet network in my home, which is entirely internal and
is protected by a rather large dog who has not eaten recently because
I am working late tonite.

* The Ethernet network in my neighbor's house, which includes a tap on the
outside porch.  The neighbors are away for the weekend.

* The wireless network at work which is located in a test lab within a
Faraday cage behind a locked door.

* The wireless network in a deserted neighborhood Starbucks, which has
closed down for the night (but whose network is still up).

* The ARCNet network which was installed 15 years ago and but is still
functioning in a legacy installation in the data center, but where
the night watchman has left the door open.

In practice, the term "physically secure" is one which applies to a
particular installation and set of practices, not to a particular
networking technology, so it is difficult to use prescriptively.

In most of the changes proposed in Issue 208, the removal of the term
"physical security" does not change the meaning of the draft at all, and
so those changes seem relatively straightforward.

The changes that are somewhat trickier is where the term is used as the
basis for some guidance as to what kind of EAP methods should be deployed,
or whether EAP should be used at all.

As Erik Nordmark discussed at IETF 56,  there is a need for prescriptive
guidance in particular situations.  For example, at IETF 56, Erik
recommended that IEEE 802.11i provide EAP WG with a document stating the
requirements for EAP methods used with IEEE 802.11 security.  If we assume
that such documents will be produced, then it isn't clear to me that we
necessarily need this kind of prescriptive guidance within RFC 2284bis
itself.  One approach might be to remove the normative language.

For example, Section 7.5 says:

" In the case of PPP and IEEE 802 wired links, it is assumed that such
attacks are restricted to attackers who can gain access to the
physical link. However, where EAP is run over physically insecure
lower layers such as wireless (802.11 or cellular) or the Internet
(such as within protocols supporting PPP, EAP or Ethernet Tunneling),
this assumption is no longer valid and the vulnerability to attack is
greater.

To protect EAP messages sent over physically insecure lower layers,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
SHOULD be used."

I think what these paragraphs are trying to say is that if you're
worried about an attacker gaining access to the link, then use an
EAP method that protects against that.  One way to get at this point
might be to say the following:

"To protect EAP messages against modification or spoofing,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
can be used."

Section 7.6 says:

"In order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2)
SHOULD be used where EAP runs over lower layers which are not physically
secure."

Again, I think the message is that if you're worried about dictionary
attacks, use an algorithm that deals with that.  One way to get at that
might be to say:

"In order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2.1)
can be used."

Section 7.7 says:

"With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator. Where the lower
layer is not physically secure (such as where EAP runs over wireless
media or the Internet), the peer is vulnerable to a rogue
authenticator. As a result, where the lower layer is not physically
secure, a method supporting mutual authentication is RECOMMENDED."

In this particular paragraph, it strikes me that the issue is really
whether rogue authenticators are a concern or not.  If so, then
mutual authentication is important.  One way to get at this might be to
say:

"With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator, making the
peer vulnerable to attack by a rogue authenticator.  Where this
vulnerability is a concern, a method supporting
mutual authentication can be used."

Section 7.11 says:

"As a result, as noted in Section 3.1, where EAP is used over a
physically insecure lower layer, per-packet authentication, integrity
and replay protection SHOULD be used, and per-packet confidentiality
is also recommended."

Instead, we might say:

"In order to address this vulnerability, lower layers providing per-packet
confidentiality, authentication, integrity and replay protection
can be used. "

[BA] Here is a revised resolution:

In Section 3.1, change:

" [3] Lower layer security. EAP assumes that lower layers either
provide physical security (e.g., wired PPP or IEEE 802 links) or
support per-packet authentication, integrity and replay
protection. EAP SHOULD NOT be used on physically insecure links
(e.g., wireless or the Internet) where subsequent data is not
protected by per-packet authentication, integrity and replay
protection."

To:

" [3] Lower layer security.  EAP does not require
lower layers to provide security services such as
per-packet confidentiality, authentication, integrity and
replay protection.  However, where these security
services are available, EAP methods supporting Key
Derivation (see Section 7.2.1) can be used to provide dynamic keying   
material.  This makes it possible to bind the EAP authentication
to subsequent data and protect against
security threats such as data modification, spoofing, or replay
(see Section 7.1 for details)."

In Section 3.4, change:

" After EAP authentication is complete, the peer will typically
transmit data to the network via the authenticator. In order to
provide assurance that the peer transmitting data is the same entity
that successfully completed EAP authentication, the lower layer needs
to bind per-packet integrity, authentication and replay protection to
the original EAP authentication, using keys derived during EAP
authentication. Alternatively, the lower layer needs to be
physically secure. Otherwise it is possible for subsequent data
traffic to be hijacked or replayed.

As a result of these considerations, EAP SHOULD be used only when
lower layers provide physical security for data (e.g., wired PPP or
IEEE 802 links), or for insecure links, where per-packet
authentication, integrity and replay protection is provided."

To:

" After EAP authentication is complete, the peer will typically
transmit data to the network via the authenticator. In order to
provide assurance that the peer transmitting data is the same entity
that successfully completed EAP authentication, the lower layer needs
to bind per-packet integrity, authentication and replay protection to
the original EAP authentication, using keys derived during EAP
authentication.  Otherwise it is possible for subsequent data
traffic to be hijacked or replayed."

[Alper Yergin]  I'd drop the "using keys derived during EAP authentication." part. I can
rely on physical security for the binding.

[Joe Salowey] I don't think this part should be removed.  You might make it
conditional, but then we must explain when it can be relaxed.  I think
there is some threat model in the document already that requires this.

In Section 5.1, change:

"Identity Requests and Responses are not protected, so
from a privacy perspective it is preferable for an EAP method to
include its own protected identity exchange."

To:

"Identity Requests and Responses are sent in cleartext, so
from a privacy perspective it is preferable for an EAP method to
include an identity exchange that supports authentication,
integrity and replay protection and confidentiality."

Change Section 7 to:

"7. Security Considerations

This section defines the threat model and security terms and
describes the security claims section required in EAP method
specifications. We then discuss threat mitigation."

In Section 7.1, change:

"On physically insecure networks, it is possible for an attacker to
gain access to the physical medium. This enables a range of attacks,
including the following:"

To:

"EAP was developed for use with dialup PPP [RFC1661] and was later
adapted for use in wired IEEE 802 networks [IEEE-802] in
[IEEE-802.1X].  Subsequently EAP has been proposed for use on wireless
LAN networks, and over the Internet.  In all these situations it is
possible for an attacker to gain access to the link.  For example,
attacks on telephone infrastructure are documented in
[DECEPTION].

An attacker with access to the link may carry out a number of attacks,
including:"

In Section 7.1, change:

" Where EAP is used over wired networks, an attacker typically requires
access to the physical infrastructure in order to carry out these
attacks. However, where EAP is used over wireless networks, EAP
packets may be forwarded by authenticators (e.g., pre-authentication)
so that the attacker need not be within the coverage area of an
authenticator in order to carry out an attack on it or its peers.
Where EAP is used over the Internet, attacks may be carried out at an
even greater distance."

To:

"Depending on the lower layer, these attacks may be carried out
without requiring physical proximity. where EAP is used
over wireless networks, EAP packets may be forwarded by
authenticators (e.g., pre-authentication) so that the attacker
need not be within the coverage area of an authenticator in
order to carry out an attack on it or its peers. Where EAP is
used over the Internet, attacks may be carried out at an
even greater distance."

In Section 7.2, delete:

" [a] Intended use. This includes a statement of whether the method is
intended for use over a physically secure or insecure network, as
well as a statement of the applicable lower layers."

In Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 delete the Intended Use
claim.

In Section 7.5, change:

" In the case of PPP and IEEE 802 wired links, it is assumed that such
attacks are restricted to attackers who can gain access to the
physical link. However, where EAP is run over physically insecure
lower layers such as wireless (802.11 or cellular) or the Internet
(such as within protocols supporting PPP, EAP or Ethernet Tunneling),
this assumption is no longer valid and the vulnerability to attack is
greater.

To protect EAP messages sent over physically insecure lower layers,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
SHOULD be used."

To:

"To protect EAP messages against modification or spoofing,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
can be used."

In Section 7.6, change:

"In order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2)
SHOULD be used where EAP runs over lower layers which are not physically
secure."

To:

"In order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2)
can be used."

In Section 7.7, change:

"With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator. Where the lower
layer is not physically secure (such as where EAP runs over wireless
media or the Internet), the peer is vulnerable to a rogue
authenticator. As a result, where the lower layer is not physically
secure, a method supporting mutual authentication is RECOMMENDED."

To:

" With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator, making the
peer vulnerable to attack by a rogue authenticator.  To address this
vulnerability, a method supporting mutual authentication 
can be used. "

In Section 7.11, change:

"As a result, as noted in Section 3.1, where EAP is used over a
physically insecure lower layer, per-packet authentication, integrity
and replay protection SHOULD be used, and per-packet confidentiality
is also recommended."

To:

"In order to address this vulnerability, lower layers providing per-packet
confidentiality, authentication, integrity and replay protection
can be used. "

Change Section 7.12 to:

"There are reliability and security issues with link
layer indications in PPP, IEEE 802 LANs and IEEE 802.11 wireless LANs:

[a] PPP. In PPP, link layer indications such as LCP-Terminate (a
link failure indication) and NCP (a link success indication) are
not authenticated or integrity protected. They can therefore be
spoofed by an attacker with access to the link.

[b] IEEE 802. IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames
are not authenticated or integrity protected. They can therefore
be spoofed by an attacker with access to the link.

[c] IEEE 802.11. In IEEE 802.11, link layer
indications include Disassociate and Deauthenticate frames (link
failure indications), and the first message of the 4-way
handshake (link success indication). These messages are not
authenticated or integrity protected, and although they are not
forwardable, they are spoofable by an attacker within range.

In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 3
unicast data frames, and are therefore forwardable. This implies
that while EAPOL-Start and EAPOL-Logoff messages may be
authenticated and integrity protected, they can be spoofed by an
authenticated attacker far from the target when
"pre-authentication" is enabled.

In IEEE 802.11 a "link down" indication is an unreliable
indication of link failure, since wireless signal strength can
come and go and may be influenced by radio frequency interference
generated by an attacker. To avoid unnecessary resets, it is
advisable to damp these indications, rather than passing them
directly to the EAP. Since EAP supports retransmission, it is
robust against transient connectivity losses."

In Section 7.13, change:

" [c] Where EAP is used over lower layers which are not physically
secure, after completion of the EAP conversation, a secure
association protocol SHOULD be run between the peer and
authenticator in order to provide mutual authentication;
guarantee liveness of the TSKs; provide protected ciphersuite and
capabilities negotiation; synchronize key usage."

To:

" [c] After completion of the EAP conversation, where the
lower layer supports security services such as
per-packet confidentiality, authentication, integrity and replay protection,
a secure association protocol SHOULD be run between
the peer and authenticator in order to provide mutual authentication;
guarantee liveness of transient session keys;
provide protected ciphersuite and
capabilities negotiation; and synchronize key usage."

[Alper Yergin] I think, we should either:
- change "SHOULD" to "MAY" or "can"; or
- "where the lower layer security services such as per-packet
confidentiality, authentication, integrity and replay protection will
to be enabled"

In Section 7.14, change:

"   EAP does not support cleartext password authentication.  This
   omission is intentional.  Where EAP is carried over physically
   insecure lower layers, including wireless LANs [IEEE-802.11] or the
   Internet, use of cleartext passwords would allow the password to be
   captured by an attacker with access to the lower layer.

   Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
   provide confidentiality, even where the lower layer is physically
   secure, EAP frames may be subsequently encapsulated for transport
   over the Internet where they may be captured by an attacker."

To:

"  EAP does not support cleartext password authentication.  This
   omission is intentional.  Use of cleartext passwords would allow the password to be
   captured by an attacker with access to the link.

   Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
   provide confidentiality, EAP frames may be subsequently encapsulated for transport
   over the Internet where they may be captured by an attacker."

[Alper Yergin] I don't think this is an "EAP support" issue. This is just a matter of
defining an "EAP method". Unless we explicitly forbid design of such a
method, we should remove the above statement. I don't think this is for EAP
specification to decide. [I understand why it's a bad idea to have cleartext
passwords, but the above statement is confusing the role of EAP, EAP
methods, etc.]

[BA] There is an IETF prohibition against cleartext passwords, so this is indeed explicitly forbidden.

[BA] Here is the proposed resolution:

In Section 3.1, change:

" [3] Lower layer security. EAP assumes that lower layers either
provide physical security (e.g., wired PPP or IEEE 802 links) or
support per-packet authentication, integrity and replay
protection. EAP SHOULD NOT be used on physically insecure links
(e.g., wireless or the Internet) where subsequent data is not
protected by per-packet authentication, integrity and replay
protection."

To:

" [3] Lower layer security. EAP does not require
lower layers to provide security services such as
per-packet confidentiality, authentication, integrity and
replay protection. However, where these security
services are available, EAP methods supporting Key
Derivation (see Section 7.2.1) can be used to provide dynamic keying 
material. This makes it possible to bind the EAP authentication
to subsequent data and protect against data modification, spoofing
or replay. See Section 7.1 for details."

In Section 3.4, change:

" After EAP authentication is complete, the peer will typically
transmit data to the network via the authenticator. In order to
provide assurance that the peer transmitting data is the same entity
that successfully completed EAP authentication, the lower layer needs
to bind per-packet integrity, authentication and replay protection to
the original EAP authentication, using keys derived during EAP
authentication. Alternatively, the lower layer needs to be
physically secure. Otherwise it is possible for subsequent data
traffic to be hijacked or replayed.

As a result of these considerations, EAP SHOULD be used only when
lower layers provide physical security for data (e.g., wired PPP or
IEEE 802 links), or for insecure links, where per-packet
authentication, integrity and replay protection is provided."

To:

"After EAP authentication is complete, the peer will typically
transmit and receive data via the authenticator. It is
desirable to provide assurance that the entities transmitting data 
are the same ones that successfully completed EAP authentication. 
To accomplish this, it is necessary for the lower layer to provide
per-packet integrity, authentication and replay protection and
to bind these per-packet services to the keys derived during EAP
authentication. Otherwise it is possible for subsequent data
traffic to be modified, spoofed or replayed."

In Section 5.1, change:

"Identity Requests and Responses are not protected, so
from a privacy perspective it is preferable for an EAP method to
include its own protected identity exchange."

To:

"Identity Requests and Responses are sent in cleartext, so
that an attacker may snoop on the identity, or even modify 
or spoof identity exchanges. To address these threats, 
it is preferable for an EAP method to include an identity 
exchange that supports per-packet authentication,
integrity and replay protection and confidentiality."

Change Section 7 to:

"7. Security Considerations

This section defines a generic threat model and as well
as the corresponding EAP method security claims 
mitigating those threats.

It is expected that the generic threat model and corresponding 
security claims will used to define EAP method requirements for
use in specific environments. An example of such a requirements 
analysis is provided in [IEEE80211iReq]. 
A security claims section is required in EAP method 
specifications, so that EAP methods can be evaluated
against the requirements."

Add as an informative reference:

"[IEEE80211iReq]
Kerry, S., "Input the IETF EAP Working Group on Methods and Key
Strength", IEEE 802.11 liason letter, 
http://www.ietf.org/IESG/LIAISON/LS-ieee-80211.txt, March 2003." 

In Section 7.1, change:

"On physically insecure networks, it is possible for an attacker to
gain access to the physical medium. This enables a range of attacks,
including the following:"

To:

"EAP was developed for use with dialup PPP [RFC1661] and was later
adapted for use in wired IEEE 802 networks [IEEE-802] in
[IEEE-802.1X]. Subsequently EAP has been proposed for use on wireless
LAN networks, and over the Internet. In all these situations it is
possible for an attacker to gain access to links over which
EAP packets are transmitted. For example,
attacks on telephone infrastructure are documented in
[DECEPTION].

An attacker with access to the link may carry out a number of attacks,
including:"

In Section 7.1, change:

"Where EAP is used over wired networks, an attacker typically requires
access to the physical infrastructure in order to carry out these
attacks. However, where EAP is used over wireless networks, EAP
packets may be forwarded by authenticators (e.g., pre-authentication)
so that the attacker need not be within the coverage area of an
authenticator in order to carry out an attack on it or its peers.
Where EAP is used over the Internet, attacks may be carried out at an
even greater distance."

To:

"Depending on the lower layer, these attacks may be carried out
without requiring physical proximity. where EAP is used
over wireless networks, EAP packets may be forwarded by
authenticators (e.g., pre-authentication) so that the attacker
need not be within the coverage area of an authenticator in
order to carry out an attack on it or its peers. Where EAP is
used over the Internet, attacks may be carried out at an
even greater distance."

In Section 7.2, delete:

"[a] Intended use. This includes a statement of whether the method is
intended for use over a physically secure or insecure network, as
well as a statement of the applicable lower layers."

In Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 delete the Intended Use
claim.

In Section 7.5, change:

"In the case of PPP and IEEE 802 wired links, it is assumed that such
attacks are restricted to attackers who can gain access to the
physical link. However, where EAP is run over physically insecure
lower layers such as wireless (802.11 or cellular) or the Internet
(such as within protocols supporting PPP, EAP or Ethernet Tunneling),
this assumption is no longer valid and the vulnerability to attack is
greater.

To protect EAP messages sent over physically insecure lower layers,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
SHOULD be used."

To:

"To protect EAP packets against modification, spoofing or replay, methods
supporting protected ciphersuite negotiation, mutual authentication 
and key derivation as well as integrity and replay protection are 
recommended. See Section 7.2.1 for definition of these security claims."

In Section 7.6, change:

"In order to protect against dictionary attacks, authentication
algorithms resistant to dictionary attack (as defined in Section 7.2)
SHOULD be used where EAP runs over lower layers which are not physically
secure."

To:

"In order to protect against dictionary attacks, authentication
methods resistant to dictionary attacks (as defined in Section 7.2.1)
are recommended."

In Section 7.7, change:

"With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator. Where the lower
layer is not physically secure (such as where EAP runs over wireless
media or the Internet), the peer is vulnerable to a rogue
authenticator. As a result, where the lower layer is not physically
secure, a method supporting mutual authentication is RECOMMENDED."

To:

"With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator, making the
peer vulnerable to attack by a rogue authenticator. Methods 
supporting mutual authentication (as defined in Section 7.2.1)
address this vulnerability."

In Section 7.11, change:

"As a result, as noted in Section 3.1, where EAP is used over a
physically insecure lower layer, per-packet authentication, integrity
and replay protection SHOULD be used, and per-packet confidentiality
is also recommended."

To:

"To protect against data modification, spoofing or snooping, it is
recommended that EAP methods supporting mutual authentication,
and key derivation (as defined by Section 7.2.1) be used, along with
a lower layers providing per-packet confidentiality, authentication, 
integrity and replay protection."

Change Section 7.12 to:

"There are reliability and security issues with link
layer indications in PPP, IEEE 802 LANs and IEEE 802.11 wireless LANs:

[a] PPP. In PPP, link layer indications such as LCP-Terminate (a
link failure indication) and NCP (a link success indication) are
not authenticated or integrity protected. They can therefore be
spoofed by an attacker with access to the link.

[b] IEEE 802. IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames
are not authenticated or integrity protected. They can therefore
be spoofed by an attacker with access to the link.

[c] IEEE 802.11. In IEEE 802.11, link layer
indications include Disassociate and Deauthenticate frames (link
failure indications), and the first message of the 4-way
handshake (link success indication). These messages are not
authenticated or integrity protected, and although they are not
forwardable, they are spoofable by an attacker within range.

In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 3
unicast data frames, and are therefore forwardable. This implies
that while EAPOL-Start and EAPOL-Logoff messages may be
authenticated and integrity protected, they can be spoofed by an
authenticated attacker far from the target when
"pre-authentication" is enabled.

In IEEE 802.11 a "link down" indication is an unreliable
indication of link failure, since wireless signal strength can
come and go and may be influenced by radio frequency interference
generated by an attacker. To avoid unnecessary resets, it is
advisable to damp these indications, rather than passing them
directly to the EAP. Since EAP supports retransmission, it is
robust against transient connectivity losses."

In Section 7.13, change:

" [c] Where EAP is used over lower layers which are not physically
secure, after completion of the EAP conversation, a secure
association protocol SHOULD be run between the peer and
authenticator in order to provide mutual authentication;
guarantee liveness of the TSKs; provide protected ciphersuite and
capabilities negotiation; synchronize key usage."

To:

" [c] After completion of the EAP conversation, where lower layer
lower layer security services such as per-packet confidentiality, 
authentication, integrity and replay protection will be enabled, 
a secure association protocol SHOULD be run between
the peer and authenticator in order to provide mutual authentication
between the peer and authenticator; guarantee liveness of transient session keys;
provide protected ciphersuite and capabilities negotiation for subsequent
data; and synchronize key usage."

In Section 7.14, change:

" EAP does not support cleartext password authentication. This
omission is intentional. Where EAP is carried over physically
insecure lower layers, including wireless LANs [IEEE-802.11] or the
Internet, use of cleartext passwords would allow the password to be
captured by an attacker with access to the lower layer.

Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
provide confidentiality, even where the lower layer is physically
secure, EAP frames may be subsequently encapsulated for transport
over the Internet where they may be captured by an attacker."

To:

"This specification does not define a mechanism for cleartext password 
authentication. The omission is intentional. Use of cleartext passwords 
would allow the password to be captured by an attacker with access a 
link over which EAP packets are transmitted. 

Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
provide confidentiality, EAP packets may be subsequently encapsulated 
for transport over the Internet where they may be captured by an 
attacker." 

Proposed resolution: Accept

Issue 209: Applicability statement
Submitter name: Allison Mankin
Submitter email address: mankin@psg.com
Date first submitted: 12/17/2003
Reference: 
Document:  RFC 2284bis-07
Comment type: E
Priority: S
Section: 1.3
Rationale/Explanation of issue:

I think there are many virtues to this spec, but it needs more attention to 
the applicability description. The problem is epitomized by comments such as:

   Where transport efficiency is a consideration, and IP transport is
   available, it may be preferable to expose an artificially high EAP
   MTU to EAP and allow fragmentation to take place in IP.
   Alternatively, it is possible to choose other security mechanisms
   such as TLS [RFC2246] or IKE [RFC2409] or an alternative
   authentication framework such as SASL [RFC2222] or GSS-API [RFC2743].

How could the same application use GSS-API or SASL if it intended to use EAP
 
They seem to have very different domains of applicability.  It would be good 
to discuss the ways that EAP is very applicable and ways in which it can be 
kind of wedged into use, with results that may be only just satisfactory.

[BA] Proposed resolution is as follows:

Change Section 1.3 to:

"1.3 Applicability

EAP was designed for use in network access authentication, where
IP layer connectivity may not be available. Use of EAP for
other purposes, such as bulk data transport, is NOT RECOMMENDED.

Since EAP does not require IP connectivity, it provides just
enough support for the reliable transport of authentication
protocols, and no more.

EAP is a lock-step protocol which only supports a single packet in
flight. As a result EAP cannot efficiently transport bulk
data, unlike transport protocols such as TCP [RFC793] or SCTP [RFC2960].

While EAP provides support for retransmission, it assumes
ordering guarantees provided by the lower layer, so that out of
order reception is not supported.

Since EAP does not support fragmentation and reassembly,
EAP authentication methods generating payloads larger than
the minimum EAP MTU need to provide fragmentation support.

While authentication methods such as EAP-TLS [RFC2716]
provide support for fragmentation and reassembly, the EAP
methods defined in this document do not. As a result,
if the EAP packet size exceeds the EAP MTU of the link,
these methods will encounter difficulties.

EAP authentication is initiated by the server (authenticator), whereas
many authentication protocols are initiated by the client (peer). As a
result, it may be necessary for an authentication algorithm to add one or
two additional messages (at most one roundtrip) in order to run over EAP.

Where certificate-based authentication is supported, the number
of additional roundtrips may be much larger due to fragmentation of
certificate chains. In general, a fragmented EAP packet
will require as many round-trips to send as there are fragments. For
example, a certificate chain 14960 octets in size would require ten
round-trips to send with a 1496 octet EAP MTU.

Where EAP runs over a lower layer in which significant packet loss is
experienced, or where the connection between the authenticator and
authentication server experiences significant packet loss, EAP methods
requiring many round-trips can experience difficulties. In these
situations, use of EAP methods with fewer roundtrips is advisable."

Proposed resolution: Accept

Issue 210: No name for the "top EAP keying material"
Submitter name: Florent Bersani
Submitter email address: florent.bersani@francetelecom.com
Date first submitted: 12/16/2003
Reference: http://mail.frascone.net/pipermail/public/eap/2003-December/001997.html
Document:  KeyFrame-01
Comment type: E
Priority: 2
Section: 2.2
Rationale/Explanation of issue:

Although the EAP hierarchy is very clearly described in section 2.2, I 
experienced some difficulties to present it to colleagues for a trivial 
reason: the top EAP key (i.e. the one that is somehow involved in the MK 
derivation e.g Ki in the EAP-SIM method, the private keys associated to 
the digital certificates used within EAP-TLS) does not appear to have a 
name. Things would become easier if there was standard terminology.

Requested change:

Add to section 2.2 at the beginning of the different key types enumerations:
EAP Permanent Key (PK):
To perform authentication and key exchange, an EAP method uses a 
permanent secret. This secret MAY belong either to the symmetric 
cryptography or asymmetric cryptography category.

Add to Figure 2:
"(PK)" near the text "EAP method" in the top left corner of the figure
"(MK)" in the box labeled "EAP Method Key Derivation"

Add to Figure 3:
"PK," before "(MSK,TEKs)"

Add to Figure 4:
"PK," before "(MSK,TEKs)"

Add to appendix B:
"Pre-master secret": created or exchanged thanks to the PK which are 
digital certificates in the case of TLS
[This wording "created or exchanged" wants to encompass all the TLS 
possibilities: RSA, DH,...]

[In general, I don't like very much my wording but issue submitters have 
to propose solutions to their issues, don't they ;-)?]

[BA]  One potential resolution to this
is to use the term "Long Term Secret" to refer to either a long-term
pre-shared key or a private key. However, in RFC 2284bis we eliminated
discussion of the Master Key since not all methods use this, so I'm not
sure it makes sense to add references to this in the Key Framework
Document.

[Florent] I agree with you so why not "EAP (long term?) credential".

Wouldn't this wording allow for unambiguous naming of the root of the 
EAP key hierarchy Hierarchy and at the same time apply to the whole 
variety of methods' "root keys" (symmetric, asymmetric, OTP,...) - my 
quick answer, I'll go to the list to review the previous debates

So I suggest using the label "EAP long-term credential" and including 
text to explain that this credential might be instantiated in numerous ways:
"The EAP (long term) credential is the credential the peer and the 
server resort to when doing a full EAP authentication*. It might be a 
symmetric cryptography key, an asymmetric cryptography key, a one-time 
password generator,..."

My feeling was though that you only have (for now) essentially two types 
of credentials: symmetric and asymmetric ones.

Anyway, it is a minor issue but it in my opinion, naming the top of the 
tree would help to clarify things.

What do you think?

[Bernard Aboba] Here is the proposed resolution: 

Add the following definition to Section 2.1: 

Long Term Credential
EAP methods frequently m