OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [saml-dev] SAML V2.0 Holder-of-Key Web Browser SSO Profile notimmune against man-in-the-middle attack

Hi Tom/Nate,

Thanks for the feedback; it seems that you had a hard week-end because of me :-(
I'd like to clarify a point, and to propose a possible solution.
  1. The spec states that you need to use the same TLS keys/certificate to establish your session with your IdP and your SP, and the link is done in the assertion
  2. The TLS certificate does not have to be an "official" one (like a national eID one we begin to have in most European countries), in order
  • to not mandate a PKI
  • to allow some anonymity at the SP side
If we do not have any official (registered) certificate, MitM will always be possible, as no session can ever be secured. Under these circumstances, this profile can only provide little help. However, if we have an eID certificate, it is possible to completely secure the sessions by using the same "official" certificate with both the IdP and the SP. The only problem is that we cannot have anonymity any more.

Proposition: instead of stating that the key/certificate bind in the assertion and used with the SP must come from the TLS authentication to the IdP, why not extending this to "a key/certificate sent to the IdP in a secure way"? This would allow to authenticate to the IdP with TLS and an official certificate (secure channel protected against MitM), and to send the key/certificate you want to use with your SP inside this channel.
This would totally protect against MitM, keeping privacy.

By the way, this would also allow other types of secure channels than TLS between the user and the IdP, like a GSM based channel, etc.

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 21 50   - LinkedIn

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

Tom Scavo wrote:
ea2af9bd0904261639p4bfaf7f2ta38f7959fba3e053@mail.gmail.com" type="cite">
[cc'ing the SAML Public Comment list since the Holder-of-Key Web
Browser SSO Profile is under Public Review at this time]

Hi Marc,

Thanks for the note, and sorry for not replying sooner.  Yes, you
bring up a good point.  Either the statements involving the
"man-in-the-middle" need to be removed or additional requirements need
to be added that make the statements true.  I've been discussing this
with the spec's primary author, Nate Klingenstein, offline (as you
know).  Your suggestion to use a known key seems reasonable.

Again, thanks for the feedback.


On Thu, Apr 16, 2009 at 8:52 AM, Marc Stern <marc.stern@approach.be> wrote:

I'd like to point out that man-in-the-middle attack is still possible with
this profile (I suppose some are aware about this, as it is stated in the
document "virtually eliminates man-in-the-middle attacks"). If an attacker
can sit in the middle of both connections (to IdP & SP), it could act as a
proxy, and use its own key in both cases, which will be consistent with the
SAML request.
The only solution is to use a known key to connect to the IdP (with an
official certificate), which poses a privacy problem, as you will be obliged
to connect to the SP with your "official" credentials.

Any envisioned work on this (double key authentication or equivalent)?


Marc Stern

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]