[Openid-specs-ab] Preveinting Artifact Capture Attack for RPF case

John Bradley jbradley at mac.com
Mon May 10 18:39:52 UTC 2010


The problem you describe is not in any way unique to AB.

It is a problem that any sort of Bearer Token has.   

If you pass a complete assertion or artifact it could be intercepted.  Sometimes in the browser or by a MTM attack that the user ignores a browser warning about.

In SP800-63 you only need to protect against this at LoA 4.

You need to audience restrict and protect the information in the token at LoA 3, but that is a separate issue.

The way the issue is normally addressed at LoA 4 is to use a holder of key token.

This can be a symmetric or asymmetric key that the presenter of the token must prove that they have knowledge of.

The most common is that if a Public/Private keypair is used to authenticate to the OP the OP includes the public key used as part of the user authentication in the assertion.  The RP can then request mutual TLS from the browser to prove it is the same browser that authenticated to the OP.

We are including a optional additional parameter for the OP to pass the publicKey.   It is not all that likely to be used but in principal we are on a Par with SAML and others for supporting HoK assertions.

John B.

On 2010-05-07, at 11:47 PM, Nat Sakimura wrote:

> The attack that I care about here is as follows: 
> 
> 1. An attacker creates an authentication request URL. 
> 2. Then attacker sends it to the victim. 
> 3. The victim clicks the link and authenticates himself to the OP. 
> 4. The attacker somehow stops the victim getting redirected to the RP. 
> 5. The attacker uses the artifact to access the RP. 
> 6. The RP obtains the assertion based on the artifact so that the attacker successfully impersonates the victim. 
> 
> It seems for this attack to succeeds, the attacker needs to have the control of the victim's browser. 
> (because all the sessions are over TLS/SSL, this is the only point that an attacker can obtain the artifact.) 
> 
> Do we need to care for it? I doubt it since if the attacker has the control over victim's browser, he can practically do anything. 
> 
> I came to think about it when I was writing a security consideration against assertion substitution attack. 
> Your inputs are most welcome. 
> 
> -- 
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20100510/2934d00d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20100510/2934d00d/attachment.bin>


More information about the Openid-specs-ab mailing list