Subject: [AAA-WG]: [issue 353] Issues with EAP-00 draft

From: Bernard Aboba <[email-masked]>
Date: Sat, 7 Sep 2002 07:41:33 -0700 (PDT)

Issue 353: Issues with EAP-00 draft
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: September 7, 2002
Reference:
Document: EAP-00
Comment type: T
Priority: 1
Section: several
Rationale/Explanation of issue:

Page 2, last sentence of the Abstract:

Change "PPP Extensible Authentication Protocol" to "Extensible
Authentication Protocol."

Page 2, section 2, last sentence:

Change "with PAP and CHAP in a roaming PPP environment." to
"with PAP, CHAP or EAP-MD5."

Page 3, Section 2.1, second paragraph, first sentence:

The first approach was described as "typical". That would imply that
additional approaches are non-typical, so that the adjective "preferred"
would not apply to them. Also, in the BNF {Section 3.1.1}, the
Destination-Realm AVP is noted as required. Where the "typical" approach
is taken, it would seem difficult to include this. So perhaps you should
describe how this is done.

Change "A preferred approach..." to "An alternate approach..."

Page 3, Section 2.1, Fourth paragraph:

Change:

"   A Diameter-EAP-Answer message containing an EAP-Payload of type EAP-
   Success or EAP-Failure MUST NOT have the Result-Code AVP set to
   DIAMETER_MULTI_ROUND_AUTH."

To:

"   A Diameter-EAP-Answer message containing an EAP-Payload of code EAP-
   Success (3) or EAP-Failure (4) MUST NOT have the Result-Code AVP set to
   DIAMETER_MULTI_ROUND_AUTH."

Page 3, Section 2.1, paragraph 5:

"Diameter-EAP-Answer messages whose Result-Code AVP is set to
   DIAMETER_MULTI_ROUND_AUTH MAY include authorization AVPs."

You might give an example of a situation where this would occur.

Section 4.2.1 last sentence:

"If the NAS performs the
   Termination-Action by sending a new Diameter-EAP-Request command upon
   termination of the current service, it MUST return the State AVP
   unmodified in the new Diameter-EAP-Request command."

I've never understood the purpose of the State AVP here, or why it is a
MUST for inclusion. Some additional explanation would be helpful.

Page 9, Section 4.2.5, third paragraph

"If the value of the Termaination-Action AVP is equal to AA-REQUEST
   (1) then upon termination of the authorized service the NAS MAY send
   a new Diameter-EAP-Request (DER) command."

This is what RFC 2865 says, but it makes more sense for the MAY to be a
SHOULD or MUST. Essentially, this becomes a way to mandate
re-authentication without a server-initiated message. By using the DEFAULT
value, it's possible to terminate the session, so a AA-REQUEST value might
as well cause something different to happen.

Section 4.2.5, page 10, third paragraph:

"When used by 802.1x access devices, the service typically
            terminates due to the expiry of the Session-Timeout AVP.
            The access device may then reauthenticate the user with a
            new DER.  The RECOMMENDED way to do this in Diameter is to
            use the Authorization-Lifetime AVP rather than the
            Termination-Action AVP.  However, the Termination-Action AVP
            MAY be used when copied from a RADIUS Access-Accept packet
            to a Diameter-EAP-Answer command by a Translation Agent."

Actually, the service only terminates if Termination-Action=DEFAULT or no
Termination-Action AVP is included at all. If
Termination-Acton=AA-REQUEST, then re-authentication occurs. See:

http://www.ietf.org/internet-drafts/draft-congdon-radius-8021x-20.txt

ADDITIONS

NAS-Session-Key AVP

I think this needs to be defined in the EAP document, not in NASREQ. Since
there is controversy about this AVP, including it in NASREQ would prevent
that document from advancing.

Security considerations

You might consider cadging this from RFC 2869bis-03:

http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-03.txt

Usage Guidelines

Please consider the inclusion (with modifications to fit Diameter) of the
following section from RFC 2869bis-03, clarifying various aspects of
AAA/EAP interoperability:

2.5.  Usage guidelines

2.5.1.  Authentication completion

Within an EAP conversation, a RADIUS Access-Accept will typically
contain an EAP-Message attribute encapsulating an EAP Success packet.
Similarly, a RADIUS Access-Reject will typically contain an EAP-Message
attribute encapsulating an EAP Failure packet. However, this is not
required. For example, the RADIUS Access-Accept/Reject could contain an
EAP-Message attribute encapsulating an EAP-Request with an appropriate
Type code. This could occur, for example, where an EAP method contains
its own (protected) success or failure indications. In this case, it may
be possible to eliminate sending of the final EAP Success or EAP Failure
packet, saving a round-trip.

2.5.2.  Conflicting messages

In some cases, the authentication result implied by the encapsulated EAP
packet may not match the result communicated in the RADIUS message. For
example, and EAP Failure packet may be encapsulated within an Access-
Accept message and an EAP Success packet may be encapsulated within an
Access-Reject. Alternatively, no EAP-Message attribute may be included
within a RADIUS Access-Accept or Access-Reject.

Such combinations are likely to cause confusion, because the NAS and
Peer will arrive at different conclusions as to the outcome of the
authentication. For example, if the NAS receives an Access-Reject with
an encapsulated EAP Success, it will not grant access to the Peer.
However, on receiving the Success, the Peer will be lead to believe that
it authenticated successfully.

Similarly, if the NAS receives an Access-Accept with an encapsulated EAP
Failure, it will grant access to the Peer. However, on receiving an EAP
Failure, the Peer will be lead to believe that it failed authentication.
If no EAP-Message attribute is included within an Access-Accept or
Access-Reject, then the Peer may not be informed as to the outcome of
the authentication, while the NAS will take action to allow or deny
access.

As described in [RFC2284bis], the EAP Success and Failure packets are
not acknowledged, and these packets terminate the EAP conversation. As a
result, if these packets are encapsulated within an Access-Challenge, no
response will be received, and therefore no further Access-Requests will
be sent to the RADIUS server. As a result, the NAS will not be given an
indication of whether to allow or deny access while the Peer will be
informed as to the outcome of the authentication.

To avoid these conflicts, the RADIUS server SHOULD check to make sure
that the results implied by an  encapsulated EAP-Message attribute and
the RADIUS message are in agreement. The following combinations SHOULD
NOT be sent by a RADIUS server as part of an EAP conversation:

   Access-Accept/EAP-Message/EAP Failure
   Access-Accept/no EAP-Message attribute
   Access-Reject/EAP-Message/EAP Success
   Access-Reject/no EAP-Message attribute
   Access-Challenge/EAP-Message/EAP Success
   Access-Challenge/EAP-Message/EAP Failure

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.

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

[This is important for 802.1aa, but it makes more sense for it to end up
in the Diameter EAP document than to put this in 802.1aa.]

2.5.4.  Displayable messages

The Reply-Message attribute, defined in section 5.18 of [RFC2865],
indicates text which MAY be displayed to the user. This is similar in
concept to the EAP Notification Type, defined in [RFC2284].  When
sending a displayable message to a NAS during an EAP conversation, the
RADIUS server SHOULD encapsulate displayable messages within EAP-
Message/EAP-Request/Notification attribute(s), and SHOULD NOT use Reply-
Message attribute(s) for this purpose.

[I think that Reply-Message is already prohibited in Diameter, since it
wasn't included in the EAP Application BNF. If so, this is a good thing,
and this section isn't needed.]

A NAS receiving Reply-Message attribute(s) MAY copy the Text field(s)
into the Type-Data field of an EAP-Request/Notification packet, fill in
the Identifier field, and send this to the Peer. However, several issues
may arise from this:

[1]  Unexpected Responses. On receiving an EAP-Request/Notification, the
     Peer will send an EAP-Response/Notification, and the NAS will pass
     this on to the RADIUS server, encapsulated within EAP-Message
     attribute(s).  However, the RADIUS server may not be expecting an
     Access-Request containing an EAP-Message/EAP-Response/Notification
     attribute.

     For example, consider what happens when a Reply-Message is included
     within an Access-Accept or Access-Reject packet with no EAP-Message
     attribute present.  If the value of the Reply-Message attribute is
     copied into the Type-Data of an EAP-Request/Notification and sent
     to the peer, this will result in an Access-Request containing an
     EAP-Message/EAP-Response/Notification attribute being sent by the
     NAS to the RADIUS server. Since an Access-Accept or Access-Reject
     packet terminates the RADIUS conversation, such an Access-Request
     would not be expected.

[2]  Identifier conflicts. While the EAP-Request/Notification contains
     an an Identifier, a Reply-Message attribute does not. As a result,
     a NAS receiving a Reply-Message attribute and wishing to translate
     this to an EAP-Request/Notification will need to choose an
     Identifier. It is possible that the chosen Identifier will conflict
     with a value chosen by the RADIUS server for another packet within
     the EAP conversation. This would violate the requirement in
     [RFC2284bis] that  Identifier values be unique within an  EAP
     conversation.

2.5.5.  Displayable messages

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.

[I think this may be irrelevant for Diameter EAP, because the BNF does not
include the Reply-Message AVP.]

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 8 Sep 2002 18:18:45 -0700

> Authentication Protocol."

OK

> "with PAP, CHAP or EAP-MD5."

OK

> would not apply to them.

Not sure I follow your reasoning.  Are you saying that typical behavior is
also optimal?  This assertion seems a bit absurd :-)...

> Also, in the BNF {Section 3.1.1}, the
> is taken, it would seem difficult to include this.

Indeed!  In fact, it looks to me like the "typical" approach, far from being
either optimal or even "preferred" is actually pretty useless: it seems to
waste bandwidth to no good purpose, since the empty request cannot be routed
to the home realm...

> So perhaps
> you should

I would prefer :-) to delete or deprecate the first approach.

>    DIAMETER_MULTI_ROUND_AUTH."

OK

> You might give an example of a situation where this would occur.

Can you think of one?

> as well cause something different to happen.

Agreed.

> I think this needs to be defined in the EAP document, not in
> NASREQ.

I disagree emphatically.  Removing this AVP from NASREQ would result in
Diameter actually having _less_ functionality than current (albeit
non-standard) RADIUS implementations.

> Since

The major controversy I recall was from Paul Funk, who hasn't followed up
AFAIK, even as far as answering my question as to why the current AVPs do
not suffice to do exactly what he wants.  Are there other complaints?

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Sep 2002 05:38:10 -0700 (PDT)

> also optimal?  This assertion seems a bit absurd :-)...

I'm just wondering which behavior the draft is advocating, and why.

> waste bandwidth to no good purpose, since the empty request cannot be routed

However, if there is no proxy, then it could conceivably be useful. For
example, the RADIUS server could decide to dispense with an EAP Identity
exchange altogether and go immediately to an identity-hiding method (EAP
TTLS or PEAP).

> I would prefer :-) to delete or deprecate the first approach.

Perhaps the right thing to do is to indicate that the second approach is
preferred, except in special cases where the first approach MAY be used.

> > You might give an example of a situation where this would occur.

The case that comes to mind is use of Session-Timeout to indicate
the desired timeout period for the NAS, before resending the EAP Request.

> not suffice to do exactly what he wants.  Are there other complaints?

Yes, see Issue #294.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Sep 2002 06:04:44 -0700 (PDT)

> non-standard) RADIUS implementations.

Question: Is there a use for this AVP outside of EAP? For example, is it
used by 3GPP2? As I recall, the 3GPP2 liason letter requested advancement
of NASREQ for use with PAP/CHAP authentication, but there was no mention of
a need for keying support.