OpenID 2.0 proposed security profiles

Wed Aug 30 19:54:38 UTC 2006

I'd like to echo Joaquin's comments. This is very useful.

And i'd like to echo Hans' comment in particular about error  
handling, error reporting, etc. If user A uses IdP B to assert  
identity at RP C, and it doesn't work, what do we want to the user to  
do, specifically? Call B? Call C? Call OpenID Inc.? (okay, I made  
that up).

On Aug 30, 2006, at 8:26, Joaquin Miller wrote:

> 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
>>
>>

Johannes Ernst
NetMesh Inc.

 http://netmesh.info/jernst

-------------- next part --------------
Skipped content of type multipart/related