OpenID 2.0 proposed security profiles

Joaquin Miller joaquin at netmesh.us
Wed Aug 30 15:26:58 UTC 2006


Hans:

Thanks for this excellent and absolutely essential analysis.

As to the proposed profiles, I feel you have done a fine job of 
keeping it simple.

Cordially, Joaquin


Hans Granqvist wrote:
>
>Hi
>
>I propose the following profiles as addition to OpenID auth
>spec. In the OpenID spirit, I have tried to keep these
>profiles as simple to implement as possible.
>
>The idea here is to list security-related variants in the spec
>and then specify a few profiles to require certain subsets of
>these variants. The IDP and the RP may publish compliance with
>profile(s) in their discovery documents.
>
>Note: the list of security variants is not implicitly complete.
>
>Some variants are enforceable only via cooperation IDP/RP. This
>means there are sometimes no way in the protocol to detect
>whether a party complies to that variant of a profile. (For
>example, variant 5 listed below is of this type.)
>
>Also note that some variants are identified because of possible
>future security threats.
>
>
>Variants
>--------
>
>Notes on the variants relate to draft #9.
>
>
>1.  Wildcards allowed in trust roots            one of Yes/No
>
>Whether the IDP accepts wild carded trust roots as specified
>in section 8.2
>
>
>2.  Stateless associations accepted             one of Yes/No
>
>If the IDP agrees to process authentication messages with
>no assoc_handle in section 8.
>
>
>3.  Types of claimed identifiers accepted       set of
>                                                Http/Https/XRI
>
>Types of identifiers as enumerated in section 9.3.
>
>
>4.  Self-issued certificates allowed            one of Yes/No
>
>Applies to all https traffic. If 'no' here, then Idp
>*probably* requires all https identifiers to chain up to
>known trust roots, but that's intentionally not implied.
>
>
>5.  XRDS file must be signed                    one of Yes/No
>
>Signature on the XRDS as per XMLDSIG. Keying material not
>specified, since RP ultimately needs to make own decision
>whether to trust keys used for such signature.
>
>
>6.  XRDS must be retrieved over secure channel  one of Yes/No
>
>This does not imply SSL. See note on 4. about trust roots.
>
>
>7.  Accepted association session types          set of
>                               No-encryption/DH-SHA1/DH-SHA256
>
>What types of session types can be used as defined
>in section 7.4.3
>
>
>8.  Accept shared MAC keys                      one of Yes/No
>
>The spec is a bit muddled on what these imply in
>section 9.2.2.2.
>
>
>9.  RP must have XRDS                           one of Yes/No
>
>Should the relying party be required to advertise
>compliance with specific profiles as per section 11.
>
>
>10. Accepted association types   set of HMAC-SHA1/HMAC-SHA256
>
>What section 7.3. association types the IDP agrees to
>use for signatures.
>
>
>11. Association must be over secure channel     one of Yes/No
>
>Whether the 7.4.1 request must take place on a
>secure channel.
>
>
>12. Allow IDP to select identifier              one of Yes/No
>
>Whether the idp allows the identity to be set to
>http://openid.net/identifier_select/2.0
>
>
>
>Profiles
>--------
>The following two profiles "A" and "B" are examples I think
>should be stated in the specification or a rider to the same
>doc. The identifier of these profiles would be a URL that
>appends to http://openid.net/auth/2.0/.
>
>The names "A" and "B" should of course be discussed. I don't
>want to name then "low security" and "medium security" as
>such distinctions carry implications and liabilities. (There
>is also a risk of security creep that forces definitions to
>change over time -- what is now 'medium security' could be
>'low security' in a few years, and possibly 'useless security'
>in yet another few years. But the definition will be stuck as
>'medium security' forever.)
>
>I don't think (although I am not sure) compliance to a specific
>profile should be mandatory in the OpenID auth spec itself.
>
>
>Profile A
>http://openid.net/auth/2.0/A
>1.  Yes
>2.  Yes
>3.  Http/Https/XRI
>4.  Yes
>5.  No
>6.  No
>7.  DH-SHA1/DH-SHA256
>8.  No
>9.  No
>10. HMAC-SHA1/HMAC-SHA256
>11. No
>12. Yes
>
>
>Profile B
>http://openid.net/auth/2.0/B
>1.  Yes
>2.  No
>3.  Http/Https/XRI
>4.  Yes
>5.  No
>6.  No
>7.  No-encryption
>8.  No
>9.  No
>10. HMAC-SHA1/HMAC-SHA256
>11. Yes
>12. Yes
>
>
>Processing
>----------
>In the specification, we need to add how to handle error states
>when profiles are not followed.  Currently the protocol is quiet
>on how any such processing is done.
>
>I propose the protocol should not contain any graceful
>degradation.
>
>Next step would be to discuss if these profiles make sense to
>the community and how to deal with errors when one party becomes
>aware the other party is not compliant to a specific profile.
>
>
>Thanks,
>Hans
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/yadis/attachments/20060830/a6c594f2/attachment.htm


More information about the yadis mailing list