Subject: [eap] Issue 72: RFC 2869bis review

From: [email-masked] (Bernard Aboba)
Date: Mon, 27 Jan 2003 05:52:47 -0800 (PST)

Issue 72: RFC 2869bis review
Submitter name: Jari Arkko
Submitter email address: [email-masked]
Date first submitted: January 26, 2003
Document: draft-aboba-radius-rfc2869bis-07.txt
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:
Comments marked with "JARI:"
JARI: I think we need a section on what has been updated since RFC 2869.
1. Introduction
[RFC2865] describes the RADIUS Protocol as it is implemented and deployed
today, and [RFC2866] describes how Accounting can be performed with
RADIUS.
JARI: Remove "as it is implemented and deployed today". I don't think
RFC2865 talks about implementation or deployment.
In order to provide for support of EAP within RADIUS, two new
JARI: s/provide for support of/support/
Once EAP has been negotiated, the NAS SHOULD send an initial EAP-Request
message to the authenticating peer. This will typically be an
EAP-Request/Identity, although an EAP-Request for an alternate EAP method
is possible. For example, a NAS might be
JARI: s/alternate/actual authentication/?
This could be usefulin cases where the identity is determined by another
means (such as the Called-Station-Id or Calling-Station-Id), a single
authentication method is required (so that the identity is not needed to
determine the method), or where identity hiding is desired, so that the
identity is not requested until after a protected channel has been set up.
The peer responds with an EAP-Response, which the NAS encapsulates within
EAP-Message attribute(s) within a RADIUS Access-Request packet, sent to
the RADIUS server. For example, if an EAP-Request/Identity message is sent
by the NAS as the first packet, the peer responds with an
EAP-Response/Identity, and the NAS encapsulates the EAP-Response/Identity
message within EAP-Message attribute(s), enclosed within an Access-Request
sent to the RADIUS server.
JARI: In the above, we need a discussion of the possibility that the
NAS decides at this point to run a local method. Add: "Alternatively, the
NAS may determine from the response that it should proceed with local
authentication. Once the NAS has begun the use of RADIUS authentication
for a particular session, it no longer can perform local authentication."
If the RADIUS server supports EAP, it MUST respond with an
Access-Challenge packet containing EAP-Message attribute(s). If the RADIUS
server does not support EAP, it MUST respond with an Access-Reject.
JARI: Support vs. wants to do vs. wants to do for this particular user?
EAP-Message attribute(s) encapsulate a single EAP packet which the NAS
decapsulates and passes on to the authenticating peer. The conversation
continues until either a RADIUS Access-Reject or Access-Accept packet is
received from the RADIUS server. Reception of an RADIUS Access-Reject
packet MUST result in the NAS denying access to the authenticating peer. A
RADIUS Access-Accept packet successfully ends the authentication phase.
JARI: This could my lack of knowledge in RADIUS, but what about the
simultaneous bidir authentications? What does the Access-Accept signify in
that case? Both end at that time, or can we open up a new RADIUS dialog
for the other auth? And what happens if the NAS/RADIUS doesn't even want
to authenticate the peer, but the peer insists on authenticating the
NAS/RADIUS? Seems like the initiate-with-Id-Request -approach seems wrong
in such a case.
Using RADIUS, the NAS can act as a pass-through for an EAP conversation
between the peer and backend authentication Server, without needing to
implement the EAP method used between them. Even where the NAS initiates
the conversation by sending an EAP-Request, it is not required that the
NAS fully implement the EAP method sent in the first packet. Depending on
the method, it may be sufficient for the NAS to be configured with the
initial packet to be sent to the peer, and for the NAS to act as a
pass-through for subsequent messages.
JARI: The above is somewhat unclear. Do you or do you not require just the
identity request to be sent by the NAS? Or do you require also a canned
first message to be sent if no id request is needed? Besides, not all
methods can have a canned first message, e.g. challenge-response...
In order to permit non-EAP aware RADIUS proxies to forward the
Access-Request packet, if the NAS initially sends an EAP-Request/Identity
message to the peer, the NAS MUST copy the contents of the Type-Data field
of the EAP-Response/Identity received from the peer into the User-Name
attribute and MUST include the Type-Data field of the EAP-
Response/Identity in the User-Name attribute in every subsequent
Access-Request.
JARI: Only because of non-EAP aware proxies? What does the EAP-aware proxy
use for routing the messages to the right direction, User-Name or contents
of the EAP messages? I think the former... so its for the operation of all
proxies, right?
JARI: I'm hoping the above "MUST copy" doesn't apply for an EAP Id
req/resp pair appearing within a tunneled method or in a sequence... (the
NAS might be able to see this message pair if it executed the first part
itself and *then* let RADIUS handle the rest. Or did we prohibit such
cases already?)
The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in
the Access-Request packet, and either NAS-Identifier or NAS-IP-Address
attributes MUST be included. In order to permit forwarding of the
Access-Reply by EAP-unaware proxies, if a User-Name attribute was included
in an Access-Request, the RADIUS server MUST include the User-Name
attribute in subsequent Access-Challenge, Access-Accept or Access-Reject
packets. Without the User-Name attribute, accounting and billing becomes
difficult to manage. If the identity is determined by another means, such
as the Calling-Station-Id, the NAS MUST include these identifying
attributes in every Access-Request, and the RADIUS server MUST copy these
identifying attributes into subsequent Access-Challenge, Access-Accept or
Access-Reject packets.
JARI: Uh.... so identity hiding breaks roaming completely? There seems to
be two issues that we need to deal with:
1) How to route the request to the right place. Here it is hard for me to
see any solutions. Or perhaps hiding just the user name but not the domain
as was done in EAP SIM & AKA. But we don't have the general machinery in
EAP for that.
2) How to associate the accounting records with the right user? Would the
Class attribute be suitable in this situation? The records would carry the
information, but only the home network can correlate them with the actual
user.
Having the NAS send the initial EAP-Request packet has a number of
advantages:
JARI: [3] Allowing for local authentication for some users.
In this case, the NAS MAY also send an Access-Request packet to the RADIUS
server containing an EAP-Message attribute signifying EAP-Start. This
allows the RADIUS server to take over the task of negotiating a more
suitable method.
JARI: Question - does the NAS include the contents of the Nak and the
request that led to it when sending this EAP-Start?
2.2. Role reversal
Since EAP is a peer-to-peer protocol, an independent and simultaneous
authentication may take place in the reverse direction. Both peers may act
as authenticators and authenticatees at the same time.
Support for role reversal is optional on the RADIUS server, and requires
JARI: Why optional? How about mandatory to implement, optional to
configure the server to actually do it? If we required mandatory support
for this, would this increase the likelihood protection against rogue
NASes? Or maybe we should require mutual auth support in EAP.
The RADIUS server then replies with an Access-Accept (in response to an
EAP-Success) or an Access-Reject (in response to an EAP-Failure),
containing no EAP-Message attribute.
JARI: May need to explain how the two RADIUS dialogs are independent, i.e.
Access-Accept as a response to the above kind of Access-Request does *not*
mean the other auth is complete and the user should be let in. Also, I'm
uncertain what happens in the user is authenticated to the NAS/RADIUS
first and an Access-Accept is returned, and *then* the user initiates EAP
in another direction. Can this happen with PPP? 802.1X?
This can be accomplished by inclusion of Session-Timeout and
Password-Retry attributes within the Access- Challenge packet.
JARI: I don't understand Password-Retry in this context. Wouldn't it be
the RADIUS server that only is aware of an authentication failure, and
would also need to send the new Requests to make possible the use of a new
password?
If Session-Timeout is present in an Access-Challenge packet that also
contains an EAP-Message, the value of the Session-Timeout provides the NAS
with the maximum number of seconds the NAS should wait for an EAP-Response
before retransmitting the EAP-Request.
JARI: Please clarify whether this can be received multiple times, and what
the semantics are. E.g. first you start PEAP and timeout is 5 s, then
inside you'll be running token caard and timeout is 60 s, apparently the
NAS takes the latest received timeout value, and starts counting from the
time that it received this value from the NAS?
As described in [RFC2284], the EAP Success and Failure packets are not
JARI: Update refs to 2284bis?
Since the responsibility for avoiding these conflicts lies with the RADIUS
server, the NAS MUST NOT "manufacture" EAP packets in order to correct
contradictory messages that it receives. This behavior, originally
mandated within [IEEE8021X], has since been deprecated.
JARI: So, what does it do then? MUST disconnect?
2.6.2. Priority
In addition to containing EAP-Message attributes, RADIUS messages may also
contain other attributes. In order to ensure the correct processing of
RADIUS messages, the NAS SHOULD process EAP-Message attributes last.
JARI: We need more detail here. Say, Session-Timeout is one of these other
attributes. What does 'process' mean? Look at the EAP message contained in
the packet? Send that message to the peer and expect it to answer -- if
so, the timeout setting would be handled too late.
It is possible that the chosen Identifier value will conflict with a value
chosen by the RADIUS server for another packet within the EAP
conversation. This would violate the requirement that the Identifier be
unique within an EAP conversation.
JARI: And after this, its still a MAY? Backwards compatibility prevents us
prohibiting it?
When used within an EAP conversation, a Reply-Message attribute received
by the NAS MAY be translated to an EAP-Request/Notification sent to the
peer. As a result, a Reply-Message attribute MUST NOT be included in a
RADIUS message containing an EAP-Message attribute. An
EAP-Message/EAP-Request/Notification or Reply-Message attribute SHOULD NOT
be included within an Access-Accept or Access-Reject packet representing
the conclusion of an EAP conversation.
JARI: But this is in conflict in 2.6.3! Delete 2.6.3 and use this instead?
Value
The Value field is four octets, containing an integer specifying the
number of password retry attempts to permit the user.
JARI: I must be missing something obvious again. What does the NAS do with
this information? If it is running EAP and carrying it over to the RADIUS
server, it doesn't appear to be able to tell whether the response messages
from the peer used the right password or not. Nor can it resend Requests,
there'd be Identifier conflicts, no?
RADIUS over IPsec, defined in [RFC3162] will eventually make this
attribute obsolete, so it should be considered an interim measure.
JARI: When is the time to start requiring this? Or should new protocols
just start using DIameter instead?
Vulnerabilities include:
 Separation of EAP server and authenticator
 Dictionary attacks
 Known plaintext attacks
 Replay protection
 Connection hijacking
 Man in the middle attacks
 Multiple databases
 Negotiation attacks
JARI: No DoS? Reading on...
For the authenticating peer, authentication policy should be set on a
per-connection basis. Per-connection policy allows an authenticating peer
to negotiate a strong EAP method when connecting to one service, while
negotiating a weaker EAP method for another service.
JARI: Per-service or per-connection? If its per-connection, what if the
attacker causes a disconnect, then offers a weaker method? Ah, the
explanation below clarifies this. Wouldn't the right name for this be
"per-service"?
An authenticating peer expecting EAP to be negotiated for a session MUST
NOT negotiate a weaker method, such CHAP or PAP.
JARI: s/such/such as/
wireless networks, the service advertisement itself may be spoof-able, so
that an attacker could fool the peer into negotiating an authentication
method suitable for a less secure network.
JARI: Ouch! So, per-service isn't very helpful either unless you support
the same security level for all services.
EAP-capable authenticating peer MUST refuse to renegotiate the
authentication protocol if EAP had initially been negotiated. Note that
problems with a non-EAP capable RADIUS proxy could prove difficult to
diagnose, since a user connecting from one location (with an EAP-capable
proxy) might be able to successfully authenticate via EAP, while the same
user connecting at another location (and encountering an EAP-incapable
proxy) might be consistently disconnected.
JARI: Ok, so to get back to the DoS issue... let's see: No, I can't think
of any additional dos problems beyond those already present in EAP.
5. Normative references
JARI: I'm not sure why the above ones are normative. At least the first
one should be informative?