Security Area Advisory Group (SAAG) IETF65, Dallas, Texas Minutes compiled by George Jones and Russ Housley Agenda WG Session Reports - KRB-WG - LTANS - DKIM - BTNS - S/MIME - PKIX - PKI4IPsec - MSEC - MOBIKE - EMU - ISMS - TLS - SASL BOF Session Reports - HOAKEY Invited Presentations - CAPWAP Security (Scott Kelly) - Authentication for TCP-based Routing and Management Protocols (Ron Bonica) - OATH HOTP C/R (Johan Rydell) - CT-KIP (Dave Mitton) Open Microphone ------------------------------------------------------------------------ WG and BOF Session Reports As usual, the SAAG session began with Working Group and BoF Reports. Each working group or BoF that had a meeting at IETF 65 gave a very brief summary of the session. Please see the minutes for each of these sessions. The highlights are not repeated here. ------------------------------------------------------------------------ CAPWAP Security, Scott Kelly http://www3.ietf.org/proceedings/06mar/slides/saag-1.ppt Introduction - CAPWAP protocol to carry Access Point (AP) configuration/control, network access control decisions, cryptographic session keys, user data, etc. - Security matters, want to solicit security input - Asking for security advisor Background - Fat APs are standalone, individually managed network elements - Station (STA) -> AP -> AS/AAA + MGT CAPWAP Architecture - Combination of the Access Controller (AC) and the Wireless Termination Point (WTP) replace the "Fat AC" functionality - STA -> WTP -> AC -> AS/AAA + MGT - The CAPWAP protocol is used between the WTP and AC Complex Trust Relationships - AAA credential between AC and Authentication Server (AS) - EAP credentials between STA and AS - 802.11i security context (the PTK) between WTP and STA - CAPWAP credential between AC and WTP - Don't want to degrade security of surrounding components Multiple Deployment Models - Direct L2 connection - Routed L3 connection, one administrative domain - Routed L3 connection, over potentially hostile hops CAPWAP Threats - Direct L2 AC as switch: physical security is basic solution - Enterprise deployment: mobile systems invalidate many local LAN security assumptions - Other deployments: -- branch office WTP with central AC -- WTP in home with AC on corporate LAN -- hotspots -- using wireless links between WTP and AC - Threat mitigation requires strong crypto, mutual authentication, data integrity, and in many cases, confidentiality - CAPWAP not planning to secure data channel -- security only related to control plane -- some talk, but lots of resistance to securing data plane Additional Security Considerations - Need to get crypto keys into device over CAPWAP channel - We don't want CAPWAP to be weak channel/link Protocol Security Requirements - In scope: AC <-> WTP - NOT in scope: -- AC <-> AAA -- STA <-> AAA -- STA <-> WTP -- MGT <-> AC - CAPWAP is not running between STA and AP Current State - Started with 4 vendor proposals - Set up evaluation team, they chose one - Chose LWAPP, which has its own security mechanism, but it is being replaced with DTLS Comparison/Contrast: DTLS vs LWAPP - Most people persuaded Summary - In OPS area, straddles SEC area - IEEE 802 working around edges, IETF can't introduce weakness - Lots of interesting work, need a security POC David Perkins: - AC-to-AC not in charter, but not a big next step - Protocol designed to support things other than 802.11, but charter says 802.11 Dorothy Gellert (CAPWAP WG Co-chair): Some talk of AC-to-AC, but not in charter. No BOFs yet. Craig Labovitz (via Jabber): How realistic is it that people will deploy general (non vendor specific) solution? A: We want to make sure protocol is not the barrier Dorothy Gellert: Many vendors talk about the importance of interoperability. Russ Housley: Will be appointing security advisor in next few days. Volunteers? ------------------------------------------------------------------------ Authentication for TCP Routing and Authentication Protocols, Ron Bonica http://www3.ietf.org/proceedings/06mar/slides/saag-2.ppt Motivation - Most operators not authenticating BCP now - Blind insertion attacks possible - Major carriers and vendors got together, came up with this solution went to TCPM WG, and they asked authors to get input from SAAG RFC2385 current BCP -- TCP MD5 - does not fulfill operator requirements Why operators aren't using it? - CPU - Poor key management -- can cause BGP resets, so avoided - Weak crypto (MD5) Alternative Approaches - 3 possible places -- Application (BGP, TLS...) -- Transport (TCP) -- Network (IKE/IPsec) - Chose transport (TCP) Chosen Approach - New TCP option in all segments - Key ID -- identifies the shared secret - Sending station picks current key, generates MAC, puts key ID and MAC in TCP option - Can use stronger crypto Enhanced Authentication Option - Another draft talks about auto distribution solution Key Chain - What's in a key chain? 64 keys; id; shared secret; vector; out/in/both; two start times, one for send, one for receiving - Windows to compensate for rollover Coming Soon - No PSK, automatically generate a key, distribute Rejected Approach: BGP - Do it in the BGP protocol -- need protection of TCP header Rejected Approach: SSL, TLS - Would not protect TCP session itself - injection, resets still possible Rejected: IKE/IPSec - Most routers configured per interface. With BGP you have no idea which session it will traverse. Operationally complex. Q: (Eric Rescorla) key management good ... have one master key A: That's one possible configuration here Q: One set of keys for all routes, or key pairs per router, How do you handle BGP cross domain? A: All run-time decisions. Q: Does the router's key database say what keys to use for what sessions? A: Run-time decisions on operators part, configurable. Q: (Russ Housley) Are you really saying that IKE/IPsec was rejected because current router implementations are designed to protect user data, not traffic to the router itself. A: Yes. Q: IPSec does not have to be per interface Russ Housley: Implementation shortcoming, not specification shortcoming Q: (Eric Rescorla) Why not new session key on per flow basis? A: See draft-weis-tcp-auth-auto-ks-00; it does that Eric Rescorla: I like to see key management in protocol. Sam Hartman: I am in favor of reusing existing key management protocols. See RFC 4107 on key management, which is a BCP Eric Rescorla: Agree, don't make key management if you can steal one Brian Weis: question for Eric Rescorla Eric Rescorla: use key establishment protocols in TCP Ron Bonica: SSL does not protect TCP session itself. Elliot Lear: If working SSL over SCTP, check SCTPs bits Ron Bonica: Ron looking for go-ahead or objections Russ Housley: Please proceed to replacing TCP MD5, but make sure there is a clear way to transition to automatic key management Ron Bonica: Should we go ahead as interim? Russ Housley: Yes, incremental improvement good. --------------------------------------------------------------- OATH HOTP C/R, Johan Rydell http://www3.ietf.org/proceedings/06mar/slides/saag-3.ppt What is OATH? - Established in 2004 - 60+ members - Neutral stance enables coordination with multiple standard bodies such as IETF, OASIS, W3C, etc. - Goals: Get rid of static passwords -- ubiquitous -- encourage device innovation and embedding -- Reduce cost and complexity of deploying strong authentication -- Open and royalty-free specifications Benefits of open standards - Lots of closed specifications in this area - Openness will drive standard to be implemented and used - Two implementations already Mutual OATH - First presented in December - Based on RFC 4226 - Implemented in smartcards, cell phones, soft/hard tokens - Protect user, protect server - Possibility of doing signatures - Building block Algorithm Identifier - Digest function, truncation, PIN keys, challenge response, modes, key/keys - Current support for 3 Digest functions, more can be added - If you force user to enter long sequence, nobody will use it -- supports truncation - counter, transaction values in protocol Algorithm ID - two way values - Mode is a structure, either Plain or Chained Mode - Key is a structure, either Single, Dual-Computed, or Dual-Stored Standard HOPT - Token displays OTP to user - OTP is sent to server - Server validates OTP, and then accepts/denies - Accept/Deny notification sent to user Mutual Challenge-Response - Token displays OTP to user - Challenge from user to server - Server calculates response, and generates challenge - Server sends response to user challenge and the server's challenge to the user - User enters PIN at token, and then enters server challenge - Token displays response to server challenge - Response to server challenge is sent to server - Server validates response, and then accepts/denies - Accept/Deny notification sent to user Improvements: - Could introduce time-stamp - Could introduce checksum Q: (George Jones) usability question...does this mean user will have to key in two values from a token? A: It depends on your use case. Q: (Eliot Lear) Which of these communications are electrical? Is there a physical interface? A: No, not in standard. C: (Phillip Hallam-Baker) You could do two phase authentication, one to get into account, stronger to validate transfers. Q: (Sam Hartman) What about MITM attacks ? A: You need to have a secure channel Q: If I've had to authenticate the channel already, what do I get out of mutual authentication? A: Challenge itself could prevent MITM Q: Do you specify that? A: (Phillip Hallam-Baker) You're trying to secure two channels: communication and user. You've got two MITM cases: man in network and key-logger. Can use SSL, etc. But security under attack at all points. Can't have one point solution. Need end-to-end, where end is the human, not the computer. Q: (Eliott Lear) Are these standards in flux? How does one participate? A: 2nd draft. See the draft. Give authors feedback. Q: Is there a public mailing list? A: No. We could consider it. C: (Russ Housley) Please let me know now if there is any objection to this document becoming an Informational RFC. --------------------------------------------------------------------- Cryptographic Token Key Initialization Protocol (CT-KIP), Dave Mitton http://www3.ietf.org/proceedings/06mar/slides/saag-4.ppt Background - Client-server protocol for initializing tokens with shared keys - General protocol for setting up, secure provisioning of tokens Objectives - Secure, interoperable, - No PKI needed Message Flow - Optional trigger message - Client Hello - Server Hello - Client Nonce - Server Finished -- includes Server Nonce Principal of operation - Encryption. Server can have PK. Can do shared key. - Used to encrypt data out of server. Client uses servers PK. Status - Protocol for secret keys - Issue: are you erasing previous token - If data is on token, more handshaking OTPS - RSA Laboratories: One-Time Password Specifications (OTPS) program - Open process, no membership required - Open mailing list Other OTPS Documents - Addressing full life cycle -- Provisioning, Retrieval, Transport, Validation - Eight documents so far -- http://www.rsasecurity.com/rsalabs/ -- click OTPS on left side of page Future Work - http://www.ietf.org/internet-drafts/draft-nystrom-ct-kip-00.txt - Will be kept current C: (Russ Housley) A few weeks ago, I posted a notice about this document to the SAAG mail list. Please let me know now if there is any objection to this document becoming an Informational RFC. C: (Russ Housley) I chartered the ENROLL WG to deal with enrollment, including certificates and shared secrets. It failed, and it is now closed. This document deals with enrollment for OTP tokens. Q: (Eliot Lear) Good stuff. Binding to HTTP? How about abstracting so that you can use other protocols. A: Draft uses lots of XML, but not intended to be only web. Q: (Siddharth Bajaj) Interested in lighter weight version. A: (Russ Housley) Would you like WG? Lets talk about a BOF for next time. ----------------------------------------------------------------- Open Microphone Mike Myers: Can protocol authors expect guidance on hash issues? Russ Housley: We did that last time. SHA-1 is weaker than we expected. Dr. Wang now claims 2^62 attack (no paper yet). Last week folks in the Netherlands posted code to find MD5 collisions in less than one minute on a PC. Still headed for SHA-256. NIST not accepting SHA-1 for digital signatures after 2010. Goal to get specifications for SHA-256 in next 18-24 months, which allows time for vendors to ship products before the 2010 deadline. Siddharth Bajaj: Dynamic passwords in Kerberos? Has IETF looked at that? Sam Hartman: Very interested. There are drafts for using OTP with Kerberos. David Perkins: PANA WG should have been described here. Russ Housley: I learned about problems on PANA too late to include it on the agenda for today. Olafur Gudmundsson: Looking at use of ECC in DNSSec, working with IRTF CFRG. Russ Housley: Good posting to CFRG mail list. Hoping for good advice. Q: At RAI area meeting talked about security approaches. Russ Housley: RAI and SEC ADs are going to talk. We have reserved a day in May to get together. Hopefully we can at least frame issues. Q: Interested in small report of what happened at the RAI area meeting? Sam Hartman: Send email. We read it all. Q: HMAC-MD5? Russ Housley: We are out of time. But it is clear that MD5 without HMAC construction is in deep trouble.