Security Considerations

9
Security Considerations Overall scope (in the context of the use cases) Trust models Threat models Countermeasures & rationale/assumptions Guidance to implementors and deployers Proof of correctness of the design(s) Initial stab at an overall outline: draft-sstc-sec-consider-00

description

Security Considerations. Overall scope (in the context of the use cases) Trust models Threat models Countermeasures & rationale/assumptions Guidance to implementors and deployers Proof of correctness of the design(s) Initial stab at an overall outline: draft-sstc-sec-consider-00. - PowerPoint PPT Presentation

Transcript of Security Considerations

Page 1: Security Considerations

Security Considerations

• Overall scope(in the context of the use cases)

– Trust models

– Threat models

– Countermeasures & rationale/assumptions

– Guidance to implementors and deployers

– Proof of correctness of the design(s)

• Initial stab at an overall outline:draft-sstc-sec-consider-00

Page 2: Security Considerations

Overall Resource

• Guidelines for Writing RFC Text on Security Considerations

draft-rescorla-sec-cons-03.txt

Page 3: Security Considerations

Trust Models

• Simple Example: The relying party believes (trusts that) Alice is authenticated because they have a AuthentiationAssertion saying so.

• Cf. BobB’s more detailed example.

Page 4: Security Considerations

Threat Models

• See draft-rescorla-sec-cons-03 for global set of threats in an Internet environment

• Assess use cases, bindings, and profiles to determine which threats apply in each case

• Don’t neglect second-order threats, e.g. vulnerabilities of external services one relies upon– E.g. DNS

Page 5: Security Considerations

Countermeasures & rationale/assumptions

• SecCons doc may describe overall design approaches

• Core-xx, bindings-model-xx, et al should document concise rationale/assumptions and ref SecCons

• See bindings-model-05 section 4.1.5 for examples

Page 6: Security Considerations

Guidance to implementors and deployers

• An important aspect is “mandatory to implement” items

• Examples..– Section 15 of RFC2616 [HTTP/1.1]– An example of how to specify Certificate-based

authentication with TLS…• Section 7 of RFC2829 [LDAPv3]

Page 7: Security Considerations

Proof of correctness

• Requirement – Due Diligence– Don’t repeat known prior mistakes (don’t do a “WEP”)– This is hard work– How formal do we need to be?

• Excellent guiding principles..– Abadi & Needham, “Prudent Engineering Practice for

Cryptographic Protocols” [ref’d]

– Example of application: Anderson & Needham “Robustness principles for public key protocols”

• (good?) Example of techniques..– “Authenticity by Typing for Security Protocols”, Gordon

& Jeffrey

Page 8: Security Considerations

Moving Forward

• Use sec-consider-00 as an initial framework for guiding the work– Ensure appropriate detailed rationale &

assumptions are included in specification docs, e.g. core-15 and bindings-model-05

– Discover & raise design issues in specification docs

• Need champion to own sec-consider-xx and drive this subprocess

Page 9: Security Considerations

Moving Forward, cont’d

• Proof-of-correctness analysis – by outside party?– Begin once specs are more fully-baked

• Oct? (Need SAML profile of xmldsig!)

– JeffH & Joe to tug sleeves of Univ. contacts (others (BobB) have contacts?)