Behavior when Authentication Request contains ACS that isn't listed in the metadata for that entityID

[Mike G.]

I just discovered that SimpleSAMLphp (SSP) treats the situation where the Authn Request contains in invalid AssertionConsumerService differently than the Shibboleth Identity Provider. The Shibboleth Identity Provider just produces an error to that effect and does not proceed with processing the Authn Request. But SSP instead uses the "default" ACS from the metadata in place of the requested ACS. I'm wondering why that choice was made, and if there is a configurable way to override that behavior -- i.e. instead of alternately using the default, use the Shibboleth Identity Provider behavior of rejecting the Authn Request in the first place.

[Tom Scavo]

On Fri, Jul 11, 2014 at 12:31 AM, Mike G. <mapg...@gmail.com> wrote:
> I just discovered that SimpleSAMLphp (SSP) treats the situation where the
> Authn Request contains in invalid AssertionConsumerService differently than
> the Shibboleth Identity Provider. The Shibboleth Identity Provider just
> produces an error to that effect and does not proceed with processing the
> Authn Request. But SSP instead uses the "default" ACS from the metadata in
> place of the requested ACS.

That's very interesting, thanks for reporting this. I think an
argument could be made for either behavior.

How are the AuthnRequests formulated in each case (both SSP and Shib)?
In particular, is AssertionConsumerServiceIndex or
AssertionConsumerServiceURL used?

> I'm wondering why that choice was made

In the case of AssertionConsumerServiceIndex, the spec clearly allows
either behavior. The case of AssertionConsumerServiceURL is less clear
but I think either behavior is justified (at least, neither behavior
is a security concern AFAICT).

> and if
> there is a configurable way to override that behavior -- i.e. instead of
> alternately using the default, use the Shibboleth Identity Provider behavior
> of rejecting the Authn Request in the first place.

In any case, I don't think it's wise to hardwire one behavior or the
other into the IdP. It really does need to be a deployment choice.

All that said, I know what my deployment choice would be :-) since
stopping the user dead in his/her tracks is to be avoided at all
costs.

Cheers,

Tom

[Ian Young]

On 11 Jul 2014, at 14:06, Tom Scavo <trs...@gmail.com> wrote:

> The case of AssertionConsumerServiceURL is less clear
> but I think either behavior is justified (at least, neither behavior
> is a security concern AFAICT).

When there's a mismatch between metadata and the messages, it's *always* a security concern. Mostly the concern would be that there is some kind of MITM attack in progress, even if you can't immediately see how such an attack might work. This is why the spec says:

> Whether the request is signed or not, the identity provider
> MUST ensure that any <AssertionConsumerServiceURL> or
> <AssertionConsumerServiceIndex> elements in the request are verified as belonging to the service
> provider to whom the response will be sent. Failure to do so can result in a man-in-the-middle attack.


This is at line 432 of 4.1.4.1 of the profiles spec.

> All that said, I know what my deployment choice would be :-) since
> stopping the user dead in his/her tracks is to be avoided at all
> costs.

I guess you're saying that you'd prefer that the SAML processor ignore the contents of a bad message and guess at what it should do, rather than indicate that there is a problem with the metadata and/or an attack may be in progress. Obviously I take the diametrically opposite position: if the incoming message is wrong in any way, the safest approach is to error out before any harm is done.

-- Ian

[Peter Schober]

* Ian Young <i...@iay.org.uk> [2014-07-11 16:04]:

> When there's a mismatch between metadata and the messages, it's
> *always* a security concern. Mostly the concern would be that there
> is some kind of MITM attack in progress, even if you can't
> immediately see how such an attack might work. This is why the spec
> says:
>
> > Whether the request is signed or not, the identity provider
> > MUST ensure that any <AssertionConsumerServiceURL> or
> > <AssertionConsumerServiceIndex> elements in the request are verified as belonging to the service
> > provider to whom the response will be sent. Failure to do so can result in a man-in-the-middle attack.

Note that the Shib developers themselfs have created an option that
allows deployers to ignore mismatching AssertionConsumerServiceURLs in
the authnRequest *if* the authnRequest is signed and the signature has
been verified. (I had to deal with a weird SAML implementation that
generated /dynamic/ ACS URLs for each authnRequest, probably in a
misguided attempt to track state of the subject in their application,
instead of relying on RelayState, and modifying the IDP and signing
the authnRequests on the SP side was a clean way out of this.)

So while I agree that signed authnRequests could take the place of
metadata verification, the above text does not seem to suggest that
with "Whether the request is signed or not"...
Well, a valid signature *is* proof that the "elements in the request
are verified as belonging to the service provider" (or that the SP's
private key is not so private in fact).
So that text could use some clarification, if you ask me (which noone
did, of course ;)).
-peter

[Tom Scavo]

On Fri, Jul 11, 2014 at 10:04 AM, Ian Young <i...@iay.org.uk> wrote:
>
>> Whether the request is signed or not, the identity provider
>> MUST ensure that any <AssertionConsumerServiceURL> or
>> <AssertionConsumerServiceIndex> elements in the request are verified as belonging to the service
>> provider to whom the response will be sent. Failure to do so can result in a man-in-the-middle attack.
>
> This is at line 432 of 4.1.4.1 of the profiles spec.

Yes, of course, but there's no evidence that either of the
implementations (SSP or Shib) are violating any requirements. In my
previous message, I was referring to this requirement in SAML Core:

"If the index specified is invalid, then the identity provider MAY
return an error <Response> or it MAY use the default location."

That why I asked whether AssertionConsumerServiceIndex or
AssertionConsumerServiceURL are involved.

>> All that said, I know what my deployment choice would be :-) since
>> stopping the user dead in his/her tracks is to be avoided at all
>> costs.
>
> I guess you're saying that you'd prefer that the SAML processor ignore the contents of a bad message and guess at what it should do, rather than indicate that there is a problem with the metadata and/or an attack may be in progress. Obviously I take the diametrically opposite position: if the incoming message is wrong in any way, the safest approach is to error out before any harm is done.

What is the harm sending a response to the default location in
metadata? If that's a security issue, then so is any IdP-first flow.

Tom

[Ian Young]

On 11 Jul 2014, at 16:29, Tom Scavo <trs...@gmail.com> wrote:

> On Fri, Jul 11, 2014 at 10:04 AM, Ian Young <i...@iay.org.uk> wrote:
>>
>>> Whether the request is signed or not, the identity provider
>>> MUST ensure that any <AssertionConsumerServiceURL> or
>>> <AssertionConsumerServiceIndex> elements in the request are verified as belonging to the service
>>> provider to whom the response will be sent. Failure to do so can result in a man-in-the-middle attack.
>>
>> This is at line 432 of 4.1.4.1 of the profiles spec.
>
> Yes, of course, but there's no evidence that either of the
> implementations (SSP or Shib) are violating any requirements.

The text I quoted appears to me to specify a mandatory requirement ("MUST") to verify the elements in question. Personally, I'd read that to be a requirement to error out in the case of a verification failure there. I guess it's that last point you disagree with?

> In my
> previous message, I was referring to this requirement in SAML Core:
>
> "If the index specified is invalid, then the identity provider MAY
> return an error <Response> or it MAY use the default location."

Yes, the index case is slightly more difficult to interpret, partly because it's not clear that "belonging" is an appropriate term when we're talking about an index but also because the two specs appear to conflict in this case.

> That why I asked whether AssertionConsumerServiceIndex or
> AssertionConsumerServiceURL are involved.

Yes, the cases are slightly different, as above. I've been assuming we've been talking about the more common URL case, fwiw.

> What is the harm sending a response to the default location in
> metadata? If that's a security issue, then so is any IdP-first flow.

The harm is that you're responding to an invalid message rather than reporting it.

-- Ian

[Michael A Grady]

On Jul 14, 2014, at 9:39 AM, Ian Young <i...@iay.org.uk> wrote:

>
> On 11 Jul 2014, at 16:29, Tom Scavo <trs...@gmail.com> wrote:
>
>> On Fri, Jul 11, 2014 at 10:04 AM, Ian Young <i...@iay.org.uk> wrote:
>>>
>>>> Whether the request is signed or not, the identity provider
>>>> MUST ensure that any <AssertionConsumerServiceURL> or
>>>> <AssertionConsumerServiceIndex> elements in the request are verified as belonging to the service
>>>> provider to whom the response will be sent. Failure to do so can result in a man-in-the-middle attack.
>>>
>>> This is at line 432 of 4.1.4.1 of the profiles spec.
>>
>> Yes, of course, but there's no evidence that either of the
>> implementations (SSP or Shib) are violating any requirements.
>
> The text I quoted appears to me to specify a mandatory requirement ("MUST") to verify the elements in question. Personally, I'd read that to be a requirement to error out in the case of a verification failure there. I guess it's that last point you disagree with?
>
>> In my
>> previous message, I was referring to this requirement in SAML Core:
>>
>> "If the index specified is invalid, then the identity provider MAY
>> return an error <Response> or it MAY use the default location."
>
> Yes, the index case is slightly more difficult to interpret, partly because it's not clear that "belonging" is an appropriate term when we're talking about an index but also because the two specs appear to conflict in this case.
>
>> That why I asked whether AssertionConsumerServiceIndex or
>> AssertionConsumerServiceURL are involved.
>
> Yes, the cases are slightly different, as above. I've been assuming we've been talking about the more common URL case, fwiw.

In the case I'm dealing with with SSP, it is indeed a URL, not an index, being sent. This has been a great discussion, as I hadn't yet consulted the specs to see if there was a "mandated" behavior. It was "surprising" behavior to both sides, although it is a signed authn request, and I/we weren't necessarily worried about it from a security perspective, more from the "just trying to understand what was happening perspective." Although I haven't looked/tested whether this behavior is the same whether or not the authn request is signed.

>> What is the harm sending a response to the default location in
>> metadata? If that's a security issue, then so is any IdP-first flow.
>
> The harm is that you're responding to an invalid message rather than reporting it.
>
> -- Ian
>

--
Michael A Grady
mapg...@gmail.com

[Tom Scavo]

On Mon, Jul 14, 2014 at 10:39 AM, Ian Young <i...@iay.org.uk> wrote:
>
> On 11 Jul 2014, at 16:29, Tom Scavo <trs...@gmail.com> wrote:
>
>> On Fri, Jul 11, 2014 at 10:04 AM, Ian Young <i...@iay.org.uk> wrote:
>>>
>>>> Whether the request is signed or not, the identity provider
>>>> MUST ensure that any <AssertionConsumerServiceURL> or
>>>> <AssertionConsumerServiceIndex> elements in the request are verified as belonging to the service
>>>> provider to whom the response will be sent. Failure to do so can result in a man-in-the-middle attack.
>>>
>>> This is at line 432 of 4.1.4.1 of the profiles spec.
>>
>> Yes, of course, but there's no evidence that either of the
>> implementations (SSP or Shib) are violating any requirements.
>
> The text I quoted appears to me to specify a mandatory requirement ("MUST") to verify the elements in question. Personally, I'd read that to be a requirement to error out in the case of a verification failure there. I guess it's that last point you disagree with?

Where does it say in the spec that the IdP MUST return a SAML error to
the SP? (If it says that, I'm guessing that most of the IdPs in the
world are violating the spec.)

>> What is the harm sending a response to the default location in
>> metadata? If that's a security issue, then so is any IdP-first flow.
>
> The harm is that you're responding to an invalid message rather than reporting it.

That just happens to be ONE way of looking at it. From my view, the
IdP is dropping the request on the floor and then turning around and
pushing an IdP-initiated response to the SP. Seems perfectly
reasonable to me (or at least it doesn't violate any protocol spec or
deployment profile that I'm aware of).

What we want IdPs to do and what they actually do are two different
things. I think you'll agree that the user experience would be better
if ALL IdPs responded to ALL AuthnRequests, even if it means the IdP
sends a SAML error to the SP. In that way, the user isn't stranded and
the SP has some hope of dealing with the error. (At least that's what
we promote here in the InCommon Federation but I can tell you it's a
real hard sell.)

Tom

[Jaime Pérez Crespo]

Hi,

On 14 Jul 2014, at 16:39 pm, Ian Young <i...@iay.org.uk> wrote:
>> What is the harm sending a response to the default location in
>> metadata? If that's a security issue, then so is any IdP-first flow.
>
> The harm is that you're responding to an invalid message rather than reporting it.

Quite an interesting discussion. In general I would say I side with Tom in this case. I am usually quite concerned about security, but I also think we have to be very careful about usability and user experience. In this case, I would really like to see what exactly is the security threat that could arise from replying to the endpoint defined in metadata in case you get a request specifying an invalid endpoint.

With unsigned requests, it could be easy to forge a request asking the response to be sent to a malicious site, so that an attacker can get the attributes (or at least as many as the original service provider requested) of the user. If requests are signed, and the signature validates, the attacker would have need access to the SP’s private key in order to forge a request and get the signature to validate. That’s a very bad scenario indeed. In any way, if the IdP replies to the default location in the metadata, the attacker cannot get the assertion back in any way, so what’s exactly the attack surface in here?

In my opinion, failure to validate the AssertionConsumerService in the request MUST be logged so that at least you have a detection mechanism that can trigger appropriate actions from the IdP administrators. But nothing else. If the ACS does not validate but the request is properly signed, then some misconfiguration happened. It could be either of:

- the SP is misconfigured, sending ACS’ in the requests that do not actually match the one declared in the metadata, or even misbehaving like the case Peter case describing, or
- the IdP is misconfigured, maybe using outdated metadata.

In the first case, responding to the default location would just work for the user, and note a warning in the logs for the IdP administrators. In the second, authentication will fail in any case, the user will see it clearly, and he or she’ll be able to complain so that the misconfiguration gets fixed. So unless there’s some important security threat that I’m missing here, I honestly don’t see the benefit of erroring out, while I see serious usability pitfalls.

--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost