Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet

From: Bernard Aboba <[email-masked]>
Date: Thu, 24 Jan 2013 06:39:57 -0800

On Jan 24, 2013, at 1:48 AM, "siva kumar" <[email-masked]> wrote:

> Hi Bernard/Calhoun,
> 
> Currently in our system, we are discarding packets with certain AVP in Access challenge packets. For eg: If framed-Ip-address is present in the
> Access challenge packet, we are dropping it. I read through the RFC and it is not specified what are the AVPs that are valid for Access challenge 
> packets. It will be great if you could throw some light for me. 
> 
> In our system only 10 AVPs are allowed in the Access challenge packet. Is it right to discard Access challenge packets based on the AVP sent by the server.
> 
> Awaiting your response regarding this.
> 
> Thanks & Regards,
> Sivakumar.S

---

From: Dave Nelson <[email-masked]>
Date: Thu, 24 Jan 2013 10:18:26 -0500

>> Currently in our system, we are discarding packets with certain
>> AVP in Access challenge packets. For eg: If framed-Ip-address
>> is present in the Access challenge packet, we are dropping it.
>> I read through the RFC and it is not specified what are the AVPs
>> that are valid for Access challenge packets.

Ummm... Doesn't this section tell you exactly that?

3.3.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in packets including EAP-Message attribute(s), and in what quantity.
   The EAP-Message and Message-Authenticator attributes specified in
   this document MUST NOT be present in an Accounting-Request.  If a
   table entry is omitted, the values found in [RFC2548], [RFC2865],
   [RFC2868], [RFC2869] and [RFC3162] should be assumed.

Request  Accept  Reject  Challenge   #    Attribute
0-1      0-1     0       0            1   User-Name
0        0       0       0            2   User-Password [Note 1]
0        0       0       0            3   CHAP-Password [Note 1]
0        0       0       0           18   Reply-Message
0        0       0       0           60   CHAP-Challenge
0        0       0       0           70   ARAP-Password [Note 1]
0        0       0       0           75   Password-Retry
1+       1+      1+      1+          79   EAP-Message [Note 1]
1        1       1       1           80   Message-Authenticator [Note 1]
0-1      0       0       0           94   Originating-Line-Info [Note 3]
0        0       0-1     0-1        101   Error-Cause [Note 2]
Request  Accept  Reject  Challenge   #    Attribute

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Alan DeKok <[email-masked]>
Date: Thu, 24 Jan 2013 10:46:03 -0500

> Ummm... Doesn't this section tell you exactly that?

  True.

  I'm a bit surprised, though, at the idea that packets can be discarded
like that.  The RFCs make it clear when packets should be silently
discarded.  They *don't* say that packets should be silently discarded
when they contain unexpected data.

  We know that the standard space contains unallocated attributes.  What
happens when an implementation receives a packet containing one of those
attributes?

  The "Table of Attributes" *implies* that it is authoritative.  So any
attribute *not* in the list is presumed to be not allowed.  Therefore,
by the above logic, that packet should be discarded.

  So any deployed implementation would know about *only* the attributes
allocated when it was published.  And would discard packets from all
newer standards.

  This practice means that it will be impossible to publish new standards.

  So this practice of discarding packets should be STRONGLY DISCOURAGED.
 Instead, the "Table of Attributes" should be used to filter attributes
in the packet.

  When the "Table of Attributes" contains a "0", and the attribute is
received in a packet, then that attribute should be discarded.  And only
that attribute should be discarded.  All other attributes should be left
alone.  The packet should be processed as normal.

  Discarding well-formed packets from valid clients is an absolutely
horrible practice.  It will break pretty much everything in RADIUS
deployments.  I cannot emphasize enough just how bad an idea this is.

  Alan DeKok.

---

From: Dave Nelson <[email-masked]>
Date: Thu, 24 Jan 2013 10:58:01 -0500

> deployments.  I cannot emphasize enough just how bad an idea this is.

I think that's generally true.  I'm not sure it's universally true.
If we're talking about a specific kind of RADIUS packet flows, for
example the interactive exchange of EAP-Messages, it becomes unclear
how the semantics of RADIUS Atributes that provision service are to be
applied.  I'm not sure that starting just any kind of service from the
NAS ought to be allowed in the middle of an authentication exchange.
I think there is an fundamental assumption that RADIUS provisions
service delivery at the NAS only *after* a successful authentication.
Therefore, properly applying service provisioning attributes in the
middle of an EAP exchange seems to be an undefined, or at least
undesirable, operation.

No?

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Alan DeKok <[email-masked]>
Date: Thu, 24 Jan 2013 11:23:40 -0500

Dave Nelson wrote:
> applied.

  Service provisioning is done after the Access-Accept.  Any service
provisioning in an Access-Challenge should be ignored.

>  I'm not sure that starting just any kind of service from the

  Yes.  Absolutely.

  But discarding the Access-Challenge entirely?  What that means is I
can *destroy* a RADIUS roaming infrastructure by included
Framed-IP-Address in an Access-Challenge.  I can do this as the home
server, or as an intermediate proxy.  Any visited RADIUS server will
panic and discard the packet.

  And... no one will be able to authenticate.

  Discarding well-formed packets because they contain *too much*
information violates the robustness principle of RFC 1122, Section
1.2.2, which was published in 1989.

  We've known for ~23 years that being liberal with "unexpected" data is
a good idea.  Let's not change that now.

  Alan DeKok.

---

From: Dave Nelson <[email-masked]>
Date: Thu, 24 Jan 2013 12:09:19 -0500

On Thu, Jan 24, 2013 at 11:23 AM, Alan DeKok <[email-masked]> wrote:

>   But discarding the Access-Challenge entirely?

No, I agree that's problematic.  OTOH, the notion of attribute
filtering might violate the notion that some attributes are implicitly
considered "mandatory".  I don't see a simple, zero-impact
recommendation to cover the OP's question for all cases.  The best I
see is the attribute filtering suggestion, in the context of
Access-Challenge, with the caveat that any service provisioning
attributes SHOULD (MUST ?) be discarded.  Other attributes will have
to be considered on the specific use case ans their particular
semantics.

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Dave Nelson <[email-masked]>
Date: Thu, 24 Jan 2013 12:49:16 -0500

> 1.2.2, which was published in 1989.

Yes, but...

I think we need to also honor the principle of "least surprise".
Selectively honoring or ignoring attributes on an implementor choice
basis doesn't honor that principle.  What the NAS (or Proxy Server)
might think to be "too much" or extraneous information might have been
important to the home server.  It's a matter of policy and intent.
There are some attributes in RADIUS that have implicit "mandatory"
status, in which case the inability of the NAS to support or enforce
them requires the NAS to deny service.

I guess this comes down to the difference between syntactically
well-formed packets and semantically well-formed packets.

I suspect that it's probably OK to filter out all attributes in an
Access-Challenge packet not permitted by the Table of Atributes in RFC
3579, for the use case of authentication by means of EAP.  By OK, I
mean *highly* RECOMMENDED.  We should explicitly address someplace
that's the right thing to do, in this use case, for those attributes
which are considered "mandatory".

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Alan DeKok <[email-masked]>
Date: Thu, 24 Jan 2013 13:41:09 -0500

Dave Nelson wrote:
> basis doesn't honor that principle.

  That's not what I proposed.  The Table of Attributes is clear.
Framed-IP-Address doesn't belong in Access-Challenge.  If it exists, it
should be *treated* is if it occurred with multiplicity "0", as per the
table.

>  What the NAS (or Proxy Server)

  Exactly.  The extensions document talks about "invalid attribute" in
that context.  It says that unexpected information should be passed
as-is, as someone else might understand it.  It also says that the data
should be ignored if you don't understand it.

> them requires the NAS to deny service.

  Yes.  RFC 2865 Section 5.6 says unknown Service-Types MUST be treated
as Access-Reject.

  I can't find anything which says that provisioning *other* kinds of
unknown services should be treated as reject.  The text assumes that
Service-Type is always in the Access-Accept, even though the Table of
Attributes says it can be omitted.

  Perhaps that should also be clarified.  If a NAS doesn't find anything
it recognizes as provisioning a service, it MUST be treated as an
Access-Reject.

> well-formed packets and semantically well-formed packets.

  Yes.

> which are considered "mandatory".

  Well, the extensions document is ongoing.  It may be a bit late to do
this (IETF last call).  But it already has text around "invalid
attributes".  And that text is relevant to this topic.

  If the WG agrees, I can update the extensions document with some text
around this subject.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 24 Jan 2013 13:49:38 -0500

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

I strongly agree with Alan here.
I think a NAS should treat such an unexpected attribute as if it had not
been present in the packet.
I'd prefer proxies pass along unfiltered because it makes it easier to
deploy extensions.
I'm OK with proxies permitting filtering, and I guess even OK with
default filters in proxies that support configuration. 

I would consider it incredibly bad from an extensibility standpoint if
someone started marketing a proxy that only permitted the attributes
listed in RFC 3579 for access-challenges containing EAP-Message and
didn't permit the behavior to be modified.

--Sam

---

From: Dave Nelson <[email-masked]>
Date: Thu, 24 Jan 2013 13:53:20 -0500

On Thu, Jan 24, 2013 at 1:41 PM, Alan DeKok <[email-masked]> wrote:

> unknown services should be treated as reject.

Section 2.5 of RFC 5080 says, in relevant part:

   In general, it is best for a RADIUS client to err on the side of
   caution.  On receiving an Access-Accept including an attribute of
   known Type for an unimplemented service, a RADIUS client MUST treat
   it as an Access-Reject, as directed in [RFC2865] Section 1.1.  On
   receiving an Access-Accept including an attribute of unknown Type, a
   RADIUS client SHOULD assume that it is a potential service
   definition, and treat it as an Access-Reject.  Unknown VSAs SHOULD be
   ignored by RADIUS clients.

   In order to avoid introducing changes in default behavior, existing
   implementations that do not obey this recommendation should make the
   behavior configurable, with the legacy behavior being enabled by
   default.  A configuration flag such as "treat unknown attributes as
   reject" can be exposed to the system administrator.  If the flag is
   set to true, then Access-Accepts containing unknown attributes are
   treated as Access-Rejects.  If the flag is set to false, then unknown
   attributes in Access-Accepts are silently ignored.

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Dave Nelson <[email-masked]>
Date: Thu, 24 Jan 2013 13:58:00 -0500

> been present in the packet.

That might be OK for Access-Challenge packets.  RFC 5080 Section 2.5
says this is a really bad idea for Access-Accept packets.

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Sam Hartman <[email-masked]>
Date: Thu, 24 Jan 2013 14:00:07 -0500

>>>>> "Dave" == Dave Nelson <[email-masked]> writes:

    Dave> On Thu, Jan 24, 2013 at 1:49 PM, Sam Hartman

    >> been present in the packet.

    Dave> That might be OK for Access-Challenge packets.  RFC 5080
    Dave> Section 2.5 says this is a really bad idea for Access-Accept
    Dave> packets.

I was speaking specifically to access-challenge.
I'm not sure I agree with  RFc 5080 here, but I think the tradeoff is
more complex.

---

From: Dave Nelson <[email-masked]>
Date: Thu, 24 Jan 2013 14:02:08 -0500

On Thu, Jan 24, 2013 at 2:00 PM, Sam Hartman
<[email-masked]> wrote:

>... I think the tradeoff is more complex.

As it almost always is between easy interoperability and security.  :-)

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636