Subject: Re: [radext] #103: Long attribute fragmentation constraints

From: "radext issue tracker" <[email-masked]>
Date: Mon, 23 Jan 2012 19:08:18 -0000

#103: Long attribute fragmentation constraints

Changes (by aland@…):

 * status:  new => closed
 * resolution:   => invalid

Comment:

 The document is clear:

 > This means if I started a fragment with vendor id 4444 and before
 finishing that fragment start a new fragment with vendor id 3333 the
 implementation would have no choice other than to think vendor id 3333
 attribute is a continuation of the 4444 fragment rather than presenting an
 error.

   Yes.  That's how it works.  The same issue applies when nested TLVs are
 used.  Or when multiple "long" attributes are used.

   Inserting a new attribute into the middle of a list of attributes is
 wrong.  While this is technically allowed by RFC 2865,
 I am not aware of any RADIUS implementation which is *required* to do such
 insertions.  In contrast, most make it difficult
 to perform such insertions.

   We have the same argument against EAP-Message.   There are RADIUS
 proxies which do not do EAP authentication,
 and are unaware of EAP.  They have not been demonstrated to have this
 issue in the real world.

   Similarly, WiMAX uses attributes longer than 253 octets, and has its own
 "continuation" bit.  Problems with WiMAX continuations have not been
 observed in the real world.

   Any RADIUS implementation which erroneously uses the 244..245 space for
 other definitions is already in violation of the RFCS.
 If they're violating the RFCs, then all bets are off.  Those systems don't
 implement RADIUS correctly, and need to be fixed.

   To summarize, this argument is entirely specious.  There exist multiple
 "fragmented" attributes today, none of which have shown problems in the
 real world.  Any system which does create problems is either violating the
 current RFCs, or will be violating this document (if the implementation
 understands it).

 > So the reader is left wondering at least one of two things:
 >1)  Should I assume string is the value field?
 > 2) Should I assume Vendor-ID is the value field?

   The Vendor-Id is the VALUE field of the attributes with format Extended-
 Type with flags.  The Vendor-Id in turn has a value field, which can be of
 type string, etc.

   The same explanation applies to nested TLVs.  The fact that there are
 multiple fields that can be called "value" is no reason to confuse them.
 They have clearly defined contexts.

-- 
-------------------------+-------------------------------------------------
 Reporter:  peterd@…     |       Owner:  draft-ietf-radext-radius-
     Type:  defect       |  extensions@…
 Priority:  major        |      Status:  closed
Component:  radius-      |   Milestone:  milestone1
  extensions             |     Version:  1.0
 Severity:  Active WG    |  Resolution:  invalid
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/103#comment:2>
radext <http://tools.ietf.org/radext/>

---

From: "radext issue tracker" <[email-masked]>
Date: Mon, 23 Jan 2012 19:08:18 -0000

Changes (by aland@…):

 * status:  new => closed
 * resolution:   => invalid

Comment:

_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Peter Deacon <[email-masked]>
Date: Mon, 23 Jan 2012 12:52:05 -0800 (Pacific Standard Time)

On Mon, 23 Jan 2012, radext issue tracker wrote:

> wrong.

Says who?

> While this is technically allowed by RFC 2865, I am not aware of
> any RADIUS implementation which is *required* to do such insertions.

What happens when an RFC compliant implementation behaves in a manner your 
not aware for reasons your not aware?

> In contrast, most make it difficult to perform such insertions.

> proxies which do not do EAP authentication, and are unaware of EAP. 
> They have not been demonstrated to have this issue in the real world.

Although it is tempting to draw parallels with EAP experience there is 
only one instance of an *EAP packet* allowed per RADIUS message.

RFC 3579 3.1

"Multiple EAP packets MUST NOT be encoded within EAP-Message
       attributes contained within a single Access-Challenge,
       Access-Accept, Access-Reject or Access-Request packet."

>   Similarly, WiMAX uses attributes longer than 253 octets, and has its 
> own "continuation" bit.  Problems with WiMAX continuations have not been 

Who has seen even a single WIMAX VSA with continuation bit set?

>   To summarize, this argument is entirely specious.  There exist
> multiple "fragmented" attributes today, none of which have shown 
> problems in the real world.  Any system which does create problems is 
> either violating the current RFCs, or will be violating this document 
> (if the implementation understands it).

I understand you may disagree with regards to the degree this may be a 
problem.  I don't believe this warrants marking my issue 'invalid'.

Fundamentally I think it is better to work from the position of what the 
RFCs actually say rather than what we all wish they would have said.

I am not seeking major unreasonable disruptive change.  Only to mitigate 
against possibilities that MAY exist in a fully RFC compliant system.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Mon, 23 Jan 2012 12:52:05 -0800 (Pacific Standard Time)

Says who?

RFC 3579 3.1

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 23 Jan 2012 22:47:15 +0100

>>   Inserting a new attribute into the middle of a list of attributes is

  Says the extensions draft.

> only one instance of an *EAP packet* allowed per RADIUS message.

  RFC 2865 says nothing about EAP packets.  It's perfectly legal under
RFC 2865 to insert one instance of attribute 79 in the middle of a list
of attribute 79's.

  Doing so will break EAP.  So by your argument, adding EAP to RADIUS is
impossible.

> Who has seen even a single WIMAX VSA with continuation bit set?

  Is it really necessary to ask a rhetorical question?

  There's also RFC 5904, which defines two more attributes that can span
multiple RADIUS attributes.

  I think it's time to stop discussing the theoretical issue of
insertions into the middle of a list.  That ship has sailed.  There are
multiple IETF and SSO specifications which violate your requirements.
They are widely deployed, and no one has indicated there is *any*
problem with them.

> problem.  I don't believe this warrants marking my issue 'invalid'.

  I don't see it as a valid objection.  It's based on assumptions which
have proven to be false for a decade.

> RFCs actually say rather than what we all wish they would have said.

  Let's discard RFC 2869 because it's "Informational" and RFC 2865 is
"Standards Track".  2869 CLEARLY VIOLATES 2865.  Then, we'll deploy an
RFC 2865 compliant RADIUS proxy.  We'll have it mangle attribute 79 as
per your argument.  It's allowed under 2865.  It's exactly your
scenario.  You MUST then agree that 2869 is wrong and impossible to
implement.

  Except we've already proven that argument false.  RFC 2869 has proven
it false for over a decade.  Therefore, your arguments against the
extensions draft don't apply, either.

> against possibilities that MAY exist in a fully RFC compliant system.

  It's impossible to be fully compliant to the RADIUS RFCs.  They are
contradictory, incomplete, and often plain wrong.  See RFC 5080.

  The only question now is whether or not we can build something which
works.  I believe so, and have given proof.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 23 Jan 2012 22:47:15 +0100

Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 23 Jan 2012 15:44:14 -0800 (Pacific Standard Time)

>  Says the extensions draft.

My impression the goal was backwards compatibility with systems predating 
the extensions draft to at least inject or forward unknown attributes. In 
this case text of the extensions draft has no "say".  It didn't exist when 
these systems were deployed.

Backwards compatibility is the only reason I bring this up.  If backwards 
compatibility is not desired then I agree with you there are no issues, 
full steam ahead.

Forwarding or otherwise processing unknown attributes is not risk free 
such as forwarding an attribute requiring per-hop encryption.  I would 
loose no sleep over requiring all implementations in the chain to fully 
support extensions.

> RFC 2865 to insert one instance of attribute 79 in the middle of a list

You brought up EAP as evidence my concerns are without merit.  I pointed 
out there are important differences between EAP and extensions which limit 
the applicability of this analogy.

>  Doing so will break EAP.  So by your argument, adding EAP to RADIUS is 

RFC 3579 dictates how EAP-Message may be used.  EAP-Message is not defined 
anywhere else.

The important distinction not accounted for in your analogy is extensions 
further constrains allowed behavior of existing RFCs.  If you do this 
there are consequences with regard to backward compatibility as existing 
implementations can not be made retroactively aware of additional 
constraints.

>  Is it really necessary to ask a rhetorical question?

I assume the reason WIMAX was brought up was to provide evidence against 
my concerns.  My response simply suggests this specific scenario is not 
really all that widespread in the "real world" even in cases where these 
specific wimax VSAs are used and therefore not such a great measuring 
stick of the existence or nonexistence of the potential for any problems.

> multiple RADIUS attributes.

My EAP caution applies here as well.  There is only one cert per message 
of a specific attribute type allowed.

> have proven to be false for a decade.

I don't follow what was proven false?

> per your argument.  It's allowed under 2865.  It's exactly your

See above for my thoughts on this EAP-Message analogy.

> scenario.  You MUST then agree that 2869 is wrong and impossible to

Do I think it is wrong and costly when two RFCs disagree with each other? 
Yes.

Would it have been possible to implement 2869 in a way that did not 
violate 2865?  Yes.

> extensions draft don't apply, either.

There is always a cost when RFCs contradict each other.  I'm simply 
suggesting a way forward which seeks to limit any effect of legacy 
problems where backwards compatibility is desired.

> contradictory, incomplete, and often plain wrong.  See RFC 5080.

Contradictions are not cost free.  My intent is simply to mitigate these 
costs as much as reasonable within the current framework of extensions.

I have on multiple occasions stated I don't care about perfect backwards 
compatibility.  My goal is simply providing a good chance of detecting the 
presence of errors.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Mon, 23 Jan 2012 15:44:14 -0800 (Pacific Standard Time)

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Tue, 24 Jan 2012 09:05:26 +0100

Peter Deacon wrote:
> My impression the goal was backwards compatibility with systems
> predating the extensions draft to at least inject or forward unknown
> attributes. In this case text of the extensions draft has no "say".  It
> didn't exist when these systems were deployed.

  No.  You can't have it both ways.  Your example was a new format VSA
inserted in the middle of a fragmented new format VSA:

>>> finishing that fragment start a new fragment with vendor id 3333

  Any implementation which does that is in violation of this draft.

> out there are important differences between EAP and extensions which
> limit the applicability of this analogy.

  I responded to that.  Since you ignored it, here it is again:

  It's the same thing.  Proxies which are UNAWARE of EAP are permitted
by RFC 2865 to mangle EAP.  This is EXACTLY your argument against this
draft.

  If your best proof is to ignore my counter-arguments, then I think
we're done here.

>>  Doing so will break EAP.  So by your argument, adding EAP to RADIUS
>> is impossible.
> 
> RFC 3579 dictates how EAP-Message may be used.  EAP-Message is not
> defined anywhere else.

  Addressed.  See above.

> The important distinction not accounted for in your analogy is
> extensions further constrains allowed behavior of existing RFCs.  If you
> do this there are consequences with regard to backward compatibility as
> existing implementations can not be made retroactively aware of
> additional constraints.

  Addressed.  See above.

> of a specific attribute type allowed.

  My EAP response appears above.  Limitations in RFCs I haven't read and
haven't implemented don't apply to me.

> I don't follow what was proven false?

  Because you deleted my argument.  See above.

> See above for my thoughts on this EAP-Message analogy.

  Nope.  You haven't addressed my point.

  Your counterpoint was to point at RFC 3579.  I haven't read it.  I've
only read 2865, and implemented proxies based on that.  I've assigned
attribute 79 as my own personal VSA, just like people have done with
241..245.  I've decided to mangle lists of attribute 79.  This is
allowed under 2865.

  Now explain to me how that's different from your arguments against
this draft.  In response, use only 2865.  Don't use 2869 or 3579.  Don't
refer to any real-world experience with the non-EAP/EAP transition.

  You can't have it both ways.  You're arguing against this draft by
pretending it doesn't exist.  You're arguing for EAP by referring to the
EAP specs.

  You're ignoring my counter-argument which uses EXACTLY your method to
prove it's impossible to deploy EAP.  If you're applying a certain
standard, apply it the same way everywhere.  It's not nice to apply it
to me, and then give yourself an exemption.

> compatibility.  My goal is simply providing a good chance of detecting
> the presence of errors.

  Make a concrete proposal.

  And address my points on EAP, without referring to any EAP RFC.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 24 Jan 2012 09:05:26 +0100

Addressed.  See above.

  Addressed.  See above.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 24 Jan 2012 15:04:15 +0100

Peter Deacon wrote:
> I simply meant multiple EAP Packets are not actually sent in single
> RADIUS Messages whereas with extensions it would be allowed and
> expected.

  And again my response: systems which implement the draft are expected
to be compliant with it.  Adding something in the middle of a fragmented
attribute is forbidden by this specification.  So there's no problem.

  For systems *not* implementing this specification, see my previous
arguments.

> My issue is "implementations" are allowed to be conduits for data they
> do not understand and there seem to be insufficient constraints in the
> "protocol" to support extensions.

  See below.  This has happened already with Operator-Name.

> The key to understanding the difference per your query is a separation
> of "protocol" from "implementation" and separation of protocol layers.

  Sure.  RFC 3579 violates RFC 2865.  But people can implement both, if
they do things which are not mandated by 2865.  Like *not* inserting
attributes into a list of unknown attributes.

  Your argument is that the problem comes from a system which does not
implement the extensions draft, but still edits the extension attributes.

  The eduroam consortium has done surveys of precisely this issue in
relation to the Operator-Name attribute.  This survey is discussed in
the extensions draft.  The *real world* problems seen with the erroneous
use of attributes are:

    - filtering unknown attributes (i.e. deleting them from the packet)
    - truncating these attributes
    - discarding the request entirely

  All of these issues can be trivially discovered with the draft as-is.
 The systems which do this are in an absolute minority.  They are *also*
in the process of being updated to support Operator-Name.  When that is
done, they will also trivially support proxying the extensions attrs.

  All possible evidence leads me to conclude that inter-operation with
legacy systems will have minimal problems.

>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |    Length     | Extended-Type |M|   Sequence  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Value ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Sequence
> 
> When Value field of attribute is fragmented into multiple attributes the
> first fragment having M flag set is set to 1 and increased by 1 with
> each subsequent fragment including the final fragment where the M flag
> is clear.
> 
> If a Value field does not span multiple attributes the sequence field is
> set to 1.
> 
> When receiving fragmented attributes sequence field is checked to ensure
> each fragment is received in the proper order.  If there are gaps in
> sequence numbers or fragments are out of order the attribute including
> all fragments are discarded.  An implementation MUST NOT attempt to
> reorder attribute fragments based on sequence.

  That isn't enough.  I can still take two fragmented attributes, and
intermix them undetectable  Take A1..A4, and B1..B4.  Then, change them
to A1,A2,B3,B4 and B1,B2,A3,A4.

  You're assuming that the implementation is aware of this draft, and
chooses to violate it.  So am I.

  If you assume that the implementation isn't aware of this draft, then
the comments about eduroam apply.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 24 Jan 2012 15:04:15 +0100

Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Tue, 24 Jan 2012 04:07:59 -0800 (Pacific Standard Time)

> RFC 2865 to insert one instance of attribute 79 in the middle of a list

Your making an argument since EAP-Message can be inserted anywhere 
including at the start or end of the packet it breaks the EAP RFC but not 
RFC 2865.  This is true.

The same idea applies to extensions.  If you add in the wrong place it 
breaks.  RFC 2865 does not.

>  It's the same thing.  Proxies which are UNAWARE of EAP are permitted by 
> RFC 2865 to mangle EAP.  This is EXACTLY your argument against this 
> draft.

RFC 2865 also says nothing about sending garbage in the Value field of 
attributes defined in other RFCs.

> contradictory, incomplete, and often plain wrong.

This also seems to be true. (Cut from previous message)

>  If your best proof is to ignore my counter-arguments, then I think

I agree with your argument of course it is true.  My concern with this 
line of thinking is examples of broken RFCs and silly what-ifs can be used 
to justify pretty much anything no matter the consequences.  They also 
ignore logical separation of "protocol" from "implementation".  It is not 
enough to respond in the abstract.  The unique details of each situation 
should be closely examined.  This is where EAP-Message and Extensions 
diverge.

You may view my argument as equally silly as the above and therefore no 
different than sending garbage Values or extra EAP-Messages and this is 
fine.

When I said there was only one EAP Packet per RADIUS message it was a 
statement in terms of what actually occurs.  I did not mean to imply that 
RFC 2865 prohibits all harmful effects or that something else couldn't 
throw a wrench into the works.

I simply meant multiple EAP Packets are not actually sent in single RADIUS 
Messages whereas with extensions it would be allowed and expected.  This 
was only intended to be a caution against assuming EAP-Message has the 
same issues and properties as extensions for the purpose of understanding 
potential risks from the perspective of what is observed with existing 
implementations.

> refer to any real-world experience with the non-EAP/EAP transition.

My issue is "implementations" are allowed to be conduits for data they do 
not understand and there seem to be insufficient constraints in the 
"protocol" to support extensions.  As much as reasonable I believe 
extensions rather than "protocol" should be changed to attempt to correct 
the mismatch.

The key to understanding the difference per your query is a separation of 
"protocol" from "implementation" and separation of protocol layers.

Sending garbage values is an "implementation" concern.

Interpreting attribute id's not defined in the "protocol" is not a protocol 
issue.

Ordering constraints are defined in the "protocol".

Allowing a protocol layered on top of an existing "protocol" to modify the 
properties of lower "protocol" is generally best avoided if possible.

     0                   1                   2                   3

Sequence

When Value field of attribute is fragmented into multiple attributes the 
first fragment having M flag set is set to 1 and increased by 1 with each 
subsequent fragment including the final fragment where the M flag is 
clear.

When receiving fragmented attributes sequence field is checked to ensure 
each fragment is received in the proper order.  If there are gaps in 
sequence numbers or fragments are out of order the attribute including all 
fragments are discarded.  An implementation MUST NOT attempt to reorder 
attribute fragments based on sequence.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Tue, 24 Jan 2012 04:07:59 -0800 (Pacific Standard Time)

0                   1                   2                   3

Sequence

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Tue, 24 Jan 2012 12:34:43 -0800 (Pacific Standard Time)

> attribute is forbidden by this specification.  So there's no problem.

Not to sound like a broken record my issue is only with implementations 
that do not support extensions but are expected to interop with systems 
that do.

> the extensions draft.  The *real world* problems seen with the erroneous

Are you able to provide a reference?  The only "Eduoroam" documents I've 
been able to find really seem to be focused on fixing vendor dictionaries 
so that they line up and do not cause requests to be discarded.

Any study that has looked into the issue of behavior of RADIUS 
implementations in detail and current practices of aggregation networks is 
welcome.  I expect we can all appreciate the *real world* encompasses more 
than the sum of our individual experiences.

It is not just RADIUS servers acting as proxies but policy systems and 
intermediate middle boxes that filter process and forward AAA signals to 
do their jobs.

> to A1,A2,B3,B4 and B1,B2,A3,A4.

I previously posted a laundry list of issues that can creep up in an 
"implementation" which does not follow the ordering constraint.  Even with 
all three of the mechanisms I proposed working together there were still 
seemingly unlikely loopholes possible as I pointed out in a follow up 
post.

While I believe there is operational value to at least allowing detection 
of the condition of attributes being removed, reorganized..etc it does 
most likely require something not following 2865 and we all know that road 
leads to absurd crackpot counterexamples of what "could" break even if it 
may be operationally useful.

With the "protocol" described in RFC 2865 sequence is sufficient. When the 
extensions protocol is layered on top of RFC 2865 "protocol" the proper 
constraints exist in 2865 to allow the "extensions protocol" to detect 
insertion when sequence is present or detect nonconsecutive attributes.

Without sequence RFC 2865 is not sufficient to prevent insertion from 
causing undetectable errors.

Note I don't care if it works.  I only care if error is detectable.

> chooses to violate it.  So am I.

Not I.

Yes.

regards.
Peter

---

From: Peter Deacon <[email-masked]>
Date: Tue, 24 Jan 2012 12:34:43 -0800 (Pacific Standard Time)

Not I.

Yes.

regards.
Peter

---

From: Alan DeKok <[email-masked]>
Date: Tue, 24 Jan 2012 23:37:03 +0100

> that do not support extensions but are expected to interop with systems

  See my previous response, which you deleted (again):

  I am aware of this issue.  I have directly addressed it.  Your
response has been to delete my arguments, and to pretend that they don't
exist.

> Are you able to provide a reference?

  The reference is in the draft.  I asked the Eduroam people, and saw
internal eduroam documents.  You can ask them, too.

> implementations in detail and current practices of aggregation networks
> is welcome.  I expect we can all appreciate the *real world* encompasses
> more than the sum of our individual experiences.

  Which is why the draft references Eduroam.  Which is why I repeatedly
referred to real-world experiences.  Your last sentence implies that I
haven't done that, and instead have relied on personal experiences.

> intermediate middle boxes that filter process and forward AAA signals to

  That sentence sounds suspiciously like bafflegab to me.  "policy
systems" and "intermediate middle boxes"?  Really?  What's wrong with
just saying "proxy" ?  Do proxies not implement "policy systems", and
act as "intermediate middle box"?

> "implementation" which does not follow the ordering constraint.  Even
> with all three of the mechanisms I proposed working together there were
> still seemingly unlikely loopholes possible as I pointed out in a follow
> up post.

  i.e. systems which don't implement the draft properly will not be
inter-operable.

  Systems which don't implement the draft at all will behave as we've
seen before.  Problems have been minimal.  We have real-world data, for
both EAP and Operator-Name.

  You've talked about real-world issues.  I'll challenge you to come up
with ONE real-world system which causes the problems you've noted above.
 It must satisfy the following criteria:

  a) NOT implement the draft
  b) act as a RADIUS proxy
  c) NOT violate 2865 by using unassigned attributes

  You'll be hard-pressed to find that, I think.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 24 Jan 2012 23:37:03 +0100

Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Tue, 24 Jan 2012 15:39:26 -0800 (Pacific Standard Time)

I'm exhausted so I must narrow my point to issues which do not require 
surveys or opinion.

RFC 2865 protocol does not prevent insertion.  It only requires order of 
attributes within RADIUS message be maintained.

The constraints of RFC 2865 are therefore NOT sufficient to support the 
extensions protocol as currently written.

As a result if extensions protocol does not explicitly deal with the 
properties of RFC 2865 the extensions protocol can fail in the narrow case 
there is interaction with systems not supporting extensions protocol.

The failure occurs because there is no restriction on where attributes may 
be inserted within a RADIUS message in the RFC 2865 protocol.  The failure 
does not apply to implementations supporting extensions protocol.

I no longer care what the chance of occurrence is.  I only care that this 
case exists and that I have contributed text to resolve it.

I'll let the WG decide what if anything further should be done about it.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Tue, 24 Jan 2012 15:39:26 -0800 (Pacific Standard Time)

regards,
Peter

---

From: Stefan Winter <[email-masked]>
Date: Wed, 25 Jan 2012 09:25:39 +0100

Hello,

> internal eduroam documents.  You can ask them, too.

All our documents are public. We just like to provide them in PDF
format, deeply buried on a website that is not search-engine friendly :-)

For Operator-Name and Chargeable-User-Identity, both of which are
IETF-space attributes, not VSAs, see [1], chapter 3.3 "Introduction of
Additional RADIUS Attributes into eduroam"

Back then we were a bit more enthusiastic than the real world is. Turned
out that Microsoft products in particular simply silently discarded
incoming requests that contained a perfectly valid Operator-Name
attribute. We have since issued an advisory to our Identity Providers
how to patch MS IAS/NPS dictionaries (including fiddling in an MS Access
database, yay!).

The advisory is at [2].

Other servers "helpfully" "fixed" the incoming string and trimmed it to
4 chars because they thought it should be an integer instead (hijacked
attribute definitions by private companies).

This is a backward compatibility issue just as much as the extended
attributes issue is: people who have implemented RADIUS to an older spec
which are unaware of newer additional specs might stumble over the newer
things.

For Operator-Name, silently discarding packets is actually arguably
spec-compliant, because RFC2865 states

"A RADIUS server MAY ignore Attributes with an unknown Type."

The MAY implies: or they may not, and decide to throw it away instead.

That is a "great" property: either throw it away or don't, the protocol
doesn't mind either way. You are compliant, thumbs up. Ecept that
interop goes down the drain.

The underlying problem with this is: *We cannot change the past*. We
have to live with software deployed in the past which might not do what
we would like it to do today. *Nothing* we write in the extended
attributes draft is going to change that!

The only direction we can be looking is forward: tell those who *do*
read the extended attributes spec *today* that they have to be cautious
not to insert attributes in the middle, but do so in the end of the
packet instead.

Yes, there will be incompatibilities with the reality out there. I'm
almost sure someone's code will catch the corner case and insert
attributes wrongly. Too bad.

Our conclusion in eduroam was that we had to introduce active monitoring
to see if a RADIUS server in the infrastructure suffers from the
problem. For Operator-Name, the process is two-stage:

1) send probing Access-Request with invalid credentials, without O-N
2) send probing Access-Request with invalid credentials, without O-N

If 1) is replied to, and 2) isn't, the server has a problem with
Operator-Name.
If both aren't replied to, the server has a more general problem.
If both are replied to, the server is alright.
[we didn't encounter 2) is replied to, but 1) not - this would very
probably mean the server applies some weird policy of only accepting
properly O-N tagged requests]

For extended attributes, if they become vital, we will have to think of
other tests to include into our compliance testing suite. And/or "name
and shame" of the servers which misbehave, so that the vendor might
eventually be inconvenienced to change the behaviour.

Greetings,

Stefan Winter

[1]
http://www.geant.net/Media_Centre/Media_Library/Media%20Library/GN3-10-304%20DJ3.1.2,1%20%20Roaming%20Developments%2024FEB11.pdf

[2]
http://www.eduroam.org/downloads/docs/advisory/eduroamOT-admin-advisory-004.pdf

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Wed, 25 Jan 2012 09:25:39 +0100

Hello,

The advisory is at [2].

Greetings,

Stefan Winter

[1]

[2]

Tel: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Jan 2012 10:44:15 -0500

For what it's worth.
I am not worried if there is an incompatibility between RFC 2865 and
extensions under the following narrow case:

1) There is some attribute x assigned by the extensions document.

2) That document was unassigned prior to extensions

3) Things break if a non-extensions aware implementation inserts an
instance of attribute x.

I think that the issue you are raising falls into this narrow case.  If
so, I think the risk is acceptable and this is not a significant
concern.

If your issue is broader than that, you need to explain it more clearly.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Jan 2012 10:44:15 -0500

For what it's worth.

--Sam