Subject: [abfab] 4K limit

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Fri, 25 Nov 2011 12:41:58 +0100

Hi,

Thinking about the 4K limit in the RADIUS payload and the four options outlined by Josh and the discussion we had in Taipei, I guess we could have a fifth option: the use of multi-packet RADIUS sessions to transfer SAML data when the payload limit is reached. This will keep us in RADIUS space and allow for arbitrary long SAML messages. Of course, this would be an optional behavior, keeping the current (one SAML message in one RADIUS packet) as the default, mandatory, one. This approach could even be usable in other potential cases where the 4K payload limit may become an issue.

From the SAML RADIUS binding point of view this would imply to allow the use of several SAML messages. In principle, several AuthN statements related to the same NAI and containing the corresponding attributes.The RADIUS client / SAML RP would have to deal with them as a single statement

From the RADIUS protocol point of view I see two possible options: making the server to send successive Access-Challenge responses with the corresponding SAML messages, or defining a new RADIUS packet type. The first option has the advantage of being easier to implement, though it implies stretching (probably too much) the semantics of the challenge loops.

There is of course a lot to ellaborate to make this a viable solution and I can volunteer to start writing something more detailed if the group thinks this idea makes any sense.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:      +34 913 129 041
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Alan DeKok <[email-masked]>
Date: Fri, 25 Nov 2011 16:17:39 +0100

> From the RADIUS protocol point of view I see two possible options: making the server to send successive Access-Challenge responses with the corresponding SAML messages, or defining a new RADIUS pac…

  It involves some serious changes to RADIUS servers and clients.

  For this to work at *all*, it would have to be done via
Access-Challenge.  These will pass through intermediate proxies.  Any
new RADIUS packet code will be dropped by nearly everyone.

> There is of course a lot to ellaborate to make this a viable solution and I can volunteer to start writing something more detailed if the group thinks this idea makes any sense.

  You'll have to pass it by radext.  That review traditionally takes a
while.

  An alternative that's been discussed has been to relax the 4K packet
size limit for RADIUS over TCP.  TCP doesn't have fragmentation issues
like UDP, which makes it easier to increase the packet size.

  Another alternative is to stop using RADIUS for bulk data transfer. :)
 Instead, put the data somewhere..., and have the client somehow... get
it via another protocol.

  Alan DeKok.

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sat, 26 Nov 2011 00:54:19 +0100

> new RADIUS packet code will be dropped by nearly everyone.

That's a good point to make the decision for a type of packet. Access-Challenge would be.

>  You'll have to pass it by radext.  That review traditionally takes a

I did not hope it to be a quick process anyway. If we decide to go this way there are some partial solutions (like requesting the SAML message to be compressed in the RADIUS attribute) that would buy us some time.

> like UDP, which makes it easier to increase the packet size.

This alternative would be ideal, as long as
(1) It is likely to be accepted and implemented.
(2) We are talking about not having any packet size limit, what I'd say would match with "TCP style"
What's you opinion on this? Would ABFAB help in building the case for it?

> Instead, put the data somewhere..., and have the client somehow... get

This has been suggested as one of the alternatives, since SAML provides this capability through so-called artifacts, But the ABFAB authentication mechanism is intended (as far as I can tell) to avoid the need of a second trust framework out of the AAA. An additional protocol to get attributes would require this second trust framework.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:      +34 913 129 041

---

From: Alan DeKok <[email-masked]>
Date: Sat, 26 Nov 2011 11:40:28 +0100

> (1) It is likely to be accepted and implemented.

  There have bee a number of discussions about extending the 4K limit
for RADIUS over TCP.  So the possibility of acceptance is there.
Implementations will follow.

> (2) We are talking about not having any packet size limit, what I'd say would match with "TCP style"

  There will still be a limit of 64K, due to the RADIUS protocol headers.

> What's you opinion on this? Would ABFAB help in building the case for it?

  Yes.  Having use-cases means it's easier to standardize something.

  Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 28 Nov 2011 12:16:49 +0100

>  From the RADIUS protocol point of view I see two possible options: making the server to send successive Access-Challenge responses with the corresponding SAML messages, or defining a new RADIUS pa…

Hi Diego, all,

we have been discussing this topic internally, and we see another 
alternative for this. We could define a new RADIUS attribute which 
indicates the total length of the SAML Message to be received (for 
example, we could call it SAML-Message-Length). This attribute would be 
included in the first RADIUS message containing SAML-Message attributes.

When the RP receives this attribute, it knows how many SAML data is 
expected from the AAA/IdP and therefore, if the total length of the 
received SAML-Message attributes is less than expected, it means that 
the message has been truncated and that more data is to be retrieved.

Then the RP would send an Access-Request message to the AAA/IdP 
requesting more data. The AAA/IdP replies with more SAML-Message 
attributes. As the RP already knows how many data is to be received, 
this process is repeated until the whole SAML message has been received.

It has to cost of defining a new RADIUS Attribute, but the advantage 
that it does not modify the RADIUS or SAML protocols.

What do you think? Do you think it is reasonable? We could elaborate a 
more detailed description if you find it interesting.

Regards,
Alejandro

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Nov 2011 13:10:38 +0100

> included in the first RADIUS message containing SAML-Message attributes.

  That could work.  I'm concerned about the possibility of conflict.
i.e. the first packet says "10K SAML data", but the total length of the
SAML data is != 10K.

> the message has been truncated and that more data is to be retrieved.

  It would be simpler I think to just have an attribute saying "more
SAML data".  If it's in an Access-Accept, the client asks for more data.
 That means that the processing flow is the same for the first
Access-Accept, and for any subsequent Access-Accepts.

> this process is repeated until the whole SAML message has been received.

  That could work...

> that it does not modify the RADIUS or SAML protocols.

  There are additional issues not discussed here.

  How do you tie the packets together?

> more detailed description if you find it interesting.

  What is already done is to use "Service-Type = Authorize-Only".  See
RFC 5080 for a discussion.

- user authenticates
- final Access-Accept contains a State attribute
- final Access-Accept contains an attribute "more SAML data"

- NAS sends new Access-Request (somehow) tied to the original session
- this Access-Request contains
  Service-Type = Authorize Only
  State from original Access-Accept
- server replies with Access-Challenge / Access-Accept
- packets contain SAML data
- if the reply is an Access-Challenge, the NAS sends
  another Access-Request

  Similar things are done already with Access-Request and
Authorize-Only.  So that behavior falls within the context of existing
RADIUS practices.

  The only new thing here is the use of Access-Challenge in this context.

  My $0.02 is that this mechanism for transporting bulk authorization
data in RADIUS should be defined separately from it's use in SAML.
There have been enough requests over the years for this that others will
find it useful, too.

  Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 28 Nov 2011 14:30:15 +0100

Hi Alan,

thanks for you quick response. Our mail was just a first attempt to 
provide a solution. I agree that some details were not described, or 
even thought. See my comments below.

> i.e. the first packet says "10K SAML data", but the total length of the

Right, that kind of situations must be avoided. Anyway, the AAA server 
would discard or send an error message on any Access-Request received 
when no additional SAML data is to be sent.

> Access-Accept, and for any subsequent Access-Accepts.

Yes, that would also work.

>    How do you tie the packets together?

As you say below, the State attribute would do the work. Additionally, 
the "more SAML data" could contain a reference, and be included in the 
following Access-Request message. Though I think the State attribute 
would be enough.

> - final Access-Accept contains an attribute "more SAML data"
-final Access-Accept contains a Termination-Action attribute with the 
value of RADIUS-Request

> - if the reply is an Access-Challenge, the NAS sends

Yeah, we had in mind something very similar.

>    The only new thing here is the use of Access-Challenge in this context.

Another alternative would be the following: after the "more SAML data" 
attribute is sent, instead of performing several 
Access-Request/Access-Challenge roundtrips, perform several 
Access-Request/Access-Accept(more-SAML-data) roundtrips. I don't know if 
this procedure would go against something in the standards.

Regards,
Alejandro

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Nov 2011 14:45:12 +0100

> following Access-Request message. Though I think the State attribute

  It would be preferable, but not enough.  The packet needs to be routed
through a proxy chain, so it needs to contain a User-Name attribute.

> -final Access-Accept contains a Termination-Action attribute with the

  I'm not sure I'd do that.  Termination-Action is for *terminating* the
service.  In your use-case, service would continue, but more SAML
authorization attributes would be needed.

  Instead, the first Access-Accept could contain "Service-Type =
Additional-Authorization".  This would be a new value indicating that
additional authorization is required for the user.

  The NAS would then send requests for more data, as discussed earlier.
 The final Access-Accept would contain an updated Service-Type, for the
users real service.

> this procedure would go against something in the standards.

  I think using Access-Challenge would be better.

  Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 28 Nov 2011 15:36:40 +0100

> through a proxy chain, so it needs to contain a User-Name attribute.

you are right. I was just assuming that the User-Name was already there.
> authorization attributes would be needed.

RFC says, in regard with the State attribute:

          This Attribute is available to be sent by the server to the client
           in an Access-Challenge and MUST be sent unmodified from the client
           to the server in the new Access-Request reply to that challenge,
           if any.
    This Attribute is available to be sent by the server to the client
           in an Access-Accept that also includes a Termination-Action
           Attribute with the value of RADIUS-Request.

So I understood that if State attribute is sent within an 
Access-Request, then Termination-Action is required.

> additional authorization is required for the user.

But then it is required to define a new Service-Type value. Service-Type 
is not mandatory, would it be better to just not including it in the 
first Access-Accept? The "more SAML data" should be enough to indicate that.

Regards,
Alejandro

---

From: Sam Hartman <[email-masked]>
Date: Mon, 28 Nov 2011 10:04:39 -0500

I'm generally in favor of exploring both relaxing the 4k limit and/or
defining a mechanism so that SAML attributes can be spread across
multiple messages.

I'm not generally in favor of defining a generic radius fragmentation
message.

My concern about using another protocol besides RADIUS to retrieve the
SAML is that you'll have proxy, firewall and credentialing issues with
that other protocol.  I think we'll run into as much fun getting our
other protocol through as we would a new RADIUS message type even if the
other protocol is HTTP.  That
said, I definitely think a different protocol is preferable to a new
RADIUS message type.

--Sam

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 28 Nov 2011 15:21:32 +0000

>I'm not generally in favor of defining a generic radius fragmentation

Obviously I want to see the limit dealt with, but I would note that SAML
is not the issue here, the user data is. The XML framing is not a
significant source of size, and the problem won't be any different with
JWT.

-- Scott

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Nov 2011 16:38:14 +0100

> RFC says, in regard with the State attribute:
...
> Access-Request, then Termination-Action is required.

  I'm not sure that's required.  I know I've *rarely* seen a
Termination-Action when there's a State in Access-Accept.  So I wouldn't
worry about it too much.

> first Access-Accept? The "more SAML data" should be enough to indicate that.

  The issue for me is a *generic* way of handling this.  A "more SAML
data" thing is specific to SAML.

  Alan DeKok.

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 28 Nov 2011 16:44:37 +0100

> significant source of size, and the problem won't be any different with

Agreed. As far as I can tell, we are talking about how to spread user identity data required for authorization into several RADIUS messages (and necessarily in several RADIUS atributes). The precise format of the identity data is immaterial.

And looking at how the thread is evolving I think that the ideas are converging…

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:      +34 913 129 041
Mobile: +34 682 051 091

---

From: Sam Hartman <[email-masked]>
Date: Mon, 28 Nov 2011 10:46:42 -0500

>>>>> "Cantor," == Cantor, Scott <[email-masked]> writes:

    Cantor,> On 11/28/11 10:04 AM, "Sam Hartman" <[email-masked]> wrote:
    >> I'm generally in favor of exploring both relaxing the 4k limit
    >> and/or defining a mechanism so that SAML attributes can be spread
    >> across multiple messages.
    >> 
    >> I'm not generally in favor of defining a generic radius
    >> fragmentation message.

    Cantor,> Obviously I want to see the limit dealt with, but I would
    Cantor,> note that SAML is not the issue here, the user data is. The
    Cantor,> XML framing is not a significant source of size, and the
    Cantor,> problem won't be any different with JWT.

OK, well, I'm happy with the direction Alan is going in  which seems to
be a service type related to user data.
What I didn't want was something at the radius messaging layer so deep
in tchanging RADIUS that it could never get standardized.

---

From: Josh Howlett <[email-masked]>
Date: Mon, 28 Nov 2011 15:53:51 +0000

>Yeah, we had in mind something very similar.

Likewise. I was going to propose something very similar to this for the
Abfab Assertion Request Profile, so that the RP is able to obtain an
assertion from an IdP at some point after authentication.

I'd like to use the same mechanism for both post hoc assertion request and
delivery of jumbo assertions (where delivery of a jumbo authentication
assertion is essentially the case where the assertion is not necessarily
solicited and happens immediately after authentication.

So I think we should try to decouple the RADIUS/EAP authentication
roundtrips from the RADIUS/SAML assertion roundtrips, modulo some
mechanism to tie these together.

There's another wrinkle that hasn't been discussed, which is that the SAML
Request may also be larger than 4K. So we really need to deal with jumbo
messages in both directions, which makes this even more interesting
although I think that Alejandro's proposal works in this case.

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Nico Williams <[email-masked]>
Date: Mon, 28 Nov 2011 11:52:08 -0600

Note that this would result in a synchronous round trip for every 4KB
of data.  That could get painful.  It'd be preferable to burn a round
trip on negotiation of large packets, no?

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 28 Nov 2011 18:02:22 +0000

>trip on negotiation of large packets, no?

I think in practice >4K is rare, >8K is even rarer, etc. You won't have
much benefit from burning a round trip ahead of time.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Mon, 28 Nov 2011 13:10:14 -0500

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> Note that this would result in a synchronous round trip for
    Nico> every 4KB of data.  That could get painful.  It'd be
    Nico> preferable to burn a round trip on negotiation of large
    Nico> packets, no?
For Moonshot, relaxing the 4k limit for TCP definitely seems more
    Nico> attractive.
We're often going to have a very few number of proxies involved.

For general RADIUS, it's more complex because there's not really a good
way to engage the proxies in negotiation.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Nov 2011 19:24:21 +0100

Nico Williams wrote:
> of data.  That could get painful.

  RADIUS isn't TCP. :(

>  It'd be preferable to burn a round

  Which is likely to work in many fewer situations.

  How can a NAS negotiate large packets through multiple layers of
proxies?  RADIUS is designed to be point to point (security, proxying,
etc.)  So any multi-hop negotiation is doomed to failure from the start.

  Alan DeKok.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 28 Nov 2011 13:33:13 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Josh Howlett
> Sent: Monday, November 28, 2011 7:54 AM
> To: Alejandro Perez Mendez; Alan DeKok
> Cc: [email-masked]
> Subject: Re: [abfab] 4K limit
> 
> >
Abfab
> Assertion Request Profile, so that the RP is able to obtain an assertion
from
> an IdP at some point after authentication.
> 

I think that in general one can deal with this by forcing the RP to make
multiple requests rather than a single request in this case.

However I also have an item which was discussed some months ago but has not
reared its head again.  That is that there may be a proxy in the middle that
wants to do some re-writing of the SAML messages in both directions.  This
would be for the purpose of changes attribute names so that a common mapping
does not need to be understood by either end but just by the proxy in the
middle.  This means that we need to be thinking of the proxy suddenly become
the server/client of the fragmented message or becoming the service that is
going to provide/ask for the OOB query method.  

Jim

> 
> Josh.
> 
> 
> 
> JANET(UK) is a trading name of The JNT Association, a company limited by
> guarantee which is registered in England under No. 2881024 and whose
> Registered Office is at Lumen House, Library Avenue, Harwell Oxford,
Didcot,
> Oxfordshire. OX11 0SG
> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Sam Hartman <[email-masked]>
Date: Mon, 28 Nov 2011 16:52:45 -0500

I think your proxy use-case argues for doing this in-band with RADIUS
so you get the same proxy chain no matter what is going on.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 29 Nov 2011 09:10:29 +0100

> solicited and happens immediately after authentication.

Agree

> mechanism to tie these together.

How are you thinking decoupling them? Performing the RADIUS/EAP as usual 
(not SAML related data), and let the RP to start afterwards an 
"assertion request process" to obtain the authentication assertion?

> although I think that Alejandro's proposal works in this case.

We also discussed this. Although a jumbo SAML Request is possible, it 
would be really unlikely. The main reason to really think about jumbo 
SAML messages was, I think, that it is impossible to foresee the amount 
of SAML Attributes that will be included in the Response. The request, 
however, should not be that big if certificates are not included on it 
(as pointed out by Scott). Anyway, I agree that, to avoid problems in 
the future, we provide for this functionality.

I think that the "more SAML data" attribute proposed by Alan would work 
also if included in requests. In such a case, the AAA/idP could send an 
Access-Challenge message (including User-Name and State attributes, for 
example), waiting for more data to come from the RP.

Additionally, the "more SAML data" could contain some kind of "cookie" 
or "nonce" value, in such a way that if returned unmodified in the 
following Request/Response message to the creator, it allows to tie all 
the messages within a conversation, if other means (e.g. State 
attribute) are finally not enough or not applicable.

Regards,
Alejandro

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 29 Nov 2011 18:55:55 +0100

> example), waiting for more data to come from the RP.

As Alan noted, we should aim for a more general name for the attribute. Though the exchange of SAML data is the main (and probably unique, at least for the moment) use case, I don't see any hurt in using something like "more additional data" or "more external data" or "more authorization data"...

> attribute) are finally not enough or not applicable.

Indeed. I think it would provide not only this tying mechanism, but also the possiblity of using it to point the conversation (and the subject of the data being exchanged) to the elements providing those additional authorization data, and I guess this could satisfy what Josh called the decoupling of the authentication and assertion roundtrips.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:      +34 913 129 041
Mobile: +34 682 051 091