Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 03 Nov 2011 13:29:45 +0100

Hi Josh,

I have some few comments regarding version -02 of the aaa-saml draft. 
Mostly typos.

0. Abstract

  * "...RADIUS attribute, binding and two..:" -> "RADIUS attribute, a
    binding and two..."

1. Introduction

  * In the 3er paragraph it is mentioned Diameter, while it is not
    mentioned again in the rest of the document. Indeed, it is a
    RADIUS-specific document.

3. RADIUS SAML-Message Attribute

  * Length should be >=3, not >=4, since it is stated in the text that
    Message field can have one or more octets (see description of
    User-Name attribute in RFC 2865 for a similar attribute).
  * I have a question related with the RADIUS maximum packet size. RFC
    2865 states that the maximum size is 4096 bytes. That means that if
    an SAML Assertion would be bigger than 4K, it would be impossible to
    transport it in a single RADIUS message. Even without signatures, a
    SAML Assertion containing attributes may exceed this size if the
    attributes contains data enough. Have you thought about any
    mechanism to lead with this kind of situations, for example the use
    of a Hash&URL or similar?

5.3.2

  * "The Relying Party, on receiving the EAP-Response/Identity message
    from the User Agent, MUST send it towards the Identity Provider
    using the SAML RADIUS binding" -> Did you mean RADIUS EAP, or is
    SAML RADIUS binding intended to transport EAP messages?

5.4.1

  * "If the Relying Provider wishes to..." -> "If the Relying Party
    wishes to..."

5.4.2

  * "Provider is NOT obligated to honor the requested set of in the
    <samlp:AuthnRequest>, if any." -> Something missing between "set of"
    and "in the".

5.4.3

  * "Verify that the InResponseTo attribute in the bearer
    <saml:SubjectConfirmationData>" -> Shouldm't it be "sender-vouches"
    instead of "bearer"?

Regards,
Alejandro

> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF.
>
> 	Title           : A RADIUS Attribute, Binding and Profiles for SAML
> 	Author(s)       : Josh Howlett
>                            Sam Hartman
> 	Filename        : draft-ietf-abfab-aaa-saml-02.txt
> 	Pages           : 14
> 	Date            : 2011-10-31
>
>     This document specifies a RADIUS attribute, binding and two profiles
>     for the Security Assertion Mark-up Language (SAML).  The attribute
>     provides RADIUS encapsulation of SAML protocol messages, while the
>     binding describes the transport of this attribute, and the SAML
>     protocol messages within, using RADIUS.  The profiles describe the
>     application of this binding for Abfab authentication and assertion
>     query/request.  The SAML RADIUS attribute and binding are defined
>     generically to permit application in other scenarios, such as network
>     access.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Gabriel López <[email-masked]>
Date: Thu, 03 Nov 2011 14:09:58 +0100

Let me add an additional comment:

I wonder about the requirement of not signing the SAML assertion. Maybe
it requires a more detailed analysis.
First, if the SAML assertion is generated by a legacy idP then it should
discriminate between requesters (the RADIUS server in this case) and to
decide not to sign the assertion issued for this entity. It could be ok,
but I think should be explicitly described in the text. Other option is
to allow the RADIUS server cuts short the assertion and to remove the
XML signature, but I don't like this.
Second, you have to take into account that the SAML assertion will be
for a one-time use and it could not be managed/validated by a third
party. Let's think in a scenario where the received assertion is used
later on to request other end user attributes and the original SAML
assertion should be first validated in order to check validity.

Best regards, Gabi.

El 03/11/11 13:29, Alejandro Perez Mendez escribió:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Application Bridging
>> for Federated Access Beyond web Working Group of the IETF.
>>

-- 
----------------------------------------------------------------
Gabriel L?pez Mill?n
Departamento de Ingenier?a de la Informaci?n y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: Luke Howard <[email-masked]>
Date: Fri, 4 Nov 2011 00:10:20 +1100

> First, if the SAML assertion is generated by a legacy idP then it should discriminate between requesters (the RADIUS server in this case) and to decide not to sign the assertion issued for this entity. It could be ok, but I think should be explicitly described     in the text. Other option is to allow the RADIUS server cuts short the assertion and to remove the XML signature, but I don't like this.

The acceptor could ignore it.

> Second, you have to take into account that the SAML assertion will be for a one-time use and it could not be managed/validated by a third party. Let's think in a scenario where the received assertion is used later on to request other end user attributes and the     original SAML assertion should be first validated in order to check validity.

This makes sense (kind of like Kerberos constrained delegation where the authorisation data is signed). But it could be optional?

-- Luke

---

From: Gabriel López <[email-masked]>
Date: Thu, 03 Nov 2011 14:19:14 +0100

> The acceptor could ignore it.
yes, I was thinking in the size of the SAML assertion and the limit of
4096 bytes commented by Alejandro in the last email. The XMLSignature
would increase considerably the message size.
> This makes sense (kind of like Kerberos constrained delegation where the authorisation data is signed). But it could be optional?
not sure about that

regards, Gabi.

-- 
----------------------------------------------------------------
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: "Cantor, Scott" <[email-masked]>
Date: Thu, 3 Nov 2011 14:30:15 +0000

>would increase considerably the message size.

The only dramatic size increase comes from putting the certificate in the
message. If you don't do that (as in, you don't use PKIX), then it isn't
really that large.

>>This makes sense (kind of like Kerberos constrained delegation where the
>>authorisation data is signed). But it could be optional?

>not sure about that

Not optional in the sense that it would be used as if it were signed, just
optional meaning not all assertions would have that capability. As in fact
they wouldn't. You can't just sign the assertion and magically treat it as
a reusable token. Well, you can, but those people are ignoring the
standard. Other content is also needed or you have a very lax model.

-- Scott

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 03 Nov 2011 15:51:04 +0100

> On 11/3/11 9:19 AM, "Gabriel López"<[email-masked]>  wrote:
What if the user has some attribute which is > 4K? For example a photo 
(for biometric comparation).
I think that this situation should not be ignored, even when I can agree 
it will not be the most usual.

Regards,
Alejandro

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 3 Nov 2011 14:58:37 +0000

>it will not be the most usual.

Sorry, I wasn't saying the assertion wouldn't be > 4K, I was saying the
signature alone isn't that much bigger than a mediumish attribute unless
you add the cert.

I thought the > 4K thing was addressed by chunking it up. If not, you have
a problem.

-- Scott

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 03 Nov 2011 16:09:44 +0100

> On 11/3/11 10:51 AM, "Alejandro Perez Mendez"<[email-masked]>  wrote:
>> What if the user has some attribute which is>  4K? For example a photo
> Sorry, I wasn't saying the assertion wouldn't be>  4K, I was saying the
> I thought the>  4K thing was addressed by chunking it up. If not, you have
> a problem.

That exactly the problem. Even splitting into 253-byte chucks, a RADIUS 
message cannot have more than 4K in total, including all the attributes. 
So, I think it would be required to find a solution for this, as it 
could happen, even without certificates and signatures.

Regards,
Alejandro

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 3 Nov 2011 15:18:39 +0000

>could happen, even without certificates and signatures.

You have to, yes.

Depending on the semantics, by reference could work, but it's definitely a
pain and complicates the security model.

-- Scott

---

From: Rhys Smith <[email-masked]>
Date: Thu, 3 Nov 2011 15:21:09 +0000

On 3 Nov 2011, at 15:09, Alejandro Perez Mendez wrote:

> That exactly the problem. Even splitting into 253-byte chucks, a RADIUS message cannot have more than 4K in total, including all the attributes. So, I think it would be required to find a solution for this, as it could happen, even without certificates and signatures.

Could send a SAML artifact and then get the real, large, SAML assertion by resolving the artifact over http on the issuing IdP?

R.
--
Dr Rhys Smith: Identity, Access, and Middleware Specialist
Cardiff University & JANET(UK)

email: [email-masked] / [email-masked]
GPG: 0xDE2F024C

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 03 Nov 2011 16:31:51 +0100

El 03/11/11 16:21, Rhys Smith escribió:
>>> On 11/3/11 10:51 AM, "Alejandro Perez Mendez"<[email-masked] 
>>> <mailto:[email-masked]>>  wrote:
>> That exactly the problem. Even splitting into 253-byte chucks, a 
>> RADIUS message cannot have more than 4K in total, including all the 
>> attributes. So, I think it would be required to find a solution for 
>> this, as it could happen, even without certificates and signatures.
>
> Could send a SAML artifact and then get the real, large, SAML 
> assertion by resolving the artifact over http on the issuing IdP?

You could, but then you would need to rely on a PKI for the trust 
(during http assertion retrieving). I thought that idea was already 
discarded in favor of AAA-based trust.

Regards,
Alejandro

> email: [email-masked] <mailto:[email-masked]> / 
> [email-masked] <mailto:[email-masked]>
> GPG: 0xDE2F024C
>
>

---

From: Leif Johansson <[email-masked]>
Date: Thu, 03 Nov 2011 16:34:23 +0100

On 11/03/2011 04:31 PM, Alejandro Perez Mendez wrote:
>>>>> What if the user has some attribute which is>  4K? For
>>>>> example a photo (for biometric comparation). I think that
>>>>> this situation should not be ignored, even when I can 
>>>>> agree it will not be the most usual.
>>>> Sorry, I wasn't saying the assertion wouldn't be>  4K, I was
>>>> saying the signature alone isn't that much bigger than a
>>>> mediumish attribute unless you add the cert.
>>>> 
>>>> I thought the>  4K thing was addressed by chunking it up. If
>>>> not, you have a problem.
>>> 
>>> That exactly the problem. Even splitting into 253-byte chucks,
>>> a RADIUS message cannot have more than 4K in total, including
>>> all the attributes. So, I think it would be required to find a
>>> solution for this, as it could happen, even without
>>> certificates and signatures.
>> 
> (during http assertion retrieving). I thought that idea was
> already discarded in favor of AAA-based trust.

You can have any white-list including one based on metadata.

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 3 Nov 2011 15:33:49 +0000

On 11/3/11 11:21 AM, "Rhys Smith" <[email-masked]> wrote:
>
>Could send a SAML artifact and then get the real, large, SAML assertion
>by resolving the artifact over http on the issuing IdP?

Existing SAML 2.0 artifacts reference protocol messages, not assertions.
That's not necessarily a problem, you can just wrap it in a Response.

Whatever you do by reference also means an extra protocol stack, extra
security considerations around the reference and the resolution process,
and state management across clusters unless you complicate the model to
get around it.

-- Scott

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Thu, 03 Nov 2011 16:40:39 +0100

Hi,

On 11/3/11 10:51 AM, "Alejandro Perez Mendez"<[email-masked]<mailto:[email-masked]>>  wrote:

I don't want to open a can of worms, but we could consider the idea of more compact coding formats, like JWT… There is a WG (JOSE, http://datatracker.ietf.org/wg/jose/) dealing with  this stuff, plus our OAuth colleagues, of course.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[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: "Cantor, Scott" <[email-masked]>
Date: Thu, 3 Nov 2011 15:59:38 +0000

>I don't want to open a can of worms, but we could consider the idea of
>more compact coding formats, like JWTŠ

Can you explain how my 5K of data becomes < 4K because I take out some
angle brackets?

-- Scott

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 3 Nov 2011 19:44:22 +0200

RADIUS was never developed for these types of things. Hence, it is not " ideally" suited for such scenarios. 

This was one of the reasons for the development of Diameter. 

ciao

Hannes

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Alejandro Perez Mendez
Sent: Thursday, November 03, 2011 5:32 PM
To: Rhys Smith
Cc: [email-masked]
Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt

	you add the cert.

	a problem.

You could, but then you would need to rely on a PKI for the trust (during http assertion retrieving). I thought that idea was already discarded in favor of AAA-based trust.

Regards,
Alejandro

R.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 03 Nov 2011 13:58:22 -0400

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

    >> I don't want to open a can of worms, but we could consider the
    >> idea of more compact coding formats, like JWTŠ

    Cantor,> Can you explain how my 5K of data becomes < 4K because I
    Cantor,> take out some angle brackets?

I have not read 02. I have some comments based on the discussion.

1) aaa-saml MUST NOT normatively repeat any text about the EAP binding
from the RADIUS eap binding. As an example the quoted description of the
handling of EAP identity is different from the RADIUS EAP spec. We
committed to not changing RADIUS or EAP. While I guess we didn't
strictly commit to not changing RADIUS EAP, I really don't think we want
to go there, especially when we have no good reason for doing so.

2) As has been pointed out the 4096 limit is on RADIUS messages *not* on
SAML assertions.  Also, it's not a limit: it is a minimum size
implementations must handle.  So, I think a better way of phrasing this
is that if your SAML assertion makes a RADIUS PDE greater than 4k it
very likely will not be carried in its entirety.

3) We have no business forbidding signatures.  We SHOULD mandate that
NASes default to not checking signatures. We SHOULD point out that you
can strip/not issue a signature to make your assertion smaller.

4) I prefer attribute query as a way to get larger/more attributes over
URL references or artifacts.

5) We need more discussion on the size issue.
I'll note several things.

First: the protocol may be useful even if it does have limitations. If
it happens that most of the things people want to do with it are
possible, but some are not, it may have sufficient utilitiy. Compression
increases the utility. It doesn't help if you want a 10k photo with
FreeRADIUS, but it does help if you're close to the boundary.  So, I
don't view it as a valid objection that is a size limit or that some use
cases are precluded by the size limit.  I do view it as an objection
that the size limit does not permit enough use cases. I don't know
whether that's true. However my personal opinion is that I don't agree
with a message complaining about a size limit unless it explains both
things that are prohibited and makes an argument about why prohibiting
those things is a bad tradeoff.

Second: We can explore whether it's operationally viable to raise the
limit. I'm a little dubious about this. The RADIUS world seems to have
hard-coded the 4k limit in servers and proxies. That is not how I would
have done things. I'm told it's a simple constant that can be increased
and rebuilt in several popular implementations.
I am skeptical of the viability of doing that or how well it works if
you do. Still we should consider.

However I do believe the length limitation is the big thing to consider
for saml-aaa.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 3 Nov 2011 11:29:20 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Thursday, November 03, 2011 10:58 AM
> To: Cantor, Scott
> Cc: [email-masked]
> NASes default to not checking signatures. We SHOULD point out that you can
> strip/not issue a signature to make your assertion smaller.

I agree with this BIG TIME.  I have just scanned the draft and the fact that
no signatures were allowed gave me heartburn.

Jim

---

From: Josh Howlett <[email-masked]>
Date: Thu, 3 Nov 2011 18:59:57 +0000

Hi Alejandro,

Thanks for your careful review. I'll correct the nits ASAP.

>        RADIUS-specific document.

Yes; aligning this with the Diameter document is the goal for the next rev.

>* I have a question related with the RADIUS maximum packet size.
>        RFC 2865 states that the maximum size is 4096 bytes. That means
>        that if an SAML Assertion would be bigger than 4K, it would be
>        impossible to transport it in a single RADIUS message. Even
>        without signatures, a SAML Assertion containing attributes may
>        exceed this size if the attributes contains data enough. Have
>        you thought about any mechanism to lead with this kind of
>        situations, for example the use of a Hash&URL or similar?

In this case I believe that Diameter should be used.

I agree that it would be possible to invent a callback mechanism to
resolve a jumbo assertion, but I believe that these would introduce
non-trivial implementation and operational issues.

Speaking from an operator's perspective, I would personally prefer to
increase the RADIUS message MTU (particularly for the TCP transport case),
but obviously there are process considerations that could impede this.

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: Josh Howlett <[email-masked]>
Date: Thu, 3 Nov 2011 19:00:01 +0000

>pain and complicates the security model.

That was my conclusion in a nutshell.

Josh.

---

From: Josh Howlett <[email-masked]>
Date: Thu, 3 Nov 2011 21:33:50 +0000

Sam,

>to go there, especially when we have no good reason for doing so.

Point taken. This started off as a narrative and ended up being
prescriptive. I'll fix.

>URL references or artifacts.

I'd prefer Diameter.

Josh.

---

From: Josh Howlett <[email-masked]>
Date: Thu, 3 Nov 2011 21:36:33 +0000

>>can

I am happy with Sam's proposal, and I'll update accordingly.

Josh.

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Thu, 03 Nov 2011 23:13:18 +0100

> Can you explain how my 5K of data becomes < 4K because I take out some

It is not some angle brackets, but avoiding XML verbosity. Anyway, I'd agree that a solution like this (or compression or anything similar) would only move the bar a little bit higher. When (and if) assertion size becomes a problem, the only choices I think you'll have are attribute queries or DIAMETER…

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: Gabriel López <[email-masked]>
Date: Fri, 04 Nov 2011 09:26:32 +0100

> standard. Other content is also needed or you have a very lax model.
Well, I'm thinking about the Federated Cross-Layer Access use case.
Network access authentication could provide RADIUS server with a SAML
assertion, then application service could obtain this assertion
(directly from the AAA server or through the end user) and take an
access control decision based on that. Protecting the SAML assertion in
a correct way would not derive in a lax model. Of course, I agree, it
doesn't follow any current SAML specification.

Anyway, this topic will require a new thread.
Thanks Scott for you comments.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 04 Nov 2011 09:57:00 +0100

> very likely will not be carried in its entirety.

The text from RFC 2865 says, regarding the Length field o a RADIUS 
message, the following:

  The minimum length is 20 and maximum length
       is 4096

Hence, IMHO it is a limit.

> URL references or artifacts.

I agree, but if attribute queries are performed using SOAP (for 
example), you would need to rely in certificate-based trust, and 
AAA-based trust would not be enough, right?

> FreeRADIUS, but it does help if you're close to the boundary.

Right. Actually, we are using compression in our prototype.

> So, I

Maybe I did not explain myself well. I was not postulating myself 
against the use of RADIUS, or complaining about it. On the contrary, I 
was just raising an issue we found in our prototype, in the aim to find 
out a consensual solution for the specific (and probably infrequent) 
cases where the size limit may appear. Of course, one can use Diameter 
instead. But I would like to have a solution for RADIUS.

> you do. Still we should consider.

I think they did that way because that limit is specified in the RADIUS 
spec. I would guess that, as you say, it will be a simple constant 
easily increseable for the servers you control. But it would be needed 
to rebuild all the RADIUS servers that take part in the federation, so 
they do not strip messages when acting as proxies. Anyway, increasing 
that number would be against RADIUS specification, if I did not 
understand it wrong.

Best regards,
Alejandro

---

From: Josh Howlett <[email-masked]>
Date: Fri, 4 Nov 2011 09:29:29 +0000

>
>Of course, one can use Diameter

Could I ask why? I am satisfied that 4k is plenty for the use-cases that I
see today. Adding support for more will incur significant complexity,
which feels disproportionate for a corner-case. If people have such a
corner case, they can use Diameter.

Josh.

---

From: Gabriel López <[email-masked]>
Date: Fri, 04 Nov 2011 11:02:07 +0100

El 04/11/11 10:29, Josh Howlett escribió:
> see today.
Well, current implementation is over RADIUS and if you have to transport
SAML assertion including XML Signature (+X.509PKC) (even if parties do
ignore it) you can have problems even with small size attributes. If you
can life with SAML assertion including XML Signature (without X.509PKC)
then it is ok.

Also, if you plan to implement this in a real deployment... well,
Diameter may not be fully used yet :)

regards, Gabi.
>  Adding support for more will incur significant complexity,

---

From: Josh Howlett <[email-masked]>
Date: Fri, 4 Nov 2011 10:10:13 +0000

>can life with SAML assertion including XML Signature (without X.509PKC)

My assumption is that the SAML responder does not include a signature; the
transport can provide the needed assurances. Deployments that require
signatures should use Diameter.

Josh.

---

From: Gabriel López <[email-masked]>
Date: Fri, 04 Nov 2011 11:31:30 +0100

> signatures should use Diameter.
Then I think the draft document should comment something like:
"SAML assertion ¿should/must? not be signed if AAA transport is RADIUS,
otherwise it could"

It is not clear for me, but if you are ok ...

regards, Gabi.

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 4 Nov 2011 14:06:53 +0000

>corner case, they can use Diameter.

I'm still doing some research on this (I need to mock up some assertions
using my data and extensions), but my intuition is that I can definitely
not get behind anything with a limit that low.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 4 Nov 2011 14:29:11 +0000

>not get behind anything with a limit that low.

I feel like I should explain that a bit more directly:

While most of the >4K use cases I have now are not federated (its usually
enrollment data that gets it above the line), my experience is that having
two infrastructures (one for intra-, one for inter-) is bad.

I also believe support for SAML based delegation is important to gradually
move people away from building "client of web service is root" models to
get around having decent delegation support. That adds size (as well as
signature).

I believe it's short shrift to focus on passing small numbers of
attributes around, because if you think that's all there is, then that
means attributes aren't getting used widely, which means federation's not
going anywhere anyway. Authentication alone is not a motivator for the
effort involved. Attributes are all that will drive it.

I'm of course fine with DIAMETER if people are deploying it, or will be
within the next 5 years or so. One question on thatŠwith the intent to
move to a model where you connect directly from the acceptor's AAA server
to the home server via TLS, does that mean only the two endpoints would
need DIAMETER anyway? That's a reasonable compromise.

-- Scott

---

From: Josh Howlett <[email-masked]>
Date: Fri, 4 Nov 2011 16:10:34 +0000

>get around having decent delegation support. That adds size (as well as

Yes, I'm certainly sympathetic to that argument. I agree that for
inter-domain delegation, we will need support for this. In that case,
Diameter is your friend. However, for intra-domain delegation, I think
there's plenty of mileage in using Kerberos delegation semantics (with an
unsigned SAML assertion in the PAC) rather than SAML delegation semantics.
In this case, we can use RADIUS.

>effort involved. Attributes are all that will drive it.

Agreed. We should certainly provide a mechanism that supports arbitrarily
sized payloads for the reasons you state. However, if a reasonable
proportion of use cases can be solved with a simple (if not necessarily
comprehensive) RADIUS-based mechanism, we should do that rather than
reinvent Diameter.

>within the next 5 years or so.

That's the $64K question. My view is that we should take a pragmatic
approach, and provide a simple option that is readily deployable today and
which addresses many -- if not all -- use cases, and provide an
alternative mechanism to satisfy those other use cases.

> One question on thatŠwith the intent to

That's certainly a possible deployment option although I believe that even
in a Diameter-based deployment, there may be a role for proxies and other
active intermediaries. However, I think I may have misunderstood the
thrust of your question...?

Josh.

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 4 Nov 2011 16:36:54 +0000

>thrust of your question...?

I'm trying to confirm my understanding that if I had an app at my end and
federated partners that supported DIAMETER that I wouldn't need the entire
eduroam fabric to be running DIAMETER too.

In other words, it's a peer to peer problem of updating software to
support a feature, not waiting for an entire national network to upgrade.

-- Scott

---

From: Josh Howlett <[email-masked]>
Date: Fri, 4 Nov 2011 17:14:15 +0000

>support a feature, not waiting for an entire national network to upgrade.

Ah ok. Yes, it's a peer to peer problem.

Josh.

---

From: Josh Howlett <[email-masked]>
Date: Sun, 6 Nov 2011 16:47:38 +0000

(Responding to my own mail)

>Ah ok. Yes, it's a peer to peer problem.

Let me clarify that, because I suspect I was still misunderstanding your
question. 

If you were relying on an intermediate fabric for trust establishment and
other assurances, then that fabric (and your federated partners,
obviously) would also need to support Diameter.

While Diameter supports proxies, it does not require them for trust
establishment and routing between federated partners as in the RADIUS
case. A Diameter based fabric is much more likely to look like a mesh
federation.

This obviously creates a problem if you already have a hub-and-spoke or
hierarchical hub-and-spoke RADIUS federation (as in the eduroam case) and
want to use SAML messages > 4kb. In this case, you need to change your
fabric.

Josh.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 06 Nov 2011 15:56:32 -0500

>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

    Josh> While Diameter supports proxies, it does not require them for
    Josh> trust establishment and routing between federated partners as
    Josh> in the RADIUS case. 

what does this statement mean? I'm obviously missing some important
feature of Diameter, which is unsurprising because I know very little
about it.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 07 Nov 2011 10:15:19 +0100

On 11/06/2011 09:56 PM, Sam Hartman wrote:
> Josh> While Diameter supports proxies, it does not require them
> for Josh> trust establishment and routing between federated
> partners as Josh> in the RADIUS case.
> 
> what does this statement mean? I'm obviously missing some
> important feature of Diameter, which is unsurprising because I know
> very little about it.

I think Josh is saying that Diameter uses SRV records much like RADSEC.

	Cheers Leif

---

From: Josh Howlett <[email-masked]>
Date: Mon, 7 Nov 2011 09:25:40 +0000

>I think Josh is saying that Diameter uses SRV records much like RADSEC.

Yes, that kind of thing.

Josh.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Nov 2011 08:19:40 -0500

>>> important feature of Diameter, which is unsurprising because I
    >>> know very little about it.
    >> 

    Josh> Yes, that kind of thing.

Yeah, but how does that help me without a trust relationship?

---

From: Josh Howlett <[email-masked]>
Date: Mon, 7 Nov 2011 13:40:43 +0000

>Yeah, but how does that help me without a trust relationship?

In RADIUS you're compelled to use proxy for federated trust relationships.
In Diameter you have more options.

Josh.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 7 Nov 2011 19:13:24 +0200

There are two aspects: 

1) How can you technically find the server you need to talk to?
Diameter has defined a DNS based discovery procedure.

2) Is the Diameter entity you talk to indeed some entity you trust?

The IETF Diameter specifications only talk about (1) and not about (2). 
They implicitly assume that (2) is addressed somehow outside the realm
of the IETF. 

There is a relationship between the two issues. Depending on how you
address (2) you may constraint the solutions for (1). Not only the AAA
community had made that observation but also the RAI guys with their
work on SIP when the had initially planned to model the proxy-to-proxy
interaction according to email. 

In Diameter the DNS based discovery was not used by anyone at few years
back; this was the time when I co-chaired the DIME group and helped to
organize interop-events were we had gotten feedback from the other
implementers. Everyone was using nailed-up connections (and they used
IPsec) and so the need to dynamically discover servers did not arise. 

Ciao
Hannes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Sam Hartman
Sent: Monday, November 07, 2011 3:20 PM
To: Josh Howlett
Cc: [email-masked]
Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt

---

From: Leif Johansson <[email-masked]>
Date: Mon, 7 Nov 2011 20:09:29 +0100

> Yeah, but how does that help me without a trust relationship?

It doesn't really.