Subject: [eap] [Issue] Various 2284bis comments

From: [email-masked] (Henrik Levkowetz)
Date: Mon, 3 Feb 2003 15:08:52 +0100

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.

--------------------------------------

	Regards,
		Henrik

-- 

Henrik Levkowetz +46708321608 [email-masked] www.ipunplugged.com
------------------------------------------------------------------------