|
1 | | -<!-- -*- mode: Text; eval: (auto-fill-mode 1); -*- --> |
2 | | -<pre class='metadata'> |
3 | | -Title: Accountable Digital Identity Association (ADIA) Security Reference |
4 | | -Shortname: adia-secref |
5 | | -Prepare for TR: true |
6 | | -Level: 1 |
7 | | -Status: ED |
8 | | -Group: fido |
9 | | -URL: |
10 | | -Editor: Rolf Lindemann, rolf@noknok.com |
11 | | -
|
12 | | -Abstract: The ADIA Security Reference describes the ADIA security goals, assets to be protected, the security measures and the relation between security measures and goals. |
13 | | -
|
14 | | -Issue Tracking: GitHub https://github.com/ADIAssociation/ADIA-specification/issues |
15 | | -Text Macro: INFORMATIVE <em>This section is not normative.</em> |
16 | | -Text Macro: NORMATIVE <em>This section is normative.</em> |
17 | | -Boilerplate: omit conformance, omit feedback-header, omit abstract-header |
18 | | -Local Boilerplate: header yes, footer yes, logo yes, copyright yes |
19 | | -Markup Shorthands: css off, markdown on |
20 | | -</pre> |
21 | | -
|
22 | | -<pre class="link-defaults"> |
23 | | -spec:html; type:dfn; for:environment settings object; text:global object |
24 | | -spec:infra; type:dfn; text:list |
25 | | -spec:url; type:dfn; text:domain |
26 | | -spec:url; type:dfn; text:valid domain; |
27 | | -spec:webappsec-credential-management-1; type:dictionary; for:/; text:CredentialRequestOptions |
28 | | -spec:webidl; type:interface; text:Promise |
29 | | -</pre> |
30 | | -
|
31 | | -<!-- only put content here if you want a custom status of document not |
32 | | - the specification-maturity-appropriate boilerplate --> |
33 | | -
|
34 | | -# ADIA Security and Privacy Goals # {#sctn-adia-secref-goals} |
35 | | -1. Allow Users to present a claim to the service provider, where |
36 | | - 1. SG-1: the service provider can verify that the shared claim was issued by an Issuer belonging to the ADIA ecosystem (and the assurance level this issuer was vetted at) and |
37 | | - 2. SG-2: the service provider can verify that the entity presenting the claim is the subject of that claim |
38 | | -2. SG-3: Ensure that the user needs to consent with the action of sharing the claim(s) |
39 | | -3. SG-4: Ensure that the user can select the claims to be shared (not only all claims or none). |
40 | | -4. SG-5: Ensure the issuer doesn't learn who the service provider is (Note: the service provider will learn who the issuer is) |
41 | | -5. SG-6: Ensure that a service provider that receives two claims doesn't learn whether the two claims belong to the same user *beyond* the degree of overlapping claims, i.e. We don't introduce another correlation handle. For example, if a service provider receives two claims that the respective subject is older than 21, there is no way for the service provider to know whether the two claims belong to the same or two different users. In the case the full name, birthdate etc. are included in the claims the service provider will learn that two claims containing the same attributes will likely or even certainly relate to the same users. |
42 | | -6. SG-7: Assessable level of assurance - throughout the system (IAL and AAL) |
43 | | -7. SG-8: Robust minimum assurance level with |
44 | | - 1. Credential guessing resilience, i.e. provide robust protection against eavesdroppers, e.g. be resilient to physical observation, resilient to targeted impersonation, resilient to throttled and unthrottled guessing |
45 | | - 2. Credential Disclosure Resilience: Be resilient to phishing attacks and real-time phishing attack, including resilience to online attacks by adversaries able to actively manipulate network traffic |
46 | | - 3. Verifier Leak Resilience: Be resilient to leaks from other relying parties. I.e., nothing that a verifier could possibly leak can help an attacker impersonate a user to another relying party (e.g. claim's subject to service provider or user to issuer). |
47 | | - 4. Credential Leak Resilience: Be resilient to leaks from other credentials. I.e., nothing that a particular credential could possibly leak can help an attacker to impersonate a user |
48 | | - 5. Forgery Resistance: Be resilient to Forgery Attacks (Impersonation Attacks). I.e. prevent attackers from attempting to modify intercepted communications in order to masquerade as a legitimate user and/or provide invalid claims. |
49 | | - 6. Parallel Session Resistance: Be resilient to Parallel Session Attacks. Without knowing a user's credential, an attacker can masquerade as the legitimate user by creating a valid message out of some eavesdropped communication between the user and an issuer or service provider. |
50 | | - 7. Forwarding Resistance: Be resilient to Forwarding and Replay Attacks. Having intercepted previous communications, an attacker can impersonate the legitimate user or provide invalid claims to the system. The attacker can replay or forward the intercepted messages. |
51 | | - |
52 | | -Issue: The DAS will learn whenever claims are presented - this needs |
53 | | - to be discussed somewhere. |
54 | | -
|
55 | | -# ADIA Assets to be Protected # {#sctn-adia-secref-assets} |
56 | | -See section "Trust Model" of the ADIA specification. |
57 | | -
|
58 | | -1. Private keys of: |
59 | | - 1. ADIA Global Directory |
60 | | - 1. ADIA Regional Directory |
61 | | - 1. Digital Address Service (DAS), key maintained by the DAS agent. |
62 | | - 1. Issuer, key maintained by the Issuer Agent. |
63 | | - 1. Service Provider, key maintained by the Service Provider Agent. |
64 | | - 1. User |
65 | | - 1. DAS User ID key, maintained by the DAS User Agent |
66 | | - 2. FIDO keys, maintained by the user's FIDO Authenticator(s), and all other FIDO related assets that need protection, see |
67 | | - <a href="https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-security-ref-v2.0-id-20180227.html#assets-to-be-protected">FIDO |
68 | | - Security Reference</a>. |
69 | | -
|
70 | | -
|
71 | | -# ADIA Security Measures # {#sctn-adia-secref-measures} |
72 | | -
|
73 | | -Issue: TODO |
74 | | -
|
75 | | -## Relation between Measures and Goals ## {#sctn-adia-secref-measgoals} |
76 | | -
|
77 | | -Issue: TODO |
78 | | -
|
79 | | -# ADIA Security Assumptions # {#sctn-adia-security-assumptions} |
80 | | -
|
81 | | -Issue: TODO |
82 | | -
|
83 | | -# Threat Analysis # {#sctn-adia-threat-analysis} |
84 | | -
|
85 | | -Issue: TODO |
86 | | -
|
| 1 | +<!-- -*- mode: Text; eval: (auto-fill-mode 1); -*- --> |
| 2 | +<pre class='metadata'> |
| 3 | +Title: Accountable Digital Identity Association (ADIA) Security Reference |
| 4 | +Shortname: adia-secref |
| 5 | +Prepare for TR: true |
| 6 | +Level: 1 |
| 7 | +Status: ED |
| 8 | +Group: fido |
| 9 | +URL: |
| 10 | +Editor: Rolf Lindemann, rolf@noknok.com |
| 11 | + |
| 12 | +Abstract: The ADIA Security Reference describes the ADIA security goals, assets to be protected, the security measures and the relation between security measures and goals. |
| 13 | + |
| 14 | +Issue Tracking: GitHub https://github.com/ADIAssociation/ADIA-specification/issues |
| 15 | +Text Macro: INFORMATIVE <em>This section is not normative.</em> |
| 16 | +Text Macro: NORMATIVE <em>This section is normative.</em> |
| 17 | +Boilerplate: omit conformance, omit feedback-header, omit abstract-header |
| 18 | +Local Boilerplate: header yes, footer yes, logo yes, copyright yes |
| 19 | +Markup Shorthands: css off, markdown on |
| 20 | +</pre> |
| 21 | + |
| 22 | +<pre class="link-defaults"> |
| 23 | +spec:html; type:dfn; for:environment settings object; text:global object |
| 24 | +spec:infra; type:dfn; text:list |
| 25 | +spec:url; type:dfn; text:domain |
| 26 | +spec:url; type:dfn; text:valid domain; |
| 27 | +spec:webappsec-credential-management-1; type:dictionary; for:/; text:CredentialRequestOptions |
| 28 | +spec:webidl; type:interface; text:Promise |
| 29 | +</pre> |
| 30 | + |
| 31 | +<!-- only put content here if you want a custom status of document not |
| 32 | + the specification-maturity-appropriate boilerplate --> |
| 33 | + |
| 34 | +# ADIA Security and Privacy Goals # {#sctn-adia-secref-goals} |
| 35 | +1. Allow Users to present a claim to the service provider, where |
| 36 | + 1. SG-1: the service provider can verify that the shared claim was issued by an Issuer belonging to the ADIA ecosystem (and the assurance level this issuer was vetted at) and |
| 37 | + 2. SG-2: the service provider can verify that the entity presenting the claim is the subject of that claim |
| 38 | +2. SG-3: Ensure that the user needs to consent with the action of sharing the claim(s) |
| 39 | +3. SG-4: Ensure that the user can select the claims to be shared (not only all claims or none). |
| 40 | +4. SG-5: Ensure the issuer doesn't learn who the service provider is (Note: the service provider will learn who the issuer is) |
| 41 | +5. SG-6: Ensure that a service provider that receives two claims doesn't learn whether the two claims belong to the same user *beyond* the degree of overlapping claims, i.e. We don't introduce another correlation handle. For example, if a service provider receives two claims that the respective subject is older than 21, there is no way for the service provider to know whether the two claims belong to the same or two different users. In the case the full name, birthdate etc. are included in the claims the service provider will learn that two claims containing the same attributes will likely or even certainly relate to the same users. |
| 42 | +6. SG-7: Assessable level of assurance - throughout the system (IAL and AAL) |
| 43 | +7. SG-8: Robust minimum assurance level with |
| 44 | + 1. Credential guessing resilience, i.e. provide robust protection against eavesdroppers, e.g. be resilient to physical observation, resilient to targeted impersonation, resilient to throttled and unthrottled guessing |
| 45 | + 2. Credential Disclosure Resilience: Be resilient to phishing attacks and real-time phishing attack, including resilience to online attacks by adversaries able to actively manipulate network traffic |
| 46 | + 3. Verifier Leak Resilience: Be resilient to leaks from other relying parties. I.e., nothing that a verifier could possibly leak can help an attacker impersonate a user to another relying party (e.g. claim's subject to service provider or user to issuer). |
| 47 | + 4. Credential Leak Resilience: Be resilient to leaks from other credentials. I.e., nothing that a particular credential could possibly leak can help an attacker to impersonate a user |
| 48 | + 5. Forgery Resistance: Be resilient to Forgery Attacks (Impersonation Attacks). I.e. prevent attackers from attempting to modify intercepted communications in order to masquerade as a legitimate user and/or provide invalid claims. |
| 49 | + 6. Parallel Session Resistance: Be resilient to Parallel Session Attacks. Without knowing a user's credential, an attacker can masquerade as the legitimate user by creating a valid message out of some eavesdropped communication between the user and an issuer or service provider. |
| 50 | + 7. Forwarding Resistance: Be resilient to Forwarding and Replay Attacks. Having intercepted previous communications, an attacker can impersonate the legitimate user or provide invalid claims to the system. The attacker can replay or forward the intercepted messages. |
| 51 | + |
| 52 | +Issue: The DAS will learn whenever claims are presented - this needs |
| 53 | + to be discussed somewhere. |
| 54 | + |
| 55 | +# ADIA Assets to be Protected # {#sctn-adia-secref-assets} |
| 56 | +See section "Trust Model" of the ADIA specification. |
| 57 | + |
| 58 | +1. Private keys of: |
| 59 | + 1. ADIA Global Directory |
| 60 | + 1. ADIA Regional Directory |
| 61 | + 1. Digital Address Service (DAS), key maintained by the DAS agent. |
| 62 | + 1. Issuer, key maintained by the Issuer Agent. |
| 63 | + 1. Service Provider, key maintained by the Service Provider Agent. |
| 64 | + 1. User |
| 65 | + 1. DAS User ID key, maintained by the DAS User Agent |
| 66 | + 2. FIDO keys, maintained by the user's FIDO Authenticator(s), and all other FIDO related assets that need protection, see |
| 67 | + <a href="https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-security-ref-v2.0-id-20180227.html#assets-to-be-protected">FIDO |
| 68 | + Security Reference</a>. |
| 69 | + |
| 70 | + |
| 71 | +# ADIA Security Measures # {#sctn-adia-secref-measures} |
| 72 | + |
| 73 | +Issue: TODO |
| 74 | + |
| 75 | +## Relation between Measures and Goals ## {#sctn-adia-secref-measgoals} |
| 76 | + |
| 77 | +Issue: TODO |
| 78 | + |
| 79 | +# ADIA Security Assumptions # {#sctn-adia-security-assumptions} |
| 80 | + |
| 81 | +Issue: TODO |
| 82 | + |
| 83 | +# Threat Analysis # {#sctn-adia-threat-analysis} |
| 84 | + |
| 85 | +Issue: TODO |
| 86 | + |
0 commit comments