Subject: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 08 Feb 2013 10:21:24 +0100

Hello,

after the valuable comments received from Jim Schaad and Yoshihiro Ohba, 
and further internal discussion, we have uploaded an updated version of 
the RADIUS fragmentation draft.

The most relevant changes include:

  * Fragmentation can only occur after authentication. Clients wanting
    to send large amounts of data can signal this situation on the first
    Access-Request, but the exchange will happen after authentication is
    completed for security reasons.
  * More-Data-Pending is now called Frag-Status, and its functionality
    has been extended to cover other fragmentation signalling (including
    the More-Data-Pending one).
  * Access-Accept fragmentation is based on a series of Access-Accept
    packets, not mixing different types.
  * Security considerations and IANA considerations have been
    significantly improved.
  * The section regarding interaction with EAP has been removed, as it
    does not make sense any more.
  * Included discussion about allowed large packet size and its security
    implications.
  * Included discussion about unsupported packet types (i.e. accounting
    and CoA) and the rationale behind that decision.

Regards,
Alejandro

-------- Mensaje original --------
Asunto: 	New Version Notification for 
draft-perez-radext-radius-fragmentation-05.txt
Fecha: 	Fri, 08 Feb 2013 01:01:48 -0800
De: 	[email-masked]
Para: 	[email-masked]
CC: 	[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked]

A new version of I-D, draft-perez-radext-radius-fragmentation-05.txt
has been successfully submitted by Alejandro Perez-Mendez and posted to the
IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 05
Title:		 Support of fragmentation of RADIUS packets
Creation date:	 2013-02-08
WG ID:		 Individual Submission
Number of pages: 27
URL:             http://www.ietf.org/internet-drafts/draft-perez-radext-radius-fragmentation-05.txt
Status:          http://datatracker.ietf.org/doc/draft-perez-radext-radius-fragmentation
Htmlized:        http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-05
Diff:            http://www.ietf.org/rfcdiff?url2=draft-perez-radext-radius-fragmentation-05

Abstract:
    This document describes a mechanism providing fragmentation support
    of RADIUS packets that exceed the 4096 bytes limit.

The IETF Secretariat

---

From: Sam Hartman <[email-masked]>
Date: Sun, 10 Feb 2013 08:54:53 -0500

Hi, Alex.

With my draft-ietf-abfab-aaa-saml hat on, I have a problem with one of
the proposed changes:

  * Fragmentation can only occur after authentication. Clients wanting to send
    large amounts of data can signal this situation on the first
    Access-Request, but the exchange will happen after authentication is
    completed for security reasons.

Unfortunately some of the use cases for SAML involve looking at the SAML
request to determine what authentication would be acceptable.  As an
example, we need to look at the LOA to determine what EAP methods are
acceptable.

As such, we do actually need to be able to send things like SAML
requests prior to authentication.

So, I'd like to better understand the reasons for this change.
If it's DOS concerns, I would prefer to revert the change and  simply
note the concern in security considerations.

Also, from a DOS standpoint, since the entity being authenticated is the
user, not the NAS, I'd like to understand how you're better off from a
DOS standpoint after authentication.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Sun, 10 Feb 2013 10:10:04 -0500

> note the concern in security considerations.

  It's partly DoS.  The issue of the NAS sending large amounts of data
to the home server is an issue.  If it's for a trusted user, OK.  If
it's for an unknown user, it's not OK.

  i.e. even if the NAS only sends 10K of data, attackers can open up
thousands of unauthenticated connections, and potentially DoS the server.

> DOS standpoint after authentication.

  It reduces the attack profile.  The issue of large volumes of
authentication data is limited to (a) trusted NASes, and (b) known users.

  The other issues are packet size, and changes to existing EAP
processing.  EAP already largely fills RADIUS packets.  Adding SAML data
means that any UDP packet will be fragmented.  It will then fail to
cross the wider net.  TCP / TLS doesn't have this problem, of course.

  The EAP processing issue is about synchronization.  The EAP-Success
needs to be in the Access-Accept.  If the NAS is sending large amounts
of data, it may overflow the initial sequence of packets.  So... does
the data get fragmented to the post-authentication stage?  Will the NAS
continue trying to send more data after EAP-Success?  Will the server
send EAP-Success in an Access-Challenge, and continue asking for the data?

  It's not clear what's best here.

  Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 11 Feb 2013 11:00:42 +0100

> example, we need to look at the LOA to determine what EAP methods are
Hi Sam,

do you expect this data to be so large that makes the first 
Access-Request packet to exceed the limit? It is not avoiding SAML data 
to be on the packet, just avoiding the use of fragmentation for security 
reasons. When using EAP, the first Access-Request is usually small, as 
it only contains EAP-Identity. Hence, almost 4KB would be available for 
SAML data.

Regards,
Alejandro

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 11 Feb 2013 06:39:19 -0800

I just created a really simple one, and it was less than 1K in size.
However, this assumes that it is not signed.  If you sign it then it will
quickly jump in size as you are going to be looking at have a certificate
and a signature included in the message which will likely be greater than
4K.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alejandro Perez Mendez
> Sent: Monday, February 11, 2013 2:01 AM
> To: Sam Hartman
> Cc: [email-masked]; [email-masked]
> Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-radext-
> radius-fragmentation-05.txt
> 
> 
> > Hi, Alex.
> >
to
> send
> > Unfortunately some of the use cases for SAML involve looking at the
> > SAML request to determine what authentication would be acceptable.  As
> > an example, we need to look at the LOA to determine what EAP methods
> > are acceptable.
> Hi Sam,
> 
> do you expect this data to be so large that makes the first Access-Request
> packet to exceed the limit? It is not avoiding SAML data to be on the
packet,
> just avoiding the use of fragmentation for security reasons. When using
EAP,
> the first Access-Request is usually small, as it only contains
EAP-Identity.
> Hence, almost 4KB would be available for SAML data.
> 
> Regards,
> Alejandro
> 
> > Also, from a DOS standpoint, since the entity being authenticated is
> > the user, not the NAS, I'd like to understand how you're better off
> > from a DOS standpoint after authentication.
> >
> > --Sam
> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 11 Feb 2013 07:35:39 -0800

It is true that a certificate is not needed, however in the cases that we
are looking at - cross-organization requests - it will be more likely to
want to include it than not.  Otherwise you have a much harder problem of
supporting referring to and fetching the certificate in order to validate
the signature. That said, I would hope that it would be possible to not do
any signatures at all.  I just don't know that it is realistic to require
that the signature be omitted.

jim

> From: Cantor, Scott [mailto:[email-masked]]
> Sent: Monday, February 11, 2013 7:13 AM
> To: Jim Schaad; 'Alejandro Perez Mendez'; 'Sam Hartman'
> On 2/11/13 9:39 AM, "Jim Schaad" <[email-masked]> wrote:
> 
> >However, this assumes that it is not signed.  If you sign it then it
> >will quickly jump in size as you are going to be looking at have a
> >certificate and a signature included in the message which will likely
> >be greater than 4K.
> 
> You don't have to include a certificate to sign a message, though.
> 
> Not that it isn't large anyway, but it's not impossible to stay under 4k
even
> when signing.
> -- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 11 Feb 2013 15:12:33 +0000

even when signing.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Feb 2013 08:15:12 -0500

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

    Alan>   It's partly DoS.  The issue of the NAS sending large amounts
    Alan> of data to the home server is an issue.  If it's for a trusted
    Alan> user, OK.  If it's for an unknown user, it's not OK.

OK.
I'm confused, because the NAS is sending data for itself in the cases
where we're talking about.
If the data is being sent by the user, I'd expect it to be in the EAP
stream.
The cases I at least am contemplating here are where the NAS wants to
send data about what it requires etc.

    Alan>   i.e. even if the NAS only sends 10K of data, attackers can
    Alan> open up thousands of unauthenticated connections, and
    Alan> potentially DoS the server.

Attackers who have any valid account could probably do the same.

    >> Also, from a DOS standpoint, since the entity being authenticated
    >> is the user, not the NAS, I'd like to understand how you're
    >> better off from a DOS standpoint after authentication.

    Alan>   It reduces the attack profile.  The issue of large volumes
    Alan> of authentication data is limited to (a) trusted NASes, and
    Alan> (b) known users.

Although this is also limited to trusted NASes.
The question is whether known user vs unknown user makes a difference
for data between NAS and home server.

    Alan>   The other issues are packet size, and changes to existing
    Alan> EAP processing.  EAP already largely fills RADIUS packets.
    Alan> Adding SAML data means that any UDP packet will be fragmented.
    Alan> It will then fail to cross the wider net.  TCP / TLS doesn't
    Alan> have this problem, of course.

my assumption is that if you were sending access-accept saml auth data
you'd do it before you started EAP.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Tue, 12 Feb 2013 09:22:12 -0500

> where we're talking about.

  The issue is that the NAS sends data on behalf of the user.  Even if
the user is unknown.  So attackers can leverage the NAS to send large
amounts of data.

> Attackers who have any valid account could probably do the same.

  Yes.  But that allows a negative feedback effect.  You call the known
person and tell them to stop attacking you.

> for data between NAS and home server.

  I think it does.  It lowers the attack profile.

> you'd do it before you started EAP.

  I'm wary of that approach.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Feb 2013 07:42:50 -0800

Let me ask a potentially stupid question:

Why can't we send a URL pointing to the {SAML Assertion, Certificate} instead of sending the data itself?

This is what was done in IKE to avoid fragmentation.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 12 Feb 2013 10:59:27 -0500

> instead of sending the data itself?

  Sure.  That may work.  Sometimes.

  The RADIUS system may not be publicly accessible.  So any web server
has to be located somewhere else.  And the RADIUS server needs a way to
talk to it.  Or, the firewall rules need to be updated to allow
non-RADIUS requests to make it to the RADIUS server.

  And this has to be bi-directional, as both ends of the RADIUS
conversation want to send large amounts of data to each other.

  I think the simplest answer is that RADIUS systems use RADIUS to
exchange RADIUS data.  Doing anything else requires talking to
non-RADIUS people, which is hard.

  The downside of this draft is that some RADIUS implementations need to
change.  But they'd have to change *anyways* to use any URL scheme.

  Another issue is proxies.  Some proxies are required to mangle the
data they pass, for inter-operability reasons.  Using RADIUS lets them
do this.  Using URLs means thet they either have to ignore the URL, or
re-host it themselves.

  Relying on non-RADIUS systems means added complexity, and dependence
on external systems.  The RADIUS process becomes more fragile.

> This is what was done in IKE to avoid fragmentation.

  I think the IPSec boxes are already "public" on the net.  Requiring
them to be closely tied to a public web server may be a simple step.

  Alan DeKok.

---

From: Gabriel López <[email-masked]>
Date: Tue, 12 Feb 2013 17:19:31 +0100

El 12/02/13 17:07, Cantor, Scott escribió:
> On 2/12/13 10:42 AM, "Bernard Aboba" <[email-masked]> wrote:
>
> In addition to all of Alan's comments, there's the fact that you have to
> secure the exchange over the URL, or punt and rely on artifact-style
> short-lived references as a replacement for securing it.
And probably sometimes, URL making use of HTTP+TLS negotiation could
require more roundtrips than fragmented attributes.

-- 
----------------------------------------------------------------
Gabriel Lpez Milln
Departamento de Ingeniera de la Informacin y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Feb 2013 11:41:36 -0500

>>>>> "Bernard" == Bernard Aboba <[email-masked]> writes:

    Bernard> Let me ask a potentially stupid question: Why can't we send
    Bernard> a URL pointing to the {SAML Assertion, Certificate} instead
    Bernard> of sending the data itself?

Hi.
First, I'm a little nervous about a SAML specific proposal.
In Kerberos, we found that even with compact representations of
authorization data, when people really start taking advantage of dynamic
authorization, the authorization data can get large.
Kerberos ended up choosing to use TCP to solve its fragmentation issues.

I suspect that SAML is only the most discussed use case for a
fragmentation solution.
However, let's explore URIs for SAML.

    so, several of us do not want to assume a PKI shared between the NAS
    and the home AAA server.
That is, we want to bootstrap our trust based on the AAA fabric.
(Note that some subset of that us wants to do interesting things to
    bootstrap AAA trust, but that also fails to involve a PKI).

SAML assertions are not always public.
That is, we may be unwilling to disclose  a SAML assertion without
authorization.

So, we need to accomplish the following:

1) Prove authorization to get the SAML assertion

2) Protect the integrity of the SAML assertion

3) Provide optional confidentiality for the SAML assertion. (several of
us want to use SAML with RADSEC)

In addition, in several of these cases, the SAML assertion is generated
as a dynamic artifact of the authentication, so you have to introduce
the complexity  of storing the SAML assertion for a while.

URLs aren't very good at providing confidentiality and integrity unless
you happen to share a PKI in common with the authority referenced in the
URI.

It's possible to design a solution based on references that meets these
constraints.  I think we discussed that in ABFAB, and that's definitely
not where we ended up.

I think that if someone wants to pursue a URI-based approach it would be
best to have a concrete proposal on the table.
Possibly something that included a URI and a hash of the content.
Except that alone is not good enough because if knowing the URI is the
authorization to get the assertion, how do you provide authentication of
the server prior to disclosing the URI without depending on a shared
PKI?

--Sam

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 12 Feb 2013 16:07:03 +0000

-- Scott