Security Area Open Meeting (SAAG) Minutes Meeting : IETF 72, Thursday 31 July 2008, 13:00-15:00 Location: Dublin Citywest Hotel, Convention 2 Chairs : Pasi Eronen and Tim Polk Minutes : Pasi Eronen Version : 1 (2008-08-04) ---------------------------------------------------------------------- WG reports ---------- [sent to SAAG mailing list archive, not minuted] SSL VPNs: An IETF Perspective (Paul Hoffman) -------------------------------------------- [slide 6, "SSL Portal VPNs"] Bob? and Steve Hanna:: "http://ourgateway.example.com" should be "https://..." [note: fixed in updated slides] [slide 8, "Security issues with portal VPNs"] Stephen Kent: Would problems arise if internal site needs TLS client authentication? Paul: Yes [slide 9, "SSL Tunnel VPNs"] Steve Hanna: Should "tunnel running under SSL" be "...over SSL"? Paul: depends on how you look at this, but yes. [QA after last slide] Gregory Lebovitz (Juniper, SSL VPN vendor): We could have implemented very similar user experience with IKE/IPsec protocols. [..missed more comments here..] Pasi Eronen: Some products are actually tunneling traffic using UDP port 4500; UDP-encapsulated IPsec ESP, but without IKE. David Johnston?: SSL is also more compatible with firewalls; I run SSL VPN at my home, so I can access it from work -- IPsec doesn't work *out* from corporate firewalls. Stephen Kent: Important part of IPsec is access control, more than just "you can come in" -- SSL VPN protocols ignore this issue. You could configure client's IPsec SPD this way, too. This is also partly perception and marketing; vendors chose to implement IPsec in certain ways. And things that make SSL VPN relatively easy to manage are things we don't usually standardize anyway. Paul: SSL VPNs were taking on when it was obvious that IKEv2 would take long. If we had been faster with IKEv2, things might have been different. Yoav Nir (Check Point, SSL VPN vendor): Even today, there's no good way to use username/password in IKE -- some proprietary EAP methods, but not as nice the HTML form you get in web browser. Also, while most vendors aren't standardizing anything related to SSL VPNs, Microsoft has published their SSTP protocol, so other vendors can work with them. IF-MAP: Open Standards for Coordinating Security (Steve Hanna) -------------------------------------------------------------- [around slide 6/7] Paul Hoffman: Is information flow from sensors *to* MAP, or do sendors *get* information MAP? What information you'd expect sensors send *to* IF-MAP? Steve: Events like detected abnormal behavior. ?: Primary source of identity information? [..missed details here..] Is MAP expected to cover things like location or presence, which is not policy but telemetry about user? Steve: Not converying of policies, but juts information. Could be real-time telemetry, but no standardized format on how to store location information in IF-MAP yet. Could have privacy/legal issues. Kaushik Narayan: Lot of things here look like accounting records, what's the difference between RADIUS accounting and MAP? Steve: RADIUS accounting is more like log message, IF-MAP has also real-time subscription and events. One could conceivably watch RADIUS accounting messages and feed information to IF-MAP. Hannes Tschofenig: Real-time accounting is also possible. And there are standards for describing location information in IETF. Tim: If this was an IETF spec, you'd have very lengthy security and privacy consideration. How did you choose SHOULDs and MUSTs? For example, why is authorization not MUST? Steve: We already have very lengthy security/privacy text. TLS with mutual authentication seems like obvious MUST. There's aloso tracking who made which change, can track if somebody is dumping lot of information, or do anomaly detection. [...missed parts of answer here...] About authorization, vendors wanted to have a very simple IF-MAP server, which simply has list of authorized devices who can access; more detailed authorization (e.g. read-only, or access only to some information) is SHOULD. X.1034 (Zachary Zeltsan) ------------------------ Glen Zorn: How can I get this document? Zachary: This is not yet published.. Tim: Liaision statement disappeared or was eaten by spam filter -- will be fixed. Will get it to all the right places soon. Joe Salowey: How long the document is open for comments? Zachary: It was already approved by SG17 in April. Some editorial work will be done before it's published. Open Mike ---------- Gregory Lebovitz: I sent email to SAAG list commenting Paul's presentation. Kaushik Narayan: Paul pointed that one reason for SSL VPNs is that IPsec requires clients to be installed. But other things, like EAP, require clients too. Might have similar problems about deployability -- is there something IETF can do to help operations and management here? Don't know what the answer is, but something to think about. Tim: IPsec is good technology, but underadopted. We want to build protocols speople use, so what we can do to make our technology more attractive to adopt is very important discussion as we build these. Paul: Get them built into browsers. Sort of humorously, but I mean it. One thing we found out that things that have to be in the operating system are difficult, things that go to the browser seem less daunting. But when we started SSL VPN testing, people cared only about IE; later, Firefox too. Tunnel VPNs are delivering what should be an OS feature via the browser. Steve Hanna: Consider deployment and ease-of-use early in design. The more difficult it is to deploy, the less likely it's going to be deployed. David Harrington: In OPS area WG, we have draft on how to improve operability and manageability of protocols, draft-ietf-opsawg-operations-and-management. Kaushkik: There are challenges in putting everything in the browser, especially at network access stage before you have IP address. Regarding operability and manageability, security protocols are special, since they require things like keys, policies, etc. Tim: Paul alluded to this when talking "options-mania", we tend to put many options and have different protocols for same thing. Gregory: SSL VPNs started from usage model, work flow, what's the easiest way for administrator get deploymnet with incremental security. Reminds me of Jeff Schillers' address to SAAG when he left as SEC AD, we went from time when we didn't have much security -- now we have it, let's help people use it. SSL VPN started with usability, then security. Tim and I had conversation earlier this week about taking baby steps towards security, not perfect security at the beginning. David Jonston: VPN is network layer, but still application. [..missed part of comment...] All OSs come with IPsec, more difficult problem is installation of credentials (certificates). Dave Mitton (RSA Security): There's variation with what people call VPNs; IPsec is integrated in network stack -- when I see an application, I don't consider it part of network. So calling browser a VPN doesn't make sense to me, particularly being remote access person with EAP/RADIUS background. [..missed part of comment..] Steve Hanna: SSL VPNs are real VPNs, since they set up network interfaces in OS -- just installed via browser. Lot of them use EAP inside TLS. Gregory: We told people to use TLS, and they did -- they just didn't come to IETF to document how they used TLS. Steve Hanna: I'd like to see some standardization, we'll have lot of devices that won't let you download code that installs a new network interface. I hope to see some standardization so devices out-of-box can support something. Microsoft has published their SSTP, more work could lead to more open standard that other vendors could ship, too. Important point about usability: in meetings and conferences there are often problems with IPsec and blocking ports -- this never happens with SSL. Pasi: Some vendors do IPsec over HTTPS TCP port -- but IPsec over TCP hasn't been standardized. Alan DeKok: Usability is all that matters; I don't care whether it's OS or application, as long as I can get to my email. Dave Crocker: Key word is usability, we tend to ignore it. [..missed part of this comment...] Stephen Kent: Usability is important, but it's mostly outside out scope. We could engineer things that can't be implemented in usable way, but mostly that's not the case. IETF as whole, also security area, stops short of mandating things that would be needed for usability, considering them implementation things. In particular, many IPsec implementations chose to provide terrible user interfaces for management. [ended around 15:00] ----------------------------------------------------------------------