1 / 9

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.

hayes-padilla
Download Presentation

Security Considerations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Overall Resource • Guidelines for Writing RFC Text on Security Considerationsdraft-rescorla-sec-cons-03.txt

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

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

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

  6. 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]

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

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

  9. 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?)

More Related