[OpenID] Abusing Authentication Failure messages

[John Bradley]

SAML and other protocols can be implemented insecurely as well, and still be spec compliant.

That is why OIX, the US Gov and others are working on standards for deployment of openID and certification of IdP against those practices.

A number of IdP are currently certified, however they do support lower security for backwards computability with RP.

Have a look at:
http://openidentityexchange.org/
http://www.idmanagement.gov/drilldown.cfm?action=openID_openGOV

Properly implementing the protocol is only one part of the puzzle.

A openID RP can be implemented securely in an entirely stateless mode.   There are performance optimizations that caching, and associations can achieve.

It is up to the RP to decide if it should logout a session that is already authenticated, if it receives a authentication failure message after the initial authentication.
Depending on the site different things may be appropriate.

John B.
On 2010-08-22, at 4:37 PM, Maarten Billemont wrote:

>>> 
>>> However, consider the fact that association is optional, signing (even without association) is optional,
>> 
>> For assertions of success, the RP (by spec) MUST verify that the signature is valid (see sections 11 and 11.4 of v2.0 for more details). It is only for assertions of failure that the spec does not mandate checking signatures (although the Protocol Overview does give that impression).
> 
> Validation of signatures is required.  But signing is merely recommended; not required.  In the end, it comes down to your following reply:
> 
>> 
>>> responses are allowed to be sent over clear-text transports (revealing identity information to intermediate parties)
>> 
>> I have noted this problem before. However, the freedom OpenID affords users also carries a burden of responsibility: if YOU are going to select your own provider, then YOU are going to need to decide which features YOU want, and YOU will have to evaluate OP's to find out whether they meet YOUR standards
> 
> You have a point here.  So you're saying that, with OpenID, it's important that users know not to lay their trust in the protocol but rather in the implementation of it.  They should pick an OP that suits their requirements.
> 
> That's great in theory.  Only, in practice, technical details are always hidden from end-users.  I don't know any OPs that introduce themselves by comparing their choice of optional OpenID features implemented or degree of respect for user privacy and security.  Though I see this getting beyond the scope of this list.
> 
> Thanks for the clarification.  While personally, I'd prefer to see the protocol with the best chance of standardizing authentication be a strict and inherently secure one, I understand this was not a requirement by design.
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general

-------------- 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-general/attachments/20100822/d017945f/attachment.bin>