Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-06

From: Alan DeKok <[email-masked]>
Date: Mon, 01 Oct 2012 10:33:19 +0200

Sam Hartman wrote:
> As I understand it, existing RFCs allow a system to reorder attributes
> of the same type.

  Re-ordering is expressly forbidden by RFC 2865, Section 2.3, page 10:

	... The forwarding
      server MUST NOT change the order of any attributes of the same
      type, including Proxy-State.

> So, you send an extensions packet to a non-extensions proxy.  That proxy
> happens to reorder the packets in a manner that some attacker
> understands but that the sending system and final server do not.  This
> is likely to lead to corruption even without an attacker.  IN the
> presence of an attacker, who controlled inputs that got packaged up in
> the fragmented attributes, the attacker may be able to inject a
> fragmented attribute not present in the original packet of the
> attacker's choosing.

  That's possible.  Using a "start fragments" bit would alleviate this.
   Packets which have the bit set (or unset) incorrectly would be
silently discarded.

> I think that if we don't choose to address this issue, it needs to be
> documented in the security considerations section.  I think whether it's
> OK to not address the issue depends on what's out there in the wild. I'm
> happy to defer to Alan and others on that.

  I'd be OK with adding a "start fragments" bit, and adding a sentence
or two in the Security Considerations section discussing why the bit was
added.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 01 Oct 2012 04:16:53 -0400

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

    Alan>   I don't understand that.  Existing systems which are RFC
    Alan> compliant and *not* supporting extensions won't be affected by
    Alan> them.  The extensions attributes use previously undefined
    Alan> numbers.  RFC compliant systems don't touch unassigned
    Alan> attributes.

I think Alan understands this at this point, but for the rest of the WG,
here's what I think the argument is.

As I understand it, existing RFCs allow a system to reorder attributes
of the same type.  That is, a proxy could reorder two type 26 (VSA)
attributes or could reorder two of the new fragmentable attributes.  An
extensions compatible proxy wouldn't do that because the sub-type
distinguishes the attributes.

--Sam

---

From: Stefan Winter <[email-masked]>
Date: Mon, 01 Oct 2012 11:45:45 +0200

Hi,

> fragmented attribute not present in the original packet of the

If the RADIUS proxy itself is the malicious entity, it can inject or
remove any attribute it so likes; whether it's extended attribs or not.

If the attacker is an intermediate IP node, any manipulations would
change the Message-Authenticator attribute, right?

I feel like I'm missing something... could someone enlighten me?

Greetings,

Stefan Winter

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

-- 
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: Alan DeKok <[email-masked]>
Date: Mon, 01 Oct 2012 11:55:35 +0200

> remove any attribute it so likes; whether it's extended attribs or not.

  The issue (I think) is more broken proxies.  e.g. proxies as seen in
Eduroam, which have self-allocated "unused" attributes.

  They expect the self-allocated attributes to be in a particular form.
 They do bad things when they see IETF versions of those attributes.

  My $0.02 is that detecting this is probably a good idea.  Catching
mangled fragments is nice.  Preventing mangled fragments from causing
decode errors is nice.

  But... in general, proxies mangling attributes they don't understand
is stupid.  People running those proxies should upgrade to RFC compliant
RADIUS servers.

  e.g. For years the Merit RADIUS server *explicitly* violated the RFCs.
 Any Proxy-State was treated as an ASCII version of an 8-bit number,
such as "42".  Packets *not* meeting that criteria were mishandled.

  This was an issue for a few years on mailing lists I'm on.  The
solution was always simple: Upgrade to a real RADIUS server.

  People did.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 01 Oct 2012 13:52:48 +0200

Hi,

> Eduroam, which have self-allocated "unused" attributes.

That part I understand; Sam mentioned possible corruption in anbsence of
an attacker.

What I don't understand is the extra complications of an actively
malicious entity which would turn the problem from a "just" interop
problem to a security threat.

Greetings,

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Mon, 01 Oct 2012 14:01:21 +0200

> problem to a security threat.

  I think it's a combination of the two.  An attacker who sends data,
knowing that a broken proxy will mangle the attribute.  He may not have
control over the proxy, but he may know how it works.

  For example, if the attacker knows that a proxy throws away the first
fragment, he can set up the data so that the second fragment falsely
seems to be the first one.  The contents are under his control, and he
can create any VSA he wants.

  It's an admittedly esoteric attack.  But that's what security is about.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 01 Oct 2012 14:24:24 +0200

Hi,

>   It's an admittedly esoteric attack.  But that's what security is about.

Even in this case, doesn't the same reasoning apply? If the entity
before the broken proxy is a RADIUS server or proxy, it has the entire
packet in its hands and can rewrite it to its liking. It doesn't have to
resort to "tricks" to make someone else do the rewrite.

And if it's not a RADIUS entity, Message-Authenticator would prevent the
mangling of anything in the packet en route.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Mon, 01 Oct 2012 08:44:57 -0400

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

    Stefan> Hi,
    >> So, you send an extensions packet to a non-extensions proxy.
    >> That proxy happens to reorder the packets in a manner that some
    >> attacker understands but that the sending system and final server
    >> do not.  This is likely to lead to corruption even without an
    >> attacker.  IN the presence of an attacker, who controlled inputs
    >> that got packaged up in the fragmented attributes, the attacker
    >> may be able to inject a fragmented attribute not present in the
    >> original packet of the attacker's choosing.

    Stefan> If the RADIUS proxy itself is the malicious entity, it can
    Stefan> inject or remove any attribute it so likes; whether it's
    Stefan> extended attribs or not.

    Stefan> If the attacker is an intermediate IP node, any
    Stefan> manipulations would change the Message-Authenticator
    Stefan> attribute, right?

    Stefan> I feel like I'm missing something... could someone enlighten
    Stefan> me?

I'm imagining a phone company exec in the 60's or 70's trying to figure
out why the calls charged to a pay phone sometimes doesn't match the
take from the coin box after physical shrinkage has been removed  as a
factor.
"I feel like I'm missing something," he says.

Your analysis considers attackers along the path of the message, but
ignores attackers producing their 2600 hz tones before the beginning or
after the end.

This is an encapsulation mechanism that can potentially carry untrusted
data.
One of the most serious attacks on systems like that are cases where as
part of the untrusted data  supplied by the attacker can be
re-interpreted as control information for the encapsulation system
itself.

Imagine a malicious Moonshot IDP who knows a proxy re-orders packets.
It can add additional attributes of the appropriate type to the
response.

Similarly if a RADIUS client takes any information supplied by a
potential attacker and sticks it into the fragmented attribute, you can
get problems of this type.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 01 Oct 2012 08:48:08 -0400

Alan> Stefan Winter wrote:
    >> That part I understand; Sam mentioned possible corruption in
    >> anbsence of an attacker.
    >> 
    >> malicious entity which would turn the problem from a "just"
    >> interop problem to a security threat.

    Alan>   I think it's a combination of the two.  An attacker who
    Alan> sends data, knowing that a broken proxy will mangle the
    Alan> attribute.  He may not have control over the proxy, but he may
    Alan> know how it works.

    Alan>   For example, if the attacker knows that a proxy throws away
    Alan> the first fragment, he can set up the data so that the second
    Alan> fragment falsely seems to be the first one.  The contents are
    Alan> under his control, and he can create any VSA he wants.

Or the attacker could just know that the proxy will reorder fragments.
The proxy need not even be broken under the current RFCs.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 01 Oct 2012 14:56:20 +0200

> The proxy need not even be broken under the current RFCs.

  But re-ordering attributes *is* forbidden under current RFCS.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 01 Oct 2012 14:57:52 +0200

> resort to "tricks" to make someone else do the rewrite.

  The issue is a working NAS, which sends valid fragments.  A broken
proxy discards fragment 1.  The attacker knows this, and sends data such
that the contents of fragment 2 are decoded as a VSA.

  The NAS doesn't look at the second fragment, because it's just taking
user data && fragmenting it.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 01 Oct 2012 08:59:49 -0400

Alan> Sam Hartman wrote:
    >> Or the attacker could just know that the proxy will reorder
    >> fragments.  The proxy need not even be broken under the current
    >> RFCs.

    Alan>   But re-ordering attributes *is* forbidden under current
    Alan> RFCS.

OK, then I'm confused.
Peter, can you try and explain your issue more clearly?

---

From: Avi Lior <[email-masked]>
Date: Mon, 1 Oct 2012 10:17:41 -0400

In the case where we are sending a message spanning several packets wouldn't it be prudent to have a message authenticator computed over the entire set.
The last packet would contains the computed authenticator.

---

From: Avi Lior <[email-masked]>
Date: Mon, 1 Oct 2012 10:28:17 -0400

Me too.

Here is what I know:

RADIUS is hop-by-hop and each hop is trusted.
RADIUS "hops" must preserve the order of attributes.

If we are sending messages that span multiple RADIUS packets then the packets can be reordered on purpose or by accident by a man-in-the-middle.  We need to mitigate that.  I suppose sequence numbers on the packet and/or an authenticator computed on the sequence of packets.  ?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 01 Oct 2012 16:45:41 +0200

Avi Lior wrote:
> If we are sending messages that span multiple RADIUS packets 

  We're not saying that in this draft.

  I'd like to avoid that subject, if at all possible.

  Alan DeKok.

---

From: Avi Lior <[email-masked]>
Date: Mon, 1 Oct 2012 10:51:52 -0400

I agree.  I fell into that trap by commenting on the discussion.

That should be a separate document.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 01 Oct 2012 17:04:49 +0200

Hi,

> It can add additional attributes of the appropriate type to the

At least that case is again not specific to the fragmentation problem:
an IdP can send whatever it likes itself; it doesn't have to play tricks
with the next hop.

I assume you are making a point that the RADIUS part of a Moonshot IdP
might rely on information from outside, too, say some SAML-producing
oracle. The oracle, as an outside party to the RADIUS conversation,
could of course produce something large & malicious, that the IdP will
send as a fragmented message, which may in turn be misinterpreted by a
non-aware proxy. Point taken, now I get it :-)

> get problems of this type.

This is symmetrical to the part above, but from the other direction.

Well, both threats exist, so they should be taken into account. Whether
or not it warrants on-the-wire changes or a mention in security
recommendations is enough I don't want to judge.

Greetings,

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Mon, 01 Oct 2012 11:11:27 -0400

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

No, what I'm describing is exactly related to the fragmentation problem.

The IDP sends an assertion longer than 253 octets (quite probable).
The IDP knows which fragment will be dropped/reordered/whatever by the
proxy.
The IDP constructs an assertion such that the assertion will be
interpreted as a different attribute.
The IDP is authorized to send any assertion, but is not authorized to
send other attributes.
Thus, the IDP exceeds its authorization.

All this of course depends on Peter coming back  with an explanation
about how this is possible.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 01 Oct 2012 17:21:43 +0200

Hi,

> Thus, the IDP exceeds its authorization.

Ah, thanks for giving this enlightening example :-)

My gut reaction would be: if the IdP is not authorised to to send a
particular attribute, as a receiver of RADIUS messages from that IdP, I
would enforce this with some filtering policy. Attribute filters for
incoming packets are quite commonly used e.g. in eduroam (strip out VLAN
assignments coming from the IdP).

This is again not directly related to fragmentation: the non-aware proxy
will detect presence of an unauthorized attribute, and strip it. It does
neither know nor care whether the originator constructed it "just like
that" or whether it used a trick to send a non-first fragment that
looked like a valid attribute.

> about how this is possible.

That's true :-)

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Mon, 01 Oct 2012 11:57:39 -0400

Stefan> Hi,
    >> The IDP sends an assertion longer than 253 octets (quite
    >> probable).  The IDP knows which fragment will be
    >> dropped/reordered/whatever by the proxy.  The IDP constructs an
    >> assertion such that the assertion will be interpreted as a
    >> different attribute.  The IDP is authorized to send any
    >> assertion, but is not authorized to send other attributes.  Thus,
    >> the IDP exceeds its authorization.

    Stefan> Ah, thanks for giving this enlightening example :-)

    Stefan> My gut reaction would be: if the IdP is not authorised to to
    Stefan> send a particular attribute, as a receiver of RADIUS
    Stefan> messages from that IdP, I would enforce this with some
    Stefan> filtering policy. Attribute filters for incoming packets are
    Stefan> quite commonly used e.g. in eduroam (strip out VLAN
    Stefan> assignments coming from the IdP).

So, see. The RADIUS server is permitted to send the attribute.  The IDP
is not.  A proxy cannot distinguish IDPs maliciously taking advantage of
the encapsulation mechanism from servers inserting an attribute.

So, no, I think filtering is an entirely inappropriate approach to
fixing a bug in the encapsulation mechanism.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 1 Oct 2012 10:49:11 -0700 (Pacific Daylight Time)

> Peter, can you try and explain your issue more clearly?

Forwarding text and recommendation removal in RFC 2865 only. Does not 
apply to 2138 and 2058.

RFC 2138 3. "Many Attributes may have multiple instances, in such a case 
the order of Attributes of the same Type SHOULD be preserved."

Injection can cause same problems such as applying authorization from 
separate AAA while forwarding.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 01 Oct 2012 22:46:55 +0200

> Forwarding text and recommendation removal in RFC 2865 only. Does not

  Uh... 2865 obseletes 2138, which in turn obseletes 2058.  This is how
the RFC process works.

  And 2865 is 12 years old.  Anyone *not* implementing it deserves what
they get.

> separate AAA while forwarding.

  So... a system which *doesn't* implement an attribute injects it into
a packet?

  Is that right?

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 01 Oct 2012 17:26:54 -0400

At this point I'm not requesting any changes with regard to this issue.

Thanks for a discussion that helped me reach a conclusion.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 1 Oct 2012 19:34:14 -0700 (Pacific Daylight Time)

On Tue, 2 Oct 2012, Emile van Bergen wrote:

> I've long gone into lurking mode, I can't resist now: that type of proxy 
> would incidentially be quite incapable of proxying any real world EAP 
> type.

> Also note that RFC 3579 doesn't list incorrect interpretations due to
> reordered EAP-Message attributes in its security considerations.

I don't want to drag on a conversation that is obviously going nowhere 
fast so this will be my last comment on the subject.  I previously 
discussed the issues with EAP and why it is different from long 
attributes.

Obviously EAP and long attrs share a central concept in common.

There are three differences I believe are important to consider:

1. Long attributes may also be used for authorization and accounting. 
EAP is with trivial exception authentication only.  Long attributes will 
be subject to all kinds of contorted code paths simple EAP forwarding will 
never see.

2.  No more than a single EAP conversation is allowed per packet. 
Multiple long attributes are allowed per packet.  This raises 
possibilities for failures which do not apply to EAP. (You don't see a
'More' flag at the EAP-Message attribute level)  I went thru this 
previously in detail if you want more information check the list archive 
or email me privately.

3. If you inject/mangle order of attributes of EAP end result is virtually 
guaranteed to be authentication failure.  This is a failure mode I would 
happily accept if it were possible with long attributes.  In fact this is 
all I seek...Parity with EAP behavior!!!!  Should something happen I just 
want to make sure it gets detected and allow the whole transaction to go 
down in flames.  We can't make this assumption with long attributes 
because we have no idea of any sort how they will be used.

I have said previously no attempt should be made to reorder attributes if 
they are sent out of order even if sequence numbers were applied and you 
could safely do it.

My goal has only been to detect things which scare me more than 
authentication failure.. corruption and small cracks left open some clever 
individual would be able to manipulate.

> A widely used RADIUS application such as EAP should provide more than 
> sufficient precedent for a concatenation-based solution /without/ 
> additional facilities like sequence numbers.

> The RADIUS data structure is quite elegant if you can see it as a named 
> array of of ordered lists. If you let go of the idea that attributes of 
> the same type are ordered, a lot of what you can build on top sudenly 
> becomes a whole lot uglier. (Filter rules -- EAP -- Extended attribute 
> encapsulation, to name a few recent hot topics).

> The behaviour of the current population of deployed RADIUS servers 
> doesn't seem to warrant that at all, in my humble opinion.

My issue is a matter of perspective and a matter of degree.

We must all look to our experience and knowledge to make a value 
judgment and here I agree with most sentiments which have been expressed.

Yet I also believe it prudent to acknowledge our own lack of visibility 
and error on the side of caution.

With seemingly small possibility of a problem, potentially scary effect 
and something trivial which can be done about it without side effects then 
why not do it?  If the sequence solution is deemed too hard perhaps Alan's 
idea for a start bit would clear out important problems esp with regards 
to VSAs.

http://en.wikipedia.org/wiki/Robustness_principle

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Tue, 02 Oct 2012 09:01:14 +0200

Peter Deacon wrote:
> 3. If you inject/mangle order of attributes of EAP end result is
> virtually guaranteed to be authentication failure.

  The key word is "virtually".   The attacks you describe for long
attributes apply equally well to EAP.

> and something trivial which can be done about it without side effects
> then why not do it?  If the sequence solution is deemed too hard perhaps
> Alan's idea for a start bit would clear out important problems esp with
> regards to VSAs.

  A start bit would allow systems to detect and prevent the attack you
describe.

  I'm looking for a clear statement on this matter.  Throwing up
problems without a conclusion doesn't help us move forward.  The
consensus of the WG seems to be against any change to the spec.

  Can you make an unambiguous statement in favor (or against) the start
bit idea?  And also state whether or not you agree it would address your
concerns?

  I'm OK with adding a start bit to the document.  It is a minor change,
and seems (to me) to completely protect against the attacks you describe.

  I believe that the attacks are due *solely* to misbehaving proxies,
and that this issue has not been seen in practice.  Yet I'm willing to
make a change, because having a robust / secure protocol is a good thing.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Oct 2012 08:40:28 -0400

> consensus of the WG seems to be against any change to the spec.

  There has been no response to that query.  There is therefore no
reason to make any change to the document.

  As has been noted on this list, the alleged attack vector has not been
seen for EAP, even with proxies that are EAP unaware.

  Alan DeKok.