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 make use of long term credentials in
order to enable authentication between the peer and server. 
In the case of a method based on pre-shared key authentication,
the long term credential is the pre-shared key. In the
case of a public-key based method, the long term
credential is the corresponding private key. 

Add a box to Figure 3 to show the Long Term Credential
(inside the EAP method). 

Proposed resolution: Accept

Issue 211: Fast reconnect
Submitter name: Florent Bersani
Submitter email address: florent.bersani@francetelecom.com
Date first submitted: 12/16/2003
Reference: 
Document:  RFC2284bis-07
Comment type: E
Priority: 2
Section: 7.2.1
Rationale/Explanation of issue:

Why provide fast reconnect features? Here, after re-reading EAP's latest version, I still think
that it might be worth a little more discussion. EAP states that "fast
reconnect" is "The ability, in the case where a security association
has been previously established, to create a new or refreshed security
association in a smaller number of round-trips. ". I guess here that
this leaves aside an important motivation for fast reconnect which is
processing power consumption: for example, with TLS, resuming a session
might save some asymmetric cryptography calculations which are known to
be pretty heavy. This might also be the case for EAP methods (eg.
EAP-TLS). I also tend to think that we could discuss another aspect of
fast reconnect which is the "depth" or "distance" of the round trips
rather than their number.

[Jari Arkko] I agree with all your points above. While I think that the RFC 2284bis
should not include guidance for all possible new features that one's
methods could do, it would still be good to clarify the definition
of fast reconnect. I think a better definition would be:

Fast reconnect
The ability, in the case where a security association has
been previously established, to create a new or refreshed
security association more efficiently or in a smaller number
of round-trips.

[BA] Proposed resolution: 

In Section 7.2.1, change the definition of Fast reconnect to:

"Fast reconnect
The ability, in the case where a security association has
been previously established, to create a new or refreshed
security association more efficiently or in a smaller number
of round-trips."

Proposed resolution: Accept

Issue 212: Protected Result Indications
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: 4.2
Rationale/Explanation of issue:

In section 4.2, 7th paragraph at the top of page 25, 1st
sentence, I cannot figure out what the sentence means:

"A mutually authenticating method (such as EAP-TLS 
[RFC2716]) that provides authorization error messages provides 
protected result indications for the purpose of this specification."

[BA] The proposed resolution is as follows:

In Section 4.2, 7th paragraph, change:

" A mutually authenticating method (such as EAP-TLS [RFC2716]) that
provides authorization error messages provides protected result
indications for the purpose of this specification. Within
EAP-TLS, the peer always authenticates the authenticator, and may
send a TLS-alert message in the event of an authentication
failure. An authenticator may use the "access denied" TLS alert
after successfully authenticating the peer to indicate that a
valid certificate was received from the peer, but when access
control was applied, the authenticator decided not to proceed. If
a method provides authorization error messages, the authenticator
SHOULD use them so as to ensure consistency with the final access
decision and avoid lengthy timeouts."

To:

"A mutually authenticating method may use error messages
to provide protected result indications. This ensures that the peer
and server are aware of each other's final access decision,
and prevents denial of service attacks as well as lengthy timeouts.

For example, within EAP-TLS [RFC2716], the peer
always authenticates the server, and sends a TLS alert message
in the event of an authentication or authorization failure.
If the server does not receive a TLS alert message from the
peer and the peer continues the conversation
to completion (e.g. sends a FINISHED message),
then the server can assume that the peer
will accept access if granted it by the server.

Similarly, the peer can assume that the server will grant
access if it does not receive a TLS alert message from the
server, and the server carries the conversation to completion
(e.g. sends a FINISHED message).

A server may use the "access denied" TLS alert
after successfully authenticating the peer to indicate that a
valid certificate was received from the peer, but when access
control was applied, the server decided not to proceed."

In Section 2.4, change:

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

To:

"   For example, EAP-TLS [RFC2716] is a client-server protocol in which
   distinct certificate profiles are typically utilized 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 certificates appropriate for each role."

In Section 2.4, change:

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

To:

"   [3] Peer policy satisfaction.  EAP methods may support protected result indications,
       enabling the peer to indicate to the EAP server within the method that it successfully authenticated the
       EAP server, as well as for the server to indicate that it has authenticated the peer.
       The pass-through authenticator is made aware that the peer has accepted the
       credentials offered by the EAP server via key attributes provided by the AAA protocol.

       However, it is possible that the EAP peer's access policy was not satisfied
       during the initial EAP exchange, even though mutual authentication occurred.
       For example, the EAP authenticator may not have demonstrated authorization to act in both
       peer and authenticator roles.  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."

In Section 7.10, change the first paragraph from:

"It is possible for the peer and EAP server to mutually authenticate
and derive keys.  In order to provide keying material for use in a
subsequently negotiated ciphersuite, an EAP method supporting key
derivation MUST export a Master Session Key (MSK) of at least 64
octets, and an Extended Master Session Key (EMSK) of at least 64
octets.  EAP Methods deriving keys MUST provide for mutual
authentication between the EAP peer and the EAP Server."

To:

"It is possible for the peer and EAP server to mutually authenticate
and derive keys.  In order to provide keying material for use in a
subsequently negotiated ciphersuite, an EAP method supporting key
derivation MUST export a Master Session Key (MSK) of at least 64
octets, and an Extended Master Session Key (EMSK) of at least 64
octets.    

EAP Methods supporting key derivation MUST also support mutual
authentication between the EAP peer and the EAP Server, as well as 
protected result indications."

[Jari Arkko] I still wonder about the protected result indications part and to which
extent current and proposed methods comply with that. For instance, is
EAP Archie's exchange considered a protected result indication, even if
it is performed as a part of the authentication exchange and not as a
separate "result exchange".

[Bernard Aboba] Key derivation protocols do not require a separate "result
exchange" in order for both sides to be kept in sync as to the authentication
state. If the parties mutually authenticate and prove possession of the
key then the only reason parties could be out of sync with respect to the
state is if one or both of them is not authorized. If the protocol
supports error messages, then the use of an error message is an explicit
failure indication and the completion of the protocol without an
error message (e.g. FINISHED message) is an implicit success indication. 

Looking at the EAP Archie security claims, EAP-Archie provides mutual
authentication and key derivation but does not claim to provide protected
result indications. Even though EAP-Archie has an Archie-FINISHED
message, it does not support any error messages, so that errors or lack of
authorization cannot be signaled.  There is therefore no way for an EAP-Archie
server or client to send an error indicating that the exchange has failed. 
This will result in long time outs and possible synchronization problems
between the client and the server.  So EAP-Archie seems to have a serious
design flaw that needs to be fixed.

> What about EAP AKA, does that satisfy the requirement?

EAP AKA has support for client error messages: AKA-Client-Error. However,
there is no support for server error messages, and the
EAP-Failure packet is used instead. If an attacker spoofs an
EAP Failure packet after mutual authentication, does the client have to
accept it? This looks like a DoS vulnerability that should be fixed. 

> It seems that the peer's response to an authenticated
> authentication request from the network can be considered to be a
> protected result indication, but I'm not sure if the reverse direction
> can be said to be indicated at the moment.

Yes, I think that is a correct assessment.

> More generally, on a shared secret-based method, how could the
> non-success of authentication be indicated so that the indication is
> still authenticated? If you found out that the shared secrets did not
> match, we can hardly authenticate the indication either... Or is it
> enough that you just show mutual possession of the shared secret?

Proving mutual possession of the shared secret is enough to provide mutual
authentication. However, there is a separate issue of authorization -- if
mutual authentication occurs, is this enough for both sides to know that
they are authorized? If not, then an authorization error message is required.
Since authentication and key derivation has occurred, this message can be MAC'd. 
If such a message is supported and is not sent, then this is an implicit
Success indication and the peer can silently discard EAP Failure packets.

So overall, it appears to me that lack of result indications in a 
protocol that provides mutual authentication and key derivation 
is typically the result of a design flaw. The MUST seems appropriate, though
obviously the result indications cannot always be protected (e.g.
if the error occurs prior to key derivation). 

[Pasi Eronen] I am against adding new "MUST" requirements at this stage,
especially if they are not absolutely necessary. 

The requirement that mutually authenticating methods must 
also support key derivation isn't probably that bad (it seems
that currently all do), but not all existing methods have
protected result indications. Furthermore, the definition
of "protected result indication" is so vague that it's not
easy to determine which current methods actually do that :-)

As Jari already pointed out, some failure indications 
simply can't be protected: if the authentication failed, 
how do you authenticate the result indication? 

Authenticating only success indications might be more feasible,
but I don't see any compelling reason to do that. Acknowledged
result indications are quite enough to avoid long timeouts
(in case of packet loss), and spoofing them doesn't lead to 
anything worse than DoS anyway.

Therefore, I suggest we keep the old text.

[Bernard Aboba] 

> Furthermore, the definition
> of "protected result indication" is so vague that it's not
> easy to determine which current methods actually do that :-)

That is part of what Russ's comment is about, and so I'd suggest that we
need to fix this.

> As Jari already pointed out, some failure indications
> simply can't be protected: if the authentication failed,
> how do you authenticate the result indication?

If you recall, the requirement was originally called "Acknowledged Result
indications", in recognition of the fact that the indications cannot
always be protected. The text was then changed to "Protected Result
indications" in an attempt to improve clarity, but that seems to have had
the opposite effect :(

> Authenticating only success indications might be more feasible,
> but I don't see any compelling reason to do that.

If mutual authentication and key derivation succeed, then one can assume
that there is an implicit indication of a successful result in the
absence of an error message to the contrary. So I'd agree that there is
no need for an explicit success indication.

> Acknowledged result indications are quite enough to avoid long timeouts

Yes.

> Therefore, I suggest we keep the old text.

The old text was apparently too vague to be useful, so keeping it probably
won't address all the concerns.

What I think we need is:

a. A definition of "protected result indications" sufficiently clear so
that we can understand if an EAP method provides it.

b. An understanding of whether we need an additional AAA attribute to tell
the authenticator when the peer has successfully authenticated it, or
whether the key attribute (and an Access Accept) is sufficient.

c. What the implications of a) and b) are in terms of method design.

[BA] Proposed resolution: 

In Section 4.2, 7th paragraph, delete:

" A mutually authenticating method (such as EAP-TLS [RFC2716]) that
provides authorization error messages provides protected result
indications for the purpose of this specification. Within
EAP-TLS, the peer always authenticates the authenticator, and may
send a TLS-alert message in the event of an authentication
failure. An authenticator may use the "access denied" TLS alert
after successfully authenticating the peer to indicate that a
valid certificate was received from the peer, but when access
control was applied, the authenticator decided not to proceed. If
a method provides authorization error messages, the authenticator
SHOULD use them so as to ensure consistency with the final access
decision and avoid lengthy timeouts."

In Section 7.2.1, change:

"   Protected result indications
             The ability within a method for the authenticator to
             indicate to the peer whether it has successfully
             authenticated to it, and for the peer to acknowledge
             receipt of that indication as well as indicating to the
             authenticator whether it has successfully authenticated to
             the peer.  Since EAP Success and Failure packets are
             neither acknowledged nor integrity protected, this claim
             requires implementation of a method-specific result
             exchange that is authenticated, integrity and replay
             protected on a per-packet basis."

To:

"Protected result indications
A method provides result indications if after the method
has finished (1) if the peer is willing to use the access provided
by the authenticator, it knows whether the authenticator will
grant access (that is, only either an EAP-Success or EAP-Failure will be accepted, no
more method specific messages are expected), and (2) if the authenticator decides to grant access, it knows
whether the peer will accept it. Result indications improve
resilience to packet loss; see Section 4.2 for discussion.
Depending on the method and circumstances, result indications
can be spoofable by an attacker. A method is said to provide protected
result indications if it supports result indications as well as the
"integrity protection" and "replay protection" claims. A method
claiming to support protected result indications MUST indicate which
result indications are protected, and which are not. See
Section 7.16 for details."

In Section 2.4, change:

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

To:

"   For example, EAP-TLS [RFC2716] is a client-server protocol in which
   distinct certificate profiles are typically utilized 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 certificates appropriate for each role."

In Section 2.4, change:

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

To:

"   [3] Peer policy satisfaction.  EAP methods may support protected result indications,
       enabling the peer to indicate to the EAP server within the method that it successfully authenticated the
       EAP server, as well as for the server to indicate that it has authenticated the peer.
       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.  The authenticator SHOULD interpret
       the receipt of a key attribute within an Accept packet
       as an indication that the peer has successfully authenticated
       and authorized the server.

       However, it is possible that the EAP peer's access policy was not satisfied
       during the initial EAP exchange, even though mutual authentication occurred.
       For example, the EAP authenticator may not have demonstrated authorization to act in both
       peer and authenticator roles.  As a result, the peer may require an additional authentication in the
       reverse direction, even if the peer provided an indication that the EAP server had
       successfully authenticated to it."

Add Section 7.16:

"7.16 Protected Result Indications

EAP Success and Failure packets are
neither acknowledged nor integrity protected.
This creates a potential vulnerability to
spoofing, as well as lengthy timeouts.

To address this vulnerability, EAP methods
may implement protected result indications.
Since protected result indications require
use of a key for per-packet authentication and
integrity protection, methods supporting
protected result indications MUST also
support the "key derivation", "mutual authentication"
"integrity protection" and "replay protection" claims.

Result indications may be implicit
or explicit. For example, a method may use
error messages in order to explicitly indicate
a failure, while the completion of
mutual authentication and key derivation without
an error message implicitly indicates a successful
result.

For example, within EAP-TLS [RFC2716], the peer
always authenticates the server, and sends a TLS alert message
in the event of an authentication or authorization failure.
If the server does not receive a TLS alert message from the
peer and the peer continues the conversation
to completion (e.g. sends a FINISHED message),
then the server can assume that the peer
will accept access if granted it by the server.

Similarly, the peer can assume that the server will grant
access if it does not receive a TLS alert message from the
server, and the server carries the conversation to completion
(e.g. sends a FINISHED message).

A server may use the "access denied" TLS alert
after successfully authenticating the peer to indicate that a
valid certificate was received from the peer, but when access
control was applied, the server decided not to proceed."

Proposed Resolution: Accept

Issue 213: Cleanup issues
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 1/20/2004
Reference: 
Document: RFC 2284bis-08.l
Comment type: T
Priority: S
Section: 3.1, 4.2, 7.2.1
Rationale/Explanation of issue:

This is a generic issue to cleanup some of the text as reflected in WG discussions. 

In Section 2.4 change:

"The authenticator SHOULD
interpret the receipt of a key attribute within an Accept packet 
as an indication that the peer has successfully authenticated and 
authorized the server." 

To:

"The authenticator SHOULD
interpret the receipt of a key attribute within an Accept packet
as an indication that the peer has successfully authenticated 
the server."

In Section 4.2, change:

" On the peer, once the method completes unsuccessfully (that is,
either the authenticator sends a method-specific failure
indication, or the peer decides that it does want to continue the
conversation, possibly after sending a method-specific failure
indication), the peer MUST terminate the conversation and indicate
failure to the lower layer."

To:


" On the peer, once the method completes unsuccessfully (that is,
either the authenticator sends a method-specific failure
indication, or the peer decides that it does not want to continue the
conversation, possibly after sending a method-specific failure
indication), the peer MUST terminate the conversation and indicate
failure to the lower layer."

In Section 4.2, change:

"     As described in Section 2.1, only a single EAP authentication
      method is allowed within an EAP conversation. EAP methods MAY
      implement protected result indications. "

To:

"     As described in Section 2.1, only a single EAP authentication
      method is allowed within an EAP conversation. EAP methods may
      implement method-specific result indications."

Proposed Resolution: Accept

Issue 214: Keying appendix E vs. EMSK guidelines
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: Jan 21, 2004
Reference:
Document: Keying Framework-01
Comment type: T
Priority: 1
Section: Appendix E
Rationale/Explanation of issue:

Appendix E of keying-01 talks about the derivation of
suitable AAA Keys for handoff situations. It gives the
following formulae:

    AAA-Key-B      = PRF(EMSK(0,63),AAA-Key-A,
                     B-Called-Station-Id,Calling-Station-Id)

    AAA-Key-E      = PRF(EMSK(0,63),AAA-Key-A,
                     E-Called-Station-Id,Calling-Station-Id)

But draft-salowey-eap-keying-02 discusses EMSK usage, and
I think we have agreed at least about this:

      o The application MUST NOT use the EMSK in any other way except to
         derive Application Master Session Keys (AMSK) using the key
         derivation specified in section 3 this document.  They MUST NOT
         use the EMSK directly.

      o Applications MUST define distinct key labels and application
         specific data used in the key derivation described in section 3.

Appendix E appears to break the second requirement. Joe's
draft gives the following construction for AMSKs:

       AMSK = KDF(EMSK, key label, optional application data, length)

Perhaps appendix E could be corrected to be inline with this?
Here's the suggested text change:

    AAA-Key-B      = PRF(EMSK(0,63),"EAP AAA-Key derivation for multiple attachments",
                     AAA-Key-A,B-Called-Station-Id,Calling-Station-Id)

    AAA-Key-E      = PRF(EMSK(0,63),"EAP AAA-Key derivation for multiple attachments",
                     AAA-Key-A,E-Called-Station-Id,Calling-Station-Id)

Also, the rules about the calling and called station ids could perhaps
be made less link layer specific:

     Calling-Station-Id  = STA MAC address
     B-Called-Station-Id = AP B MAC address
     E-Called-Station-Id = AP E MAC address

=>

     Calling-Station-Id  = peer identity
     B-Called-Station-Id = second attachment point identity
     E-Called-Station-Id = third attachment point identity

[BA] Here are the proposed fixes:

Change Appendix E to the following:

Appendix E. AAA-Key Derivation

Where a AAA-Key is generated as the result of a successful EAP 
authentication, the AAA-Key is set to MSK(0,63). 

As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758],
[IEEE-03-084], and [8021XHandoff], keying material may be required
for use in fast handoff between authenticators. Where the
backend authentication server provides keying material to multiple
authenticators in order to fascilitate fast handoff, it is highly
desirable for the keying material used on different authenticators to
be cryptographically separate, so that if one authenticator is
compromised, it does not lead to the compromise of other
authenticators. Where keying material is provided by the backend
authentication server, a key hierarchy derived from the EMSK, 
can be used to provide cryptographically separate keying material 
for use in fast handoff:

[Joe] DO you think that keys will always be distributed from the AAA or
may it be distributed from a separate server?  If it is possible that
you may want to distribute this functionality then you should derive a
separate AMSK from the EMSK so you avoid exporting the EMSK. 

AAA-Key-A = MSK(0,63)

AAA-Key-B = PRF(EMSK(0,63),"EAP AAA-Key derivation for multiple attachments",
AAA-Key-A,B-Called-Station-Id,Calling-Station-Id)

[Joe] AAA-Key-B = PRF(EMSK(0,63),"EAP AAA-Key derivation for 
multiple attachments",
AAA-Key-A,B-Called-Station-Id,Calling-Station-Id,length)


AAA-Key-E = PRF(EMSK(0,63),"EAP AAA-Key derivation for multiple attachments",
AAA-Key-A,E-Called-Station-Id,Calling-Station-Id)

[Joe] AAA-Key-E = PRF(EMSK(0,63),"EAP AAA-Key derivation for 
multiple attachments",
AAA-Key-A,E-Called-Station-Id,Calling-Station-Id, length)

Where:

Calling-Station-Id = peer identity
B-Called-Station-Id = second attachment point identity
E-Called-Station-Id = third attachment point identity

[Joe] length = length of derived key material

Here AAA-Key-A is the AAA-Key derived during the initial EAP
authentication between the peer and authenticator A. Based on this
initial EAP authentication, the EMSK is also derived, which can be
used to derive AAA-Keys for fast authentication between the EAP peer
and authenticators B and E. Since the EMSK is cryptographically
separate from the MSK, each of these AAA-Keys is cryptographically
separate from each other, and are guaranteed to be unique between the
EAP peer (also known as the STA) and the authenticator (also known as
the AP).

[BA] Here is the final text:

"Appendix E - AAA-Key Derivation

Where a AAA-Key is generated as the result of a successful EAP 
authentication, the AAA-Key is set to MSK(0,63).

As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758],
[IEEE-03-084], and [8021XHandoff], keying material may be required
for use in fast handoff between authenticators. Where the
backend authentication server provides keying material to multiple
authenticators in order to fascilitate fast handoff, it is highly
desirable for the keying material used on different authenticators to
be cryptographically separate, so that if one authenticator is
compromised, it does not lead to the compromise of other
authenticators. Where keying material is provided by the backend
authentication server, a key hierarchy derived from the EMSK, 
can be used to provide cryptographically separate keying material 
for use in fast handoff:

AAA-Key-A = MSK(0,63)
AAA-Key-B = PRF(EMSK(0,63),"EAP AAA-Key derivation for 
multiple attachments", AAA-Key-A,B-Called-Station-Id,
Calling-Station-Id,length)

AAA-Key-E = PRF(EMSK(0,63),"EAP AAA-Key derivation for 
multiple attachments",AAA-Key-A,E-Called-Station-Id,
Calling-Station-Id, length)

Where:
Calling-Station-Id = STA MAC address
B-Called-Station-Id = AP B MAC address
E-Called-Station-Id = AP E MAC address
length = length of derived key material 

Here AAA-Key-A is the AAA-Key derived during the initial EAP
authentication between the peer and authenticator A. Based on this
initial EAP authentication, the EMSK is also derived, which can be
used to derive AAA-Keys for fast authentication between the EAP peer
and authenticators B and E. Since the EMSK is cryptographically
separate from the MSK, each of these AAA-Keys is cryptographically
separate from each other, and are guaranteed to be unique between the
EAP peer (also known as the STA) and the authenticator (also known as
the AP)."

Proposed Resolution: Accept

Issue 215: Comments on Section 3 of Key Framework
Submitter name: Joe Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted: 1/21/2004
Reference: http://mail.frascone.net/pipermail/public/eap/2004-January/002170.html
Document: Keying Framework
Comment type: 'E'ditorial
Priority: '1' Should fix
Section: Section 3
Rationale/Explanation of issue:

1.  Use of term "security Association":

In section 3 the use of term security association is somewhat
non-standard.  A security association is typically something that is
generated dynamically and valid for a length of time.

[1] The EAP-SA is more of a static relationship such as a trusted root
key.
[2] The EAP-Method SA is more along the lines of standard SA
terminology.  It is not visible outside the EAP-method.
[3] The EAP-Key SA I do not think is really an SA.  There are
EAP-Key(s), but they must be managed outside the EAP protocol since EAP
provides no key management functionality other than establishment.
These EAP-Seeded SAs are managed by some other application separate from
EAP.  Examples of EAP Seeded SA are in section 3.5
[4] The AAA-SA is similar to [1] above in that there is a trusted root
key.

There are also "EAP-Seeded" SAs of which 3.5 is an example

Recommended Changes:

Use a different term than security association for other relationships
or don't discuss them in this section.

I'm not sure that so much detail is needed for the EAP-Method SA since
it is not visible outside a method.

Create  section on EAP-Seeded SAs which describes Unicast SA and other
possible SA based on the exchanged EAP keys.

DO not use the term EAP SA as it confusing as to what is being
discussed. 

I'm not sure that multicast security association needs to be discussed
as it is usually is derived from a unicast security association and not
directly involved with EAP

2. Key Naming (Section 3.7)

I think the only thing that needs to be named within the scope of EAP is
the MSK and the EMSK resulting from a particular EAP exchange.  This
needs to be defined by the method. Here is some suggested text:

"EAP methods are responsible for defining and exporting a key name.  The
base EAP key name is an octet string between 15 and 31 octets.  To name
the MSK a M is prepended to the base name and for the EMSK a 'E' is
prepended to the base name.   The method for generating a base name is
specific to the method, but it must be unique to each exchange and
cryptographically bound to the exchange.  An example for EAP-TLS is to
take MD5 hash of the two finished messages in the TLS handshake in the
order that they appear.  It is NOT RECOMMENDED that a static function of
the MSK or EMSK be used as publically known name. Other applications may
use the EAP key name to derive names for their purposes that have
additional meaning.  "

[Bernard Aboba] The term "long term" credential is being used now instead of
"security association" where this is more accurate. 

A section on EAP-seeded SAs is indeed needed. This
requires a rewrite of the "Service SA" section. 

The multicast SA is not always derived from the unicast SA,
it seems to me. For example, with IKEv2/EAP, only a unicast
SA is derived; the multicast SA if it is derived at all would
have to be derived via GKMP, and I'm not sure how EAP would
be involved in that. I think some more text describing the
relationship is needed. 

However, I don't believe that the exported portion of the EAP key
hierarchy can be method-specific (MSK, EMSK, IV and keys derived from
them). That would introduce method dependencies into both the AAA and
Secure Association Protocol, which would violate one of the EAP
invariants -- method independence. Also, existing methods don't export key names.    

I'm rewritting Section 3 to address Joe's concerns and
also to sync up the terms and text with IEEE 802.11i
Section 8.4 "Security Association Management." See:

http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-03_a.txt

[Jari Arkko] In general, I agree with what Joe is saying and
with Bernard's response.

Here's what I would recommend:

- Remove the concept of an EAP Key SA; I think the
Section 2 key terms (MSK, EMSK, ...) are more than
sufficient.

- Discuss only *SA* naming in 3.5, move rest to a
new section under section 2.

- Stick to the "Service SA" name which I like better than
"EAP Seeded SAs".

- Re-organize key naming. I don't believe we currently
rely on the key names in anything, so I think we have
a freedom to make a change. Here's the principles I
used

 - Start with the type identifier to avoid accidental
or malicious collisions.
- Continue with the method type, again for the same
reason.
- Name all keys in the same way
- Just name the thing with the concatenation of
a set of parameters rather than using a PRF,
because then we can avoid the discussion of which
PRF to use.

Here's an attempted small rewrite/reorg of Section 3.
You will find attached the original file part that I
started from (taken a few minutes ago from your web
Bernard), my edited result, and the diff.

Editorials:

- In Section 3.1.2, change

o The client's permanent identity (IMSI) (server)

to

o The client's permanent identity (IMSI)

- Move Section 2.5 under Section 4, maybe as the
last subsection there. Then the text flows better
from Section 2 to Section 3.

- Appendix E does not define the PRF function it uses.
Suggestion: As this is an example only, we could say

PRF = Some suitable pseudo-random function

2.6 Key Naming

MSK Name

This key is created between the EAP peer and EAP server, and is
uniquely named by the concatenation of the string "MSK", EAP
Method Type, EAP peer name, EAP server name, EAP peer nonce, and
the EAP server nonce. Here the EAP peer name and EAP server name
are the identifiers securely exchanged within the EAP method.
Since multiple MSKs may exist between an EAP peer and EAP server,
the EAP peer nonce and EAP server nonce allow MSKs to be
differentiated; at least one of these nonces is necessary. The
inclusion of the Method Type in the name ensures that each EAP
method has a distinct name space.

Note that the components of the MSK Name are only known by the
EAP method. As a result, the MSK Name is exported out of the
method, and no detailed format of the MSK Name can be specified
without a reference to a particular method.

EMSK Name

The EMSK is named similarly to the above. Its name is the
concatenation of the string "EMSK", EAP Method Type, EAP peer
name, EAP server name, EAP peer nonce, and the EAP server nonce.

AMSK Name

AMSKs, if any, may be named by the concatenation of the string
"AMSK", EMSK Name, key label, and application data (see Appendix
F).

AAA-Key Name

The AAA-Key is named by the concatenation of the string
"AAA-Key", MSK Name, and the authenticator name, since the
AAA-Key is bound to a particular authenticator. For the purpose
of identification, the NAS-Identifier attribute is recommended.
In order to ensure that all parties can agree on the NAS name
this requires the NAS to advertise its name (typically using a
media-specific mechanism, such as the 802.11 Beacon/Probe
Response)."

PMK Name

The PMK has no name of its own, and is only identified by the
AAA-Key from which it is derived.

TEKs

The TEKs may or may not be named. Their naming is specified in
the EAP method.

TSKs

The TSKs are typically named. Their naming is specified in
the Secure Association protocol.


3. Security Associations

During EAP authentication and subsequent exchanges, three types of
security associations (SAs) are created:

[1] EAP method SA. This SA is between the peer and EAP server. It
stores state that can be used for "fast resume" or other
functionality in some EAP methods. Not all EAP methods create such
an SA.

[2] AAA SA(s). These SAs are between the authenticator and the backend
authentication server. They permit the parties to mutually
authenticate each other and protect the communications between
them.

[3] Service SA(s). These SAs are between the peer and authenticator,
and they are created as a result of phases 1-2 of the conversation
(see Section 1.3).

3.1. EAP Method SA (peer - EAP server)

An EAP method may store some state on the peer and EAP server even
after phase 1a has completed.

Typically, this is used for "fast resume": the peer and EAP server
can confirm that they are still talking to the same party, perhaps
using fewer roundtrips or less computational power. In this case,
the EAP method SA is essentially a cache for performance
optimization, and either party may remove the SA from its cache at
any point.

An EAP method may also keep state in order to support pseudonym-based
identity protection. This is typically a cache as well (the
information can be recreated if the original EAP method SA is lost),
but may be stored for longer periods of time.

The EAP method SA is not restricted to a particular service or
authenticator and is most useful when the peer accesses many
different authenticators.

An EAP method is responsible for specifying how the parties select if
an existing EAP method SA should be used, and if so, which one.
Where multiple backend authentication servers are used, EAP method
SAs are not typically synchronized between them.

EAP method implementations should consider the appropriate lifetime
for the EAP method SA. "Fast resume" assumes that the information
required (primarily the keys in the EAP method SA) hasn't been
compromised. In case the original authentication was carried out
using, for instance, a smart card, it may be easier to compromise the
EAP method SA (stored on the PC, for instance), so typically the EAP
method SAs have a limited lifetime.

Contents:

o Implicitly, the EAP method this SA refers to
o One or more internal (non-exported) keys
o EAP method SA name
o SA lifetime

3.1.1. Example: EAP-TLS

In EAP-TLS [RFC2716], after the EAP authentication the client (peer)
and server can store the following information:


o Implicitly, the EAP method this SA refers to (EAP-TLS)
o Session identifier (a value selected by the server)
o Certificate of the other party (server stores the clients's
certificate and vice versa)
o Ciphersuite and compression method
o TLS Master secret (known as the EAP-TLS Master Key or MK)
o SA lifetime (ensuring that the SA is not stored forever)
o If the client has multiple different credentials (certificates
and corresponding private keys), a pointer to those credentials

When the server initiates EAP-TLS, the client can look up the EAP-TLS
SA based on the credentials it was going to use (certificate and
private key), and the expected credentials (certificate or name) of
the server. If an EAP-TLS SA exists, and it is not too old, the
client informs the server about the existence of this SA by including
its Session-Id in the TLS ClientHello message. The server then looks
up the correct SA based on the Session-Id (or detects that it doesn't
yet have one).

3.1.2. Example: EAP-AKA

In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the
client and server can store the following information:

o Implicitly, the EAP method this SA refers to (EAP-AKA)
o A re-authentication pseudonym
o The client's permanent identity (IMSI)
o Replay protection counter
o Authentication key (K_aut)
o Encryption key (K_encr)
o Original Master Key (MK)
o SA lifetime (ensuring that the SA is not stored forever)


When the server initiates EAP-AKA, the client can look up the EAP-AKA
SA based on the credentials it was going to use (permanent identity).
If an EAP-AKA SA exists, and it is not too old, the client informs
the server about the existence of this SA by sending its re-
authentication pseudonym as its identity in EAP Identity Response
message, instead of its permanent identity. The server then looks up
the correct SA based on this identity.

3.2. AAA SA(s) (authenticator - backend authentication server)

In order for the authenticator and backend authentication server to
authenticate each other, they need to store some information.

In case the authenticator and backend authentication server are
colocated, and they communicate using local procedure calls or shared
memory, this SA need not necessarily contain any information.

3.2.1. Example: RADIUS

In RADIUS, where shared secret authentication is used, the client and
server store each other's IP address and the shared secret, which is
used to calculate the Response Authenticator [RFC2865] and Message-
Authenticator [RFC3579] values, and to encrypt some attributes (such
as the AAA-Key [RFC2548]).

Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for
key management, the parties store information necessary to
authenticate and authorize the other party (e.g. certificates, trust
anchors and names). The IKE exchange results in IKE Phase 1 and
Phase 2 SAs containing information used to protect the conversation
(session keys, selected ciphersuite, etc.)

3.2.2. Example: Diameter with TLS

When using Diameter protected by TLS, the parties store information
necessary to authenticate and authorize the other party (e.g.
certificates, trust anchors and names). The TLS handshake results in
a short-term TLS SA that contains information used to protect the
actual communications (session keys, selected TLS ciphersuite, etc.).

3.3. Service SA(s) (peer - authenticator)

The service SA stores information about the service being provided.
This includes:

o Service parameters (or at least those parameters
that are still needed)
o On the authenticator, service authorization
information received from the backend authentication
server (or necessary parts of it)
o On the peer, usually locally configured service
authorization information.
o Transient Session Keys used to protect the communication
o The AAA-Key, if it can be needed again (to refresh
and/or resynchronize other keys or for another reason)
o AAA-Key lifetime

The information in the service SA can be grouped into several
different SAs. This would make sense if, for instance, the service
provided is naturally divided into several different subconversations
with different parameters.

How exactly the relevant service SA is chosen at each point depends
on the protocol; see below for examples.

3.3.1. Example: 802.11i

[IEEE802.11i] Section 8.4.1.1 defines the security associations used
within IEEE 802.11. A summary follows; the standard should be
consulted for details.

o Pairwise Master Key Security Association (PMKSA)

The PMKSA is a bi-directional SA, used by both parties for sending
and receiving. It is created on the peer when EAP authentication
completes successfully or a pre-shared key is configured. The
PMKSA is created on the authenticator when the PMK is received or
created on the authenticator or a pre-shared key is configured.
The PMKSA is used to create the PTKSA. PMKSAs are cached for
their lifetimes. The PMKSA consists of the following elements:

- PMKID (security association identifier)
- Authenticator MAC address
- PMK
- Lifetime
- Authenticated Key Management Protocol (AKMP)
- Authorization parameters specified the AAA server or
by local configuration. This can include
parameters such as the peer's authorized SSID.
On the peer, this information can be locally
configured.
- Key replay counters (for EAPOL-Key messages)
- Reference to PTKSA (if any), needed to:
o delete it (e.g. AAA server initiated disconnect)
o replace it when a new four-way handshake is done
- Reference to accounting context (the details of which depend
on the accounting protocol used, and various implementation
and administrative details. In RADIUS, this could include
(e.g. packet and octet counters, and Acct-Multi-Session-Id).

 o Pairwise Transient Key Security Association (PTKSA)

The PTKSA is a bi-directional SA created as the result of a
successful four-way handshake. There may only be one PTKSA
between a pair of peer and authenticator MAC addresses. PTKSAs
are cached for the lifetime of the PMKSA. Since the PTKSA is tied
to the PMKSA, it only has the addititional information from the
4-way handshake. The PTKSA consists of the following:

- Key (PTK)
- Selected ciphersuite
- MAC addresses of the parties
- Replay counters, and ciphersuite specific state
- Reference to PMKSA: This is needed when:
o A new four-way handshake is needed (lifetime, TKIP
countermeasures), and we need to know which PMKSA to use

o Group Transient Key Security Association (GTKSA)

The GTKSA is a uni-directional SA created based on the four-way
handshake or the group key handshake. A GTKSA consists of the
following:

- Direction vector (whether the GTK is used for transmit or receive)
- Group cipher suite selector
- Key (GTK)
- Authenticator MAC addres
- Via reference to PMKSA, or copied here:
o Authorization parameters
o Reference to accounting context

3.3.2. Example: IKEv2/IPsec

Note that this example is intended to be informative, and it does not
necessarily include all information stored.

o IKEv2 SA

- Protocol version
- Identitities of the parties
- IKEv2 SPIs
- Selected ciphersuite
- Replay protection counters (Message ID)
- Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er)
- Key for deriving keys for IPsec SAs (SK_d)
- Lifetime information
- On the authenticator, service authorization information
received from the backend authentication server.

When processing an incoming message, the correct SA is looked up based
on the SPIs.

o IPsec SAs/SPD

- Traffic selectors
- Replay protection counters
- Selected ciphersuite
- IPsec SPI
- Keys
- Lifetime information
- Protocol mode (tunnel or transport)

The correct SA is looked up based on SPI (for inbound packets), or
SPD traffic selectors (for outbound traffic). A separate IPsec SA
exists for each direction.

3.3.3. Sharing service SAs

A single service may be provided by multiple logical or physical
service elements. Each service is responsible for specifying how
changing service elements is handled. Some approaches include:

Transparent sharing
If the service parameters visible to the other party (either peer
or authenticator) do not change, the service can be moved without
requiring cooperation from the other party.

Whether such a move should be supported or used depends on
implementation and administrative considerations. For instance, an
administrator may decide to configure a group of IKEv2/IPsec
gateways in a cluster for high-availability purposes, if the
implementation used supports this. The peer does not necessarily
have any way of knowing when the change occurs.

No sharing
If the service parameters require changing, some changes may
require terminating the old service, and starting a new
conversation from phase 0. This approach is used by all services
for at least some parameters, and it doesn't require any protocol
for transferring the service SA between the service elements.

The service may support keeping the old service element active
while the new conversation takes phase, to decrease the time the
service is not available.

Some sharing
The service may allow changing some parameters by simply agreeing
about the new values. This may involve a similar exchange as in
phase 2, or perhaps a shorter conversation.

 This option usually requires some protocol for transferring the
service SA between the elements. An administrator may decide not to
enable this feature at all, and typically the sharing is restricted
to some particular service elements (defined either by a service
parameter, or simple administrative decision). If the old and new
service element do not support such "context transfer", this
approach falls back to the previous option (no transfer).

Services supporting this feature should also consider what changes
require new authorization from the backend authentication server
(see Section 1.7).

Note that these considerations are not limited to service
parameters related to the authenticator--they apply to peer's
parameters as well.

3.4. SA Naming

In order to support the correct processing of phase 2 security
associations, the Secure Association (phase 2) protocol supports the
naming of phase 2 security associations and associated transient
session keys, so that the correct set of transient session keys can
be identified for processing a given packet. Explicit creation and
deletion operations are also typically supported so that
establishment and re-establishment of transient session keys can be
synchronized between the parties.

In order to securely bind the AAA SA (phase 1b) to its child phase 2
security associations, the phase 2 Secure Association Protocol allows
the EAP peer and authenticator to mutually prove possession of the
AAA-Key. In order to avoid confusion in the case where an EAP peer
has more than one AAA-Key (phase 1b) applicable to establishment of a
phase 2 security association, it is necessary for the secure
Association Protocol (phase 2) to support key selection, so that the
appropriate phase 1b keying material can be utilized by both parties
in the Secure Association Protocol exchange.

For example, a peer might be pre-configured with policy indicating
the ciphersuite to be used in communicating with a given
authenticator. Within PPP, the ciphersuite is negotiated within the
Encryption Control Protocol (ECP), after EAP authentication is
completed. Within [IEEE80211i], the AP ciphersuites are advertised
in the Beacon and Probe Responses, and are securely verified during a
4-way exchange after EAP authentication has completed.

As part of the Secure Association Protocol (phase 2), it is necessary
to bind the Transient Session Keys (TSKs) to the keying material
provided in the AAA-Token. This ensures that the EAP peer and
authenticator are both clear about what key to use to provide mutual
proof of possession.

[BA] OK.  Folded in Jari's changes, plus a bunch more of my own. See:

http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-03_a.txt

Proposed Resolution: Accept

Issue 216: MSK issues
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: 1/21/2004
Reference: http://mail.frascone.net/pipermail/public/eap/2004-January/002172.html
Document: Keying Framework-01
Comment type: 'T'echnical
Priority: 'S'
Section: Section 2.3, 4.1
Rationale/Explanation of issue:

Here's a summary of the modifications I would do to fix this:

   o  In Figure 4, s/MSK/AAA-Key/ in the Authenticator box.

   o  In Section 4.1, replace the paragraph

    "Utilizing the AAA protocol, the authenticator and backend
    authentication server mutually authenticate and derive session keys
    known only to them, used to provide per-packet integrity and replay
    protection, authentication and confidentiality.  The MSK is
    distributed by the backend authentication server to the authenticator
    over this channel, bound to attributes constraining its usage, as
    part of the AAA-Token.  The binding of attributes to the MSK within a
    protected package is important so the authenticator receiving the
    AAA-Token can determine that it has not been compromised, and that
    the keying material has not been replayed, or mis-directed in some
    way."

           with:

    "Utilizing the AAA protocol, the authenticator and backend
    authentication server mutually authenticate and derive session keys
    known only to them, used to provide per-packet integrity and replay
    protection, authentication and confidentiality.  The AAA-Key is
    distributed by the backend authentication server to the authenticator
    over this channel, bound to attributes constraining its usage, as
    part of the AAA-Token.  The binding of attributes to the AAA-Key within a
    protected package is important so the authenticator receiving the
    AAA-Token can determine that it has not been compromised, and that
    the keying material has not been replayed, or mis-directed in some
    way."

   o  Section 2.3, replace the paragraph

    The MSK and EMSK are used to derive the AAA-Key and key name which
    are enclosed within the AAA-Token, transported to the  NAS by the AAA
    server, and used within the secure association protocol for
    derivation of Transient Session Keys (TSKs) required for the
    negotiated ciphersuite.

           with

    The MSK and EMSK are used to derive the AAA-Key and key name. AAA-Key
    and key name are enclosed within the AAA-Token, which is transported to the
    NAS by the AAA server, and used within the secure association protocol for
    derivation of Transient Session Keys (TSKs) required for the
    negotiated ciphersuite.

Proposed Resolution: Accept

Issue 217: Result Indications
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 1/20/2004
Reference: 
Document: RFC 2284bis-08.l
Comment type: T
Priority: S
Section: 7.2.1
Rationale/Explanation of issue:

In Section 7.2.1, change:

"   Protected result indications
             A method provides result indications if after the method
             has finished (1) if the peer is willing to use the access
             provided by the authenticator, it knows whether the
             authenticator will grant access (that is, only either an
             EAP-Success or EAP-Failure will be accepted, no more method
             specific messages are expected), and (2) if the
             authenticator decides to grant access, it knows whether the
             peer will accept it.  Result indications improve resilience
             to packet loss; see Section 4.2 for discussion. Depending
             on the method and circumstances, result indications can be
             spoofable by an attacker.  A method is said to provide
             protected result indications if it supports result
             indications as well as the "integrity protection" and
             "replay protection" claims.  A method claiming to support
             protected result indications MUST indicate which result
             indications are protected, and which are not.  See Section
             7.16 for details."

To:

Protected result indications
A method provides result indications if after the 
method has finished:

1) When peer is willing to accept access to the network, it knows whether 
the authenticator will grant access.

2) When the peer decides to grant access, it knows 
whether the peer will accept it.

Result indications improve resilience to packet loss, 
and prevent long timeouts; see Section 4.2 for discussion. 
Depending on the method design and circumstances, result 
indications may be vulnerable to spoofing or replay by an attacker. 

A method is said to provide protected result indications if 
it supports result indications as well as the 
"integrity protection" and "replay protection" claims. 
A method claiming to support protected result indications 
MUST indicate which result indications are protected, and 
which are not. See Section 7.16 for details."

[Joe Salowey] Here again we have a mix of authentication and authorization.  It
would be better to qualify the above statement.

"Protected result indications
A method provides result indications if after the
method has finished:

1) When the peer successfully completes the authentication, it
knows whether the authenticator has successfully completed the
authentication.

2) When the authenticator successfully completes the authentication, it
knows whether the peer has successfully completed the authentication.

In the case where successful authentication is sufficient to authorize
access then the peer and authenticator will also know if the other party
is willing to provide or accept access.  This may not always be the
case."

[Bernard Aboba] I think there may be multiple issues lurking here.  These include:

1.  DoS attacks due to forged Failure packets.
2.  Man-in-the-middle attacks due to forged Success packets.
3.  Timeouts caused by loss of Success and failure packets.

Let me try to review what RFC 2284bis-08 says about these issues, so that
we can understand if it makes sense.

First, there is Section 4.2:

"  Success and Failure packets MUST NOT be sent by an EAP authenticator
   if the specification of the given method does not explicitly permit
   the method to finish at that point.  A peer EAP implementation
   receiving a Success or Failure packet where sending one is not
   explicitly permitted MUST silently discard it.  By default, an EAP
   peer MUST silently discard a "canned" Success packet (a Success
   packet sent immediately upon connection).  This ensures that a rogue
   authenticator will not be able to bypass mutual authentication by
   sending a Success packet prior to conclusion of the EAP method
   conversation."

To my mind this paragraph targets problems 2&3. For example, in a
mutually authenticating method, a Success packet sent prior to completion
of the mutual authentication (e.g. in EAP-TLS, before receipt of the
FINISHED message from the server) would be silently discarded by the peer.
Since a successful mutual authentication results in derivation of a key,
protection against a forged Success can rely on mutual proof of possession
of the derived key.  This proof of possession can at the same time ensure
synchronized peer and server state.  The end result is that the peer
authenticates the server, and also receives an indication that the server
will grant access.  The server authenticates the peer and receives an
indication from the peer that it will accept the granted access.
Note that this is really only the definition of a protected SUCCESS
indication.

The issue of forged Success packets was first raised by the University of
Maryland, and much of the state machine, 802.1X-REV and RFC 2284bis effort
has been oriented toward resolving this.

To some extent this paragraph helps with problem 1, but only partially. A
method-specific failure indication can only be protected if it is sent
after key derivation.  If the method gets as far as allowing both sides to
mutually authenticate and derive a key, the failure message is almost by
definition an "authorization failure" message.  That is, if the key is
derived and used to protect the error message, and the peer can
successfully verify the MIC, then authentication has succeeded.
This kind of protected error message is definitely useful because it
prevents what otherwise might be a long timeout on the peer side.  But it
does not address the DoS vulnerability because forged messages can be sent
at many points prior to key derivation that would successfully disrupt the
method exchange.

In reading the currently proposed definition of "Protected Result
Indication" I don't think that it covers this case -- a protected FAILURE
indication.

Back to the text of Section 4.2:

      Implementation Note: Because the Success and Failure packets are
      not acknowledged, they are not retransmitted by the authenticator,
      and may be potentially lost.  A peer MUST allow for this
      circumstance as described in this note.  See also Section 3.4 for
      guidance on the processing of lower layer success and failure
           indications.

Hmm.  Clearly the text seems to imply that a peer MUST do something to
handle the loss of Success and Failure packets, but I think the text could
be more clear on what an implementation needs to do to be compliant.  I
think there is an implication that the peer needs to implement the
recommendations in Section 3.4.  Or perhaps the requirement has to do with
the interface between the EAP layer and lower layer? Section 3.4 only has
a single normative word (a "MAY") so one searches in vain for requirements
there.

      As described in Section 2.1, only a single EAP authentication
      method is allowed within an EAP conversation. EAP methods MAY
      implement protected result indications. After the authenticator
      sends a method-specific failure indication to the peer, regardless
      of the response from the peer, it MUST subsequently send a Failure
      packet.  After the authenticator sends a method-specific success
      indication to the peer, and receives a method-specific success
      indication from the peer, it MUST subsequently send a Success
           packet.

This paragraph talks about something that an EAP method MAY do.  However,
the actions to be taken here don't depend on whether the method-specific
indication is protected or not.  So perhaps the word "protected" should be
removed from the second sentence.

      On the peer, once the method completes unsuccessfully (that is,
      either the authenticator sends a method-specific failure
      indication, or the peer decides that it does want to continue the
      conversation, possibly after sending a method-specific failure
      indication), the peer MUST terminate the conversation and indicate
      failure to the lower layer.  The peer MUST silently discard
      Success packets and MAY silently discard Failure packets.  As a
      result, loss of a Failure packet need not result in a timeout.

I think we have a typo here.  Shouldn't "it does want" be "it does not
want"?

      On the peer, after protected successful result indications have
      been exchanged by both sides, a Failure packet MUST be silently
      discarded.  The peer MAY, in the event that an EAP Success is not
      received, conclude that the EAP Success packet was lost and that
      authentication concluded successfully.

      If the authenticator has not sent a method-specific result
      indication, and the peer is willing to continue the conversation,
      once the method completes the peer waits for a Success or Failure
      packet and MUST NOT silently discard either of them.  In the event
      that neither a Success nor Failure packet is received, the peer
      SHOULD terminate the conversation to avoid lengthy timeouts in
      case the lost packet was an EAP Failure.

      If the peer attempts to authenticate to the authenticator and
      fails to do so, the authenticator MUST send a Failure packet and
      MUST NOT grant access by sending a Success packet.  However, an
      authenticator MAY omit having the peer authenticate to it in
      situations where limited access is offered (e.g., guest access).
      In this case the authenticator MUST send a Success packet.

      Where the peer authenticates successfully to the authenticator,
      but the authenticator does not send a method-specific result
      indication the authenticator MAY deny access by sending a Failure
      packet where the peer is not currently authorized for network
           access.

These paragraphs seem OK to me.

Next we have the infamous "protected result indications" definition in
Section 7.2.1:

   Protected result indications
             A method provides result indications if after the method
             has finished (1) if the peer is willing to use the access
             provided by the authenticator, it knows whether the
             authenticator will grant access (that is, only either an
             EAP-Success or EAP-Failure will be accepted, no more method
             specific messages are expected), and (2) if the
             authenticator decides to grant access, it knows whether the
             peer will accept it.  Result indications improve resilience
             to packet loss; see Section 4.2 for discussion. Depending
             on the method and circumstances, result indications can be
             spoofable by an attacker.  A method is said to provide
             protected result indications if it supports result
             indications as well as the "integrity protection" and
             "replay protection" claims.  A method claiming to support
             protected result indications MUST indicate which result
             indications are protected, and which are not.  See Section
             7.16 for details.

It occurs to me reading this again that the definition of result indications
really only applies to a method-specific SUCCESS indication, not to a
FAILURE indication.  A method provides a method-specific failure
indication if it supports error messages of any kind.  So perhaps the the
first sentence should start "A method provides failure result
indications if it supports error messages sent by both
the peer and server.  A method provides a success result indications if..."

[Joe Salowey] Here again we have a mix of authentication and authorization.  It
would be better to qualify the above statement.

"Protected result indications
A method provides result indications if after the
method has finished:

1) When peer successfully completes the authentication, it
knows whether the authenticator has successfully completed the
authentication.

2) When the authenticator successfully completes the authentication, it
knows
whether the peer has successfully completed the authentication.

In the case where successful authentication is sufficient to authorize
access then the peer and authenticator will also know if the other party
is willing to provide or accept access.  This may not always be the
case."

[Bernard Aboba]
Last but not least we have Section 7.16:

7.16 Protected Result Indications

   EAP Success and Failure packets are neither acknowledged nor
   integrity protected.  This creates a potential vulnerability to
   spoofing, as well as lengthy timeouts.

   To address this vulnerability, EAP methods may implement protected
   result indications.  Since protected result indications require use
   of a key for per-packet authentication and integrity protection,
   methods supporting protected result indications MUST also support the
   "key derivation", "mutual authentication" "integrity protection" and
   "replay protection" claims.

This paragraph seems ok, other than perhaps the "may implement" could be
changed to a "MAY implement".

   Result indications may be implicit or explicit.  For example, a
   method may use error messages in order to explicitly indicate a
   failure, while the completion of mutual authentication and key
   derivation without an error message implicitly indicates a successful
     result.

On rereading this, it occurs to me that it is only SUCCESS result
indications that can be implicit;  FAILURE indications need to be explicit.
So this is not so clear.

   For example, within EAP-TLS [RFC2716], the peer always authenticates
   the server, and sends a TLS alert message in the event of an
   authentication or authorization failure.  If the server does not
   receive a TLS alert message from the peer and the peer continues the
   conversation to completion (e.g. sends a FINISHED message), then the
   server can assume that the peer will accept access if granted it by
   the server.

   Similarly, the peer can assume that the server will grant access if
   it does not receive a TLS alert message from the server, and the
   server carries the conversation to completion (e.g. sends a FINISHED
     message).

   A server may use the "access denied" TLS alert after successfully
   authenticating the peer to indicate that a valid certificate was
   received from the peer, but when access control was applied, the
   server decided not to proceed.

As a result of the discussion we had on the operation of TLS session
resume, I went back and looked at RFC 2246 as well as E. Rescorla's SSL
and TLS book.  I think these paragraphs are correct as written and apply
to session resume.  Or am I missing something?

[Joe Salowey] I haven't quite parsed your entire message yet, but 
here is the issue I was looking at:

From 2246 the abbreviated handshake looks like this:

       Client                                                Server 

       ClientHello                   ------->

                                                        ServerHello

                                                 [ChangeCipherSpec]

                                     <--------             Finished

       [ChangeCipherSpec]

       Finished                      -------->

      Application Data              <-------     Application Data

In this case the client does not receive an indication that
the server accepted the authentication. Since the server
finished message comes first it is possible that the Client's
finished message is rejected by the server. At this point a
failure or success is possible. Although the protocol
authentication is not considered complete until all the
finished messages have been correctly verified, I suppose
that it is very unlikely that the client would successfully
verify the server's finished message and respond with a bad
finished message if it were a valid client. I don't think
there is a very big problem here. However I do think we
should change

"...server can assume that the peer will accept access if
granted it by the server."

to

"...server can assume that the peer has authenticated the server."

And

" Similarly, the peer can assume that the server will grant access if it
does not receive a TLS alert message from the server,..."

To

" Similarly, the peer can assume that the server has successfully
authenticated the peer if it does not receive a TLS alert message from
the server,..."

[BA] Here is the proposed resolution:

Change the definition of Proposed Result Indications to:

"Protected Result Indications

Result indications improve resilience to packet loss; see
Section 4.2 for discussion. In some scenarios and with some
EAP methods they can also address some Denial-of-Service
vulnerabilities, though not all. See Section 7.16 for details.

A method provides result indications if under most conditions after the
method's last message is sent and received:

1) The peer is aware of whether it has authenticated the server, as well
as whether the server has authenticated it.

2) The server is aware of whether it has authenticated the peer, as
well as whether the peer has authenticated it.

In the case where successful authentication is sufficient to authorize
access then the peer and authenticator will also know if the other party
is willing to provide or accept access. This may not always be the
case. An authenticated peer may be denied access due to lack of
authorization (e.g. session limit) or other reasons. Since the
EAP exchange is run between the peer and the server,
other nodes (such as AAA proxies) may also affect the authorization
decision. This is discussed in more detail in Section 7.16.

Depending on the method and circumstances, result indications can be
spoofable by an attacker. A method is said to provide protected result
indications if it supports result indications as well as the "integrity
protection" and "replay protection" claims. A method claiming to support
protected result indications MUST indicate which result
indications are protected, and which are not."

Proposed Resolution: Accept

Issue 218: TLS example
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 2/2/2004
Reference: http://mail.frascone.net/pipermail/public/eap/2004-February/002210.html
Document: RFC 2284bis-08.n
Comment type: T
Priority: S
Section: 7.16
Rationale/Explanation of issue:

Discussion of EAP-TLS has resulted in additional insight that 
should be reflected in the specification.    

Delete the definition of "Protected Result Indications" from Section 7.2.1. 

Add the following definition to Section 1.2: 

"Result indications
             A method provides result indications if after the 
             method's last message is sent and received:

             1) The peer is aware of whether it has authenticated the
             server, as well as whether the server has authenticated it.

             2) The server is aware of whether it has authenticated the
             peer, as well as whether the peer has authenticated it.

In the case where successful authentication is sufficient
to authorize access then the peer and authenticator will
also know if the other party is willing to provide or
accept access. This may not always be the case. An
authenticated peer may be denied access due to lack of
authorization (e.g. session limit) or other reasons. Since
the EAP exchange is run between the peer and the server,
other nodes (such as AAA proxies) may also affect the
authorization decision. This is discussed in more detail
in Section 7.16."

Change Section 7.16 to: 

"7.16 Protected Result Indications

Within EAP, Success and Failure packets are neither    
acknowledged nor integrity protected.  Result indications    
improve resilience to loss of Success and Failure packets    
when EAP is run over lower layers which do not support              
retransmission or synchronization of the authentication
state.  In media such as IEEE 802.11, which provides 
for retransmission, as well as synchronization of 
authentication state via the 4-way handshake defined 
in [IEEE802.11i], additional resilience is typically of
marginal benefit. 

Depending on the method and circumstances, result
indications can be spoofable by an attacker.  A method is
said to provide protected result indications if it supports
result indications as well as the "integrity protection"
and "replay protection" claims. A method supporting
protected result indications MUST indicate which
result indications are protected, and which are not.

Protected result indications are not required to protect
against rogue authenticators. Within a mutually authenticating
method, requiring that the server authenticate to the peer
before the peer will accept a Success packet prevents an
attacker from acting as a rogue authenticator.

However, it is possible for an attacker to forge a Success packet
after the server has authenticated to the peer, but before the
peer has authenticated to the server. If the peer were to
accept the forged Success packet and attempt to access the
network when it had not yet successfully authenticated to
the server, a denial of service attack could be mounted against
the peer. After such an attack, if the lower layer supports
failure indications, the authenticator can synchronize state
with the peer by providing a lower layer failure
indication. See Section 7.12 for details.

If a server were to authenticate the peer and send a Success packet
prior to determining whether the peer has authenticated the
authenticator, an idle timeout can occur if the authenticator is not
authenticated by the peer. Where supported by the lower layer, an
authenticator sensing the absence of the peer can free resources.

In a method supporting result indications, 
a peer that has authenticated the server does not consider the 
authentication successful until it receives an indication
that the server successfully authenticated it. Similarly, a server
that has successfully authenticated the peer does not consider the
authentication successful until it receives an indication
that the peer has authenticated the server.

In order to avoid synchronization problems, prior to sending
a success result indication, it is desirable for the sender to
verify that sufficient authorization exists for granting access,
though as discussed below this is not always possible.

While result indications may enable synchronization of the authentication
result between the peer and server, this does not guarantee that the peer
and authenticator will be synchronized in terms of their authorization
or that timeouts will not occur. For example, the EAP server may not
be aware of an authorization decision made by a AAA proxy; the AAA
server may check authorization only after authentication has
completed successfully, only to discover that authorization
cannot be granted; or the AAA server may grant access
but the authenticator may be unable to provide it due to a temporary
lack of resources. In these situations, synchronization may only be
achieved via lower layer result indications.

Success indications may be explicit or implicit. For example, where a
method supports error messages, an implicit success indication may be
defined as the reception of a specific message without a preceding error
message. Failures are typically indicated explicitly. As described in Section 4.2,
a peer silently discards a Failure packet received at a point where the
method does not explicitly permit this to be sent. For example, a method
providing its own error messages might require the peer to receive an
error message prior to accepting a Failure packet.

Per-packet authentication, integrity and replay protection of result
indications protects against spoofing. Since protected result
indications require use of a key for per-packet authentication and
integrity protection, methods supporting protected result indications MUST
also support the "key derivation", "mutual authentication" "integrity
protection" and "replay protection" claims.

Protected result indications address some denial-of-service 
vulnerabilities due to spoofing of Success and Failure
packets, though not all. EAP methods can typically provide 
protected result indications only in some circumstances. 
For example, errors can occur prior to key derivation, and 
so it may not be possible to protect all failure
indications. It is also possible that result indications may
not be supported in both directions or that synchronization may
not be achieved in all modes of operation.

For example, within EAP-TLS [RFC2716], in the client
authentication handshake the server authenticates the 
peer, but does not receive a protected indication of whether the peer 
has authenticated it. In contrast, the peer authenticates the server and
is aware of whether the server has authenticated it. In the session
resumption handshake, the peer authenticates the server, but does
not receive a protected indication of whether the server has
authenticated it. In this mode, the server authenticates the peer and
is aware of whether the peer has authenticated it."

Proposed Resolution: Accept

Issue 219: Session independence
Submitter name: Hannes Tschofenig
Submitter email address: mailto:hannes.tschofenig@siemens.com
Date first submitted: 2/6/2004
Reference: http://mail.frascone.net/pipermail/public/eap/2004-February/002232.html
Document: RFC2284bis-07
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

i took a look at the definition of "session independence" which is described
in section 7.2.1 of eap-rfrc2284bis:
"
   Session independence
             The demonstration that passive attacks (such as capture of
             the EAP conversation) or active attacks (including
             compromise of the MSK or EMSK) does not enable compromise
             of subsequent or prior MSKs or EMSKs.
"
it would be good to specify which keys should not enable compromise
subsequent MSKs / EMSKs. which keys (AAA-Key, MSK, EMSK, EAP-SA-key,
long-term key, etc.) have you had in mind?

an example: if you have a fast reconnect then you might want to send a
protected message to derive new session keys. i simply guess here about the
desired properties of a fast resume since i think that they are not
described anywhere. if an adversary learns the EAP SA then he is also able
to learn new session keys. 

maybe it would be helpful to point to terms such as perfect forward secrecy
or to the vulnerability of a known key attack here.

[Bernard Aboba] 

I believe we decided not to get into this level of detail in 
RFC 3748. However, if you'd like to see this addressed in the
Key Framework document, please submit proposed text. 

Proposed Resolution: Reject

Issue 220: Relationship between AAA-Key and MSK/EMSK
Submitter name: Hannes Tschofenig
Submitter email address: mailto:hannes.tschofenig@siemens.com
Date first submitted: 2/6/2004
Reference: http://mail.frascone.net/pipermail/public/eap/2004-February/002231.html
Document: Key Framework
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

it is said that the AAA-Key is derived from the MSK and EMSK. 

the eap-keying document does not specify how this key derivation is
achieved. worse, in Section 4.2.1 the text says: 

"  The AAA-Key is derived from the keying material exported by the EAP
   method (MSK and EMSK).  This derivation occurs on the AAA server.  In
   many existing protocols that use EAP, the AAA-Key and MSK are
   equivalent, but more complicated mechanisms are possible (see
   Appendix E for details).
"

appendix e, however, does not help since it talks only about a very special
case, namely fast handoff. 

we discussed this issue in one of the eap keying design team phone
conferences but it got lost somehow. 

it would be more helpful to provide a proposal for AAA-Key to MSK/EMSK key
derivation. 

[Joe Salowey] I agree the definition of the AAA-key seems incomplete, I think the
definition is any key that is used by the authenticator and supplicant
to derive keys for data traffic protection (I don't think AAA-key is the
best name since it doesn't have to involve a AAA in the basic case).
In the case of standard 802.11 this AAA-Key the same as the MSK.  In the
fast handoff example I believe additional AAA-keys are pushed to
neighboring access points.  In order to provide computational
independence from the MSK they should be derived from the EMSK.  

I have submitted an issue in email
http://mail.frascone.net/pipermail/eap/2004-January/002143.html (which
has not yet been assigned a number) which describes how to derive keys
from the EMSK for specific purposes.   I think appendix e needs to be
updated as discussed in Issue 214
http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20214.  I haven't
had time to take a detailed look at Jari's proposal.  I'm not sure why
the A-AAA-Key is needed in this derivation but it is equivalent to the
MSK.  

Could you provide some more context from your discussion?  What exactly
are you deriving keys to do? In my opinion it is best to use the MSK as
in the case of 802.11 (single authenticator to supplicant).  If keys are
going to be used for other purposes, between other parties or in other
ways they should be derived from the EMSK.    

[BA] The proposed resolution is as follows:

Add the following sentence to the beginning Appendix E:

Where a AAA-Key is generated as the result of a successful EAP 
authentication, the AAA-Key is set to MSK(0,63). 

[Joe Salowey] Why isn't the AAA-Key equivalent to the MSK?  Exposing the notion of a
AAA-Key is not so good since it suggests things would work differently
with a AAA server and without.  I don't think we want this.  We should
not define a AAA-Key that is different than the MSK.    

[Jari Arkko] Isn't this what Bernard was trying to do when he said:

>>Add the following paragraph to the beginning of Appendix E:
>>
>>Where a AAA-Key is generated as the result of a successful 
>>EAP authentication, the AAA-Key is set to MSK(0,63).

Or is your issue Joe that the length difference causes
something? Or that the pure existence of a value called
the AAA key is harmful, because that implies the existence
of AAA, which might not always be present?

I think we need a quantity for this purpose. I'm even fine
with the value being called "MSK" if the length and other
considerations allow it. Or we could call it the FOO-Key,
always present in an authenticator, be it a AAA-based or
a standalone...

[Joe Salowey] I think this is mostly a naming issue.  AAA-Key indicates something
specific to AAA, which I don't think is appropriate.  Instead of AAA-Key
perhaps we should use something like Application Master Session Key
(AMSK).  Here is some text along what I am thinking.  It needs some
work, but here is the general idea:

EAP may provide keying material to multiple applications.  Each
application should have its own computationally independent AMSK.
Traditionally the application used with EAP is link layer ciphering.  In
this case the AMSK is derived from the MSK[0..64].  Since some link
layer ciphering applications use this key directly (dynamic-wep) it is
NOT RECOMMENDED that the MSK be used to derive keys for other purposes.
For other applications the AMSK SHOULD be derived from the EMSK using
the guidelines outlined in the document.  In some cases the AMSK must be
transferred from an EAP Server to a NAS or other device. In this case an
AMSK is transmitted in a AAA-Token (perhaps key-token is better?)
containing the AMSK and the AMSK name.  Applications must define what
parameters are used in deriving the AMSK and how the keys are used.  In
some cases they will have to define how the AAA-token/key-token is
transferred from the EAP server to where it is used. 

Do you agree with this direction?

[Nick Petroni] On the topic of the distinction between AAA and MSK keys, it seems Figure
4 in the keying document adds to the confusion (at least for me). The
figure shows the peer, authenticator, and backend all having access to the
MSK. As previously noted in this thread, sometimes AAA == MSK, but
potentially not. If I understand this correctly, I would say the middle
box, which depicts the authenticator, should have "AAA" instead of "MSK".
Perhaps AAA should also be indicated on the peer and backend, probably in
addition to MSK and EMSK.  Any other thoughts on this?

[Jari Arkko] I think that's right. Some of this was already noted in
issue #216. But we should also show AAA-Key in the peer and the
backend.

[Joe] I still think the quantity AAA-Key is not well defined.  I'm not
quite sure what AAA-key is supposed to represent. What is it used for?
Today it is used for link-layer-encryption and it is the MSK.  Using
this key for other purposes may lead to loss of computational
independence and result in problems.   The use of the work AAA-key is
misleading in the context it is currently being used. I think it would
be better to discuss things in terms of applications specific keys, with
one of the applications being link layer encryption.  I'll create an
issue with some proposed text for discussion.

> [Joe] I still think the quantity AAA-Key is not well defined.  I'm not
[np] Joe, I couldn't agree more. I welcome some discussion on the topic.

> quite sure what AAA-key is supposed to represent. What is it used for?
[np] I think it represents the trust relationship between the AP and the
AAA...*something* has to be transferred so that the AP is in the loop.
Where this comes from and how it is used should, indeed, be clearly
defined.

> Today it is used for link-layer-encryption and it is the MSK.  Using
> this key for other purposes may lead to loss of computational
[np] Yes, this is for certain. Is it possible to make the MSK/AAA only for
link-layer-encryption and use the EMSK for all other things? I think you
suggested something similar to this before, but I'm not sure I understood
completely.

> independence and result in problems.   The use of the work AAA-key is
> misleading in the context it is currently being used. I think it would
[np] yeah, I think AAA key is the wrong term as well.

Proposed Resolution: Discuss

Issue 221: EMSK Usage Guidelines
Submitter name: Joe Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted: 1/19/2004
Reference: http://mail.frascone.net/pipermail/public/eap/2004-January/002143.html
Document: Keying Framework-01
Comment type: 'T' Technical
Priority: 'S'
Section: Section 2.4, 5
Rationale/Explanation of issue:

Guidelines need to be set for the usage of the EMSK material.

Suggested text from draft-salowey-eap-key-deriv-02.txt

2.4 Requirements for EMSK usage 

EAP reserves a portion of keying material, called the EMSK, for
extended uses.  Keys derived from this key material may be used to
key applications on different devices and different processes separate
from the entity that receives the MSK.

If the keying material is used to provide keys for multiple
Applications or devices, it is desired that the keys will be
cryptographically separate. Cryptographic separation means that
knowledge of one key does not provide an easy way to determine another
key derived from the same key material.  This is also known as
computationally independent.  
   
This section provides guidelines for a mechanism which can be used
with existing and new EAP methods and applications to provide
cryptographic separation between keys derived for different applications

and devices.  These derived keys are referred to in this section as
Application Master Session Keys or AMSK. 
 
2.4.1 Requirements for EAP methods
     
   In order for an EAP method to meet the guidelines for EMSK usage it
   must meet the following requirements.  
   
     o It must specify how to derive the EMSK 
   
     o The key material used for the EMSK MUST be computationally
	  independent of the MSK and TEKs.
   
     o The EMSK MUST NOT be used for any other purpose than the key
        derivation described in this document.  
   
     o The EMSK MUST be secret and not known to someone observing the
        authentication mechanism protocol exchange.

     o The EMSK MUST be maintained within the EAP server.  Only keys
        (AMSKs) derived according to this specification may be exported
        from the EAP server.
 
     o The EMSK MUST be unique for each session. 
 
     o The EAP mechanism SHOULD provide a way of naming the EMSK.

   Implementations of EAP frameworks on the EAP-Peer and EAP-Server
SHOULD
   provide an interface to obtain AMSKs.  The implementation MAY
   restrict which callers can obtain which keys.
   
2.4.2 Requirements for EAP applications
   
   In order for an application to meet the guidelines for EMSK usage it
   must meet the following, 
   
     o The application MAY use the MSK transmitted to the NAS in any
        way it chooses. This is required for backward compatibility. New

        applications following this specification SHOULD NOT use the
        MSK. If more than one application uses the MSK, then the
        cryptographic separation is not achieved. Implementations SHOULD

        prevent such combinations.
        
     o The application MUST NOT use the EMSK in any other way except to
        derive Application Master Session Keys (AMSK) using the key
        derivation specified in this document.  It MUST NOT
        use the EMSK directly for cryptographic protection of data.
     
     o Applications MUST define distinct key labels, application
        specific data, length of derived key material used in the key
	  derivation described in section 2.4.3.
 
     o Applications MUST define how they use their AMSK to derive TSKs
        for their use.

2.4.3 EAP AMSK Key Derivation
   
   The EAP EMSK usage guidelines provide a means for generating multiple

   application-specific master keys (AMSKs). These AMSKs are then used
   to derive transient session keys (TSKs), which are used as actual
   ciphering keys. This allows multiple applications to use keys
   independently derived from the EAP method. 
   
   The EAP EMSK usage guidelines AMSK key derivation function (KDF)
   derives an AMSK from the Extended Master Session Key (EMSK) described

   above, an application key label, optional application data, and
   output length. 
   
      AMSK = KDF(EMSK, key label, optional application data, length)
   
   The key labels are printable ASCII strings unique for each
   application (see Section 5 for IANA Considerations). 
   
   Additional ciphering keys (TSKs) can be derived from the AMSK using
   an application specific key derivation mechanism. In many cases, this

   AMSK->TSK derivation can simply split the AMSK to pieces of correct
   length. In particular, it is not necessary to use a cryptographic
   one-way function. Note that the length of the AMSK must be specified
   by the application. 
   
2.4.3.1 The EAP AMSK Key Derivation Function
   
   The EAP key derivation function is taken from the PRF+ key expansion
   PRF from [IKEv2].  This KDF takes 4 parameters as input: secret,
   label, application data, and output length.  It is only defined for
   255 iterations so it may produce up to 5100 bytes of key material. 
   
   For the purposes of this specification the secret is taken as the
   EMSK, the label is the key label described above concatenated with a
   NUL byte, the application data is also described above and the output

   length is two bytes.  The application data is optional and may not be

   used by some applications.  The KDF is based on HMAC-SHA1 [RFC2104]
   [SHA1]. For this specification we have:
   
   KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ...
   
      where:
      T1 = prf (K, S | 0x01)
      T2 = prf (K, T1 | S | 0x02)
      T3 = prf (K, T2 | S | 0x03)
      T4 = prf (K, T3 | S | 0x04)
   
      prf = HMAC-SHA1
      K = EMSK
      L = key label
      D = application data
      O = OutputLength (2 bytes)
      S = L | "\0" | D | O
       
   
   The prf+ construction was chosen because of its simplicity and
   efficiency over other PRFs such as those used in [TLS].  The
   motivation for the design of this PRF is described in [SIGMA].  
   
   The NUL byte after the key label is used to avoid collisions if one
   key label is a prefix of another label (e.g. "foobar" and
   "foobarExtendedV2"). This is considered a simpler solution than
   requiring a key label assignment policy that prevents prefixes from
   occurring.
 
5. IANA Considerations
 
   This specification introduces a new name space for "key labels".  Key

   labels are ASCII strings and are assigned on a first come first
   served basis.  It is RECOMMENDED that a reference to a specification
   that provides the following information
   
     o A description of the application
     o The key label to be used
     o How TSKs will be derived from the AMSK and how they will be used
     o If application specific data is used, what it is and how it is
        maintained
     o Where the AMSKs or TSKs will be used and how they are
        communicated if necessary.

[Jari Arkko] We discussed the incorporation of the EMSK guidelines document
to the keying framework in IETF-58. That discussion ended up
recommending to merge it in. So unless anyone wants to object
here, I think we should consider this issue closed.

I looked at Joe's suggested text [1] and it looks good to me.

A couple of comments on Section 2.4:

- s/Applications/applications.

- "The application MUST NOT use the EMSK in any other way except to
derive Application Master Session Keys (AMSK) using the key
derivation specified in this document." This seems inconsistent
with the idea that applications should only know the AMSK, not
the EMSK.

- Don't we need key names, too? Suggest branching a key naming
hierarchy from the EMSK before using it to branch AMSKs.

[Bernard Aboba] 

New text is needed before Jari's issues can be
resolved. Here is my take on what we have so far: 

Add Appendix F: 

Appendix F - AMSK Key Derivation

The EAP AMSK key derivation function (KDF) derives an AMSK from the
Extended Master Session Key (EMSK), an application key label,
optional application data, and output length.

AMSK = KDF(EMSK, key label, optional application data, length)

The key labels are printable ASCII strings unique for each
application (see Section 5 for IANA Considerations).

Additional ciphering keys (TSKs) can be derived from the AMSK using
an application specific key derivation mechanism. In many cases, this
AMSK->TSK derivation can simply split the AMSK to pieces of correct
length. In particular, it is not necessary to use a cryptographic
one-way function. Note that the length of the AMSK must be specified
by the application.

F.1 The EAP AMSK Key Derivation Function

The EAP key derivation function is taken from the PRF+ key expansion
PRF from [IKEv2]. This KDF takes 4 parameters as input: secret,
label, application data, and output length. It is only defined for
255 iterations so it may produce up to 5100 bytes of key material.

For the purposes of this specification the secret is taken as the
EMSK, the label is the key label described above concatenated with a
NUL byte, the application data is also described above and the output
length is two bytes. The application data is optional and may not be
used by some applications. The KDF is based on HMAC-SHA1 [RFC2104]
[SHA1]. For this specification we have:

KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ...

where:
T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)

prf = HMAC-SHA1
K = EMSK
L = key label
D = application data
O = OutputLength (2 bytes)
S = L | " " | D | O

The prf+ construction was chosen because of its simplicity and
efficiency over other PRFs such as those used in [TLS]. The
motivation for the design of this PRF is described in [SIGMA].

The NUL byte after the key label is used to avoid collisions if one
key label is a prefix of another label (e.g. "foobar" and
"foobarExtendedV2"). This is considered a simpler solution than
requiring a key label assignment policy that prevents prefixes from
occurring.

Change Section 6 to the following: 

"6. IANA Considerations

This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to EAP key
management, in accordance with BCP 26, [RFC2434].

The following terms are used here with the meanings defined in BCP
26: "name space", "assigned value", "registration".

The following policies are used here with the meanings defined in BCP
26: "Private Use", "First Come First Served", "Expert Review",
"Specification Required", "IETF Consensus", "Standards Action".

For registration requests where a Designated Expert should be
consulted, the responsible IESG area director should appoint the
Designated Expert. The intention is that any allocation will be
accompanied by a published RFC. But in order to allow for the
allocation of values prior to the RFC being approved for publication,
the Designated Expert can approve allocations once it seems clear
that an RFC will be published. The Designated expert will post a
request to the EAP WG mailing list (or a successor designated by the
Area Director) for comment and review, including an Internet-Draft.
Before a period of 30 days has passed, the Designated Expert will
either approve or deny the registration request and publish a notice
of the decision to the EAP WG mailing list or its successor, as well
as informing IANA. A denial notice must be justified by an
explanation and, in the cases where it is possible, concrete
suggestions on how the request can be modified so as to become
acceptable.

This document introduces a new name space for "key labels". Key
labels are ASCII strings and are assigned via Designated Expert with
Specification Required. It is RECOMMENDED that the specification
provide the following information:

o A description of the application
o The key label to be used
o How TSKs will be derived from the AMSK and how they will be used
o If application specific data is used, what it is and how it is
maintained
o Where the AMSKs or TSKs will be used and how they are
communicated if necessary."

[Ashwinp] Assigning key labels via FCFS will lead to the proliferation of
proprietary keying mechanisms without IETF review. Don't we at least
want to require a specification?

[Jari Arkko] Strictly speaking it might lead to use of EAP keys in
different applications, but at least those EAP keys would be
derived in a standardized manner.

But in any case, even that might lead to problems.
There might be a number of proprietary ways to key
a standard application FOO.

I think Specification Required would be appropriate.
Maybe even something stronger.

[Bernard Aboba] How about IETF consensus?  Here is the proposed text of the IANA section:

6.  IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to EAP key
   management, in accordance with BCP 26, [RFC2434].

   The following terms are used here with the meanings defined in BCP
   26: "name space", "assigned value", "registration".

   The following policies are used here with the meanings defined in BCP
   26: "Private Use", "First Come First Served", "Expert Review",
   "Specification Required", "IETF Consensus", "Standards Action".

   For registration requests where a Designated Expert should be
   consulted, the responsible IESG area director should appoint the
   Designated Expert.  The intention is that any allocation will be
   accompanied by a published RFC.  But in order to allow for the
   allocation of values prior to the RFC being approved for publication,
   the Designated Expert can approve allocations once it seems clear
   that an RFC will be published.  The Designated expert will post a
   request to the EAP WG mailing list (or a successor designated by the
   Area Director) for comment and review, including an Internet-Draft.
   Before a period of 30 days has passed, the Designated Expert will
   either approve or deny the registration request and publish a notice
   of the decision to the EAP WG mailing list or its successor, as well
   as informing IANA.  A denial notice must be justified by an
   explanation and, in the cases where it is possible, concrete
   suggestions on how the request can be modified so as to become
     acceptable.

   This document introduces a new name space for "key labels".  Key
   labels are ASCII strings and are assigned via IETF Consensus.  It is
   expected that key label specifications will include the following
     information:

        o A description of the application
        o The key label to be used
        o How TSKs will be derived from the AMSK and how they will be used
        o If application specific data is used, what it is and how it is
                     maintained
        o Where the AMSKs or TSKs will be used and how they are
          communicated if necessary.

[Jari Arkko] I have taken a look at this issue and its current
status at the keying-03a draft revision from Bernard's
page. Here are conclusions:

1) I agree with the IANA consideration of "IETF
Consideration" for new keying applications.

2) I think the placement of the text in Appendix F
is somewhat misleading. Other appendices are
really about _example_ keying hierarchies, mostly
about EAP-TLS. AMSK derivation, as I see it, is
a part of our document's main content. One can
see this, for instance, in that there must be
just one way to derive AMSKs or otherwise there
will be no interoperability or keys might
accidentally depend on each other.

3) To resolve one of my earlier comments, I suggest
replacing

 o The application MUST NOT use the EMSK in any other way except to
derive Application Master Session Keys (AMSKs) using the key
derivation specified in this document. It MUST NOT
use the EMSK directly for cryptographic protection of data.

with

o A node MUST NOT use the EMSK in any other way except to
derive Application Master Session Keys (AMSKs) using the key
derivation specified in this document. It MUST NOT
use the EMSK directly for cryptographic protection of data,
and SHOULD provide only the AMSKs to applications.

4) To resolve my other earlier comment, I suggest
adding to 3.5 (key naming) under the "EAP SA Name"
bullet item the following additional text:

AMSKs, if any, may be named by the concatenation of the EAP SA
Name, key label, and application data (see Appendix F).

[Joe Salowey] I'll have to go back and look, but we need to make sure that the
application data does not have secret data in it. It probably shouldn't,
but if we are going to use it in the name it MUST be public data.

[Jari Arkko] That's a good point. But in the end, I think it simply means
that it becomes a requirement to hav only public data (or at
least a one-way function if private data is used) before you
can use something as an "application data" item in the AMSK
generation. That is, I don't believe this is an issue as
long as we remember to document the requirement... 

[Joe Salowey] Would it be better to have a fixed length ID instead of a variable
length name? Perhaps a hash of this information would be better? 

[Jari Arkko] I don't have a fundamental objection to the use of
a hash. The only reason that I included this type of a name
is that the same type is already used in other EAP key/sa names.

[Joe Salowey] OK I need to look at it. I think we want to keep the naming
consistent. 

5) It seems that the document is still inconsistent in its
use of terms for SAs. Section 3.5 talks about "EAP SA" while
Section 3 beginning talks about "EAP Key SA" and "EAP Method
SA". I think the latter is correct.

Proposed Resolution: Discuss

Issue 222: Synchronized State
Submitter name: Joe Salowey	
Submitter email address: jsalowey@cisco.com
Date first submitted: 2/9/2004
Reference:
http://mail.frascone.net/pipermail/public/eap/2004-February/002262.html
Document: RFC2284bis-08, draft-walker-ieee802-req-00
Comment type: 'T'
Priority: '1' Should fix
Section: 7.x
Rationale/Explanation of issue:

draft-walker-ieee802-req-00 places a requirement on synchronized state
which is then equated to protected result indicators.  It seems that the
two are not equivalent.  Synchronized state does not require protected
result indicators, since 802.11i has a 4-way handshake, protected result
indicators do not serve much purpose.  They are more important in
protocols that do not have subsequent protected messages such as
straight 802.1x (although if subsequent protection is not used there is
little you can do to secure the system in anycase).

Requested change:

Either add a section is 2284bis referring to synchronized state and
refer to it from draft-walker-ieee802-req-00 or  remove the reference to
protected result indicators in [3] of draft-walker-ieee802-req-00 and
replace with synchronized state reference.

Synchronized State

At the completion of an EAP authentication method the Peer and Server
MUST have the same notion of state related to the authentication.
Successful authentication MUST NOT result in a situation where both
parties believe the authentication succeeded, but have different notions
of state including; the protocol both executed, what credentials were
presented and accepted by both parties, what keys both have derived, and
how to distinguish this instance of the protocol from all other
instances of the protocol. They MUST also share the same view of
negotiable attributes of the EAP method specific protocol, such as
cipher suites, limitations of usage on all protocol state, and the same
view of what attributes of the protocol instance are public and which
are private to the two parties alone.  If the peer and the server do not
share the same notion of state then either or both of the parties MUST
fail the authentication and MUST NOT generate keys for export out of the
method.

[Bernard Aboba] Here is the proposed resolution:

Add to the end of Section 7.2.1:

"Note: This list of security claims is not exhaustive.  Additional
properties, such as additional denial-of-service protection,
may be relevant as well."

Proposed Resolution: Accept

Issue 223: PRI cleanup
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: February 15, 2003
Reference: 
Document: RFC2284bis-08
Comment type: E
Priority: S
Section: 2.4, 4.2, 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6, 7.2, 7.2.1
Rationale/Explanation of issue:

Now that PRIs are not a security claim any more, we need to remove them from
the list of security claims for each of the methods defined in RFC 2284bis. 
Also, the language in Sections 2.4, 4.2 and 7.2 is not consistent with the definition of
result indications in Section 1.2 or 7.16. 

In Section 2.4, change "protected result indications" to "result indications". 

In Section 4.2, change the implementation note to the following:

Implementation Note: Because the Success and Failure packets are
not acknowledged, they are not retransmitted by the authenticator,
and may be potentially lost. A peer MUST allow for this
circumstance as described in this note. See also Section 3.4 for
guidance on the processing of lower layer success and failure
indications.

As described in Section 2.1, only a single EAP authentication
method is allowed within an EAP conversation. EAP methods may
implement result indications. After the authenticator sends
a failure result indication to the peer, regardless of the
response from the peer, it MUST subsequently send a Failure
packet. After the authenticator sends a success result
indication to the peer, and receives a success result indication
from the peer, it MUST subsequently send a Success packet.

On the peer, once the method completes unsuccessfully (that is,
either the authenticator sends a failure result indication,
or the peer decides that it does not want to continue
the conversation, possibly after sending a failure result
indication), the peer MUST terminate the conversation and indicate
failure to the lower layer. The peer MUST silently discard
Success packets and MAY silently discard Failure packets. As a
result, loss of a Failure packet need not result in a timeout.

On the peer, after success result indications have been
exchanged by both sides, a Failure packet MUST be silently
discarded. The peer MAY, in the event that an EAP Success is not
received, conclude that the EAP Success packet was lost and that
authentication concluded successfully.

If the authenticator has not sent a result indication, and
the peer is willing to continue the conversation, once the
method completes the peer waits for a Success or Failure
packet and MUST NOT silently discard either of them. In the event
that neither a Success nor Failure packet is received, the peer
SHOULD terminate the conversation to avoid lengthy timeouts in
case the lost packet was an EAP Failure.

If the peer attempts to authenticate to the authenticator and
fails to do so, the authenticator MUST send a Failure packet and
MUST NOT grant access by sending a Success packet. However, an
authenticator MAY omit having the peer authenticate to it in
situations where limited access is offered (e.g., guest access).
In this case the authenticator MUST send a Success packet.

Where the peer authenticates successfully to the authenticator,
but the authenticator does not send a result indication, 
the authenticator MAY deny access by sending a Failure
packet where the peer is not currently authorized for network
access.

In Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6, delete:

" Protected result ind.: No"

In Section 7.2, change:

" [b] Security claims. This is a statement of the claimed security
properties of the method, using terms defined in Section 7.2.1:
mutual authentication, integrity protection, replay protection,
confidentiality, key derivation, dictionary attack resistance,
fast reconnect, cryptographic binding, protected result
indications. The Security Claims section of an EAP method
specification SHOULD provide justification for the claims that
are made. This can be accomplished by including a proof in an
Appendix, or including a reference to a proof."

To:

" [b] Security claims. This is a statement of the claimed security
properties of the method, using terms defined in Section 7.2.1:
mutual authentication, integrity protection, replay protection,
confidentiality, key derivation, dictionary attack resistance,
fast reconnect, cryptographic binding. The Security Claims section 
of an EAP method specification SHOULD provide justification for
the claims that are made. This can be accomplished by including
a proof in an Appendix, or including a reference to a proof."

In 7.2.1, change:

"Replay protection
This refers to protection against replay of an EAP method
or its messages, including method-specific success and
failure indications.

Confidentiality
This refers to encryption of EAP messages, including EAP
Requests and Responses, and method-specific success and
failure indications. A method making this claim MUST
support identity protection (see Section 7.3)."

To:

"Replay protection
This refers to protection against replay of an EAP method
or its messages, including success and failure result
indications.


Confidentiality
This refers to encryption of EAP messages, including EAP
Requests and Responses, and success and failure result
indications. A method making this claim MUST support
support identity protection (see Section 7.3)."

In Appendix A, change:

" o The concepts of Mutual Authentication, Key Derivation and
Protected Result Indications are introduced and discussed
throughout the document where appropriate."

To:

" o The concepts of Mutual Authentication, Key Derivation and
Result Indications are introduced and discussed
throughout the document where appropriate."

Proposed Resolution: Accept

Issue 224: State Synchronization
Submitter name: Joe Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted: 2/24/2004
Reference:
http://mail.frascone.net/pipermail/public/eap/2004-February/002229.html;
see also issue 222
Document: EAP-WLAN-00
Comment type: 'T'echnical 
Priority: '1' Should fix 
Section: 2.2, clause [3]
Rationale/Explanation of issue:

Synchronization of state is not the same as protected result indicators.
It is possible to have synchronized state without protected result
indicators and it is possible for a poorly implemented method to
implement protected result indicators and not have synchronized state.
The suggestion is to replace protected result indicators with a
description of synchronized state. The following suggested text is
based on some email exchanges on the EAP list with Jessie Walker.

Synchronized State

At the completion of an EAP authentication method the Peer and Server
must have the same notion of state information related to the
authentication. If the peer and the server do not share the same notion
of state information then either or both of the parties must fail the
authentication and must not generate keys for export out of the method.
The exact state attributes that are shared may vary from method to
method but it typically includes the protocol both executed, what
credentials were presented and accepted by both parties, what
cryptographic keys are shared and what EAP method specific attributes
were negotiated, such as cipher suites and limitations of usage on all
protocol state. Both parties must be able to distinguish this instance
of the protocol from all other instances of the protocol and they must
share the same view of which state attributes are public and which are
private to the two parties alone.

[Bernard Aboba] Here is the proposed fix:

Change item [4] to the following:

"[4]  Synchronization of state.  This requirement applies when the EAP
     method completes successfully. The exact state attributes that are
     shared may vary from method to method but typically include the
     protocol both executed, what credentials were presented and
     accepted by both parties, what cryptographic keys are shared and
     what EAP method specific attributes were negotiated, such as cipher
     suites and limitations of usage on all protocol state.  Both
     parties must be able to distinguish this instance of the protocol
     from all other instances of the protocol and they must share the
     same view of which state attributes are public and which are
     private to the two parties alone."

Proposed Resolution: Accept

Issue 225: Review
Submitter name: Steve Bellovin
Submitter email address: smb@research.att.com
Date first submitted: 2/24/2004
Reference:
Document: EAP-WLAN-00
Comment type: 'T'echnical 
Priority: S
Section: Various
Rationale/Explanation of issue:

The document doesn't have a Security Considerations section, and -- 
speaking almost purely syntactically; I haven't read the draft yet -- 
I'd sure want Section 2.5 to explain which criteria each of the 
unacceptable methods fail to meet.

[BA] Here is the proposed resolution:

Add the following text:

"2.4. Non-compliant EAP authentication methods

EAP-MD5-Challenge (the current mandatory-to-implement EAP
authentication method), is defined in [RFC3748] Section 5.4. EAP-
MD5-Challenge and two EAP authentication methods defined in
[RFC3748], One-Time Password (Section 5.5) and Generic Token Card
(Section 5.6), are non-compliant with the requirements defined in
this document. As noted in [RFC3748], these methods do not support
any of the mandatory requirements defined in Section 2.2 including
key derivation, or mutual authentication. In addition, these methods
do not support the optional features defined in Section 2.4.

3. Security Considerations

Within [IEEE802.11i], EAP is used for both authentication and key
exchange between the EAP peer and server. Given that wireless local
area networks provide ready access to an attacker within
range, EAP usage within [IEEE802.11i] is subject to the threats
outlined in [RFC3748] Section 7.1. Security considerations relating
to EAP are discussed in [RFC3748] Sections 7; where an authentication
server is utilized, the security considerations described in 
[RFC3579], Section 4 will apply. 

The system security properties required to address the threats 
described in [RFC3748] Section 7.1 are noted in [Housley56]:

Algorithm independence
Wherever cryptographic algorithms are chosen, the algorithms must
be negotiable, in order to provide resilience against compromise of
a particular algorithm. This is addressed by mandatory requirement
[7] in Section 2.1.1. For interoperability, at least one suite of 
algorithms MUST be implemented. Since no standards track EAP methods 
meeting these requirements have been published as RFCs, [IEEE802.11i] 
does not define a mandatory-to-implement algorithm. However, it is
hoped that this document will contribute toward the development of
EAP methods meeting these requirements, so that selection of a 
mandatory-to-implement algorithm might be possible in the future. 

Strong, fresh session keys
Session keys must be demonstrated to be strong and fresh in all
circumstances, while at the same time retaining algorithm
independence. Key strength is addressed by mandatory
requirement [2] in Section 2.1.1. Recommendations for 
ensuring the Freshness of keys derived by EAP methods are 
discussed in [RFC3748], Section 7.10. Algorithm independence
is one of the EAP invariants described in [KEYFRAME]. 

Replay protection
All protocol exchanges must be replay protected. This is 
addressed by mandatory requirement [6] in Section 2.1.1.

Authentication
All parties need to be authenticated. Mutual authentication is
required as part of mandatory requirement [3] in Section 2.1.1. 
The confidentiality of the authenticator must be maintained. 
Identity protection is an optional capability, described in 
requirement [10] in Section 2.3. No plaintext passwords are
allowed. EAP does not support plaintext passwords, as noted 
in [RFC3748] Section 7.14. 

Authorization
EAP peer and authenticator authorization must be performed.
Issues relating to authorization are discussed in 
[RFC3748] Section 7.15, and [RFC3579] Section 4.3.7. 

Session keys
Confidentiality of session keys must be maintained. Issues 
relating to Key Derivation are described in [RFC3748] 
Section 7.10, as well as in [KEYFRAME]. 

Ciphersuite negotiation
The selection of the "best" ciphersuite must be securely confirmed.
This is addressed in mandatory requirement [7] in Section 2.1.1.

Unique naming
Session keys must be uniquely named. Key naming issues are
addressed in [KEYFRAME]. 

Domino effect
Compromise of a single authenticator cannot compromise any other
part of the system, including session keys and long-term secrets.
This issue is addressed by mandatory requirement [6] in Section 2.1.1.

Key binding
The key must be bound to the appropriate context. This issue is
addressed in optional requirement [9] in Section 2.3. Channel binding
is also discussed in Section 7.15 of [RFC3748].

Add to the informative references:

[RFC3579]
Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service)
Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.

[KEYFRAME]
Aboba, B., "EAP Key Management Framework", draft-ietf-eap-keying-01 (work in progress), 
October 2003.

[Housley56] Housley, R., "Key Management in AAA", Presentation to the AAA
WG at IETF 56, http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html,
March 2003."

Proposed Resolution: Accept

Issue 226: Comments on WLAN requirements
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 2/25/2004
Reference:
Document: EAP-WLAN-00
Comment type: 'T'echnical 
Priority: S
Section: 1, 1.2, 2.2, 3
Rationale/Explanation of issue:

I don't think there is enough overview material, describing the 
IEEE 802.11i environment. 

Change Section 1 to the following:

"1. Introduction

The Draft IEEE 802.11i MAC Security Enhancements Amendment [IEEE802.11i]
makes use of IEEE 802.1X [IEEE8021X-REV] which in turn relies on the
Extensible Authentication Protocol (EAP), defined in [RFC2284bis].

Deployments of IEEE 802.11 wireless LANs today are based on EAP, and use
several EAP methods, including EAP-TLS [RFC2716], EAP-TTLS [TTLS], PEAP
[PEAP] and EAP-SIM [SIM]. These methods support authentication
credentials that include digital certificates, user-names and passwords,
secure tokens, and SIM secrets.

This document defines requirements for EAP methods used in IEEE 802.11
wireless LAN deployments."

The draft could benefit by addition of a terminology section. 

Add Section 1.2:

"1.2 Terminology

authenticator
The end of the link initiating EAP authentication. The
term Authenticator is used in [IEEE-802.1X], and
authenticator has the same meaning in this document.

peer
The end of the link that responds to the authenticator. In
[IEEE-802.1X], this end is known as the Supplicant.

Supplicant
The end of the link that responds to the authenticator in
[IEEE-802.1X]. 

backend authentication server
A backend authentication server is an entity that provides
an authentication service to an authenticator. When used,
this server typically executes EAP methods for the
authenticator. This terminology is also used in
[IEEE-802.1X].

EAP server
The entity that terminates the EAP authentication method
with the peer. In the case where no backend authentication
server is used, the EAP server is part of the
authenticator. In the case where the authenticator
operates in pass-through mode, the EAP server is located on
the backend authentication server.

Master Session Key (MSK)
Keying material that is derived between the EAP peer and
server and exported by the EAP method. The MSK is at least
64 octets in length. In existing implementations a AAA
server acting as an EAP server transports the MSK to the
authenticator.

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

4-Way Handshake
A pairwise Authentication and Key Management Protocol (AKMP) 
defined in [IEEE802.11i], which confirms mutual possession 
of a Pairwise Master Key by two parties and distributes a 
Group Key."

Proposed Resolution: Accept

Issue 227: Corrections
Submitter name: Russ Housley
Submitter email address: housley@vigilsec.com
Date first submitted: 2/27/2004
Reference:
Document: EAP-WLAN-00
Comment type: 'T'echnical 
Priority: S 
Section: Various
Rationale/Explanation of issue:

Abstract

The Draft IEEE 802.11i MAC Security Enhancements Amendment makes use of

[ It is clear that 802.11i will be approved soon and depend on EAP.
Since this document will live forever, it might be better to drop
'Draft.' Alternatively, we could wait until 802.11i is published. ]

2.1. Credential types

The Draft IEEE 802.11i MAC Security Enhancements Amendment requires that
EAP authentication methods are available. Wireless LAN deployments are
expected to use different credentials types, including digital
certificates, user-names and passwords, existing secure tokens, and
mobile network credentials (GSM and UMTS secrets). Other credential
types that may be used include public/private key (without necessarily
requiring certificates), and asymmetric credential support (password on

[ s/password/such as password/ ]

[1] Generation of keying material. This corresponds to the "Key

[ s/keying/symmetric keying/ ]

derivation" security claim defined in [RFC2284bis], Section 7.2.1.

[7] Key strength. An EAP method suitable for use with IEEE 802.11 MUST
be capable of generating keying material with 128-bits of effective
key strength, as defined in [RFC2284bis] Section 7.2.1. As noted
in [RFC2284bis] Section 7.10, an EAP method supporting key
derivation MUST export a Master Session Key (MSK) of at least 64
octets, and an Extended Master Session Key (EMSK) of at least 64
octets.

[ This should probably be placed after [1] so that discussion of key
derivation are next to each other. ]

2.4. Optional features

EAP authentication methods used for wireless LAN authentication MAY
support the following features:

[ Do we want to say that they are desirable? Or, say that they are
useful in some environments? ]

[9] Channel binding. This corresponds to the "Channel binding"
security claim defined in [RFC2284bis], Section 7.2.1.

[ Why isn't [9] a SHOULD? I know that none of the current EAP methods
give it to use, but it might be good to push for it. ]

[Bernard Aboba] The proposed resolution is as follows:

Drop the term "Draft" and refer to [RFC3748] instead of [RFC2284bis]. 

Accept the proposed editorial changes.

Leave "Channel Bindings" as a MAY.  This is still an experimental facility. 
Leave optional capabilities as is. 

Proposed Resolution: Accept

Issue 228: Typos for Auth48
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 2/28/2004
Reference:
Document: RFC2284bis-09
Comment type: Editorial 
Priority: 2 
Section: 2.2, 3.1, Appendix A
Rationale/Explanation of issue:

Section 2.2, Figure 1: The "!" and "-" lines are offset 3 spaces to the left on the bottom
of the figure.  These should be aligned.  

Section 3.1, clause [1]

Change "and a non-negligible" to "and with a non-negligible"

In Appendix A, change:

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

To:

"
    o  It is now required in Section 5.1 that if the Type-Data field of
       an Identity Request contains a null character, only the part
       before the null is displayed. RFC 2284 prohibits the Null
       termination of the Type-Data field of Identity messages. This
       rule has been relaxed for Identity Request messages and the
       Identity Request Type-Data field may now be null terminated."

Proposed Resolution: Accept

Issue 229: EAP Peer SM Review
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 2/28/2004
Reference: http://mail.frascone.net/pipermail/public/eap/2004-March/002341.html
Document: EAP-SM-02
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:

Overall:

Peer and authenticator are inconsistently capitalized. Suggest
using lower case for both, as is done in RFC 2284bis. 

Page 5

"all other EAP packets are delivered to the Peer state machine." 

This should instead say "EAP packets with Code set to
Request, Success or Failure are delivered to the peer state machine." 

Page 6, Section 3.1

"connected,mutually" -> "connected, mutually"

"conditions.A variable" -> "conditions. A variable"

Page 7, Section 3.1

"such as that of the Method." -> "such as that of the method."

Page 9

In Figure 3, the variable lastId is not initialized to NONE in the INITIALIZE state. 

I am not sure that (altAccept && decision != FAIL) is a condition that should lead to 
the SUCCESS state. Why is this not decision == UNCOND_SUCC as with a timeout? 

[Nick Petroni] 

I have put up a -03a to address some of these. comments inline.

http://www.cs.umd.edu/~npetroni/EAP/

> Peer and authenticator are inconsistently capitalized. Suggest
> using lower case for both, as is done in RFC 2284bis.
[np] Fixed I think. let me know if I missed any.

> Page 5
>
> "all other EAP packets are delivered to the Peer state machine."
>
> This should instead say "EAP packets with Code set to
> Request, Success or Failure are delivered to the peer state machine."
[np] fixed.

> Page 6, Section 3.1
>
> "connected,mutually" -> "connected, mutually"
>
> "conditions.A variable" -> "conditions. A variable"
[np] aaah. gotta love acroread in Linux. besides its propensity to crash
when searching it also copies horribly at the end of the line. nice catch.

>
> Page 7, Section 3.1
>
> "such as that of the Method." -> "such as that of the method."
[np] fixed.

>
> Page 9
>
> In Figure 3, the variable lastId is not initialized to NONE in the
> INITIALIZE state.
>
> I am not sure that (altAccept && decision != FAIL) is a condition that
> should lead to the SUCCESS state. Why is this not
> decision == UNCOND_SUCC as with a timeout?
[np] It seems that altAccept is an alternative to rxSuccess so it should
be equivalent to that input I think. The current diagram shows
rxSuccess && (reqId == lastId) && (decision != FAIL). So, if you change
one, you should have to change both right? I think it's right as is, but
I could be convinced otherwise.

I think the idea behind the decision is as follows:

UNCOND_SUCC  peer already knows auth's decision is yes and wants to accept.
             Since it knows the decision, it can assume the success
             packet was lost in transit on a timeout.

COND_SUCC   peer wants to accept, but doesn't yet know what the auth
             has decided. It therefore needs some indication of success to
             go to the SUCCESS state.

FAIL         peer or auth is not happy, either way don't go to success


I think the point is that timeout requires you to KNOW you have succeeded
(decision=UNCOND_SUCC) whereas success/altAccept *is* the indication you
are waiting for when decision=COND_SUCC. So, those events can transition
to SUCCESS when decision is COND_SUCC as well. Does that make sense?

Proposed Resolution: Accept

Issue 230: State Machine Nits
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: 3/18/2004
Reference: http://mail.frascone.net/pipermail/public/eap/2004-March/002379.html
Document: EAP-SM-02
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:

Title should expand "EAP" per RFC editor
     requirements.

- Abstract should expand AAA and replace
   RADIUS with AAA so that it doesn't have to be
   expanded also.

- Move the second last paragraph after the text
   that talks about the switch.

- Delete last paragraph of the abstract,
   it is in part duplication and in part contain
   temporary status information about the document.

- Section 2, s/out of scope for/outside the scope of/
   I think, English is not my native language...

- For some reason, the bottom page heading is right on
   the next line after text ends. E.g. Section 4.1.
   I find this a bit confusing, it takes a moment to
   realize that your eyes have read into the heading and
   not a continuation of the paragraph. If you can change
   this easily, please do. If not, don't worry about it...

- Inconsistent capitalization of the sentences explaining
   variables, see e.g. Sections 4.1.1 vs 4.1.2.

- s/wasn't/was not/
   s/don't/do not/
   s/can't/can not/
   s/hasn't/has not/

- In Section 5.2, I think it would be useful to add
   the following just before "m.init": "In the following
   we will discuss procedure calls that the state machine
   can make to methods."

- As discussed with the RFC editor and in IETF-59,
   we need a .txt version with the state machine
   as a table.

[Nick Petroni] 

Jari, thanks for the comments. I have 2 questions and a couple comments inline...

> - Title should expand "EAP" per RFC editor
>       requirements.
ok, fixed.

>
> - Abstract should expand AAA and replace
>    RADIUS with AAA so that it doesn't have to be
>    expanded also.
fixed.

>
> - Move the second last paragraph after the text
>    that talks about the switch.
I don't quite understand this request. Which paragraph moved where?

>
> - Delete last paragraph of the abstract,
>    it is in part duplication and in part contain
>    temporary status information about the document.
done.

>
> - Section 2, s/out of scope for/outside the scope of/
>    I think, English is not my native language...
agreed. changed.

> - For some reason, the bottom page heading is right on
>    the next line after text ends. E.g. Section 4.1.
>    I find this a bit confusing, it takes a moment to
>    realize that your eyes have read into the heading and
>    not a continuation of the paragraph. If you can change
>    this easily, please do. If not, don't worry about it...
This is a LaTeX-ism, worst case I will fix it by hand.

> - Inconsistent capitalization of the sentences explaining
>    variables, see e.g. Sections 4.1.1 vs 4.1.2.
Which do you prefer? start with caps or no?

> - s/wasn't/was not/
>    s/don't/do not/
>    s/can't/can not/
>    s/hasn't/has not/
ewww, yeah. done.

> - In Section 5.2, I think it would be useful to add
>    the following just before "m.init": "In the following
>    we will discuss procedure calls that the state machine
>    can make to methods."
done with slight word smithing.  "The following describes the interaction
between the state machine and EAP methods."

Also made this change in 4.2. Furthermore, I made the order of "IN",
"OUT", and "IN/OUT" consistent between these two sections.

> - As discussed with the RFC editor and in IETF-59,
>    we need a .txt version with the state machine
>    as a table.
Working on that now... should have something to show tonight or tomorrow.

[Jari Arkko] Thanks for your quick response Nick. Inline some
answers to your questions:

>>- Move the second last paragraph after the text
>>   that talks about the switch.
> 
> I don't quite understand this request. Which paragraph moved where?
   
    This document describes a state machine based on an EAP "Switch"
    model. This model includes  events and actions for the interaction
    between the EAP Switch and EAP methods. The State Machine and
    associated model are informative only. Implementations may achieve
    the same results using different methods.

    A brief description of the EAP "Switch" model is given in the
    Introduction section.

=>

    This document describes a state machine based on an EAP "Switch"
    model. This model includes  events and actions for the interaction
    between the EAP Switch and EAP methods. A brief description of
    the EAP "Switch" model is given in the Introduction section.

    The State Machine and associated model are informative only.
    Implementations may achieve the same results using different
    methods.

>>- For some reason, the bottom page heading is right on
>>
   the next line after text ends. E.g. Section 4.1.
>>   I find this a bit confusing, it takes a moment to
>>   realize that your eyes have read into the heading and
>>   not a continuation of the paragraph. If you can change
>>   this easily, please do. If not, don't worry about it...
> 
> This is a LaTeX-ism, worst case I will fix it by hand.








Great, thanks!

Proposed Resolution: Accept

Issue 231: RFC 3748 NITs
Submitter name: Florent Bersani
Submitter email address: mailto:florent.bersani@rd.francetelecom.fr
Date first submitted: 3/18/2004
Reference: http://mail.frascone.net/pipermail/public/eap/2004-March/002385.html
Document: RFC2284bis-09
Comment type: Editorial
Priority: 2
Section: Various
Rationale/Explanation of issue:

While rereading draft-ietf-eap-rfc2284bis-09.txt, I think I have spotted some nits or
minor issues:

1) Specification of length fields. I did not find a place where it said
the value of this field gave the length in bytes

2) Section 6.2 "Method Types 42-191 may be allocated on the advice of a
Designated Expert, with Specification Required" - types 43 and 44 have
been allocated (EAP-FAST and Zonelabs EAP), thus change to "Method Types
44-191 may be allocated on the advice of a Designated Expert, with
Specification Required"

3) While reading section 7.2, I got the impression that MS-CHAPv2 was
more resistant to dictionary attacks than MS-CHAPv1, which is the only
to be MS-CHAP to be mentioned. This is of course not true (see for
instance http://www.schneier.com/paper-pptpv2.pdf and
http://mopo.informatik.uni-freiburg.de/pptp_mschapv2/pptp_mschapv2.html).
Perhaps adding MS-CHAPv2 to the list would save users from misusing it
(since it is still widely available)

4) Section 7.10 "This restriction will be relaxed in a future document
that specifies how the EMSK can be used". My understanding is that this
document will be the EAP Key Management Framework itself (see the
ongoing discussion about the incorporation of
draft-salowey-eap-key-deriv-02.txt.

[Bernard Aboba] 

The length descriptions include sentences like:

"A message with the Length field set to a value larger than the
number of received octets MUST be silently discarded." 

So I think this is sufficiently clear. 

The proposed changes are as follows:

In Section 6.2, change:

"  Method Types 1-41 have been allocated, with 20 available for re-use.
   Method Types 42-191 may be allocated on the advice of a Designated
   Expert, with Specification Required."

To:

"  Method Types 1-44 have been allocated, with 20 available for re-use.
   Method Types 45-191 may be allocated on the advice of a Designated
   Expert, with Specification Required."

In Section  7.6, change:

"   Password authentication algorithms such as EAP-MD5, MS-CHAPv1
   [RFC2433] and Kerberos V [RFC1510] are known to be vulnerable to
   dictionary attacks.  MS-CHAPv1 vulnerabilities are documented in
   [PPTPv1]; Kerberos vulnerabilities are described in [KRBATTACK],
   [KRBLIM], and [KERB4WEAK]."

To:

"   Password authentication algorithms such as EAP-MD5, MS-CHAPv1
   [RFC2433] and Kerberos V [RFC1510] are known to be vulnerable to
   dictionary attacks.  MS-CHAPv1 vulnerabilities are documented in
   [PPTPv1]; MS-CHAPv2 vulnerabilities are documented in [PPTPv2];
   Kerberos vulnerabilities are described in [KRBATTACK], [KRBLIM], and [KERB4WEAK]."

Add the following informative reference:

"   [PPTPv2]   Schneier, B. and Mudge, "Cryptanalysis of Microsoft's
              PPTP Authentication Extensions (MS-CHAPv2)", CQRE '99, 
              Springer-Verlag, 1999, pp. 192-203."

Proposed Resolution: Accept

Issue 232: User identity confidentiality
Submitter name: Hannes Tschofenig	
Submitter email address: Hannes.Tschofenig@siemens.com
Date first submitted: 3/10/2004
Reference:
http://mail.frascone.net/pipermail/public/eap/2004-March/002366.html
Document: draft-walker-ieee802-req-00
Comment type: 'T'
Priority: '1' Should fix
Section: 2.3 and 2.4
Rationale/Explanation of issue:

Section 2.4 lists the requirement for user identity confidentiality as a MAY
requirement:

"
[10] End-user identity hiding.  This corresponds to the
     "Confidentiality" security claim defined in [RFC2284bis], Section
     7.2.1.
"

User identity confidentiality gains more importance in the presence of wlan
hotspots and also due to transmission of location information.

Additionally, the requirement does not differentiate between active and
passive user identity confidentiality. Solid active user identity
confidentiality requires public based mechanism and cannot be a MUST or
SHOULD requirement. Passive user identity confidentiality can, however, be
accomplished with authentication and key exchange protocols based symmetric
keys. For the wireless environment passive user identity confidentiality
should be of higher priority.

Requested change:

Add a requirement to section 2.3 (SHOULD requirement section):

Passive user identity confidentiality for the EAP peer:  This corresponds to
the
     "Confidentiality" security claim defined in [RFC2284bis], Section
     7.2.1. Passive user identity confidentiality provides protection
against an eavesdropper at the wireless link or in the AAA infrastructure.
It does not protect against an active adversary.
"

Modify existing requirement in section 2.4 (MAY requirement section):

Active user identity confidentiality for the EAP peer:  This corresponds to
the
     "Confidentiality" security claim defined in [RFC2284bis], Section
     7.2.1. Active user identity confidentiality prevents disclosure of the
identity of the EAP peer even against an active adversary.
"

[Bernard Aboba]  The proposed resolution is as follows:

Promote Requirement [10] of Section 2.3 to a SHOULD. 

Proposed Resolution: Accept

Issue 233: WLAN Comments
Submitter name: Avi Lior	
Submitter email address: mailto:avi@bridgewatersystems.com
Date first submitted: 3/23/2004
Reference:
http://mail.frascone.net/pipermail/public/eap/2004-March/002394.html
Document: draft-walker-ieee802-req-00
Comment type: 'T'
Priority: '1' Should fix
Section: Various
Rationale/Explanation of issue:

I have been reading draft-walker-ieee802-req-00.txt and comparing it to
2284bis-09  Note that its 09 and not 07.  I found the following:

In walker you say:

[3] Synchronization of state.  This corresponds to the "Protected
     result indication" security claim defined in [RFC2284bis], Section
         7.2.1.

The problem:
Section 7.2.1 of 2284bis-09 does not contain "Protected result indication".
This now appears in section 7.16 of 2284bis-09.

EDITORIAL COMMENT

[5]  Protection against man-in-the-middle attacks.  This corresponds to
     the "Cryptographic binding", "Integrity Protection", "Replay
     protection", and "Session Independence" security claims defined in
     [RFC2284bis], Section 7.2.1.

In the above use:
 "Integrity protection" instead of "Integrity Protection"
 "Session independence" instead of "Session Independence"

EDITORIAL COMMENT

Rewrite:
2.5.  Non-compliant EAP authentication methods

EAP-MD5-Challenge (the current mandatory-to-implement EAP authentication
method), is defined in [RFC2284bis] Section 5.4.  EAP-MD5-Challenge and
two EAP authentication methods defined in [RFC2284bis], One-Time
Password (Section 5.5) and Generic Token Card (Section 5.6), are non-
compliant with the requirements defined in this document.

As:

2.5.  Non-compliant EAP authentication methods

EAP-MD5-Challenge (the current mandatory-to-implement EAP authentication
method), defined in [RFC2284bis] (Section 5.4) and the
two EAP authentication methods defined in [RFC2284bis], One-Time
Password (Section 5.5) and Generic Token Card (Section 5.6), are non-
compliant with the requirements defined in this document.

[Bernard Aboba] The proposed resolution is as follows:

For the "Protected Result Indication" issue, see the resolution of Issue 224. 

For the "Non-compliant methods" issue, see the resolution of Issue 225.

Accept the editorial changes relating to capitalization.

Proposed Resolution: Accept

Issue 234: Comments
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: 3/25/2004
Reference: http://mail.frascone.net/pipermail/public/eap/2004-March/002400.html
Document: draft-walker-ieee802-req-00
Comment type: T/E
Priority: S/1
Section: various
Rationale/Explanation of issue:

1) Security considerations

The draft does not have a "security considerations" section.
I think this section should provide at least a brief rationale
about why the requirements are what they are.  In some cases,
the reasons are fairly obvious; in other cases, it is not
immediately clear why a system not meeting that requirement
would be unacceptable.

2) Conditional compliance

Section 1.1 defines the terms "unconditionally compliant" and
"conditionally compliant". Since the draft includes only one
SHOULD level requirement (about fragmentation), I do not think
this distinction adds any value to the document.

3) Synchronization of state

I agree with Joe Salowey's comment in issue 224 that protected
result indications and synchronization of state don't have much
to do with each other.  Joe's proposed text looks basically OK,
but I am not sure whether it is actually necessary. Much of it
just attempts to capture what being a "not totally flawed"
authentication method means.

I also agree with 2284bis's conclusion that protected result
indications do not add any significant value in 802.11 use, so
IMHO they should not be required.

4) Cryptographic bindings

A strict reading of the draft would suggest that, for instance,
OTP-over-PEAPv1 would not be acceptable while OTP-over-PEAPv2
would be. This is because PEAPv1 does not have "cryptographic
bindings". However, both cases are actually equally secure since
OTP does not generate a key: so actually PEAPv2 does not have
"cryptographic binding" in this case either...

IMHO this case does not have so severe security problems that it
should be prohibited. As noted in 2284bis section 7.4, there are
other valid approaches that prevent the MitM attack, including
policies about when to use which methods.  Also, 2284bis already
requires that "tunneled methods MUST support protection against
man-in-the-middle attacks" (section 2.1), presumably meaning
that policy is one possible way to support this.

How about "When a tunnel method is used with "inner" methods
that support key derivation, the tunnel method SHOULD support
the "cryptographic binding" claim."? Or perhaps no text
is required here since 2284bis already has the MUST requirement
relating to this?

5) Dictionary attacks

There are good reasons to prohibit methods vulnerable to
dictionary attacks, but IMHO those same reasons apply
equally to 802.11i PSK mode. Perhaps this apparent
contradiction should be somehow justified, or maybe
changed to a "SHOULD NOT"?

[Bernard Aboba] The proposed resolutions are as follows:

1) A security considerations section has been added. See the resolution of Issue 225.

2) Other proposed resolutions will promote more requirements to a SHOULD. 

3) See resolution of Issue 224. 

4) Discuss the proposed modification within IEEE 802.11i. 

5) The PSK mode vulnerability exists in part because there is no mandatory-to-implement EAP method satisfying the 
dictionary attack requirement. Therefore the solution is not to weaken the requirement, but to encourage
development of methods that conform to it. 

Proposed Resolution: Accept

Issue 235: Rewrite of Section 1
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 4/3/2004
Reference: http://mail.frascone.net/pipermail/public/eap/2004-April/002414.html
Document: Keying-01
Comment type: T/E
Priority: S
Section: 1
Rationale/Explanation of issue:

I've gone and rewritten Section 1 of the Key Framework document in order to
improve the organization and readability.  See URL for complete text. 

[Florent Bersani] I have concerns with the current wording of section 1.4.1 of the Key 
management framework: it seems to me as though it hinders the channel 
binding capability (please see the thread on Jari and Pasi's new I-D on 
authenticated service identities) - since to provide channel binding, 
EAP methods precisely need to transfer media specific information 
(though in a possibly media agnostic framework like the aforementioned 
draft).

I understand (and subscribe to) the fact that EAP methods should be 
media agnostic in their design. However, a possible way to do so is 
precisely to define appropriate elements for every media type (although 
this probably means quite a lot of work for now and the future).

I would thus rather have something like: "Should an EAP method have 
knowledge of the lower layer over which it is transported and should it 
wish to utilize identifiers associated with a particular media 
environment - for instance to provide channel binding, it MAY do so but 
it SHOULD support all media types EAP is commonly run over to avoid 
specializing EAP to a particular media type".

[Bernard Aboba]

Media independence is one of the fundamental properties of EAP.  It is not
a "nice to have".

Had this advice been taken in 1998 when EAP was first implemented,
operation over 802.11 would not be possible today since that was not one
of the media on which EAP was commonly run over at the time.

Similarly, 802.16 is not common today, but it has adopted EAP as its
authentication framework.

I am not aware of a case in which media independence needs to be
compromised in order to provide for identification or channel binding.
For example, an EAP method need not necessarily be aware of the content
of an Identifier in order to use it.  In terms of channel binding, it can
pass the Called or Calling-Station-Id to the AAA server as an opaque blob
and receive back a confirmation of whether it matched or not, again
without having knowledge of media.

[Florent Bersani] 

Let's rephrase: my point was that to the naive reader that I am, the 
media independence seemed to contradict the channel binding. If this is 
not the case (which I do hope and believe), then some clarification 
might be needed. The text you very kindly provided might be well suited 
to do so...

My only question (which does not belong to EAP) is more of a trivial 
conclusion on implementations: for the EAP method to pass the opaque 
blob containing the Called or Calling-Station-Id, it first needs to get 
that blob. Hence, we need here some communication between the EAP method 
and something that is aware of the media over which EAP is being run, 
don't we?

[Joe] Yes, there needs to be a communication between EAP, which does
authentication, and the party(s) responsible for authorization.  There
needs to be some data exported out of the EAP method to accomplish this such
as authenticated identity and channel binding information.  The
authorization piece would need to be aware of what the parties communication is trying
to do.

[Alper Yergin] This should be handled by the NAS, which implements (and glues together)
EAP, EAP lower layer, AAA backend protocols.

[Bernard Aboba] To address the issue here is the proposed fix:

Add the following paragraph to Section 1.4: 

"Note that media independence may be retained within
EAP methods that support channel binding or method-specific
identification. An EAP method need not be aware of the content
of an identifier in order to use it. This enables an EAP method 
to use media-specific identifiers such as MAC addresses without 
compromising media independence. To support channel binding,
an EAP method can pass binding parameters to the AAA server in the
form of an opaque blob, and receive confirmation of whether the
parameters match, without requiring media-specific knowledge."

For the full text, see Section 1 of: 
http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02_c.txt

Proposed Resolution: Accept

Issue 236: Rewrite of Section 2
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 4/3/2004
Reference: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02_c.txt
Document: Keying-01
Comment type: T/E
Priority: S
Section: 2
Rationale/Explanation of issue:

I've gone and rewritten Section 2 of the Key Framework document in order to
improve the organization and readability. 

[Florent Bersani] 

Well, I see four types of keys

>    [1] Keys calculated locally by the EAP method but not exported,
>        such as the TEKs.
>    [2] Keys exported by the EAP method: MSK, EMSK, IV 
>

>and
>        keys calculated from exported quantities: AAA-Key.
>  
>
Shouldn't this be a (logically) separated type?

[BA] Yes. Fixed. 

>    [3] Keys calculated by the Secure Association Protocol: TSKs.
>
>   In order to protect some or all of the EAP conversation, EAP methods
>   supporting key derivation typically negotiate a ciphersuite and
>   derive Transient EAP Keys (TEKs) to provide keys for that
>   ciphersuite.  However, the TEKs are stored locally within the EAP
>   method and are not exported.
>  
>
Does this preclude TEK caching? My answer is no. Is clarification 
required to specify what does "be exported" and "not be exported" mean?

[BA] TEK caching is not precluded.  This should be clarified in Section 3. 

See the reference for updated Section 2 text. 

Proposed Resolution: Accept

Issue 237: Reference cleanup
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 4/3/2004
Reference: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02_c.txt
Document: Keying-01
Comment type: E
Priority: S
Section: 7
Rationale/Explanation of issue:

I've gone and cleaned up Section 7 (References). See URL for complete text. 

Proposed Resolution: Accept

Issue 238: AAA-Key Missing from Figure 5
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: 5/7/2004
Reference: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02_c.txt
Document: Keying-02_c
Comment type: E
Priority: S
Section: 2.2, Figure 5
Rationale/Explanation of issue:

The "peer" box in Figure 5 does not list
AAA-Key, it only lists MSK, EMSK, and TSKs.
Compare this to Figure 4, where AAA-Key is
listed.

Suggested resolution: add AAA-Key to the list
of keys in the "peer" box.

Proposed Resolution: Accept

Issue 239: Various NITs
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: 5/7/2004
Reference: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02_c.txt
Document: Keying-02_c
Comment type: E
Priority: S
Section: Multiple
Rationale/Explanation of issue:

- Abstract: s/Extensible Authenticaton Protocol/
Extensible Authentication Protocol/
- 1.3.3: s/capabilties/capabilities/
- 1.4.1: s/transproted/transported/
- 2.4, bullet "[b]": s/identifies/identities/
- 2.4: s/port identifer/port identifier/
- 3.5.1: s/authentiator/authenticator/
- 3.6.2: s/Identitites/Identities/
- 4.5: s/persistant/persistent/
- Appendix A: s/fascilitate/facilitate/
- RFC2284bis reference lists just one
author, but there are many. Is this an
xml2rfc database bug? I've seen those
sometimes... have to edit manually.

Proposed Resolution: Accept

Issue 240: Reference Issues
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: 5/7/2004
Reference: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02_c.txt
Document: Keying-02_c
Comment type: E
Priority: S
Section: Normative References
Rationale/Explanation of issue:

I'm not sure the reference [IEEE802] needs to
be normative. As far as I can see, its used
as an example in the text. But I may have missed
something.

RFC 1321 is not used anywhere in the text, but
its in the informative references section. Same
for RFC 2230, 2402, 2406, 2782, 3079, 3394, and
FIPS197, FIPS.180-1.1995, EAPAPI, and IEEE80211F.

Proposed Resolution: Accept

Issue 241: Corner Case in 802.1X/EAP State Machines
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 5/7/2004
Reference: http://mail.frascone.net/pipermail/public/eap/2004-May/002462.html
Document: SM-03, 2284bis-09
Comment type: T
Priority: S
Section: Normative References
Rationale/Explanation of issue:

Recent interoperabilty tests have discovered a corner case in the
802.1X/EAP State Machines where it is not entirely clear what the correct
behavior is:

  Supplicant                               Authenticator                          AAA Server
            ------- EAPOL-Start ----------->
            <----- ID Req(1) -----------------
            ------- EAP Response(1)---------------------------------------------------->
            <----- EAP Request(2) -------------------------------------------------------
            ------- EAPOL-Start ----------->

What is the correct behavior for the Authenticator?

1. Retransmit the EAP-Request (ID=2)?
2. Abort the EAP authentication and send another EAP-Request (ID=3)?

Since there is an EAP-Request outstanding, the EAP state machine appears
to indicate that the correct response is to retransmit (option 1).
However, the IEEE 802.1X-REV state machine appears to indicate that the
correct response is to abort authentication. [RFC 3748] Section 4.1 states:

"Additional Request packets MUST be sent until a valid Response packet is
received, or an optional retry counter expires."

Note that the AAA server has sent an EAP-Request with ID=2 so that it is
expecting an EAP-Response with ID=2, which is not what it would get if the
Authenticator takes Action #2.

[Jim Burns] My hand trace of the state machine indicates that they define the 
result to be #2:

" 2. Abort the EAP authentication and send another EAP-Request (ID=3)"

This occurs because an EAPOL-START from the .1X supplicant means to 
(re)start the .1X process.

Details of hand trace follow:
----------------
Starting states:
    .1X authenticator front end machine is in the AUTHENTICATING state
    .1X authenticator back end machine is in the REQUEST state
    EAP authenticator machine is in the IDLE state
------------------
Hand trace following the event:  EAPOL-Start arrives.
.1X authenticator front end machine transitions to the ABORTING 
state, setting authAbort to TRUE
.1X authenticator back end machine transitions to the INTIALIZE 
state (due to authAbort) and sets authAbort to FALSE
.1X authenticator front end machine transitions to the RESTART 
state and sets eapRestart to TRUE
EAP authenticator machine transitions to the INITIALIZE state 
restarting the EAP authenticator machine that will cause a NEW beginning 
EAP request (often, but not always a request id) to be sent from the 
authenticator with a new EAP ID.

[John Vollbrecht] It seems in this case that the lower layer terminates the initial session 
and causes a restart.  If EAP knows that the lower layer is terminated then 
I am not sure why it would continue to resend.

Perhaps a additional clause in the 3748 document saying

" --- until a vialid Respons packet is received, an optional retry counter 
expires, or a termination of the sequence is received from the lower layer."

[Bhawani Sapkota] I think there is only one positive action in this case. Since the client has already
abandoned the on-going eap conversation, and most likely has already reset its eap
state machine, by retransmitting original eap request (id=2 in your original email)
does not fix any problem. The correct action must therefore be the second option.

The question about what the server is supposed to do when it receives
Access-Request/EAP-Response/Identity, since it is an EAP-Response/Identity, the
server can unambiguously determine that this is not a continuation of the existing
session. However, if the state attribute is included, based on server's
implementation, it can further utilize that information to gain additional
information about the client's previous state.

[Paul Funk] The new 802.1X Authenticator state machine is just plain wrong.

The problem is that upon association both sides start sending. The
authenticator sends an EAP-Request/Identity while the supplicant
sends an EAPOL-Start.

The old 802.1X state machines had it right. If the authenticator
receives an EAPOL-Start after sending its EAP-Request/Identity,
it simply sends another Request-Identity with the same ID. This
has the benign effect of causing two EAP-Response/Identity
messages to be sent by the supplicant. The second is simply
ignored by the authenticator, and there is not an issue of two
authentication sessions being created.

The new 802.1X state machines move the Identity logic out of
the PAE state machines into the Backend state machines. An
Identity message in either direction is no longer anything special,
and cannot be distinguished from other EAP messages. Now the
authenticator PAE state machine is at a loss for how to control
the backend so it doesn't think that a whole new authentication is
required.

Note that there are existing APs that don't implement the old (but
correct) state machine logic, and they cause all kinds of havoc
with RADIUS servers. Some start an authentication session with
the RADIUS server, then abandon it and start a new one. Some
even send the State attribute from the first authentication in the
new authentication. So in a sense this is not a new problem.

There is no reason to abort an authentication because an EAPOL-Start
has arrived, if the only packet sent by the AP is an EAP-Request/
Identity. This is akin to two peers both initiating a TCP session with
the other - you're supposed to end up with just one session.

However, it is necessary to abort the authentication upon EAPOL-Start
if it has gone further than EAP-Request/Identity having been sent. This
does indicate that the supplicant wishes to abort that EAP session. It is
also necessary for receipt by the AP of an EAPOL-Start to cause
resend of EAP-Request/Identity, since it cannot be determined whether
the original EAP-Request/Identity has been lost. It's a good idea, I think,
for the resend of the EAP-Request/Identity to use the same ID; this
guarantees that both sides will treat it as a duplicate packet in the same
authentication session.

Since in the new 802.1X state machines, EAP-Request/Identity is no
longer a "canned" packet, one must conclude that this was done to
allow the AP to send an EAP-Start to the RADIUS server, in order to
allow the RADIUS server to issue the EAP-Request/Identity. I'm not
sure why that would be useful. However, if that is the intent, the only
way to fix the state machine would be for the authenticator PAE to
cache the initial EAP-Request/Identity and resend it if it receives an
EAPOL-Start. This would be done from its CONNECTING state,
not from its AUTHENTICATING state - in AUTHENTICATING, an
EAPOL-Start would abort the authentication and initiate a new one.

Note that there is confusion as to how to transition from CONNECTING
to AUTHENTICATING. The diagram indicates that the transition occurs
when the first request is sent. However, documentation of the
"authEntersAuthenticating" counter indicates that the transition occurs
upon receipt of EAP-Response/Identity. I think the latter makes more
sense, and would enable the type of logic I've suggested.

[Jim Burns]

I believe the correct fix would be as follows:
The EAP state machine (not the .1X state machine) differentiates between 
its initial EAP request and subsequent requests following receipt of a 
response to its initial request. If EAP is in the initial state and 
receives an 'eapRestart' then it ignores it and just resends its initial 
request with the same ID. In other words, put the resend of the initial 
request that used to reside in the .1X-2001 machine in the EAP machine.

An initial suggestion (I have not fully hand traced this) as to how this 
might be done would be to modify the EAP Authenticator state machine 
with the following:
1. add an internal variable: eapBegun.
2. Set eapBegun to FALSE in INITIALIZE state.
3. On the transition from IDLE to RETRANSMIT alter the logic from 
'retransWhile==0' to be '(retransWhile==0 || ((eapBegun=FALSE) && 
(eapRestart )))'
4. Change unconditional transition into INITIALIZE from 'eapRestart && 
portEnabled' to '(eapRestart && (eapBegun=TRUE)) && portEnabled)'
5. Set eapBegun to TRUE in RECEIVED state.

I doubt this catches all the nuances, and I am sure the EAP state 
machine folks might do it more elegantly, but I believe that this 
achieves the goal that Paul has discussed.

Proposed Resolution: Discuss

Issue 242: Errata
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: 5/24/2004
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00608.html
Document: RFC 3579
Comment type: T
Priority: S
Section: Errata
Rationale/Explanation of issue:

Here is Errata text for RFC 3579:

  "The use of the State attribute is necessary in order to
   distinguish a restarted EAP authentication process from
   the continuation of an ongoing process (by the same user
   on the same NAS and port).

   The following rules specify how this attribute is used
   with RADIUS EAP:

     o  RADIUS servers SHOULD always include the State
        attribute in an Access-Challenge, Access-Accept,
        or Access-Reject message.

     o  Normally, a NAS copies the received State attribute
        to an Access-Request sent as a response to an
        Access-Challenge [RFC2865], Section 5.24. Note that
        an Access-Request sent as a result of a new or
        restarted authentication run MUST NOT include the
        State attribute, even if the State attribute has
        previously been received in an Access-Challenge
        for the same user and port."

Proposed Resolution: Accept

Issue 243: Clarification of "State Synchronization"
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: 5/11/2004
Reference: http://mail.frascone.net/pipermail/eap/2004-May/002495.html
Document: draft-walker-ieee802-req-01
Comment type: T
Priority: S
Section: Normative References
Rationale/Explanation of issue:

A question has arisen about the meaning of the phrase
"protocol both executed" in Section 2.2, clause [4].

Some questions:

a. Does this refer to the EAP Type used by both sides?  Most current
   EAP methods do not include the Type field in MICs, so they do
   not verify this.

b. If we are talking about a protocol inside the EAP method, does this
   apply to protocol version numbers and other such state?

c. Can clause [4] be operationalized? That is, is the text
   specific enough to make a judgment on whether a
   method satisfies the conditions?

Some older methods don't even generate keys, so those would not
include the EAP Type or anything else for that matter. Looking
at key generating methods, some do not take EAP Type into account
(e.g., EAP TLS) and some do (e.g., EAP AKA).

I think it would be prudent to include the context information
in new protocol designs. However, you might question whether
its necessary to include the EAP Type, if the formulas for
different methods are different? OTOH, this may not always
be the case. For instance, if EAP TLS does not include the
EAP Type in cryptographic protection, does it mean that EAP
TLS and another, new, TLS-based method could be switched
without the endpoints realizing this?

Also, even if method 1 and method 2 have a MIC
for the EAP Type, it does *not* guarantee that you
couldn't switch methods. Lets assume the two methods
calculate their MICs as follows:

    method_1_MIC = MAC_K(EAP Type | ... | Parameter 1)
    method_2_MIC = MAC_K(Parameter 2 | ... | EAP_Type)

where Parameter i is whatever other data that gets
included in the MIC. Now, we can substitute method 2
for method 1 as long as we set Parameter 1 = method 2's
EAP Type number and Parameter 2 = method 1's EAP Type
number. In order to avoid this, there would have to
be either (a) a common formula on what data methods
include in their MICs, or (b) include EAP Type in the
key derivation of AAA-Key. Both alternatives have a
number of problems, so it seems that we can't make
this bullet proof. An approch similar to channel
bindings might work better in this context.

Finally, executed EAP Type is just one part of the
"context" around an authentication method. You could
argue that we should also specify whether lower layer
and its properties should be included. But then we are
again in the realm of channel bindings, which we earlier
agreed should not be mandatory now, due to lack of
support in methods.

> b. If we are talking about a protocol inside the EAP method, does this
>    apply to protocol version numbers and other such state?

I think it should -- if the protocol in question has version
numbers. However, even this question is more complicated
than at first appears, so it may be hard to write down the
specific requirement. The use of extension AVPs under the
basic MICs should also be OK in addition to an explicit
version number.

> c. Can the text proposed in Issue 224 be operationalized? That is,
>    is the text specific enough to make a judgement on whether a
>    method satisfies the conditions?

I think we can improve the text. I guess the question is
if we'll end up in the same situation as we did earlier
with PRIs, i.e., we gradually realize that we can't make the
text (or the scheme) bullet proof.

[Bernard Aboba] The proposed resolution is as follows:

Change clause [4] of Section 2.2 to the following:

[4]  Synchronization of state.  The EAP method state of the EAP peer and
     server must be synchronized when the EAP method completes
     successfully.  This includes the internal state of the
     authentication protocol but not the state external to the EAP
     method,  such as the negotiation occuring prior to initiation of
     the EAP method.  The exact state attributes that are shared may
     vary from method to method but typically include the method version
     number, what credentials were presented and accepted by both
     parties, what cryptographic keys are shared and what EAP method
     specific attributes were negotiated, such as ciphersuites and
     limitations of usage on all protocol state.  Both parties must be
     able to distinguish this instance of the protocol from all other
     instances of the protocol and they must share the same view of
     which state attributes are public and which are private to the two
     parties alone.

[Jari Arkko] I propose the following: 

Change clause [4] of Section 2.2 to the following: 

[4]  Shared state equivalence.  The shared EAP method state of the EAP peer
     and server must be equivalent when the EAP method completes
     successfully on both sides.  This includes the internal state of the
     authentication protocol but not the state external to the EAP
     method,  such as the negotiation occurring prior to initiation of
     the EAP method.  The exact state attributes that are shared may
     vary from method to method but typically include the method version
     number, what credentials were presented and accepted by both
     parties, what cryptographic keys are shared and what EAP method
     specific attributes were negotiated, such as ciphersuites and
     limitations of usage on all protocol state.  Both parties must be
     able to distinguish this instance of the protocol from all other
     instances of the protocol and they must share the same view of
     which state attributes are public and which are private to the two
     parties alone.

Proposed Resolution: Accept

Issue 244: Fixes for Type Code Allocations
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: 5/23/2004
Reference:
Document: RFC2284bis-09
Comment type: E
Priority: S
Section: 6.2
Rationale/Explanation of issue:

Change:

"The original EAP method Type space has a range from 1 to 255, and is
the scarcest resource in EAP, and thus must be allocated with care.
Method Types 1-45 have been allocated, with 20 available for re-use.
Method Types 46-191 may be allocated on the advice of a Designated
Expert, with Specification Required."

To:

"The original EAP method Type space has a range from 1 to 255, and is
the scarcest resource in EAP, and thus must be allocated with care.
Method Types 1-45 have been allocated, with 20 available for re-use.
Method Types 20 and 46-191 may be allocated on the advice of a
Designated Expert, with Specification Required."

Proposed Resolution: Accept

Issue 245: EAP Restart Issue
Submitter name: John Vollbrecht
Submitter email address: jrv@umich.edu
Date first submitted: 5/7/2004
Reference: http://mail.frascone.net/pipermail/eap/2004-May/002460.html
Document: RFC2284bis-09
Comment type: T
Priority: S
Section: 4.1
Rationale/Explanation of issue:

Section 4.1 of RFC 3748 states:

"Additional Request packets MUST be sent until a valid Response packet is
received, or an optional retry counter expires."

Where the lower layer terminates the initial session and causes a restart,
if EAP knows that the lower layer is terminated then I am not sure why it
would continue to resend.

Perhaps we should change this to:

"Additional Request packets MUST be sent until a valid Response packet is
received, an optional retry counter expires, or  a lower layer failure indication is received."

Proposed Resolution: Accept

Issue 246: IANA Considerations
Submitter name: Florent Bersani
Submitter email address: mailto:%20florent.bersanti@francetelecom.com
Date first submitted: 6/8/2004
Reference: http://mail.frascone.net/pipermail/eap/2004-June/002522.html
Document: RFC2284bis-09
Comment type: E
Priority: S
Section: 6.2
Rationale/Explanation of issue:

While reviewing again RFC 3748b, I just came across two little (and 
fairly uninteresting I admit) questions/remarks (that may however help 
RFC 3748 understanding in the future:

1) It is apparently not specified how expanded (method) types for 
vendor-ID 0 (IETF) can be allocated (e.g. Designated Expert, with 
Specification Required or standards action, FCFS, ...).
In section 6.2 we indeed only read:
"Method Type values 256-4294967295 may be allocated after Type values 
1-191 have been allocated."
I know we've probably got time before this happens but I just feel 
reluctant to leave an incomplete spec behind us ;-)

2) The (non)-use of 0 as packet code or method type

The newbie I am is pretty sure that there are good reasons why EAP did 
not start its code and type space at 0 (and I'd be more than thankful to 
anybody who could tell me why) but I find the current wording about not 
using this value a (very little) bit confusing.

In section 6.1 of RFC 3748b we read:
"Packet Codes have a range from 1 to 255" and on the IANA website 
(http://www.iana.org/assignments/eap-numbers) we find:

"(last updated 12 April 2004)
Packet Codes:
Value Description Reference
1 Request [RFC-ietf-eap-rfc2284bis-09.txt]
2 Response [RFC-ietf-eap-rfc2284bis-09.txt]
3 Success [RFC-ietf-eap-rfc2284bis-09.txt]
4 Failure [RFC-ietf-eap-rfc2284bis-09.txt]
5-255 Unallocated"

In section 6.2 of RFC 3748b we read:
"The original EAP method Type space has a range from 1 to 255" and on 
the IANA website (http://www.iana.org/assignments/eap-numbers) we find:

"(last updated 12 April 2004)
...
Value Description Reference
0 RESERVED
1 Identity [RFC-ietf-eap-rfc2284bis-09.txt]
..."

Indeed, the value 0 is used in the NAK response.

My suggestion would be to find a way to simply reflect this usage in RFC 
3748 and for IANA.
My preference would be adding a small reminder on the value 0 usage in 
RFC 3748 section 6.2 and updating the IANA website to also refer to RFC 
3748 for this value. I am ready to propose some text if people feel like 
making this minor and unimportant change.

BR,
Florent

P.S: BTW, it seems like we (EAP and/or IANA) have not captured the point 
I raised earlier on Method Type 7&8 
(http://mail.frascone.net/pipermail/public/eap/2004-May/002486.html).
Again, I am ready to propose some text if people feel like making this 
minor and unimportant change (and I concurred to Jari's proposal 
"allocated but unused").

Proposed Resolution: Discuss

Issue 247: Comments on EAP State Machine (Editorial)
Submitter name: Florent Bersani
Submitter email address: florent.bersani@rd.francetelecom.fr
Date first submitted: 6/8/2004
Reference: http://mail.frascone.net/pipermail/eap/2004-June/002523.html
Document: SM-03
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

Below are some comments that came to my mind while reading the latest 
version of EAP state machine I am aware of 
(http://www.cs.umd.edu/~npetroni/EAP/drafts/ietf-eap-statemachine/04/draft-ietf-eap-statemachine-strawman-
04.pdf).

I know that these comments may:
* Come much too late (since IETF last call has ended 2004-05-13 so it 
shouldn't be the time IINM to propose any "real" changes to this document)
* Be completely naive or off the rocket
* Echo some comments that have already been made (although I tried my 
best to reread - and understand ;-) - the EAP state machine issues 
tracked by Bernard

I just felt like making them:
* Because the probability that they be of some help somehow is - I hope 
- non-zero
* Because the probability that someone kindly replies to educate me, is 
- I hope - non-zero
* For the record

So here they go.

Comment #1 - Editorial

In section 3.2 state machine symbols, we can read:
"+ Arithmetic addition operator.
- Arithmetic subtraction operator."

I find these definitions useless (IINM we never see the notation + in 
the state machines and the notation ++ which is perhaps why this was 
included should either be defined directly or assumed understandable as 
it is said in section 3.1 "The interpretation of the special symbols and 
operators used in the state diagrams is as defined in Section 3.2; these 
symbols and operators are derived from the notation of the C++ 
programming language, ISO/IEC 14882.") BTW, I cannot find any use of - 
or -- in the document. And anyway, I think that in case + and - are 
however necessary for the comprehension of the document, it should be 
stated on which space they operate (N, Z/2**16Z, Z/2**32Z...)

Comment #2 - Editorial

This is about portEnabled and eapRestart.

This discussion for what regards portEnabled is a follow-up on issues 
198 and 203. I do still find the name of this variable too .1X centric 
and, in the light of the recent debates on corner cases on EAP starts 
and restarts, I'd prefer a more explicit name (like Yoshi had proposed 
for instance). Also I'd like the current definition (e.g. in section 
4.1.1 "portEnabled (boolean) Indicates that the EAP peer state machine 
should be ready for communication. This is set to TRUE
when the EAP conversation is started by the lower layer. If at any point 
the communication port or session is not available, portEnabled is set 
to FALSE and the state machine transitions to DISABLED.") clarified (and 
why not - two - example instantiations given, one .1x and one IKEv2 for 
instance) to take the "new"? problems into account (e.g. section 7.12 of 
RFC 3748b "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. " )

For eapRestart, my problem is much the same, two concrete examples (.1X, 
PPP or IKEv2 for instance) would considerably help understand what this 
variable stands for.

Comment #3 - Editorial

This is about the initialization of lastID which is not done in the EAP 
peer state machine. This had been pointed out in issue 229 but 
apparently not taken into account.
Also specify, e.g. in section 4.3.1 that lastId may take the value "NONE"

Comment #4 - Editorial

This is about idleWhile. From my understanding, this timer steadily 
decreases and when it reaches 0, the peer may time out. Clearly, knowing 
the initial value of this timer, by a simple subtraction, one can get to 
know how long the peer has been waiting.
So, contrary to the definition in section 4.1.1 ("idleWhile (integer) 
Outside timer used to indicate how long the peer has waited for a new 
(valid) request."), I'd rather say that this timer indicates how long 
remains before the peer may time out.

Comment #7 - Editorial

I do not find any definition of m.buildResp (that is used in Figure 3 
EAP peer state machine) in section 4.4 Peer state machine procedures). 
Moreover, i would find it clearer if m.buildresp somehow indicated that 
it does not only depend on ReqId but also on some internal method state 
that has been calculated by m.process.

Comment #8 - Editorial

Although in section 4.4, it is said parseEapReq() "checks that the 
lengthfield is not longer than the received packet", I do not find it 
completely straightforward from Figure 3 what the peer does in case 
there is a parse error due to the length (or an invalid code type or...).

Comment #11 - Editorial

eapTimeout does not seem to be defined in the text.

Comment #13 - Editorial

Why call section 5 "standalone authenticator"? I bet this is the old 
story of the glass half full or half empty, because I'd rather have 
standalone EAP server.


Comment #15 - Editorial

The title of Section 6 is "EAP Backend Authenticator" which I find quite 
strange. I'd rather suggest "backend authentication server".

Comment #16 - Editorial

In section 6.2 we find: "The only difference is that some methods on the 
backend may support "picking up" a conversation started by the 
pass-through. That is, the EAP Request packet was sent by the 
pass-through, but the backend must process the corresponding EAP 
Response. Usually only the Identity method supports this, but others are 
possible"
Would it be possible to explain whether this possibility is explicitly 
left open by some document (in this case, which one) or is implicitly 
allowed (and in this case, whether there are yet 
settings/implementations which use such a possibility).

Comment #18 - Editorial

If the purpose of aaaIdentity is to allow encapsulation of the peer's 
identity in e.g. RADIUS User-Name attribute, I'd rather have aaaIdentity 
be directly the identity of the peer than a whole EAP packet.

[Nick Petroni] 

Sorry for the long delay in my responses. Hopefully we can get these
issues resolved this week or next. Here are my suggestions for addressing
Issue 247. I would like feedback, particularly on the last comment where I
am unsure the best way to resolve the issue.

Regards,
nick

Comment #1 - Editorial
 In section 3.2 do the following:
  - remove definition of '+'
  - remove definition of '-'
  - remove definition of '<'
  - remove definition of '>='
  - add definition of '++' as follows:
     "++  Increment the preceding integer operator by 1"
  - add definition of '<='
     "<=  Less than or equal to. Evaluates to TRUE if the value of
      the expression to the left of the operator is either less than or
      equal to the value of the expression to the right."

Comment #2 - Editorial
  In sections 4.1.1 and 5.1.1 add the following to the definition of
   portEnabled:
   "To avoid unnecessary resets, the lower layer may dampen link down
    indications when it believes that the link is only temporarily down and
    that it will soon be back up (see RFC 3748, section 7.12). In this case,
    portEnabled may not always be equal to the the "link up" flag of the
    lower layer."

Comment #3 - Editorial
  - In Figure 3 add the following to the INITIALIZE state:
     "lastId = NONE"
  - In section 4.3.1 change
       "lastId (integer)"  to  "lastId (integer or NONE)"

Comment #4 - Editorial
  In section 4.1.1 change definition of idleWhile to:
   "Outside timer used to indicate how long remains before the peer
    will timeout while waiting for a valid request."

Comment #7 - Editorial
  -In section 4.4 add the following definition:
       "m.buildResp()
       Method procedure to create a response message"

  -In sections 4.4, 5.4, and 6.4 add the following before the list of
     procedures:
    "NOTE: For method procedures, the method uses its internal state
     in addition to the information provided by the EAP layer. The
     only arguments that are explicitly shown as inputs to the
     procedures are those provided to the method by EAP. Those inputs
     provided by the method's internal state remain implicit."

  - For all procedures, add a sentence to the definition which defines
   the *type* of the return value.

Comment #8 - Editorial
  - In section 4.4  change
     "Also checks that the length  field is not longer than the received
      packet."
               to
     "In case of a parsing error (e.g. the length field is longer than
      the received packet), rxReq, rxSuccess, and rxFailure will all
      be set to FALSE. The values of reqId and reqMethod may be
      undefined as a result. "

  - In section 5.4  change
     "Also checks that the length  field is not longer than the received
      packet."
               to
     "In case of a parsing error (e.g. the length field is longer than
      the received packet), rxResp will
      be set to FALSE. The values of respId and respMethod may be
      undefined as a result."

Comment #11 - Editorial
  - In section 5.1.2, add the following definition:
    "eapTimeout (boolean)
        Set to TRUE in the TIMEOUT_FAILURE state if the authenticator
        has reached its maximum number of retransmissions without
        receiving a response."

Comment #13 - Editorial
   No changes

Comment #15 - Editorial
   No changes

Comment #16 - Editorial
  No changes

Comment #18 - Editorial
  Request advice on how to fix this from the group.

[Florent Bersani] 

All of your proposed resolutions look great to me.

Thanks a lot.

Florent, hope the group will give some feedback on the last (minor one)

Proposed Resolution: Accept

Issue 248: Comments on EAP State Machine (Technical)
Submitter name: Florent Bersani
Submitter email address: florent.bersani@rd.francetelecom.fr
Date first submitted: 6/8/2004
Reference: http://mail.frascone.net/pipermail/eap/2004-June/002523.html
Document: SM-03
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

Comment #5 - Technical

That's just a triviality about for instance the peer state machine: 
thanks to EAP idleWhile, the method does not have to set timers (EAP 
cares for it). However, in case the method wants to implement a "bad 
packet received" counter (e.g. it is waiting for a packet and to provide 
DoS resilience it wants to allow receiving a limited number of "bad 
packets" before the right one - instead of going automatically to 
failure), it has to do so by itself (and typically will use altReject if 
it wants to fail before the timeout. This is not an issue but perhaps it 
could be worth discussing the usefulness of such a behavior for EAP 
methods (see e..G g. RFC 3748 section 7.5 "Whether a MIC validation 
failure is considered a fatal error or not is determined by the EAP 
method specification") and that it can indeed be implemented in the EAP 
state machines (with a little disymmetry between the timer implemented 
within EAP and the "bad packet received" counter implemented within the 
method. I guess this comment is a way for me to express that I 
wholeheartedly agree with the point .3 Joe made in issue 203 (in other 
words the imbrication of EAP and EAP methods confine to layer violation).

Comment #6 - Technical

This is about DONE, CONT and MAY_CONT/UNCOND_SUCC, COND_SUCC and FAIL.

While I do not doubt that there are could technical reasons to use these 
variables (rather than simply CONT and DONE) and that the EAP state 
machine does not claim to be THE way to implement EAP (in its 
introduction "The State Machine and associated model are informative 
only. Implementations may achieve the same results using different 
methods"), I think that giving briefly the rationales behind this choice 
(which is not explicit in section 4.2 IMHO) would help the reader. In 
particular, giving an example of MAY_CONT's usefulness.

About the decision variable, here also an explanation of the design 
(maybe with an example) could help. Indeed, it seems to me that not all 
pairs (state, decision) are acceptable so state/decision are not totally 
independent. Here again, giving an example why COND_SUCC was introduced 
could help.

I think this concern is also related to the conditions in the state 
machine that allow the peer to transition to success or failure. They do 
not appear to be either trivial or symmetric. The newbie I unfortunately 
am, needs much more time to (fully) understand them than any other 
transition condition in the state machine. Bernard for instance 
questioned about these Success/Failure transitions in Issue 229. For 
instance, I am wondering, how the condition "altAccept && methodState != 
CONT && decision == FAIL" may occur.

Also in section 4.2 I tend to feel dizzy with some text in the paragraph 
methodState=DONE: "If both (a) the server has informed us that it will 
allow access and the next packet will be EAP Success,and (b) we're 
willing to use this access, set decision=UNCOND SUCC." I guess that 
condition (a) should rather be formulated in terms of altAccept, 
shouldn't it? Indeed while IIRC RFC 3748 mandates (in section 4.2 "The 
authenticator MUST transmit an EAP packet with the Code field set to 3 
(Success)" that a success packet be sent, this does not guarantee that 
the peer will ever receive it.

Comment #9 - Technical

Apparently Figure 4 (EAP Standalone Authenticator State Machine) leaves 
the door open to a sequence of EAP authentication methods (which is 
explicitly forbidden by RFC 3748 section 2.1 "However, the peer and 
authenticator MUST utilize only one authentication method (Type 4 or 
greater) within an EAP conversation"). This behavior may be prevented 
thanks to Policy.getDecision or PolicygetNextMethod... but I do not find 
this is exactly a matter of policy and at least, this should be pointed 
out (that the policy MUST forbid this behavior).

Comment #10 - Technical

Why include a separate TIMEOUT_FAILURE State? Why not use the FAILURE state?

Comment #12 - Technical

This one is stupid but what happens, according to Figure 4, when the 
standalone authenticator fails directly, i.e. starts by INITIALIZE, 
transitions to SELECT_ACTION where Policy.getDecision replies FAILURE 
and thus transitions to FAILURE - in the FAILURE state, I bet there is 
some problem with eapReqData = buildFailure(currentId) since currentId=NONE

Comment #14 - Technical

I am totally novice to DoS (I found a lot of papers on the subject, for 
instance related to IKE - I plan to read them soon :-)) so this point is 
probably not very important (my understanding is that one of the 
difficulties with DoS is to understand what is really relevant and what 
rather belongs to the .11 microwave oven attack, another one could be 
set the trade off between DoS resilience and "efficiency").

It just seems to me that Figure 4 prevents the standalone authenticator 
from ignoring (bogus) NAKs. Indeed, let us consider a corporate WLAN 
deployment where exactly one EAP method is allowed - so that no valid 
user will ever NAK. In this setting, there is no point in processing the 
NAK, possibly loosing the valid user's response if the attacker's NAK 
arrived first and starting all over. I did not find text on this in RFC 
3748 (the text I found was about preventing NAKs when a response to a 
method has already been received) which is not our case here.

Comment #17 - Technical

I fail to understand the transition in Figure 7 from 
INITIALIZE_PASSTHROUGH to AAA_IDLE when currentId==None, given that 
AAA_IDLE sets aaaEapResp=TRUE

[Nick Petroni]

A proposal from Pasi... Looks good to me.

> Comment #17 - Technical
>   Request text for section 7 and/or section 8 to
>   describe expected behavior when aaaEapRespData is NONE.

Here's also some text related to issue 248 comment #17:

  In Sections 6.1.1 and 7.1.2 change

  "aaaEapResp ... Indicates an EAP response is available for
  processing by the AAA server.

  aaaEapRespData ... The EAP packet to be processed."

  to

  "aaaEapResp ... Usually indicates that an EAP response, stored in
  aaaEapRespData, is available for processing by the AAA server.
  If aaaEapRespData is set to NONE, indicates that the AAA server
  should send the initial EAP request.

  aaaEapRespData ... The EAP packet to be processed or NONE."

[Florent Bersani] 

> Looks good to me. 

So does it for me :-)

[Nick Petroni] 

As Monday 7/19 is the cut-off for document submission, I would like to ask
for help in resolving as much of the remaining issues as possible in the
state machine document. Here is a list of necessary changes as I see them
for Issue 248. Please let me know how these look in principle and
contribute text if possible. I also will attempt to contribute text over
the next couple of days.

Thanks,
nick

Comment #5 - Technical
  No changes.

Comment #6 - Technical
  Request text to clarify the use the methodState variable in section
   4.2.

Comment #9 - Technical
  Request text amendments for policy functions to clarify that
  multiple authentication methods are not expected or propose
  alternate solution.

Comment #10 - Technical
  - change the text of TIMEOUT_FAILURE in section 5.5 and
    TIMEOUT_FAILURE2 in section 7.5 to the following:
  "A final state indicating failure because no response has been
   received. Because no response was received, no new message
   (including failure) should be sent to the peer."

Comment #12 - Technical
  Supersede by the resolution of Issue 251 (TBD).

Comment #14 - Technical
  Request text to describe the possible DoS issues and possible
  mitigation techniques. Specific changes to the SM necessary to
  achieve such mitigations would be great.

Comment #17 - Technical
  Request text for section 7 and/or section 8 to
  describe expected behavior when aaaEapRespData is NONE.

[Florent Bersani] 

I looked again at my comment #6 and the current text in the draft.

I guess that my original comment was twofold:
1) Since among the 9 theoretically possible (methodState,decision) 
pairs, only 6 were allowed (namely (CONT,FAIL), (MAY_CONT,COND_SUCC), 
(MAY_CONT, FAIL), (DONE, COND_SUCC), (DONE, UNCOND_SUCC) and 
(DONE,FAIL), I took this as a hint that there might be simpler way to 
implement things...
1) While thinking on simpler ways, I came to question the usefulness of 
COND_SUCC: to me this decision value is harmful from a security POV. An 
attacker has no problem whatsoever to make the peer believe anything 
(i.e. success or failure) as soon as the peer has set COND_SUCC. So my 
comment was about: do we want to keep COND_SUCC? (same comment applies 
to MAY_CONT: I fail to see why we have (MAY_CONT,FAIL) - it could be 
replaced by (CONT,FAIL), couldn't it?)

This reflexion led me to the mechanism EAP-PSK currently uses to (try 
to) end properly its dialog, see 
http://perso.rd.francetelecom.fr/bersani/EAP_PSK/draft-bersani-eap-psk-03-d.html#rflag 
for a presentation of this mechanism (sorry for this rude ad on EAP-PSK 
but I think that what's in there could clarify my comment... and 
possibly get me some feedback ;-)).

After rereading the state machine draft , I believe that the text of 
section 4.2 is pretty clear (congratulations ;-)). My only remaining 
unanswered question is: do we want to keep COND_SUCC?

I am in favor of deleting it (as a legacy venue for irritating - though 
perhaps not very important - security trouble)...

... but I understand that I am probably *unfortunately* the only one to 
have this position and that it is probably too late to change this 
direction (don't worry, I am not going at this point  to try and reopen 
issues like #26 
http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2026 or others by 
saying that the current EAP-Success/Failure packet is not only useless 
but harmful ;-))

As a fall-back solution, I would recommend inserting something like the 
following text advising that COND_SUCC may be dangerous:

"In case the peer reaches the decision COND_SUCC, please note that the 
peer is vulnerable to an active attacker that may easily lead him to 
believe that the authenticator has reached any decision the attacker 
chooses. In situations where security is a concern, it is RECOMMENDED to 
avoid using the value COND_SUCC of the decision variable"

What do you think?

[Nick Petroni] 

> This reflexion led me to the mechanism EAP-PSK currently uses to (try
> to) end properly its dialog, see
> http://perso.rd.francetelecom.fr/bersani/EAP_PSK/draft-bersani-eap-psk-03-d.html#rflag
> for a presentation of this mechanism (sorry for this rude ad on EAP-PSK
> but I think that what's in there could clarify my comment... and
> possibly get me some feedback ;-)).
>
> After rereading the state machine draft , I believe that the text of
> section 4.2 is pretty clear (congratulations ;-)). My only remaining
> unanswered question is: do we want to keep COND_SUCC?
I think the answer is we have to. Some methods simply will not know
whether or not they are complete and actually must wait for Success or
Failure or another request to be received. We cannot exclude (for
legacy purposes) methods that cannot say for certain that they are not
complete or do not know the success of the method itself. COND_SUCC is
the only way to handle methods like MD5 where you have no idea if you
authenticated correctly or not. you have to wait for success or failure.

> ... but I understand that I am probably *unfortunately* the only one to
> have this position and that it is probably too late to change this
> direction (don't worry, I am not going at this point  to try and reopen
> issues like #26
> http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2026 or others by
> saying that the current EAP-Success/Failure packet is not only useless
> but harmful ;-))
I don't think you could change it if you wanted to... I think the charter
is pretty clear that existing methods can't be made obsolete. I could be
wrong though.

> As a fall-back solution, I would recommend inserting something like the
> following text advising that COND_SUCC may be dangerous:
>
> "In case the peer reaches the decision COND_SUCC, please note that the
> peer is vulnerable to an active attacker that may easily lead him to
> believe that the authenticator has reached any decision the attacker
> chooses. In situations where security is a concern, it is RECOMMENDED to
> avoid using the value COND_SUCC of the decision variable"
This would be a good recommendation to method writers I think, but I am
not sure a general claim about setting that variable alone is enough. We
could add some guidelines for method authors in the Implementation
Considerations section or perhaps better somewhere else? IMHO, the
middle of the SM description is not the place to get into this.

[Florent Bersani] 

Aaaaaaaaaaaaaarghn the L word in a protocol that apparently is becoming 
pervasive for the future (invading IKEv2, IEEE 802.1X, IEEE 802.11, IEEE 
802.16e, and why not IEEE 802.20)!

I am aware of what you say but I respectfully and strongly disagree.: if 
EAP is going to be a protocol of the future why cripple it with problems 
of the past.

This being said (and I expected your answer), I won't keep bothering 
with old (and given the point where we are now, slightly unconstructive) 
remarks.

> COND_SUCC is
>the only way to handle methods like MD5 where you have no idea if you
>authenticated correctly or not. you have to wait for success or failure.
>  
>
Again I wish that MD5-Challenge would disappear ;-)

>  
>
>>... but I understand that I am probably *unfortunately* the only one to
>>have this position and that it is probably too late to change this
>>direction (don't worry, I am not going at this point  to try and reopen
>>issues like #26
>>http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2026 or others by
>>saying that the current EAP-Success/Failure packet is not only useless
>>but harmful ;-))
>>    
>>
>I don't think you could change it if you wanted to... I think the charter
>is pretty clear that existing methods can't be made obsolete. I could be
>wrong though.
>  
>
No, no I think you are right

>  
>
>>As a fall-back solution, I would recommend inserting something like the
>>following text advising that COND_SUCC may be dangerous:
>>
>>"In case the peer reaches the decision COND_SUCC, please note that the
>>peer is vulnerable to an active attacker that may easily lead him to
>>believe that the authenticator has reached any decision the attacker
>>chooses. In situations where security is a concern, it is RECOMMENDED to
>>avoid using the value COND_SUCC of the decision variable"
>>    
>>
>This would be a good recommendation to method writers I think, but I am
>not sure a general claim about setting that variable alone is enough.
>
I think that you have seen only the aspect: "a good EAP method SHOULD 
provide protected result indications to avoid using COND_SUCC" but you 
have overlooked the aspect "EAP peer and server SHOULD use only good EAP 
methods" ;-)

I agree that the EAP state machine is probably not the best doc for his 
manifesto but since it is the State Machine that introduces COND_SUCC 
(which is not mandated by RFC 3748), then I'd recommend providing 
guidance on the usage of this "dangerous" variable.

> We
>could add some guidelines for method authors in the Implementation
>Considerations section or perhaps better somewhere else? IMHO, the
>middle of the SM description is not the place to get into this.
>  
>
The IEEE 802 requirements probably have a word on protected result 
indications (I got to check that)... but I'd rather have IETF also state 
its opinion on EAP methods (while this could be done in a future IETF 
"how to design a good EAP method" document, I'd rather not count on the 
future and do what is possible now ;-)

[Nick Petroni] 

I certainly appreciate your opinion, but I hope you know that it is not
me with whom you are disagreeing. I am simply explaining what I understand
the constraints of this working group to be. I share your admonishment for
using bad methods, but it has been my understanding from the beginning
that these are our constraints. Sorry if this ruins your day :(. If I am
wrong, someone else can certainly correct me freely. It has certainly
happened on more than one occasion :).

[Jari Arkko] 

And then to the "L" issue:

>>Aaaaaaaaaaaaaarghn the L word in a protocol that apparently is becoming
>>pervasive for the future (invading IKEv2, IEEE 802.1X, IEEE 802.11, IEEE
>>802.16e, and why not IEEE 802.20)!








Welcome to the real world :-(

>>I am aware of what you say but I respectfully and strongly disagree.: if
>>EAP is going to be a protocol of the future why cripple it with problems
>>of the past.
(snip)
>>Again I wish that MD5-Challenge would disappear ;-)

Fortunately or unfortunately, EAP is already deployed. We have
created this working group in the IETF to "fully document and
improve the interoperability of the existing EAP protocol" (quoting
our charter). I think we should adopt better alternatives
and designs whenever we can -- and I think we have often done
that when working with the details -- but not when it would affect
backwards compatibility. EAPv2 is also off-limits for our
working group, though of course individuals in the group
can pursue, say, next-gen network access protocol designs
in their research work.

So, lets keep resolve the other stuff the best we can,
but not outlaw existing EAP methods. And as I have
said before, it would be good to have text to point
out specific vulnerabilities and issues in existing
EAP methods and the "L" part of the state machine.

I think RFC 3748 is our primary document regarding
the security properties of EAP (or lack thereof),
so I don't think we should hold the publication of the
state machine to develop such text. But if you already
have such text or you can clearly see what the implications
are, please send text so that Nick can put it in.

[Florent Bersani] 

What about the following text (alluding to the potential well-known 
vulnerabilities):

Add to section 8 "Implementation considerations" of the EAP state 
machine draft (or to section 9 "security considerations"):

"As noted in RFC 3748 there are some security concerns that arise 
because of the following EAP packets:

   1. EAP-Request/Response Identity
   2. EAP-Response/NAK
   3. EAP-Success/Failure

Since these packets are not cryptographically protected by themselves, 
an attacker can modify them without immediate detection by the peer or 
the server.

Following Figure 3 specification, an attacker may cause denial of 
service by:

    * Sending an EAP-Failure to the peer before the peer has started an
      EAP authentication method. Indeed, as long as the peer has not
      modified the methodState variable which is initialized to NONE,
      the peer MUST accept an EAP-Failure.
    * Forcing the peer to engage in endless EAP-Request/Response
      Identity exchanges before it has started an EAP authentication
      method. Indeed, as long as the peer has not modified the
      selectedMethod variable which is initialized to NONE, the peer
      MUST accept an EAP-Request/Identity and respond to it with an
           EAP-Response/Identity

Following Figure 4 specification, an attacker may cause denial of 
service by:

    * Sending a NAK to the server after the server first proposes an EAP
      authentication method to the peer. Indeed, as the methodState
      takes the value PROPOSED, the server is obliged to process a NAK
      that is included in response to its first packet of an EAP
      authentication method.

There MAY be some cases when it is desired to prevent such attacks. This 
can be done by modifying initial values of some variables of the EAP 
state machines. However, such modifications are NOT RECOMMENDED.

There is indeed a tradeofff between mitigating these denial of service 
attacks and being able to deal with EAP peers and servers in general. 
For instance, should the sending of a NAK to the server after it has 
just proposed an EAP authentication method to the peer be ignored, then 
a legitimate peer that is not able or willing to process the proposed 
EAP authentication method would fail without an opportunity to negotiate 
another EAP method."

What do you reckon?

>
> --Jari (the co-chair hat on)

Nice hat ;-)

Nick Petroni wrote:

>Florent,
>
>I certainly appreciate your opinion, but I hope you know that it is not
>me with whom you are disagreeing.
>
I know that, don't worry.

> I am simply explaining what I understand
>the constraints of this working group to be.
>
It seemed like I just felt being reminded them by our beloved chairs ;-)

> I share your admonishment for
>using bad methods, but it has been my understanding from the beginning
>that these are our constraints. Sorry if this ruins your day :(. If I am
>wrong, someone else can certainly correct me freely.
>
I think (as Jari) that you are right :-))

> It has certainly
>happened on more than one occasion :).
>Take care,
>nickf

[Jari Arkko] 

Your text below looks good, Florent. Thanks. I see
that Nick already incorporated this to -04. Good.

Proposed Resolution: Accept

Issue 249: General Issue with EAP State Machine
Submitter name: Florent Bersani
Submitter email address: florent.bersani@rd.francetelecom.fr
Date first submitted: 6/8/2004
Reference: http://mail.frascone.net/pipermail/eap/2004-June/002523.html
Document: SM-03
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

Comment #19 - General

Just a late and useless remark, I tend to dislike EAP being too much 
802.1X centric: EAP is (or at least should be) media independent. 
Therefore, the problems implied by splitting the server side into an 
authenticator and an authentication server do probably not belong 
(originally) to EAP.

Thus, for the sake of clarity, I would rather have had two separate 
documents: one for the EAP state machine (peer and standalone server) 
and for the EAP state machines in case the server side is split (the 
split case is however also evoked in RFC 3748 - which I would also have 
avoided)...

[Nick Petroni] 

I very much appreciate your opinion on this, I tended to be an EAP
"purist" as well. However, given the widespread deployment of this
particular architecture, as well as the informational nature of this
document, I would like to propose we reject this issue. Furthermore, the
document is so late in its lifecycle I don't think it would be wise (or
possible?) to make such major changes.

Thanks for all of your comments, I am confident they will lead to a better
document.

[Florent Bersani] 

I unfortunately agree with this rejection for obvious pragmatic reasons.

Proposed Resolution: Reject

Issue 250: Definition
Submitter name: Florent Bersani
Submitter email address: florent.bersani@rd.francetelecom.fr
Date first submitted: 6/25/2004
Reference: http://mail.frascone.net/pipermail/eap/2004-June/002567.html
Document: SM-03
Comment type: E
Priority: 1
Section:
Rationale/Explanation of issue:

allowMethod is not defined in the document, but is used in figure 3

This should be defined. 

[Nick Petroni] 

I propose to add the following to section 4.4

"allowMethod()
   Determine if it is allowable for the peer to perform the proposd
   method. This decision may be based on policy and/or implementation
   support for the proposed method."

[Florent Bersani] Looks good to me.

Proposed Resolution: Accept

Issue 251: Identity Attacks
Submitter name: Florent Bersani
Submitter email address: florent.bersani@rd.francetelecom.fr
Date first submitted: 6/25/2004
Reference: http://mail.frascone.net/pipermail/eap/2004-June/002567.html
Document: SM-03
Comment type: T
Priority: 1
Section: Various
Rationale/Explanation of issue:

[Pasi Eronen] To summarize the discussion about issue #251 at San Diego,
the conclusion seemed to be that

- The "canned" success/failure prohibited by RFC3748
  means success/failure sent immediately after a
  connection is established.

- The 1X-REV behavior of sending success/failure on
  administrative change is not totally in line with this.

- However, you could argue that those canned messages are not
  really part of an EAP conversation, but just use EAPOL frame
   type.

- Perhaps using something else would have been prettier, but
  the current behavior doesn't seem to be that harmful either
  (e.g. if you disable the port, the client is not going to get
  access anyway), and it's too late to change it.

- EAP peer state machine discards canned success/failure
  (because "reqId == lastId" can't be true, since lastId
  is NONE). Thus, no changes required there.

- EAP authenticator state machine does not explicitly mention
  that canned success/failure is prohibited. If desired, we
  could add something like "Policy.getDecision MUST comply with
  RFC3748 restrictions about canned Success and Failure messages."
  in author's 48 hours.

- Sending success/failure after an identity request/response
  pair is allowed by RFC3748 (and is explicitly mentioned
  in an example). The peer can, of course, have a policy
  requiring authentication of the server.

I didn't notice this at San Diego, but additionally it
seems that:

- The current version of EAP peer state machine does not accept
  a Success message after identity request (because decision is FAIL;
  this still worked in version -01 where decision could be also
   COND_SUCC).

- We could add text saying that "The peer state machine assumes
  that the peer's policy requires that an authentication method
  is always run. That is, an EAP Success message immediately
  following an EAP Identity or Notification exchange is ignored."

- Or, we could add a constant AllowImmediateSuccess, and
  change "decision = FAIL" to "if (AllowImmediateSuccess)
  decision = COND_SUCC; else decision = FAIL;" in the
  INITIALIZE state.

Comments? What should we do about the last item?
(Personally, I'd prefer the first alternative, as we
could add that at author's 48 hours.)

[John Vollbrecht] I also prefer the first alternative, but I think input from the list would 
be useful.

[Jari Arkko] Oops. I would actually prefer the latter. (Not sure why
you think only the former can be done in AUTH48.)

[Yoshi Obha] I prefer the latter approach (i.e., the one that uses
AllowImmediateSuccess), too.

[Yoshi Ohba] 

Hi John,

Please see my comments in line.

On Tue, Aug 10, 2004 at 11:37:45AM -0400, John Vollbrecht wrote:
> A couple questions --
> 
> --On Tuesday, August 10, 2004 12:48 PM +0300 Pasi.Eronen@nokia.com wrote:
> 
> >Hi,
> >
> >To summarize the discussion about issue #251 at San Diego,
> >the conclusion seemed to be that
> >
> >- The "canned" success/failure prohibited by RFC3748
> >  means success/failure sent immediately after a
> >  connection is established.
> >
> -- so not a success failure sent because of administrative changes
> 
> >- The 1X-REV behavior of sending success/failure on
> >  administrative change is not totally in line with this.
> >
> -- it does seem different.  so not specifically prohibited.
> 
> >- However, you could argue that those canned messages are not
> >  really part of an EAP conversation, but just use EAPOL frame
> >  type.
> >
> ok - this seems reasonable
> 
> >- Perhaps using something else would have been prettier, but
> >  the current behavior doesn't seem to be that harmful either
> >  (e.g. if you disable the port, the client is not going to get
> >  access anyway), and it's too late to change it.
> >
> this doesn't seem to deal with the case where a port is taken down and up, 
> sending a Success, and it may be in the middle of a conversation.








I don't understand the case where an authenticator sends a Success in
the middle of a conversation in this case.  When a port on an IEEE
802.1X authenticator is taken down and up, isn't the IEEE 802.1X
authenticator state machine initialized with restarting the EAP state
machine?    

[Jim Burns] 

You asked:
   When a port on an IEEE 802.1X authenticator is taken down and up, isn't the IEEE 802.1X
authenticator state machine initialized with restarting the EAP state machine?


The answer is:
Yes. The 802.1X authenticator state machine shall restart when the port
cycles (802.1X portEnabled variable will toggle) and it will set
eapRestart to cause EAP state machine to restart as well. In fact, the
802.1X state machine will wait for the EAP state machine to reset
eapRestart before continuing.

[John Vollbrecht] 

In the case where a port may be administratively set to "Force Auth" (sec 
8.2.4.11 of 802-1X-Rev-d11)  a port will send a canned Success message.

The scenario I imagine is that two ports are doing EAP, and the 
authenticator is taken down and its portControl variable is set to 
ForceAuthorized.  It then sends a Success.

If the Station state machine is is a state where it will accept a Success, 
it may not notice that the authenticator has gone down and back up.  It 
will accept the Success and connect to the net.  Thus the Peer could come 
up to a authenticator which to which it has not authenticated.

This is clearly an unlikely situation.   It is unlikely to happen at all. 
If it does happen it is unlikely that the AP it connects to will not be the 
one that just went down and came up.

In my mind it is something to note but not requiring change.  I just want 
to be sure everyone agrees.

Proposed Resolution: Accept

Issue 252: currentId Issue
Submitter name: Suresh Babu
Submitter email address: mailto:suba_proj@yahoo.com
Date first submitted: 6/24/2004
Reference: http://mail.frascone.net/pipermail/eap/2004-June/002546.html
Document: SM-03
Comment type: T
Priority: S
Section: 6.1
Rationale/Explanation of issue

When starting (initializing) the state machine, the currentid is initialized to NONE.
After successful reauthentication in MD5 case it goes to 1, and sends a success packet
with id=1, When the reAuthWhen timer expires in 802.1x layer, it reaches RESTART state
and sets eapRestart to TRUE, So to move to CONNECTING state we had make eapRestart as FALSE,
This is set by eap-statemachine. So again currentId becomes NONE.

So under what conditions  currentid can have 0-255 values, here i`m able get only
0-1. How to get around of this problem?

[Nick Petroni] 

IMHO this is not a problem with the state machine. The situation you have
described, whereby only two values are used for the identifier, is
completely allowable in EAP. Section 4.1 of RFC 3748 states the following:

   Identifier

      The Identifier field is one octet.  The Identifier field MUST be
      the same if a Request packet is retransmitted due to a timeout
      while waiting for a Response.  Any new (non-retransmission)
      Requests MUST modify the Identifier field.

      The Identifier field of the Response MUST match that of the
      currently outstanding Request.  An authenticator receiving a
      Response whose Identifier value does not match that of the
      currently outstanding Request MUST silently discard the Response.

      In order to avoid confusion between new Requests and
      retransmissions, the Identifier value chosen for each new Request
      need only be different from the previous Request, but need not be
      unique within the conversation.  One way to achieve this is to
      start the Identifier at an initial value and increment it for each
      new Request.  Initializing the first Identifier with a random
      number rather than starting from zero is recommended, since it
      makes sequence attacks somewhat more difficult.

      Since the Identifier space is unique to each session,
      authenticators are not restricted to only 256 simultaneous
      authentication conversations.  Similarly, with re-authentication,
      an EAP conversation might continue over a long period of time, and
      is not limited to only 256 roundtrips.

As you can see, each message simply needs a different Identifier from the
previous message, so alternation is quite ok. Furthermore, the situation
you have described is the running of multiple instances of the EAP state
machine for the purposes of 802.1X reauthentication. Technically these
values repeat, but only among different "runs" of EAP. The range of 0-255
the POSSIBLE values of the identifier field, you are explicitly not
guaranteed to use all values or prevent collision among runs.

Unless I am missing something in your question I would like to propose we
reject the comment as an Issue with the SM.

[Jari Arkko] I agree with your assessment. I think we can reject #252.

Proposed Resolution: Reject

Issue 253: AAA-Key Name is Misleading
Submitter name: Joe Salowey
Submitter email address: jsalowey@cisco.com 



Date first submitted: 6/28/2004
Reference: http://mail.frascone.net/pipermail/eap/2004-June/002573.html
Document: Keying-02
Comment type: E
Priority: 1
Section: Various
Rationale/Explanation of issue

The name AAA-Key is misleading since it creates a dependency between EAP
keying and AAA services.  EAP keying does not require the use of AAA
service so this name should not be used.  A better name would be application
master key.

Requested change:

Change AAA-Key to application master session key.

[Bernard Aboba] 

Since I agree with Joe's comments, it pains me that the term "AAA-Key" is
used in RFC 3748, and therefore I don't feel we can change the term in the
EAP Key Management framework document.
 
However, we probably should expose language clarifying that the AAA-Key
exists even where there is no AAA server.

[Jari Arkko]
I think that is all we can do. Too bad, but can't be helped.

[Bernard Aboba] The definition of "AAA-Key" already contains the sentence:

"Despite the name, the AAA-Key is computed regardless of whether a backend authentication
server is present."

So I'm not sure how much more we can do. 

Proposed Resolution: Reject

Issue 254: Key Lifetime Issues
Submitter name: Bernard Aboba
Submitter email address: mailto:aboba@internaut.com
Date first submitted: 8/8/2004
Reference:
Document: Keying-03
Comment type: T
Priority: S
Section: 2.3
Rationale/Explanation of issue

The Key Lifetime section does not address several issues:

* Re-key. Section 2.3 should discuss the distinction between
re-key and re-authentication. EAP does not support rekey
without re-authentication for the exported keys:
MSK, EMSK, IV.  However, the Secure Association Protocol
may support rekey of the TSKs without re-authentication.

* Caching. Section 2.3 should discuss the potential implications of
key caching, for each type of key. Caching of exported keys varies
between lower layers, and as a result, EAP or EAP methods do not
negotiate the lifetime of exported keys. Section 2.3
should lay out the potential options for cache
synchronization and analyze the pros and cons.

* AAA control. Maximum MSK/EMSK key lifetime on the authenticator is currently
controlled by the Session-Timeout attribute. This is true even when EAP is
used for pre-authentication, since this provides the AAA server with a defined
time after which the MSK/EMSK is known to have expired on the authenticator. 

There is currently no attribute that controls the maximum lifetime of the TSKs, 
but this does not appear to be a deficiency since there is little reason for 
this to vary by user, and as a result, this parameter can be set 
universally on the authenticator. 

[BA] Here is the proposed rewrite of the key lifetime section:

"2.3 Key Lifetimes

Key lifetime issues are discussed
in the sections that follow. Issues include:

[a] Key lifetime negotiation. 
Where key lifetimes cannot be assumed, it may be
necessary to negotiate them. Where negotiation is supported,
it is RECOMMENDED that the negotiation be secured. 
Note that key lifetime negotiation may not always be required. 
A difference between IKEv1 and IKEv2 is that in IKEv1 SA
lifetimes were negotiated. In IKEv2, each end of the SA is responsible
for enforcing its own lifetime policy on the SA and rekeying the SA when
necessary.

[b] Key resynchronization. 
It is possible for the
peer or authenticator to reboot or reclaim resources, clearing
portions or all of the key cache. Therefore, key lifetime negotiation 
cannot guarantee that the
key cache will remain synchronized, and the peer may not
be able to determine before attempting to use it whether a particular key 
exists within the authenticator cache. 
It is therefore RECOMMENDED for the lower layer to provide a
mechanism for key state resynchronization.
Since in this situation one or more of the parties
initially do not possess a key with which to protect the
resynchronization exchange, securing this mechanism may be
difficult. 

2.3.1 Parent-child relationships

When keying material exported by EAP methods
expires, all keying material derived from
the exported keying material, (including the
AAA-Key, AMSKs and TSKs) also expires. 

Similarly, when an EAP reauthentication takes
place, new keying material is derived and exported 
by the EAP method, which eventually results in
replacement of calculated keys, including the
AAA-Key, AMSKs, and TSKs. 

As a result, the lifetime of keys calculated from
the exported keying material can be no longer than
the lifetime of the exported keying material itself. 
However, the lifetime of calculated keys
can be less than that of the exported keys. 
For example, TSK rekey may occur prior to 
EAP reauthentication. 

Note that deletion of the AAA-Key does not 
necessarily imply deletion of the
corresponding TSKs. Replacement or deletion of TSKs only 
implies replacement of the AAA-Key when the TSKs are taken 
from a portion of the AAA-Key. 

Failure to mutually prove possession of the
AAA-Key during the Secure Association Protocol exchange
need not be grounds for deletion of the AAA-Key by both
parties; rate-limiting Secure Association Protocol exchanges could
be used to prevent a brute force attack. 

2.3.2 Local Key Lifetimes

The Transient EAP Keys (TEKs) are session keys used to
protect the EAP conversation. The TEKs are internal to the EAP
method and are not exported. TEKs are typically created
during an EAP conversation, used until the end of the
conversation and then discarded. However, methods may
rekey TEKs during a conversation.

When using TEKs within an EAP conversation or across conversations,
it is necessary to ensure that replay protection and key separation
requirements are fulfilled. For instance, if a replay counter is used,
TEK rekey MUST occur prior to wrapping of the counter.
Similarly, TSKs MUST remain cryptographically separate from TEKs
despite TEK rekeying or caching. This prevents TEK compromise from
leading directly to compromise of the TSKs and vice versa.

EAP methods may cache local keying material which may persist
for multiple EAP conversations when fast reconnect is used
[RFC 3748]. For example, EAP methods based on TLS (such as
EAP-TLS [RFC2716]) derive and cache the TLS Master Secret,
typically for substantial time periods. The lifetime of
other local keying material calculated within the EAP
method is defined by the method. Note that in general,
when using fast reconnect, there is no guarantee to
that the original long-term credentials are
still in the possession of the peer. For instance, a
card hold holding the private key for EAP-TLS may have
been removed. EAP servers should verify that the
long-term credentials are still valid, such as by checking
that certificate used in the original authentication has not yet
expired.

2.3.3 Exported and Calculated Key Lifetimes

All EAP methods generating keys are required to generate the MSK
and EMSK, and may optionally generate the IV. 
Existing EAP methods do not negotiate the lifetime of the exported
keys. EAP, defined in [RFC3748],
also does not support the negotiation of lifetimes for exported keying
material such as the MSK, EMSK and IV.

Several mechanisms exist for managing key lifetimes:
 
[a] AAA attributes. 
AAA protocols such as RADIUS [RFC2865] and Diameter [DiamEAP] support
the Session-Timeout attribute. The Session-Timeout value represents
the maximum lifetime of the exported keys, and all keys calculated from it, 
in all circumstances. The AAA server MUST expire the exported keys, and
all keys calculated from them, 
prior to the future time indicated by Session-Timeout. On the 
authenticator, where EAP is
used for authentication, the
Session-Timeout value represents the maximum session time prior to
re-authentication, as described in [RFC3580]. 

Where EAP is used for pre-authentication,
the session may not start until some future time, or may never
occur. Nevertheless, the Session-Timeout value represents the time
after which the AAA-Key, and all keys calculated from it, 
will have expired on the authenticator. 
If the session subsequently starts, re-authentication will be 
initiated once the Session-Time has
expired. If the session never started, or started and ended, the AAA-Key
and all keys calculated from it will
be expired by the authenticator prior to the future time indicated by 
Session-Timeout. 

Since the TSK lifetime is
often determined by authenticator resources, 
the AAA server has no insight into the
TSK derivation process, and by the principle of 
ciphersuite independence, it is not appropriate
for the AAA server to manage any aspect of the TSK
derivation process, including the TSK lifetime. 

[b] Lower layer mechanisms. While AAA attributes can communicate the
maximum exported key lifetime, this only serves to synchronize the
key lifetime between the backend authentication server and the
authenticator. Lower layer mechanisms can then be used to 
enable the lifetime of exported and calculated keys to be negotiated
between the peer and authenticator.

Where TSKs are established as the result of a Secure
Association Protocol exchange, it is 
RECOMMENDED that the Secure Association Protocol 
include secure negotiation of the TSK lifetime
between the peer and authenticator. Where
the TSK is taken from the AAA-Key, there is no
need to manage the TSK lifetime as a separate
parameter, since the TSK lifetime and AAA-Key
lifetime are identical.

[c] System defaults. 
Where the EAP method does not support the negotiation of
the exported key lifetime, and a negotiation mechanism is not provided
by the lower lower, there may be no way for the peer to learn 
knowledge of the exported key liftime. In this case
it is RECOMMENDED that the peer assume a default
value of the exported key lifetime; 
8 hours is suggested. Similarly, the lifetime of calculated keys can also 
be managed as a system parameter on the authenticator. 

2.3.4 Key cache synchronization

Issues arise when attempting to synchronize the key
cache on the peer and authenticator. 
Lifetime negotiation alone cannot guarantee
key cache synchronization. 

One problem is that the AAA protocol cannot
guarantee synchronization of key lifetimes between the peer and
authenticator. Where the Secure Association Protocol
is not run immediately after EAP
authentication, the exported and calculated key lifetimes will not
be known by the peer during the hiatus. Where EAP pre-authentication
occurs, this can leave the peer uncertain whether 
a subsequent attempt to use the exported keys will 
prove successful. 

However, even where the Secure Association Protocol is run
immediately after EAP, it is still possible for the authenticator
to reclaim resources if the created key state is not immediately
utilized. 

The lower layer may utilize Discovery
mechanisms to assist in this. 
For example, the authenticator manages the
AAA-Key cache by deleting the oldest AAA-Key first
(LIFO), the relative creation time of the last AAA-Key to be
deleted could be advertised with the Discovery phase,
enabling the peer to determine whether a given AAA-Key
had been expired from the authenticator key cache prematurely."       

[Jari Arkko] 

Looks good! A couple of nits inline:

> "2.3.  Key Lifetimes
> 
>    Key lifetime issues are discussed in the sections that follow.
>    Issues include:
> 
> [a]  Key lifetime negotiation.  Where key lifetimes cannot be assumed,
>      it may be necessary to negotiate them.  Where negotiation is
>      supported, it is RECOMMENDED that the negotiation be secured.  Note
>      that key lifetime negotiation may not always be required.  A
>      difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
>      were negotiated. In IKEv2, each end of the SA is responsible for
>      enforcing its own lifetime policy on the SA and rekeying the SA
>      when necessary.


The reader may wonder why we suddenly talk about
IKE. Suggest s/A difference/To take an example from IKE,
the difference/

[BA] OK. 
 
 

> 2.3.1.  Parent-child relationships
> 
>   
When keying material exported by EAP methods expires,  all keying
>    material derived from the exported keying material, (including the
>    AAA-Key, AMSKs and TSKs) also expires.
> 
>    Similarly, when an EAP reauthentication takes place, new keying
>    material is derived and exported by the EAP method, which eventually
>    results in replacement of calculated keys, including the AAA-Key,
>    AMSKs, and TSKs.
> 
>    As a result, the lifetime of keys calculated from the exported keying
>    material can be no longer than the lifetime of the exported keying
>    material itself.  However, the lifetime of calculated keys can be
>    less than that of the exported keys.  For example, TSK rekey may
>    occur prior to EAP reauthentication.
> 
>    Note that deletion of the AAA-Key does not necessarily imply deletion
>    of the corresponding TSKs.  Replacement or deletion of TSKs only
>    implies replacement of the AAA-Key when the TSKs are taken from a
>    portion of the AAA-Key.

I do not understand this paragraph. The first part appears to claim
that TSKs can break the death-of-the-parent rule. The second part
appears to claim that AAA-Key gets changed because it is used twice.
Or maybe the latter is something that we do want to mandate, but
the text still reads funny, it sounds like the requirement only
exists if we take a part of AAA-Key, not all of it. Or did you
want to say that when TSKs are bit-by-bit copies of the AAA-Keys
parts, then we throw that part away?

[BA] How about if we delete this paragraph entirely? 



> [a]  AAA attributes.  AAA protocols such as RADIUS [RFC2865] and
>      Diameter [DiamEAP] support the Session-Timeout attribute.  The
>      Session-Timeout value represents the maximum lifetime of the
>      exported keys, and all keys calculated from it, in all
>      circumstances.  The AAA server MUST expire the exported keys, and
>      all keys calculated from them, prior to the future time indicated

Is it really "prior to"? Not "latest at"?

[BA] Yes. 
> [b]  Lower layer mechanisms.  While AAA attributes can communicate the
>      maximum exported key lifetime, this only serves to synchronize the
>      key lifetime between the backend authentication server and the
>      authenticator.  Lower layer mechanisms can then be used to enable
>      the lifetime of exported and calculated keys to be negotiated
>      between the peer and authenticator.
> 
>      Where TSKs are established as the result of a Secure Association
>      Protocol exchange, it is RECOMMENDED that the Secure Association
>      Protocol include secure negotiation of the TSK lifetime between the
>      peer and authenticator.    







Why do we recommend this? What if the lower layer uses the IKEv2
principle?

[BA] Actually the requirement is really support for resynchronization. 

How about this? 

Change: 

"Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include secure negotiation of the TSK lifetime between the
peer and authenticator."

To: 

"Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include support for TSK resynchronization."

[Jari Arkko]

> [BA] How about if we delete this paragraph entirely?

Ok.

> [BA] Actually the requirement is really support for resynchronization,
> since it's possible to accomplish this without key lifetime negotiation
> (e.g. IKEv2) How about this?
> 
> Change:
> 
> "Where TSKs are established as the result of a Secure Association
> Protocol exchange, it is RECOMMENDED that the Secure Association
> Protocol include secure negotiation of the TSK lifetime between the
> peer and authenticator."
> 
> To:
> 
> "Where TSKs are established as the result of a Secure Association
> Protocol exchange, it is RECOMMENDED that the Secure Association
> Protocol include support for TSK resynchronization."


















































































































































































































Sounds good. Thanks.

[BA] Here is the proposed text for the newly re-organized Section 4: 

4. Key Management

The EAP peer, authenticator and backend server may support key
caching. Since EAP supports key derivation, but not key management,
this functionality needs to be provided by the Secure Association
Protocol. Key management support includes:

[a] Key lifetime determination. EAP does not support negotiation of
key lifetimes, nor does it support rekey without reauthentication.
As a result, the Secure Association Protocol is responsible for
rekey and determination of the key lifetime. Where key caching is
supported, secure negotiation of key lifetimes is RECOMMENDED.
Lower layers that support rekey, but not key caching may not
require key lifetime negotiation. To take an example from IKE, the
difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
were negotiated. In IKEv2, each end of the SA is responsible for
enforcing its own lifetime policy on the SA and rekeying the SA
when necessary.

[b] Key resynchronization. It is possible for the peer or
authenticator to reboot or reclaim resources, clearing portions or
all of the key cache. Therefore, key lifetime negotiation cannot
guarantee that the key cache will remain synchronized, and the peer
may not be able to determine before attempting to use a AAA-Key
whether it exists within the authenticator cache. It is therefore
RECOMMENDED for the Secure Association Protocol to provide a
mechanism for key state resynchronization. Since in this situation
one or more of the parties initially do not possess a key with
which to protect the resynchronization exchange, securing this
mechanism may be difficult.

[c] Key selection. Where key caching is supported, it may be possible
for the EAP peer and authenticator to share more than one key of a
given type. As a result, the Secure Association Protocol needs to
support key selection, using the EAP Key Naming scheme described in
this document.

[d] Key scope determination. Since the Discovery phase is handled out-
of-band, EAP does not provide a mechanism by which the peer can
determine the authenticator identity. As a result, where the
authenticator has multiple ports and AAA-Key caching is supported,
the EAP peer may not be able to determine the scope of validity of
a AAA-Key. Similarly, where the EAP peer has multiple ports, the
authenticator may not be able to determine whether a peer has
authorization to use a particular AAA-Key. To allow key scope
determination, the lower layer SHOULD provide a mechanism by which
the peer can determine the scope of the AAA-Key cache on each
authenticator, and by which the authenticator can determine the
scope of the AAA-Key cache on a peer.

4.1. Key Caching

Key caching may be supported on the EAP peer, authenticator and
backend server. Where explicitly supported by the lower layer, the
EAP peer and authenticator MAY cache the AAA-Key and/or TSKs. The
structure of the key cache on the peer and authenticator is defined
by the lower layer. Unless specified by the lower layer, the EAP
peer, authenticator and server MUST assume that peers and
authenticators do not cache the AAA-Key or TSKs.

The EAP peer and server MAY cache keys exported by the EAP method as
well as keys derived from them, subject to the following
restrictions:

[1] In order to avoid key reuse, on the EAP server, transported keys
are deleted once they are sent. An EAP server MUST NOT retain keys
that it has previously sent to the authenticator. For example, an
EAP server that has transported a AAA-Key based on the MSK MUST
delete both the AAA-Key and the MSK, and no keys may be derived
from either the AAA-Key or the MSK from that point forward.

[Jari Arkko] 
> s/forward/forward by the server/ (we still want to allow the
> NAS to derive keys from MSK...)

[BA] Change made.

[2] Keys which are not transported, such as the EMSK, MAY be cached on
the EAP server. While AMSKs calculated from the EMSK MUST be
deleted from the EAP server once they are transported, the parent
EMSK may remain in the EAP server cache.

4.2. Parent-Child Relationships

When keying material exported by EAP methods expires, all keying
material derived from the exported keying material expires, including
the AAA-Key, AMSKs and TSKs.

When an EAP reauthentication takes place, new keying material is
derived and exported by the EAP method, which eventually results in
replacement of calculated keys, including the AAA-Key, AMSKs, and
TSKs.

As a result, while the lifetime of calculated keys can be less than
or equal that of the exported keys they are derived from, it cannot
be greater. For example, TSK rekey may occur prior to EAP
reauthentication.

Failure to mutually prove possession of the AAA-Key during the Secure
Association Protocol exchange need not be grounds for deletion of the
AAA-Key by both parties; rate-limiting Secure Association Protocol
exchanges could be used to prevent a brute force attack.

4.3. Local Key Lifetimes

The Transient EAP Keys (TEKs) are session keys used to protect the
EAP conversation. The TEKs are internal to the EAP method and are
not exported. TEKs are typically created during an EAP conversation,
used until the end of the conversation and then discarded. However,
methods may rekey TEKs during a conversation.

When using TEKs within an EAP conversation or across conversations,
it is necessary to ensure that replay protection and key separation
requirements are fulfilled. For instance, if a replay counter is
used, TEK rekey MUST occur prior to wrapping of the counter.
Similarly, TSKs MUST remain cryptographically separate from TEKs
despite TEK rekeying or caching. This prevents TEK compromise from
leading directly to compromise of the TSKs and vice versa.

EAP methods may cache local keying material which may persist for
multiple EAP conversations when fast reconnect is used [RFC 3748].
For example, EAP methods based on TLS (such as EAP-TLS [RFC2716])
derive and cache the TLS Master Secret, typically for substantial
time periods. The lifetime of other local keying material calculated
within the EAP method is defined by the method. Note that in
general, when using fast reconnect, there is no guarantee to that the
original long-term credentials are still in the possession of the
peer. For instance, a card hold holding the private key for EAP-TLS
may have been removed. EAP servers should verify that the long-term

[Jari Arkko] 

> s/should/SHOULD also/

[BA] Change made.

credentials are still valid, such as by checking that certificate
used in the original authentication has not yet expired.

4.4. Exported and Calculated Key Lifetimes

All EAP methods generating keys are required to generate the MSK and
EMSK, and may optionally generate the IV. However, EAP, defined in
[RFC3748], does not support the negotiation of lifetimes for exported
keying material such as the MSK, EMSK and IV.

Several mechanisms exist for managing key lifetimes:

[a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and
Diameter [DiamEAP] support the Session-Timeout attribute. The
Session-Timeout value represents the maximum lifetime of the
exported keys, and all keys calculated from it. If the AAA server
caches exported keys, then it MUST expire the exported keys and all
keys calculated from them, no later than the future time indicated
by Session-Timeout.

On the authenticator, where EAP is used for authentication, the
Session-Timeout value represents the maximum session time prior to
re-authentication, as described in [RFC3580]. Where EAP is used
for pre-authentication, the session may not start until some future
time, or may never occur. Nevertheless, the Session-Timeout value
represents the time after which the AAA-Key, and all keys
calculated from it, will have expired on the authenticator. If the
session subsequently starts, re-authentication will be initiated
once the Session-Time has expired. If the session never started,
or started and ended, the AAA-Key and all keys calculated from it
will be expired by the authenticator prior to the future time
indicated by Session-Timeout.

Since the TSK lifetime is often determined by authenticator
resources, the AAA server has no insight into the TSK derivation
process, and by the principle of ciphersuite independence, it is
not appropriate for the AAA server to manage any aspect of the TSK
derivation process, including the TSK lifetime.

[b] Lower layer mechanisms. While AAA attributes can communicate the
maximum exported key lifetime, this only serves to synchronize the
key lifetime between the backend authentication server and the
authenticator. Lower layer mechanisms can then be used to enable
the lifetime of exported and calculated keys to be negotiated
between the peer and authenticator.

Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include support for TSK resynchronization. Where the TSK
is taken from the AAA-Key, there is no need to manage the TSK
lifetime as a separate parameter, since the TSK lifetime and AAA-
Key lifetime are identical.

[c] System defaults. Where the EAP method does not support the
negotiation of the exported key lifetime, and a key lifetime
negotiation mechanism is not provided by the lower lower, there may
be no way for the peer to learn the exported key liftime. In this
case it is RECOMMENDED that the peer assume a default value of the
exported key lifetime; 8 hours is suggested. Similarly, the
lifetime of calculated keys can also be managed as a system
parameter on the authenticator.

4.5. Key cache synchronization

Issues arise when attempting to synchronize the key cache on the peer
and authenticator. Lifetime negotiation alone cannot guarantee key
cache synchronization.

One problem is that the AAA protocol cannot guarantee synchronization
of key lifetimes between the peer and authenticator. Where the
Secure Association Protocol is not run immediately after EAP
authentication, the exported and calculated key lifetimes will not be
known by the peer during the hiatus. Where EAP pre-authentication
occurs, this can leave the peer uncertain whether a subsequent
attempt to use the exported keys will prove successful.

However, even where the Secure Association Protocol is run
immediately after EAP, it is still possible for the authenticator to
reclaim resources if the created key state is not immediately
utilized.

The lower layer may utilize Discovery mechanisms to assist in this.
For example, the authenticator manages the AAA-Key cache by deleting
the oldest AAA-Key first (LIFO), the relative creation time of the
last AAA-Key to be deleted could be advertised with the Discovery
phase, enabling the peer to determine whether a given AAA-Key had
been expired from the authenticator key cache prematurely.

4.6. Key Scope Issues

As described in Section 2.3, the AAA-Key is calculated from the EMSK
and MSK by the EAP peer and server, and is used as the root of the
ciphersuite-specific key hierarchy. Where a backend authentication
server is present, the AAA-Key is transported from the EAP server to
the authenticator; where it is not present, the AAA-Key is calculated
on the authenticator.

Regardless of how many sessions are initiated using it, the AAA-Key
scope is between the EAP peer that calculates it, and the
authenticator that either calculates it (where no backend
authenticator is present) or receives it from the server (where a
backend authenticator server is present).

It should be understood that an authenticator or peer:

[a] may contain multiple physical ports;
[b] may advertise itself as multiple "virtual" authenticators
or peers;
[c] may utilize multiple CPUs;
[d] may support clustering services for load balancing or failover.

As illustrated in Figure 1, an EAP peer with multiple ports may be
attached to one or more authenticators, each with multiple ports.
Where the peer and authenticator identify themselves using a port
identifier such as a link layer address, it may not be obvious to the
peer which authenticator ports are associated with which
authenticators. Similarly, it may not be obvious to the
authenticator which peer ports are associated with which peers. As a
result, the peer and authenticator may not be able to determine the
scope of the AAA-Key.

When a single physical authenticator advertises itself as multiple
"virtual authenticators", the EAP peer and authenticator also may not
be able to agree on the scope of the AAA-Key, creating a security
vulnerability. For example, the peer may assume that the "virtual
authenticators" are distinct and do not share a key cache, whereas,
depending on the architecture of the physical AP, a shared key cache
may or may not be implemented.

Where the AAA-Key is shared between "virtual authenticators" an
attacker acting as a peer could authenticate with the "Guest"
"virtual authenticator" and derive a AAA-Key. If the virtual
authenticators share a key cache, then the peer can utilize the AAA-
Key derived for the "Guest" network to obtain access to the
"Corporate Intranet" virtual authenticator.

Several measures are recommended to address these issues:

[a] Authenticators are REQUIRED to cache associated authorizations
along with the AAA-Key and apply authorizations consistently. This
ensures that an attacker cannot obtain elevated privileges even
where the AAA-Key cache is shared between "virtual authenticators".

[b] It is RECOMMENDED that physical authenticators maintain separate
AAA-Key caches for each "virtual authenticator".

[c] It is RECOMMENDED that each "virtual authenticator" identify itself
distinctly to the AAA server, such as by utilizing a distinct NAS-
identifier attribute. This enables the AAA server to utilize a
separate credential to authenticate each "virtual authenticator".

[d] It is RECOMMENDED that Secure Association Protocols identify peers
and authenticators unambiguously, without incorporating implicit
assumptions about peer and authenticator architectures. Using
port-specific MAC addresses as identifiers is NOT RECOMMENDED where
peers and authenticators may support multiple ports.

[e] The AAA server and authenticator MAY implement additional
attributes in order to further restrict the AAA-Key scope. For
example, in 802.11, the AAA server may provide the authenticator
with a list of authorized Called or Calling-Station-Ids and/or
SSIDs for which the AAA-Key is valid.

[f] Where the AAA server provides attributes restricting the key scope,
it is RECOMMENDED that restrictions be securely communicated by the
authenticator to the peer. This is typically accomplished using
the Secure Association Protocol, but also can be accomplished via
the EAP method or the lower layer.

4.7. Key Strength

In order to guard against brute force attacks, EAP methods deriving
keys need to be capable of generating keys with an appropriate
effective symmetric key strength. In order to ensure that key
generation is not the weakest link, it is RECOMMENDED that EAP
methods utilizing public key cryptography choose a public key that
has a cryptographic strength meeting the symmetric key strength
requirement.

As noted in [RFC3766] Section 5, this results in the following
required RSA or DH module and DSA subgroup size in bits, for a given
level of attack resistance in bits:

Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits)
----------------- ----------------- ------------
70 947 128
80 1228 145
90 1553 153
100 1926 184
150 4575 279
200 8719 373
250 14596 475

4.8. Key Wrap

As described in [RFC3579] Section 4.3, known problems exist in the
key wrap specified in [RFC2548]. Where the same RADIUS shared secret
is used by a PAP authenticator and an EAP authenticator, there is a
vulnerability to known plaintext attack. Since RADIUS uses the
shared secret for multiple purposes, including per-packet
authentication, attribute hiding, considerable information is exposed
about the shared secret with each packet. This exposes the shared
secret to dictionary attacks. MD5 is used both to compute the RADIUS
Response Authenticator and the Message-Authenticator attribute, and
some concerns exist relating to the security of this hash
[MD5Attack].

As discussed in [RFC3579] Section 4.3, the security vulnerabilities
of RADIUS are extensive, and therefore development of an alternative
key wrap technique based on the RADIUS shared secret would not
substantially improve security. As a result, [RFC3759] Section 4.2
recommends running RADIUS over IPsec. The same approach is taken in
Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key
attributes, to be protected by IPsec or TLS.

Where an untrusted AAA intermediary is present (such as a RADIUS
proxy or a Diameter agent), and data object security is not used, the
AAA-Key may be recovered by an attacker in control of the untrusted
intermediary. Possession of the AAA-Key enables decryption of data
traffic sent between the peer and a specific authenticator; however
where key separation is implemented, compromise of the AAA-Key does
not enable an attacker to impersonate the peer to another
authenticator, since that requires possession of the EMSK, which is
not transported by the AAA protocol. This vulnerability may be
mitigated by implementation of redirect functionality, as provided in
[RFC3588].

Proposed Resolution: Accept