Subject: [eap] Re: Issue 73: Various RFC 2284bis Comments

From: [email-masked] (Bernard Aboba)
Date: Tue, 4 Feb 2003 17:01:23 -0800 (PST)

Some thoughts:

"HENRIK: Very well, but what do we wish to say with that? Is there a
conclusion here, or is this just FYI"

BA: There used to be a conclusion there, but somehow it got lost :)

I think that the point of this (if indeed there is one) was to clarify a
paragraph in RFC 2284 (has anyone implemented this?):

         Implementation Note: Because the Success and Failure packets
         are not acknowledged, they may be potentially lost.  A peer
         MUST allow for this circumstance.  The peer can use a Network
         Protocol packet as an alternative indication of Success.
         Likewise, the receipt of a LCP Terminate-Request can be taken
         as a Failure.

The idea of the new text is to clarify that packets like LCP Terminate-Request
can cause a link to go down, and therefore can cause EAP authentication to fail. But
packets like NCP mentioned above do not cause EAP authentication to
succeed.

-----------------------------------
HENRIK: (I assume the state machine covers this? and also has other
timers to guarantee that the protocol doesn't hang forever
waiting for an infinite timer to expire. How much of this should
be described here? Should some text be removed, with reference
to the state machine document?)

BA: I think that the state machine should probably cover the various ways
in which the RTO timer can be set. This includes [RFC2988] algorithms by
default; RFC 2869bis and 2284bis already has text that state how the RTO can
be set via the Session-Timeout attribute in RADIUS. So that same interface
can presumably be used by the lower layer to manipulate the EAP RTO value.

-----------------------------------
HENRIK: In view of the possibility of inserting a false EAP Failure
packet in e.g. wireless networks, maybe there should be a
RECOMMENDED discard of premature Failure packets in the case of
insecure link in combination with EAP methods with protected
error indications?

BA: I would argue that premature Failure packets should always be
discarded. If the method isn't "complete" then they are unexpected. This
isn't that much of a constraint, since methods should probably terminate
via their own error messages, as opposed to by sending an EAP Failure right
away.
-----------------------------------

HENRIK: How should the estimated effective key strength be indicated?

BA: An excellent question :) Do you have a proposal?

-----------------------------------
HENRIK: I believe I can see one security issue which has not
been discussed in this section, but might be mentioned: If the
authenticator uses pass-through to a backend authentication
server, it seems to me that the authenticator will not
understand method-specific success and failure indications, and
are dependent on seeing the final EAP Success (or Failure)
packet in order to know the outcome of the authentication. This
means that the link between authenticator and backend
authentication server needs to be secure against injection of
false EAP Success or Failure indications. This is probably the
case in most deployments, but might want mentioning for
completeness? I can propose some text for your consideration.

BA: Actually, the authenticator only looks for the AAA Accept/Reject and
does not peer into the encapsulated EAP packet.

Nevertheless, injection of spoofed EAP packets of any kind between the AAA
server and authenticator would be a bad thing. This is discussed in the
Security Considerations section of RFC 2869bis, and you might want to
steal some text from there:

http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-08.txt
=================================================================
Issue 73: Various RFC 2284bis Comments
Submitter name: Henrik Levkowetz
Submitter email address: [email-masked]
Date first submitted: Feburary 3, 2003
Document: RFC2284bis-10
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:
Hi,

Going over the 2284bis draft, I've come up with some points I'd like
to raise as issues for discussion. My comments are marked with HENRIK:

--------------------------------------
In section 3.4:

In 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. In
802.11, control and management frames are not authenticated and an
attacker within range can gain access to the physical medium. Link layer
indications include Disassociate and Deauthenticate frames (link failure
indications), and Association and Reassociation Response frames (link
success indications).

HENRIK: Very well, but what do we wish to say with that? Is there a
conclusion here, or is this just FYI

--------------------------------------
In section 4.1:

When run over a reliable lower layer (e.g. EAP over ISAKMP/TCP, as
within [PIC]), the EAP retransmission timer SHOULD be set to an
infinite value, so that retransmissions do not occur at the EAP
layer.

HENRIK: (I assume the state machine covers this? and also has other
timers to guarantee that the protocol doesn't hang forever
waiting for an infinite timer to expire. How much of this should
be described here? Should some text be removed, with reference
to the state machine document?)

--------------------------------------
In section 4.2.1:

[b] Receipt of EAP Success and Failure packets prior to method
completion. A peer EAP implementation receiving an EAP Success
packet prior to completion of the method in progress MUST silently
discard it. This ensures that a rogue authenticator will not be
able to bypass mutual authentication by sending an EAP Success
prior to conclusion of the EAP method conversation. A peer EAP
implementation receiving an EAP Failure packet prior to completion
of the method in progress MAY silently discard it. When using EAP
methods that provide their own (protected) error indications,
premature EAP Failure packets are unexpected, so that this
technique may be more readily employed.

HENRIK: In view of the possibility of inserting a false EAP Failure
packet in e.g. wireless networks, maybe there should be a
RECOMMENDED discard of premature Failure packets in the case of
insecure link in combination with EAP methods with protected
error indications?

--------------------------------------
In section 7.2:

[d] Key strength. If the method derives keys, then the effective key
strength MUST be estimated.

HENRIK: How should the estimated effective key strength be indicated?

--------------------------------------
In section 7.:

HENRIK: I believe I can see one security issue which has not
been discussed in this section, but might be mentioned: If the
authenticator uses pass-through to a backend authentication
server, it seems to me that the authenticator will not
understand method-specific success and failure indications, and
are dependent on seeing the final EAP Success (or Failure)
packet in order to know the outcome of the authentication. This
means that the link between authenticator and backend
authentication server needs to be secure against injection of
false EAP Success or Failure indications. This is probably the
case in most deployments, but might want mentioning for
completeness? I can propose some text for your consideration.

---

From: [email-masked] (Henrik Levkowetz)
Date: Fri, 7 Feb 2003 18:05:57 +0100

Sorry for the response time. My machine crashed yesterday, I'm now
up and about again with a new box.

Some comments:

On Tue, 4 Feb 2003 17:01:23 -0800 (PST)
> packets like NCP mentioned above do not cause EAP authentication to

Ok. Do we want to add something regarding how to treat link down
indication on a wireless link? Maybe: 

"Link down indications on 802.11 SHOULD NOT be taken as an authentication
failure indication."

Ok. I propose we leave the text as it is.

I would agree. I propose we change the text accordingly

From:
								"... A
       peer EAP implementation receiving an EAP Failure packet prior to
       completion of the method in progress MAY silently discard it.
       When using EAP methods that provide their own (protected) error
       indications, premature EAP Failure packets are unexpected, so
       that this technique may be more readily employed."

To:
								"... A
       peer EAP implementation receiving an EAP Failure packet prior to
       completion of the method in progress MAY silently discard it.
       When using EAP methods that provide their own (protected) error
       indications, premature EAP Failure packets are unexpected. In
       this case any premature EAP failure packet SHOULD be silently
       discarded."

Mmm, could we assume that effective key strength can be indicated through
effective key length? Then we might change the text as follows:

From:
	"[d] Key strength. If the method derives keys, then the effective key
	     strength MUST be estimated."
To:

	"[d] Key strength. If the method derives keys, then the effective key
	     length MUST be estimated."	

There is some text there, but as it is talking about the RADIUS case,
not all is applicable, and it does not specifically talk about the
case of the unprotected generic EAP Success and Failure messages. 
I propose a new section:

"7.12 Separation of EAP server and authenticator

   It is possible for the EAP peer and authenticator to mutually
   authenticate, and derive a Master Session Key (MSK) for a ciphersuite
   used to protect subsequent data traffic.  This does not present an
   issue on the peer, since the peer and EAP client reside on the same
   machine; all that is required is for the EAP client module to derive
   and pass a Transient Session Key (TSK) to the ciphersuite module.

   However, in the case where the EAP server and authenticator reside on
   different machines, there are several implications for security.

   [a] Authentication will occur between the peer and the EAP server,
       not between the peer and the authenticator. This means that it is
       not possible for the peer to validate the identity of the NAS or
       tunnel server that it is speaking to, using EAP alone.

   [b] The authenticator is dependent on seeing the General EAP Success
       or Failure indications in order to know the outcome of an
       authentication conversation. It will not understand any method
       specific success or failure indications. And whereas individual
       EAP methods may employ Message Integrity Checks to ensure that
       individual packets have not been tampered with, the general EAP
       Success and Failure indications cannot be protected in this
       manner. This means that even if an authentication conversation
       between EAP server and peer has failed, injection of a EAP
       Success packet on the link between server and authenticator at
       the right time may lead to unauthenticated access. It is
       therefore important that the link between server and
       authenticator is either physically secure, or a secure transport
       mechanism for EAP packets are provided between EAP server and
       authenticator. The specification of such a wrapping mechanism is
       outside the scope of this document.

   [c] A EAP Master Session Key (MSK) negotiated between the peer and
       EAP server will need to be transmitted to the authenticator.
       Therefore a mechanism needs to be provided to transmit the MSK
       from the EAP server to the authenticator or tunnel server that
       needs it. The specification of the key transport and wrapping
       mechanism is outside the scope of this document.
"

	Henrik

> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap