OpenID 2.0 proposed security profiles

[Granqvist, Hans]

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/58e10c58/attachment.html