[OpenID] ANN: OpenID Information Cards spec and workingimplementation

Johnny Bufu johnny at sxip.com
Tue Aug 28 18:08:44 UTC 2007


Thanks a lot for the feedback Peter! I have some comments and  
questions inserted inline.


On 27-Aug-07, at 6:04 PM, Peter Williams wrote:
> Johnny: Some comments and initial conclusion following, merely  
> trying to comprehend what I am reading.
>
>
>
> (1)     It makes sense that the MSFT CardSpace process on the WinNT  
> host acts as trusted relay between two web sessions. This make  
> better sense __in assurance terms__ than making an OP using a  
> general thread pool perform less-trustworthy layer 7 gatewaying.
>
>
> a.      However, the overall security concept places an even higher  
> trust burden on the OP, charged with issuing a dumb-mode  
> verification token attesting to its belief that the OpenID Auth  
> Response provided by the STS is valid.

That's the general OpenID approach. The flow we're proposing is  
"OpenID wrapped into Infocard".

> b.      The trust burden placed on an OP mitigates against the  
> assurance rationale offered in (1), unless it’s a specific design  
> intent to separate the roles of STS and OP (similar to how  
> Authenticode CAs perform an entirely different role to the role  
> performed by Authenticode’s so-called timestamp authorities)
>
>
> (2)     All webSSO communications involving an infocard both to and  
> from a RP website MUST use infocard-defined protocols and signaling  
> (hidden form fields, object tags, XHTML behaviors, object  
> properties for claimset requirements)
>
>
> a.      The specification would seem to limit itself to HTML- 
> capable, MIME capable, HTTP systems.
>
>
> (3)     By referencing attached and unattached OpenID tokens, the  
> infocard protocol implementation uniquely shall decide which  
> communications security services shall be applied to token passing,  
> if any.
>
>
> a.      The strength of the reference  is dependent on the strength  
> of SHA1, a suspect candidate.

Can you detail why, or give me a hint on a better approach (ideally  
supported by the infocard layer, of course)?

> (4)     Communications between the cardspace trusted process and  
> the STS MUST use ws-federation active
>
>
> (5)     The OP SHALL support two endpoints: (i) OpenID Auth and  
> (ii) ws-federation active

Yes - that's what we have in our implementation :
/TokenService/* for the Higgins STS
/op for the OpenID Provider endpoint


> (6)     A “stub” OpenID Auth 2.0 protocol handler MUST be co- 
> resident with the STS handler supporting the ws-federation active  
> endpoint.
>
> a.      The protocol engine of the OpenID Auth 2.0 handler MUST be  
> limited to
>
> i.      manufacturing OpenID tokens
>
> ii.     manufacturing OpenID Auth Response messages to be wrapped  
> in OpenID Tokens, and
>
> iii.    possibly  “supporting” dumb mode verification procedures  
> for OpenID Auth Response messages it knows it has previously wrapped

True, and that's what the OpenID Higgins token extension does in our  
implementation. The stateless verification functionality / endpoint  
is not baked into the STS itself, though it could be done.

The STS and the OP do need to share the secret (private association)  
used by the former to sign the issued OpenID Auth Responses (so that  
the OP can actually perform the verification when the RP comes asking).

> b.      OpenID Tokens MUST wrap only OpenID Auth Response messages  
> by the thread operating the ws-federation active endpoint.
>
>
> (7)     A complete OpenID Auth protocol handler shall be listening  
> on the OpenID Auth endpoint.
>
> a.      It MUST NOT be able to manufacture OpenID Tokens
>
> b.      It MUST NOT be able to perform dumb mode verification  
> procedure on any Auth Response message that has ever been wrapped  
> in an OpenID Token
>
> c.      The Message queues shall be compartmentalized from queues  
> supporting the stub OpenID Auth protocol handler.
>
> d.      The protocol engine may support any version of OpenID Auth

Not sure what you mean by "complete". In our implementation the OP (/ 
op endpoint) only deals with direct (stateless) verification requests  
and nothing else.

> (8)     An RP MUST rely on SSL to authenticate an OP Provider  
> performing dumb-mode verification of Auth Response messages.

True, but that's a general thing, not specific to the modified flow  
we're proposing.
> a.      An RP may rely on PKI/certs signals to determine that a  
> given OP Provider is entitled to speak for the verification of  
> tokens issued by a given STS.

Possible, however in OpenID the discovery mechanism is used for this.

> b.      A PKI control system may obviate the need for 6a(iii) when  
> the RP can be trusted to handle PKI signals in a conforming manner
>
>
>
> Initial conclusions:-
>
>
> A.      It’s complicated set of trusted channel and trusted process  
> relationships.

Trust is complicated in general, I don't think anyone would disagree  
here. :-)

However I don't think the modified flow we're proposing changes the  
trust relationships:

- the RP trusts the authoritative OP for the OpenID it receives
- the STS/OP can be seen as one (trust) entity, though they can be  
deployed separately (but they are still controlled by the same one  
entity, the IdP, which has full control over them, so any trust  
issues between these can be dealt with internally and not exposed to  
the RP or of influence to the protocol flow)


>  B.      The purpose of doing all what follows is to eliminate “the  
> "Rogue Relying Party Proxying" attack described in the Security  
> Consideration section of [OpenID.authentication 2.0] (Recordon, D.,  
> Hoyt, J., Fitzpatrick, B., and D. Hardt, “OpenID Authentication 2.0  
> - Draft 11,” January 2007.).”


That's one benefit. Another one is the consistent user experience  
(for Infocard / selector users).

> C.      Several protocols must be integrated – protocols that were  
> not designed as a family: ws-fed, Openid Auth, https/SSL/PKI,  
> infocard.

HTTPS/SSL will not be required for the RPs; for the STS/OP I don't  
think it's an issue.

Infocard was designed to transport token of types different than just  
SAML 1.1 (that's most commonly used), but I don't think Infocard +  
OpenID token is more difficult that Infocard + SAML token.

> D.      It is critically dependent on trustworthy http channels:  
> e.g. https, SSLVPNs, IPSEC VPN, or equivalent. https is also a  
> critical security enforcing function in authenticating the validity  
> of claims.

True, but that's again generally valid, whether you're dealing with a  
SAML token or an OpenID token.

> E.      There is not a lot left of OpenID Auth, apart from the  
> definition of KV Form of Auth Response, and dumb mode verification  
> flow.
>
> F.      The role of OpenID AX seems mostly unchanged
>
> G.      The control relationship between infocard authority  
> (service discovery), token authorities  (claim provider), token  
> verification authorities (current validity of claims), and critical  
> https endpoints will require advanced, highly coordinated PKI.

Not sure why you see PKI as the only way to deal with these. They can  
be (web) applications living on the IdP's network, over which the IdP  
has full control through various means.

> H.      The RP-centric discovery and locating process (via HTML and  
> XRI metadata) is eliminated in favor of card-discovery and server- 
> location processes mediated by the Cardspace process on the browser  
> host, as directed by the infocard protocol.

That's not entirely so. The card "knows" the STS/OP who issued it -  
this replaces the first discovery step normally performed by the RP  
(and eliminates the phishing attack).

When the RP does get the OpenID Auth Response it does have to verify  
it, and discovery is one of the verification steps.

> I.      The implementer of an OP must implement several SOAP and  
> WS* vocabularies in order to process an RSTR
>
>
>                    xmlns:ic="http://schemas.xmlsoap.org/ws/2005/05/ 
> identity"
>
>                xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
>
>                xmlns:wsa="http://www.w3.org/2005/08/addressing"
>
>                xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/ 
> oasis-200401-wss-wssecurity-secext-1.0.xsd"
>
>                xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"
>
>                xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/ 
> oasis-200401-wss-wssecurity-utility-1.0.xsd">
>

Yes, the OP has to also be an STS (or the other way around). Our  
focus was to make it as simple as possible for the RPs - and the  
changes needed there are minimal.



Johnny





More information about the general mailing list