[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] FW: SAML 2.0 and Man in the Middle attacks
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]