230 likes | 242 Views
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.
E N D
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.
Better-Than-Nothing Security(BTNS) BOF at IETF-61 Joe Touch Director, Postel Center Research Assoc. Prof. CS & EE USC/ISI
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
Overview of ANONsec • Goal • Approach • ANONsec threat models • TCP RST motivation • Keying issues • Hash issues
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
Approach • Reduce deployment effort • Reduce configuration complexity • Reduce need for infrastructure • Reduce performance penalty • Increase throughput • Decrease load on security endsystems
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
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
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
TCP RST Issue • Symptoms: • Bad data, RSTs, etc. affect connections • Dropped TCP connections affect BGP • Fundamental problem: • Spoofing
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
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)
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)
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
In-Scope • Current focus • IPsec suite • Possible later focus (recharter): • TCP/MD5 (fix keying, algorithms, etc.) • SSL • DNSSEC • Persistent pairwise IDs
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
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
Target Milestones • Problem definition RFC @ 3 mos • Threat models RFC @ 3 mos • IKE extensions @ 6 mos • IPsec extension @ 9 mos
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