1 / 23

Better-Than-Nothing Security (BTNS) BOF at IETF-61

This document provides an overview of the ANONsec ID and presents the agenda for the Better-Than-Nothing Security (BTNS) BOF meeting at IETF-61.

Download Presentation

Better-Than-Nothing Security (BTNS) BOF at IETF-61

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. Note Well • Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an “IETF Contribution.” Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: • the IETF plenary session, • any IETF working group or portion thereof, • the IESG, or any member thereof on behalf of the IESG, • the IAB or any member thereof on behalf of the IAB, • any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, • the RFC Editor or the Internet-Drafts function • All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668.Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. • Please consult RFC 3667 for details.

  2. Better-Than-Nothing Security(BTNS) BOF at IETF-61 Joe Touch Director, Postel Center Research Assoc. Prof. CS & EE USC/ISI

  3. Agenda • Agenda bashing (5 minutes) • Overview of ANONsec ID (15 mins) • WG Discussion: • Scope (10 mins) • Possible threat models (10 mins) • Candidate protocols (10 mins) • Charter discussion (20 mins) Mailing list, ID, BOF problem statement: http://www.postel.org/anonsec

  4. Overview of ANONsec • Goal • Approach • ANONsec threat models • TCP RST motivation • Keying issues • Hash issues

  5. Goal • Solve security problems… • with security solutions • …rather than non-security patches • Why: • Patches are simpler than security protocols • Patches can have unintended side-effects • Challenge: • Reduce barriers to using security protocols

  6. Approach • Reduce deployment effort • Reduce configuration complexity • Reduce need for infrastructure • Reduce performance penalty • Increase throughput • Decrease load on security endsystems

  7. Use of Non-Auth Assoc. • Protects connection-in-progress • Don’t know endpoint ID, but know it’s the same endpoint throughout an association • Useful for: • BGP • DNS

  8. Prelim. Threat Models • Current security protocols assume: • Off- and on-path attacks • Authoritative endpoint identification • Relax (in select environments): • Off-path only • Anonymous (non-authoritative) associations

  9. E.g.: TCP RSTs • See: draft-touch-tcp-antispoof • Assumes endpoints, ports known • Susceptibility increases by BW2 • Many solutions: • TCP/MD5 • IPsec • Port randomization • RST windowing • Timestamp windowing

  10. RSTs and BW

  11. TCP RST Issue • Symptoms: • Bad data, RSTs, etc. affect connections • Dropped TCP connections affect BGP • Fundamental problem: • Spoofing

  12. TCP RST Solutions: • Treat symptoms: • TCP RST, timestamp windowing • TCP port randomization • Have BGP not drop data when TCP drops >> non-security protocol mods. • Use existing net or transport security: • TCP/MD5 • IPsec >> cumbersome to configure, impact load

  13. Approach Detail • Configuration complexity / infrastructure • Use non-authenticating keying (‘anonymous’ part of ANONsec) • Increase throughput / decrease load • Consider alternate threats (off-path, replay only) • Match hash to threats(full, header-only, cookie)

  14. Keying issues • Authenticate mode • Shared secret (existing) • Cert. from known CA (existing) >> a.k.a. STS or authenticated Diffie-Hellman • Anonymous mode • Cert. from unknown CA (e.g., self-signed) • No cert., no shared secret >> Schneier’s “shared secret” shared secret, a.k.a. Diffie-Hellman)

  15. Hash issues • Full mode (existing) • On- and off-path protection • Protects headers and data • Header-only mode • On- and off-path protection of headers • Off-path protection of data • Cookie mode • Off-path protection

  16. WG Discussion….

  17. In-Scope • Current focus • IPsec suite • Possible later focus (recharter): • TCP/MD5 (fix keying, algorithms, etc.) • SSL • DNSSEC • Persistent pairwise IDs

  18. Out of Scope • Opportunistic Encryption • Requires alternate infrastructure (DNS) • Indirect (non-security) protection • BGP filtering • TTL filtering, address filtering, content validation • TCP window attenuation • RST windowing, timestamps • TCP cookies • Port randomization, SYN cookies

  19. Threat Models…

  20. Protocols…

  21. Charter bashing: • Problem definition: • RFC defining the overall problem space (based on anonsec-00) • RFC on threat models with relaxed assumptions suitable for infrastructure-free and/or high-performance use • Infrastructure-free use: • RFC on IKE extensions and/or configurations for infrastructure-free use • High-performance use: • RFC on IPsec extensions and/or configurations for high-performance

  22. Target Milestones • Problem definition RFC @ 3 mos • Threat models RFC @ 3 mos • IKE extensions @ 6 mos • IPsec extension @ 9 mos

  23. Related Drafts • Draft-touch-tcp-antispoof / Draft-ietf-tcpm-tcp-antispoof (next) • Describes TCP RST spoofing concerns and various proposed solutions • Draft-touch-anonsec • Describes the framework for BTNS • Draft-bradner-pbk-frame • Describes other anonymous authentication

More Related