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
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