Subject: [eap] Proposed resolution to Issue 74

From: [email-masked] (Bernard Aboba)
Date: Thu, 6 Mar 2003 10:46:36 -0800 (PST)

Add as an Appendix:

"Appendix A - Method Specific Behavior

A.1 Message Integrity Checks

Today, EAP methods commonly define message integrity checks (MICs)
that cover more than one EAP packet. For example,
EAP methods such as EAP-TLS [RFC2716] define a MIC
covering an extended PDU that could be split
into multiple fragments, or that can cover portions of earlier
messages (FINISHED message). Where the MIC
covers more than one EAP packet,a validation failure
typically needs to be considered a fatal error.

If a per-packet MIC is employed within an EAP method,
then peers, authentication servers, and authenticators
not operating in pass-through mode MUST validate the MIC,
A MIC validation failure SHOULD be considered a fatal error
and SHOULD be logged.

However, it is also possible to develop EAP methods
that support per-packet MICs, and
respond to verification failures by silently
discarding the offending packet.

In this document, descriptions of EAP message handling
assume that per-packet MIC validation, where it occurs,
is effectively performed as though it occurs before
examining any of the EAP message fields (such as 'Code')."

---

From: [email-masked] (Jari Arkko)
Date: Thu, 06 Mar 2003 23:34:50 +0200

> examining any of the EAP message fields (such as 'Code')."

So, we first validate the MIC and only then look at the
packet if it was even a Response, or for the right Identifier?
Why? And I don't understand how this works. Assume I'm the peer
who is running some method with per-packet MICs. I get a
Failure, or a Request for another Type. But I ignore these
and just proceed to verify the MIC?

If the concern is avoidance of side effects on a packet
that fails the MIC check, then maybe the following text
might do it: "... is effectively performed as though it occurs
before sending any responses or changing the state of the
node which received the packet."

Jari

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 6 Mar 2003 14:16:15 -0800 (PST)

> node which received the packet."

Yes, that is the concern (that the Id was updated even though the MIC
check failed). Your text sounds fine.

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 6 Mar 2003 14:36:27 -0800 (PST)

OK. How about this?

Appendix A - Method Specific Behavior

In this document, descriptions of EAP message handling
assume that per-packet MIC validation, where it occurs,
is effectively performed as though it occurs
before sending any responses or changing the state of the
host which received the packet."

---

From: [email-masked] (Nick Petroni)
Date: Fri, 7 Mar 2003 01:41:20 -0500 (EST)

> discarding the offending packet.

So we are saying that a MIC failure SHOULD end the conversation (isn't
that what fatal error means?), but that you COULD discard instead?
My current understanding would be that discard should be chosen over
failure, but I am open to being convinced otherwise.

nick

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 6 Mar 2003 21:31:39 -0800 (PST)

> failure, but I am open to being convinced otherwise.

RFC 2869 indicates sending a Reject as a SHOULD so I think we have
to be consistent with that. While some might argue that discard would be a
more appropriate choice, the main focus of RFC 2284bis and RFC 2869bis is
to more clearly specify current practice, without breaking backward compatibility.

---

From: [email-masked] (Nick Petroni)
Date: Fri, 7 Mar 2003 02:19:55 -0500 (EST)

So, to be clear, the state machine draft is explicitly wrong in this case.

Methods should return methodState = FAIL instead of going to the discard
state?

This may be another problem of how to indicated different levels of
requirements in the same state machine, but I am unclear how to resolve
fatal error being preferred, but discard being allowed. Should the check be
more complex such that in the METHOD state the MIC is checked AND a
determination is made whether or not that failure is a fatal error?

As an additional note, I understand the need for backwards compatibility,
but to keep this as a SHOULD seems to imply to me that it's better to
implement it this way in the future. I don't necessarily agree that it is
and in the very least I think it would be nice to explain why failing on
invalid MICs could lead to denial of service. Also, my understanding of
why the Packet-Reject attribute was added in the first place is to be
consistent with how the non-passthrough works (or should work). If that is
the case, then since this appendix applies to both cases perhaps we should
make that distinction? If that is not the case, then I think I am
confused why Packet-Reject was created.

comments welcome.

nick

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 6 Mar 2003 22:26:50 -0800 (PST)

> Methods should return methodState = FAIL instead of going to the discard

Depends on whether you want to illustrate the more secure approach, or
describe what implementations do today. One advantage of having the state
machine be a separate document, is that you could conceivably say "this
state machine chooses the most secure alternative when available, even if
it is only a MAY."

> determination is made whether or not that failure is a fatal error?

I think you have to put a stake in the sand and say "this is the approach
we think the state machine should take." I would say that the state
machine doesn't have to implement every conceivable option or exhibit
every behavior. It just has to be consistent in its philosophy -- and
upfront about what it is trying to do.

> implement it this way in the future.

Yes, that is a problem. Part of the issue is that in
TLS a MIC failure is fatal, so it's hard to get around that in TLS-based
methods: EAP TLS, TTLS, PEAP, etc.

Is this another example of behavior that is really method-specific, and
*not* handled in a consistent way by EAP and/or RADIUS? If so, then the
answer is to say that the RADIUS implementation MAY send a Reject or MAY
silently discard, depending on the requirements of the method in question.

> I don't necessarily agree that it is
> invalid MICs could lead to denial of service.

Yes, I do think that is less robust than silent discard.

> Also, my understanding of
> consistent with how the non-passthrough works (or should work).

Yes -- it was added to allow for silent discard where an authenticator in
pass-through is present. An authenticator without pass-through can already
silently discard invalid packets.

> If that is

It probably should. Or we could change both RFC 2869bis and RFC 2284bis to
make it clear that this is *not* a RADIUS decision, but rather a decision
made by the EAP method.

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 7 Mar 2003 05:27:18 -0800 (PST)

I've updated the proposed resolution to Issue 83 (which also relates to
Issue 74), to reflect your points. How does this look?

"2.5 Invalid packets

A RADIUS server receiving EAP-Message attribute(s) it does not understand
MAY return an Access-Reject. In order for the RADIUS server to
communicate that an invalid EAP packet has been received, but
that the problem is non-fatal, an Access-Challenge containing a
Service-Type=Packet-Reject MAY be sent. In some cases, the EAP method may
make the determination of whether the error is fatal or non-fatal.

A NAS compliant with this specification, on receiving an
Access-Challenge with a Service-Type=Packet-Reject,
SHOULD discard the current EAP packet, and check whether
it has received additional EAP Response packets with an
Identifier matching that of the last Request. If so,
a new EAP Response packet, if available, MUST be sent to the RADIUS server
within an Access-Request packet. In order to provide protection
against Denial of Service (DoS) attacks, it is advisable for
the authenticator to allocate a finite Response buffer,
and to discard packets according to an appropriate policy once
that buffer has been exceeded.

Once the RADIUS server responds with a packet containing a
non-null EAP-Message attribute, the NAS updates the
Identifier value, and any pending Responses that do
not match this value can be discarded. If another EAP Response
packet is not available, then the retransmission timer is
reset and the NAS retransmits the outstanding Request to the peer.

A NAS that does not support Service-Type=Packet-Reject behaves
as specified in [RFC2865], Section 5.6:

"A NAS is not required to implement all of these service types,
and MUST treat unknown or unsupported Service-Types as though
an Access-Reject had been received instead."

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 7 Mar 2003 05:42:13 -0800 (PST)

Here is an update to the proposed resolution of Issue 74 to bring it in
line with the updated resolution to Issue 83. What do you think?

Today, EAP methods commonly define message integrity checks (MICs)
that cover more than one EAP packet. For example,
EAP methods such as EAP-TLS [RFC2716] define a MIC
covering an extended PDU that could be split
into multiple fragments, or that can cover portions of earlier
messages (FINISHED message). Where the MIC
covers more than one EAP packet, a validation failure
is typically considered a fatal error.

If a per-packet MIC is employed within an EAP method,
then peers, authentication servers, and authenticators
not operating in pass-through mode MUST validate the MIC.
MIC validation failures SHOULD be logged.
Whether a MIC validation failure is considered a fatal error
or not is determined by the EAP method specification.

Within EAP-TLS [RFC2716] a MIC validation failures is treated
as a fatal error, since that is what is specified in TLS [RFC2246].
However, it is also possible to develop EAP methods
that support per-packet MICs, and
respond to verification failures by silently
discarding the offending packet.

host which received the packet.

---

From: [email-masked] (Nick Petroni)
Date: Fri, 7 Mar 2003 09:58:43 -0500 (EST)

This looks good to me.

---

From: [email-masked] (Nick Petroni)
Date: Fri, 7 Mar 2003 10:07:31 -0500 (EST)

I think this works too. I think you have correctly characterized it as a
method issue.

nick

Nick L. Petroni, Jr.
Graduate Student, Computer Science
Maryland Information Systems Security Lab
University of Maryland
http://www.cs.umd.edu/~npetroni

---

From: [email-masked] (Henrik Levkowetz)
Date: Fri, 7 Mar 2003 16:29:26 +0100

The text reads well to me.

	Henrik

On Fri, 7 Mar 2003 05:42:13 -0800 (PST)
Bernard Aboba <[email-masked]> wrote:

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

	Henrik

-- 
  Timing has an awful lot to do with the outcome of a rain dance.

---

From: [email-masked] (John Vollbrecht)
Date: Fri, 07 Mar 2003 15:22:07 -0500

--On Friday, March 7, 2003 2:19 AM -0500 Nick Petroni <[email-masked]> 
wrote:

> fatal error being preferred, but discard being allowed. Should the check
> be more complex such that in the METHOD state the MIC is checked AND a
Isn't this a case of what is specified for method, not for the state 
machine?  If the method chooses to return a failure or a discard it can, 
and the state machine can handle it.  We may want to ask if the state 
machine should handle the discard case, but that seems a separate question 
than whether the method should fail or continue on MIC failure.

> confused why Packet-Reject was created.
is the question whether there needs to be a distinction between passthru 
and non passthru given that we have the Packet Reject attribute which makes 
both work the same?
> > to be consistent with that. While some might argue that discard would
> > be a more appropriate choice, the main focus of RFC 2284bis and RFC
> > 2869bis is to more clearly specify current practice, without breaking
> > backward compatibility.
> >
> >
> >
>
>
>
>

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 7 Mar 2003 15:00:38 -0800 (PST)

> than whether the method should fail or continue on MIC failure.

Yes, that's right. It's not a decision for the authenticator or
authentication server to make -- it's specified by the method. The new
proposed resolutions for Issue 74 and 83 now reflect that.