Subject: [abfab] Conflict between draft-ietf-abfab-aaa-saml and what Moonshot actually does

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Jul 2013 07:50:48 -0400

On one of the Moonshot lists, we recently noticed that Moonshot simply
expects the AAA server to send back a SAML assertion in the AAA message.

However, draft-ietf-abfab-aaa-saml  expects a SAML response.

One answer is that Moonshot is broken and should be fixed to conform to
the spec.

However, Scott seemed to think the current behavior might be reasonable,
and it's certainly a lot easier to implement.  (Well, OK, we do have a
full SAML library, so parsing a response should be relatively easy too)

There are a couple of advantages to the current text.
First, it permits a request/response protocol.  Second, it permits
multiple assertions, which Jim is interested in for some of his use
cases.

There are some advantages to the Moonshot approach.  It's simpler and it
is shorter in a space-constrained RADIUS packet.

My recommendation is that  if an AAA server is sending an unsolicited
response with a single assertion, it just include the assertion.
Otherwise, it should include a response.
What do people think of this?

--Sam

---

From: Josh Howlett <[email-masked]>
Date: Wed, 10 Jul 2013 12:45:17 +0000

>What do people think of this?

I like it.

Josh.

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 10 Jul 2013 13:24:06 +0000

>full SAML library, so parsing a response should be relatively easy too)

Parsing is not so big a deal, it's more about what processing rules would
be expected to apply.

>From a coding PoV, if you have to handle the response in at least some
cases than the main win would appear to be space, which is not
insignificant in this context I suppose.

I did note in the same thread that you may want to speak to encryption in
this as well. I don't know if it's even possible, let alone desirable, to
do XML Encryption here, but you should answer that somewhere if you
haven't already.

-- Scott

---

From: David Chadwick <[email-masked]>
Date: Wed, 10 Jul 2013 15:57:24 +0100

> What do people think of this?

Firstly I suggest these should be flagged as different attribute types, 
so that the recipient knows before starting parsing the value what data 
type it is.

Secondly, (excuse my ignorance here), but is it possible to send 
multiple values of a particular attribute? If so, then there should be 
no reason to limit unsolicited responses to containing a single 
assertion. Each attribute value can be a different assertion

regards

David

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Jul 2013 15:22:04 -0400

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

    >> My recommendation is that if an AAA server is sending an
    >> unsolicited response with a single assertion, it just include the
    >> assertion.  Otherwise, it should include a response.  What do
    >> people think of this?

    Cantor,> From a coding PoV, if you have to handle the response in at
    Cantor,> least some cases than the main win would appear to be
    Cantor,> space, which is not insignificant in this context I
    Cantor,> suppose.

Well, if you are an IDP who doesn't care about solicited requests--if
    the request will never influence your behavior--then you can simply
    your processing.  Similarly if you're a client that wouldn't know
    what to do with multiple assertions andnever sends a request, you
    can simply processing.

    Cantor,> I did note in the same thread that you may want to speak to
    Cantor,> encryption in this as well. I don't know if it's even
    Cantor,> possible, let alone desirable, to do XML Encryption here,
    Cantor,> but you should answer that somewhere if you haven't
    Cantor,> already.

I don't think encryption should be an MTI, but nor do I think it should
be forbidden.
Figuring out the keys is unspecified, although metadata is the obvious
answer.
I.E. I don't think we have anything new to say about encryption.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 10 Jul 2013 12:57:48 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Wednesday, July 10, 2013 4:51 AM
> To: [email-masked]
> Subject: [abfab] Conflict between draft-ietf-abfab-aaa-saml and what
> Moonshot actually does
> 
> 
> 
full
> SAML library, so parsing a response should be relatively easy too)
> 
multiple
> assertions, which Jim is interested in for some of his use cases.
> 
is
> shorter in a space-constrained RADIUS packet.
> 

I think this is reasonable with one caveat, I don't believe that an
unsolicited response should be returned if the IDP  make a request.

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 10 Jul 2013 13:01:39 -0700

> Sent: Wednesday, July 10, 2013 12:22 PM
> To: Cantor, Scott
> Cc: [email-masked]
> Subject: Re: [abfab] Conflict between draft-ietf-abfab-aaa-saml and what
> Moonshot actually does
> 
> I don't think encryption should be an MTI, but nor do I think it should be
> forbidden.

Yeah, my first thought was how would a key for the IDP ever be figured out.
We are basically assuming that any and all proxies have to be extremely
trusted and all links are encrypted.  I don't see that we are going to buy
anything by having encryption except to make things bigger which would be a
problem.

Jim

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 10 Jul 2013 20:39:22 +0000

>    what to do with multiple assertions andnever sends a request, you

A SAML IdP would generally have more trouble handling the requirement to
not generate a response, but of course if you're generating an assertion
as part of some other software that's not an issue.

Certainly it's true that a client that could preclude the other case would
be able to simplify, but as a library developer, I tend not to think about
such cases.

>I.E. I don't think we have anything new to say about encryption.

Ok, then it's relevant that a client might not get just an Assertion but
alternatively an EncryptedAssertion, different elements.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 10 Jul 2013 20:40:38 +0000

>Yeah, my first thought was how would a key for the IDP ever be figured

SP, not IdP. The relying party's key is what's used to encrypt, in general.

>anything by having encryption except to make things bigger which would be

I assumed as much so wondered if you wanted to preclude it.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Jul 2013 18:33:34 -0400

>> Yeah, my first thought was how would a key for the IDP ever be

    Cantor,> SP, not IdP. The relying party's key is what's used to
    Cantor,> encrypt, in general.

    >> We are basically assuming that any and all proxies have to be
    >> extremely trusted and all links are encrypted.  I don't see that
    >> we are going to buy anything by having encryption except to make
    >> things bigger which would be a problem.

    Cantor,> I assumed as much so wondered if you wanted to preclude it.

seems to me that if you have a way of getting a credible key for the SP,
then it's fine to use it.

If you encrypt in a key that the other party doesn't know, interop may
be impacted. This is probably unsurprising:-)

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 10 Jul 2013 23:53:59 +0000

>be impacted. This is probably unsurprising:-)

I have no issue with allowing it, I just wanted to note it as another case
where the object "at hand" might not be <saml:Assertion>. I also don't
know if it warrants defining a different RADIUS attribute to carry it.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Jul 2013 21:43:26 -0400

In this case I think you should send a response rather than encrypted assertion

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: Gabriel López <[email-masked]>
Date: Thu, 11 Jul 2013 09:45:54 +0200

> In this case I think you should send a response rather than encrypted assertion
    I agree.

    And in this case I think it would be a more elegant solution if the
client specifies (AuthnQuery, AttributeQuery, AuthzDeciscionQuery) the
kind of assertion to be returned by the idP . I think current draft
version points out a MAY in this case. It also would help the idP to do
not spend time processing SAML data if the client does not support it.

    regards, Gabi.

-- 
--------------------------------------------------------------
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: David Chadwick <[email-masked]>
Date: Thu, 11 Jul 2013 10:05:51 +0100

in my opinion you should have different Radius attributes for each 
different type of encoded attribute: response, assertion, encrypted 
assertion etc. so that the RP/SP knows what it is receiving

David

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 11 Jul 2013 11:11:09 +0200

Hi,

I think a better option would be to  define a "type" subfield in the 
SAML-AAA attribute, indicating what's coming next in the value field 
(i.e. Response, Assertion..).

Regards,
Alejandro

---

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Jul 2013 06:20:06 -0400

>>>>> "Alejandro" == Alejandro Perez Mendez <[email-masked]> writes:

    Alejandro> Hi, I think a better option would be to define a "type"
    Alejandro> subfield in the SAML-AAA attribute, indicating what's
    Alejandro> coming next in the value field (i.e. Response,
    Alejandro> Assertion..).

    Alejandro> Regards, Alejandro

I thought we had this for context anway.
I agree though.

---

From: Josh Howlett <[email-masked]>
Date: Fri, 12 Jul 2013 08:43:11 +0000

Why?

Isn't it sufficient for the AAA layer to know that it is a SAML blob? Why
does the AAA layer care about the semantics of the blob?

Josh.

---

From: David Chadwick <[email-masked]>
Date: Fri, 12 Jul 2013 09:52:01 +0100

To make parsing and diagnostics somewhat easier. Why does Radius 
differentiate between attributes at all? Or, to follow your argument, 
why not simply have an XML attribute type to say that what follows is a 
blob of XML? Why bother saying that it is SAML?

regards

David

---

From: Sam Hartman <[email-masked]>
Date: Fri, 12 Jul 2013 06:37:24 -0400

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

    Josh> Why?  Isn't it sufficient for the AAA layer to know that it is
    Josh> a SAML blob? Why does the AAA layer care about the semantics
    Josh> of the blob?

You and I should get together in person and work through this again and
write text in the same session.

Unfortunately this seems to be a case where the discussion expires from
the cache too soon.:-)

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 12 Jul 2013 13:57:53 +0000

> Unfortunately this seems to be a case where the discussion expires from

Ultimately you just have to strike a balance between overly specifying things and not signaling enough. I don't know enough about RADIUS to judge, but for me the rule of thumb is to either signal based on broad semantic categories (assertion vs. protocol messages) or be consistent and signal different XML elements uniquely based on Qname/xsi:type.

-- Scott

---

From: Josh Howlett <[email-masked]>
Date: Thu, 18 Jul 2013 13:33:37 +0000

>
>Ultimately you just have to strike a balance between overly specifying
>things and not signaling enough. I don't know enough about RADIUS to
>judge, but for me the rule of thumb is to either signal based on broad
>semantic categories (assertion vs. protocol messages) or be consistent
>and signal different XML elements uniquely based on Qname/xsi:type.

Right. And on this basis, from my knowledge of SAML and RADIUS, I see no
reason not to follow the pattern set by the existing SAML bindings. I
would welcome some reasoning from those arguing otherwise as to why we
shouldn't do this. I.e. what makes RADIUS a special case? Clearly we could
move the payload semantics to the RADIUS layer, but why do it? ("Because
we can" does not cut it!)

Josh.

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 18 Jul 2013 14:07:26 +0000

> we can" does not cut it!)

Since bindings in general don't carry Assertion alone, that distinction is probably worthy of a separate attribute.
 
-- Scott

---

From: Josh Howlett <[email-masked]>
Date: Thu, 18 Jul 2013 14:18:09 +0000

>
>Since bindings in general don't carry Assertion alone, that distinction
>is probably worthy of a separate attribute.

Yes, good point. This would fit nicely with Sam's proposal for returning
an unsolicited response as a raw assertion. That differentiation adds
value in this case: we can assume that the acceptor isn't interested in
the response semantics and so we avoid some needless parsing.

Thanks, Josh.