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