Re: [security-services] FW: SAML 2.0 and Man in the Middle attacks

["Tom Scavo" <trscavo@gmail.com>]

Hal,

Does the emerging SAML V2.0 Holder-of-Key Web Browser SSO Profile meet
these requirements?  It seems like it does.

Tom

On Thu, Sep 11, 2008 at 11:10 AM, Hal Lockhart <hal.lockhart@oracle.com> wrote:
> 2nd of 2 messages from Approach Belgium.
>
>
>
> Can anyone suggest any current work which could be used for this? Is anyone
> interested in getting involved in this?
>
>
>
> Hal
>
>
>
> ________________________________
>
> From: marc.stern@approach.be [mailto:marc.stern@approach.be]
> Sent: Wednesday, September 03, 2008 6:23 AM
> To: hal.lockhart@oracle.com
> Cc: bcampbell@pingidentity.com; paulmadsen@ntt-at.com;
> robert.philpott@rsa.com; eve.maler@sun.com; jamie.clark@oasis-open.org
> Subject: Re: SAML 2.0 and Man in the Middle attacks
>
>
>
> Hal,
>
> Thank you for the answer.
> I was probably a bit quick and not precise enough, sorry about that.
> Here is the point.
>
> We have the usual situation where a Service Provider delegates citizen
> authentication to a Government Identity Provider. In theory, any
> authentication mechanism could be used.
>
> When using standard browsers, we can only use the Web browser SSO profile,
> which is not immune to MITM attacks between the client and the SP (MITM
> between client and IDP is out of scope and should be solved at IDP level).
> The only way to effectively stop these attacks is to have a secure channel
> with mutual authentication between the client and the SP. Here is a
> conceptual description of the steps
>
> generate a key pair on the client
> sign the public key (or a hash obviously) together with the authentication
> data
> have that public key signed in the SAML assertion
> use the generated key pair to establish the communication (SSL/TLS) with the
> SP
>
> The above steps assume that the authentication mechanism supports a digital
> signature mechanism.
>
> By using the ECP profile, I assume it could be possible to protect against
> MITM attacks, but we have to add some specific logic at the ECP level, at
> the IDP level, and at the SP level. Do I understand correctly ?
> Potential problems:
>
> We so cannot use a standard SAML toolkit at the SP & IDP level, but we have
> to perform a dedicated implementation. Or will all toolkits supports
> extensions for ECP developed independently of the toolkit ? I guess not, as
> you have things like verification of the SSL/TLS channel.
> Furthermore, to implement ECP profile at the browser level, we need to add a
> plug-in to every browser (thus IE, FF, Safari, Opera, ...), possibly on each
> platform (if the code is compiled)
>
> These problems, and especially the second one, led several countries to
> choose for a complete independent implementation which would use a kind of
> stand-alone ECP, and thus another protocol.
>
> Here are my concrete questions/concerns:
>
> Are the problems I described correct ?
> Is there any (almost) standard ECP sub-profile that could solve these
> problems, like CardSpace ?
> Is there any other profile with a completely different approach that could
> solve the problem ?
>
> Thanks
>
> Marc Stern
> Senior Consultant - Security Group Head
> Approach Belgium - http://www.approach.be
> Avenue Einstein, 2A   -    B-1348 Louvain-la-Neuve   -     Belgium
> Tel: +32 10 83 21 36   -    GSM: +32 475 68 29 10    -   Fax: +32 10 83 22
> 55   - LinkedIn
>
> Disclaimer_____________________________________________________________________________
> 1. This message is intended for the use of the addressee only and may
> contain information that is privileged and confidential.
> 2. If you are not the intended recipient, you are notified that any
> dissemination of this Communication is strictly prohibited.
> 3. If you have received this communication in error, please notify us
> immediately by return of this e-mail.
> 4. E-mail quotations and proposals are for information only, and are subject
> to confirmation by the Signature of the appropriate contractual
> documentation by the authorized persons or both
>
> Hal Lockhart wrote:
>
> Marc,
>
>
>
> It is not accurate to say that generically SAML is not immune to MITM
> attacks. SAML defines a variety of bindings and profiles which accept
> different requirements and constraints and as a result have different
> security properties.
>
>
>
> It seems most likely what you have in mind are some of the Web Browser
> profiles which accept the use of a standard off-the-shelf Web Browser as the
> client agent and thus accept the limitations imposed by these products.
> (Note that other specifications, such as WS-Federation which accept the same
> restrictions have the same limitations.)
>
>
>
> Perhaps if you could provide additional information about the requirements
> of your project, we could advise you as to which profiles might be
> appropriate. If no existing profile meets you requirements, it would not be
> difficult to define one which does. In addition to profiles which are
> already OASIS Standards, we have more than a dozen in progress, all designed
> to meet the needs of specific environments, including the US government and
> various European organizations.
>
>
>
> I would also encourage you to become active in the SAML Technical Committee
> (SSTC). In addition to being able to define or influence new specifications,
> the committee members have a wide range of knowledge of the use of SAML to
> meet different kinds of requirements.
>
>
>
> Hal
>
>
>
> From: marc.stern@approach.be [mailto:marc.stern@approach.be]
> Sent: Tuesday, September 02, 2008 10:40 AM
> To: hal.lockhart@oracle.com ; bcampbell@pingidentity.com;
> paulmadsen@ntt-at.com; robert.philpott@rsa.com; eve.maler@sun.com;
> jamie.clark@oasis-open.org
> Subject: SAML 2.0 and Man in the Middle attacks
>
>
>
> Hello,
>
> I am currently leading the technical part of a big European project
> (http://www.eid-stork.eu/) targeting federated identity between EU
> countries.
>
> We are obviously looking at SAML, but we have a major concern, as it is not
> immune at all against MITM attacks.
> Several countries are in favor of developing an alternative protocol (like
> TLS-Federation - ), but I would like to check with you if this problem was
> ever tackled.
>
> Did you provide any work on this ?
> Could this be solved by any way ?
> How does it integrate with CardSpace ? Could such a combination solve the
> problem ?
>
> Thank you
>
> --
>
> Marc Stern
> Senior Consultant - Security Group Head
> Approach Belgium - http://www.approach.be
> Avenue Einstein, 2A   -    B-1348 Louvain-la-Neuve   -     Belgium
> Tel: +32 10 83 21 36   -    GSM: +32 475 68 29 10    -   Fax: +32 10 83 22
> 55   - LinkedIn
>
> Disclaimer_____________________________________________________________________________
> 1. This message is intended for the use of the addressee only and may
> contain information that is privileged and confidential.
> 2. If you are not the intended recipient, you are notified that any
> dissemination of this Communication is strictly prohibited.
> 3. If you have received this communication in error, please notify us
> immediately by return of this e-mail.
> 4. E-mail quotations and proposals are for information only, and are subject
> to confirmation by the Signature of the appropriate contractual
> documentation by the authorized persons or both