From info at caitr.org Mon Apr 7 10:05:50 2003 From: info at caitr.org (CAITR) Date: Mon Apr 7 12:05:59 2003 Subject: [saag] Internetworking 2003: Call for Papers Message-ID: <20030407160550.60103.qmail@web41813.mail.yahoo.com> Call for Papers ============== Internetworking 2003, June 22-24, 2003, San Jose, California http://www.caitr.org/internetworking03/index.htm REMINDER: Deadline for submissions is April 11, 2003 The Internetworking 2003 Technical Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following: - Voice over IP (VoIP) - IP Video Conferencing - Storage Area Networks (SANs) - Unicast and Multicast Routing and Convergence - QoS Routing - Network Security and Service Integration - Operational Support Systems - Virtual Private Networks - Internetworking Wireless LANs and 3G Wireless Networks - IP-based Infrastructure for Wireless Networks - Internetworking IP and Optical Networks - Internetworking MPLS with Legacy ATM and Frame Relay Networks - Transition from IPv4 to IPv6 and interworking - Pervasive Computing - High Speed Transport Layer Protocols - Peer to Peer Networking and Grid Computing - Video Teleconferencing (VTC) - 802.11 Hotspots Conference Technical Co-chairs: - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Vishal Sharma, Metanoia - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets - Ran Canetti, Co-chair, IETF Working Group on Multicast Security -------------- next part -------------- An HTML attachment was scrubbed... URL: http://jis.mit.edu/pipermail/saag/attachments/20030407/63ab0898/attachment.html From mcgrew at cisco.com Fri Apr 11 15:28:27 2003 From: mcgrew at cisco.com (David A. Mcgrew) Date: Fri Apr 11 17:37:02 2003 Subject: [saag] Comments on draft-bellovin-mandate-keymgmt-00.txt Message-ID: Steve, I'm glad that the you're writing up this kind of guideline. Publishing documents outlining policy will help coordinate security work across the IETF. The draft looks pretty good, though I have a couple of questions and a bunch of detailed comments. I like that the draft discusses "automated key management" rather than a key management protocol. This inclusiveness allows systems that don't use explicit key management messages, but that derive session keys from other implicit information, to meet the security requirements. This is surely the right way to go. However, this fact makes me think that "limited available bandwidth or very high round-trip times" (mentioned at the end of Section 2) isn't a valid motivation for not using automated key management. The injunction that automated key management must be used if "a stream cipher such as RC4 or AES counter mode [AESMODE] is used" is certainly needed. But this injunction ought to also be applied to all cipher modes that use implicit IVs rather than explicit random IVs, at least if the re-use of a key would lead to the re-use of IV values. This is the case if the implicit IV generation method defined in Appendix C of [AESMODE] is used. The fundamental cryptographic issue here is that ciphers that implement randomized encryption (e.g. use an random IV) require less synchronization than those who don't. As an aside, some randomized counter mode variants have been defined; it's included in the CTR submission to NIST. We probably don't want to mandate automated key management for these variants. Another related point that's worth making is that key management protocols can and should coordinate other information besides keys. Some systems rely on the uniqueness of device identifiers or other nonce values that are provided as inputs to cryptographic systems. An example of this is when a single counter mode key is used by multiple senders, in which case each sender must include a distinct value in the counter to avoid keystream re-use. It is reasonable to mandate that these per-device values be passed out by an authenticated key management protocol, unless there is a trusted central system that administers them. In multicast or multi-unicast situations, there may be a need to communicate the current value of the anti-replay information. Another kind of information that needs to be synchronized is the crypto parameters. If multiple cipher types can be used, there ought to be an automated check that both sides are in synchronization. I believe that 3DES can be broken if an adversary has access to a DES decryption oracle that uses the initial part of the 3DES key. I think that it might be useful to take a bottom-up approach to some of these requirements. You could require that crypto implementations use automated key management if it is needed meet the requirements of the crypto mechanisms that it uses. For example: * A crypto implementation MUST track the amount of data protected by each key that it uses and prevent its overuse. DES and 3DES keys can be used for no more than 2^32 invocations of the cipher, while AES keys (for all key sizes) can be used for no more than 2^64 invocations of the cipher. * A crypto implementation MUST ensure that initialization vectors are generated appropriately. Ciphers using implicit IVs MUST ensure that the values of the inputs used to compute those IVs are distinct. < ... add more imperatives here ... > * A crypto implementation MUST ensure that all of the above conditions are met. If an automated key management system is needed in order to meet these goals, then such a system MUST be implemented. And now for a bunch of random comments. The draft mandates key management if "a central party will have to manage n^2 static keys". I think that I agree with this requirement, though it might be good to make it more precise. Some might read it to mean that manual keying is acceptable if each of the n parties is responsible for establishing a shared key with its n-1 peers. Was this what you'd intended? I'm not sure that I understand the requirement about when "long-lived session keys are used by more than two parties." Certainly a cryptographic system shouldn't overuse a key. I'm not sure what the restriction to more than two parties means. Do you have in mind the multiple-sender case? A minor point: it might be considered reasonable to allow manual keys for debugging purposes. It would be good to include some disclaimer or discussion about this special case. Yet another minor point: I like the use of the Denning-Sacco and Lowe breaks of the Needham-Schroeder public key protocol as a motivating example for not designing your own KMP. I certainly find it motivating! It might be good to add a references to those breaks. David From housley at vigilsec.com Thu Apr 17 18:53:57 2003 From: housley at vigilsec.com (Russ Housley) Date: Fri Apr 18 11:14:16 2003 Subject: [saag] Comments on draft-bellovin-mandate-keymgmt-00.txt In-Reply-To: Message-ID: <5.2.0.9.2.20030417174438.02d31da0@mail.binhost.com> David: >I'm glad that the you're writing up this kind of guideline. Publishing >documents outlining policy will help coordinate security work across the IETF. >The draft looks pretty good, though I have a couple of questions and a >bunch of >detailed comments. > >I like that the draft discusses "automated key management" rather than a key >management protocol. This inclusiveness allows systems that don't use >explicit >key management messages, but that derive session keys from other implicit >information, to meet the security requirements. This is surely the right >way to >go. However, this fact makes me think that "limited available bandwidth >or very >high round-trip times" (mentioned at the end of Section 2) isn't a valid >motivation for not using automated key management. > >The injunction that automated key management must be used if "a stream cipher >such as RC4 or AES counter mode [AESMODE] is used" is certainly needed. But >this injunction ought to also be applied to all cipher modes that use implicit >IVs rather than explicit random IVs, at least if the re-use of a key would >lead >to the re-use of IV values. This is the case if the implicit IV generation >method defined in Appendix C of [AESMODE] is used. The fundamental >cryptographic issue here is that ciphers that implement randomized encryption >(e.g. use an random IV) require less synchronization than those who don't. As >an aside, some randomized counter mode variants have been defined; it's >included >in the CTR submission to NIST. We probably don't want to mandate >automated key >management for these variants. I have not had a chance to look at these variants. Do they guarantee that there will not be a collision between the counters, or do they use a large random value and live with the slim possibility of collision? >Another related point that's worth making is that key management protocols can >and should coordinate other information besides keys. Some systems rely >on the >uniqueness of device identifiers or other nonce values that are provided as >inputs to cryptographic systems. An example of this is when a single counter >mode key is used by multiple senders, in which case each sender must include a >distinct value in the counter to avoid keystream re-use. It is reasonable to >mandate that these per-device values be passed out by an authenticated key >management protocol, unless there is a trusted central system that administers >them. In multicast or multi-unicast situations, there may be a need to >communicate the current value of the anti-replay information. Another >kind of >information that needs to be synchronized is the crypto parameters. If >multiple >cipher types can be used, there ought to be an automated check that both sides >are in synchronization. I believe that 3DES can be broken if an adversary has >access to a DES decryption oracle that uses the initial part of the 3DES key. > >I think that it might be useful to take a bottom-up approach to some of these >requirements. You could require that crypto implementations use automated key >management if it is needed meet the requirements of the crypto mechanisms that >it uses. For example: > > * A crypto implementation MUST track the amount of data protected by > each key >that it uses and prevent its overuse. DES and 3DES keys can be used for >no more >than 2^32 invocations of the cipher, while AES keys (for all key sizes) can be >used for no more than 2^64 invocations of the cipher. s/MUST/SHOULD/ I can think of many cases where this is not done because the likelihood of exceeding these limits is so slim. > * A crypto implementation MUST ensure that initialization vectors are >generated appropriately. Ciphers using implicit IVs MUST ensure that the >values >of the inputs used to compute those IVs are distinct. I do not see this as key management. Rather, I see this as properly using a particular algorithm in a particular mode. >< ... add more imperatives here ... > > > * A crypto implementation MUST ensure that all of the above conditions are >met. If an automated key management system is needed in order to meet these >goals, then such a system MUST be implemented. > > >And now for a bunch of random comments. The draft mandates key management >if "a >central party will have to manage n^2 static keys". I think that I agree with >this requirement, though it might be good to make it more precise. Some might >read it to mean that manual keying is acceptable if each of the n parties is >responsible for establishing a shared key with its n-1 peers. Was this what >you'd intended? > >I'm not sure that I understand the requirement about when "long-lived session >keys are used by more than two parties." Certainly a cryptographic system >shouldn't overuse a key. I'm not sure what the restriction to more than two >parties means. Do you have in mind the multiple-sender case? I think this is about multicast keys. At least that is how I interpreted the discussion. >A minor point: it might be considered reasonable to allow manual keys for >debugging purposes. It would be good to include some disclaimer or discussion >about this special case. > >Yet another minor point: I like the use of the Denning-Sacco and Lowe >breaks of >the Needham-Schroeder public key protocol as a motivating example for not >designing your own KMP. I certainly find it motivating! It might be good to >add a references to those breaks. Russ From mcgrew at cisco.com Mon Apr 21 08:04:47 2003 From: mcgrew at cisco.com (David Mcgrew) Date: Mon Apr 21 10:06:19 2003 Subject: [saag] Comments on draft-bellovin-mandate-keymgmt-00.txt In-Reply-To: <5.2.0.9.2.20030417174438.02d31da0@mail.binhost.com> References: Message-ID: <4.3.2.7.2.20030421062605.03822b10@mira-sjcm-1.cisco.com> Russ, At 05:53 PM 4/17/2003 -0400, Russ Housley wrote: >David: > >>I'm glad that the you're writing up this kind of guideline. Publishing >>documents outlining policy will help coordinate security work across the >>IETF. >>The draft looks pretty good, though I have a couple of questions and a >>bunch of >>detailed comments. >> >>I like that the draft discusses "automated key management" rather than a key >>management protocol. This inclusiveness allows systems that don't use >>explicit >>key management messages, but that derive session keys from other implicit >>information, to meet the security requirements. This is surely the right >>way to >>go. However, this fact makes me think that "limited available bandwidth >>or very >>high round-trip times" (mentioned at the end of Section 2) isn't a valid >>motivation for not using automated key management. >> >>The injunction that automated key management must be used if "a stream cipher >>such as RC4 or AES counter mode [AESMODE] is used" is certainly needed. But >>this injunction ought to also be applied to all cipher modes that use >>implicit >>IVs rather than explicit random IVs, at least if the re-use of a key >>would lead >>to the re-use of IV values. This is the case if the implicit IV generation >>method defined in Appendix C of [AESMODE] is used. The fundamental >>cryptographic issue here is that ciphers that implement randomized encryption >>(e.g. use an random IV) require less synchronization than those who >>don't. As >>an aside, some randomized counter mode variants have been defined; it's >>included >>in the CTR submission to NIST. We probably don't want to mandate >>automated key >>management for these variants. > >I have not had a chance to look at these variants. Do they guarantee that >there will not be a collision between the counters, or do they use a large >random value and live with the slim possibility of collision? they use a 128-bit random IV and trust that collisions are sufficiently unlikely. As an aside, the new EAX mode does this in the internal counter mode that it uses for encryption. >>Another related point that's worth making is that key management >>protocols can >>and should coordinate other information besides keys. Some systems rely >>on the >>uniqueness of device identifiers or other nonce values that are provided as >>inputs to cryptographic systems. An example of this is when a single counter >>mode key is used by multiple senders, in which case each sender must >>include a >>distinct value in the counter to avoid keystream re-use. It is reasonable to >>mandate that these per-device values be passed out by an authenticated key >>management protocol, unless there is a trusted central system that >>administers >>them. In multicast or multi-unicast situations, there may be a need to >>communicate the current value of the anti-replay information. Another >>kind of >>information that needs to be synchronized is the crypto parameters. If >>multiple >>cipher types can be used, there ought to be an automated check that both >>sides >>are in synchronization. I believe that 3DES can be broken if an >>adversary has >>access to a DES decryption oracle that uses the initial part of the 3DES key. >> >>I think that it might be useful to take a bottom-up approach to some of these >>requirements. You could require that crypto implementations use >>automated key >>management if it is needed meet the requirements of the crypto mechanisms >>that >>it uses. For example: >> >> * A crypto implementation MUST track the amount of data protected by >> each key >>that it uses and prevent its overuse. DES and 3DES keys can be used for >>no more >>than 2^32 invocations of the cipher, while AES keys (for all key sizes) >>can be >>used for no more than 2^64 invocations of the cipher. > >s/MUST/SHOULD/ > >I can think of many cases where this is not done because the likelihood of >exceeding these limits is so slim. Agreed, there are cases where the limits aren't approached. This text would have been better: * A crypto implementation MUST prevent the overuse of each key. An implementation which can be caused to exceed the usage limit MUST track key usage and ensure that usage limits are respected. >> * A crypto implementation MUST ensure that initialization vectors are >>generated appropriately. Ciphers using implicit IVs MUST ensure that the >>values >>of the inputs used to compute those IVs are distinct. > >I do not see this as key management. Rather, I see this as properly using >a particular algorithm in a particular mode. Right, it's a low-level requirement. What I'm proposing is that key management be required whenever it is needed in order to meet low-level requirements. More inline: >>< ... add more imperatives here ... > >> >> * A crypto implementation MUST ensure that all of the above conditions are >>met. If an automated key management system is needed in order to meet these >>goals, then such a system MUST be implemented. ...this is the catch-all requirement. My thinking here is that it might be easier to work from the bottom up than the top down. There are lots of cases to consider in the modes of operation analysis, for example, especially when we consider the possibility that a single key could be used by multiple senders. I think that it would be easier to make a blanket statement than to write specific requirements for all of the different cases separately in the key management draft. What do you think? David >>And now for a bunch of random comments. The draft mandates key >>management if "a >>central party will have to manage n^2 static keys". I think that I agree >>with >>this requirement, though it might be good to make it more precise. Some >>might >>read it to mean that manual keying is acceptable if each of the n parties is >>responsible for establishing a shared key with its n-1 peers. Was this what >>you'd intended? >> >>I'm not sure that I understand the requirement about when "long-lived session >>keys are used by more than two parties." Certainly a cryptographic system >>shouldn't overuse a key. I'm not sure what the restriction to more than two >>parties means. Do you have in mind the multiple-sender case? > >I think this is about multicast keys. At least that is how I interpreted >the discussion. > >>A minor point: it might be considered reasonable to allow manual keys for >>debugging purposes. It would be good to include some disclaimer or >>discussion >>about this special case. >> >>Yet another minor point: I like the use of the Denning-Sacco and Lowe >>breaks of >>the Needham-Schroeder public key protocol as a motivating example for not >>designing your own KMP. I certainly find it motivating! It might be good to >>add a references to those breaks. > >Russ From jari.arkko at piuha.net Tue Apr 22 13:45:06 2003 From: jari.arkko at piuha.net (Jari Arkko) Date: Tue Apr 22 05:46:18 2003 Subject: [saag] More comments on draft-bellovin-mandate-keymgmt-00.txt In-Reply-To: References: Message-ID: <3EA50F22.2000002@piuha.net> I have some comments on Steven's key management draft. The comments are embedded in the draft itself at the URL http://www.piuha.net/~jarkko/publications/ipsec/mandate_keymgmt_review.txt --Jari From mcgrew at cisco.com Thu Apr 24 12:26:12 2003 From: mcgrew at cisco.com (David Mcgrew) Date: Thu Apr 24 14:26:42 2003 Subject: [saag] Comments on draft-bellovin-mandate-keymgmt-00.txt In-Reply-To: <5.2.0.9.2.20030417174438.02d31da0@mail.binhost.com> References: Message-ID: <4.3.2.7.2.20030424111405.03044d48@mira-sjcm-1.cisco.com> Steve, I ran across the references that I'd mentioned in my earlier mail and realized that I'd misspoke. So I figured I'd correct myself and provide the references, thus making a virtue out of a slip-up. I wrote: >>Yet another minor point: I like the use of the Denning-Sacco and Lowe >>breaks of >>the Needham-Schroeder public key protocol as a motivating example for not >>designing your own KMP. I certainly find it motivating! It might be good to >>add a references to those breaks. It turns out that the first break was on the secret-key version of the NS protocol, while the second was on the public-key version. Not a big deal. The references are: R. Needham and M. Schroeder. Using encryption for authentication in large networks of computers. Communications of the ACM, 21(12), December 1978. D. Denning and G. Sacco. Timestamps in key distributed protocols. Communication of the ACM, 24(8):533--535, 1981. Gavin Lowe. An attack on the Needham-Schroeder public key authentication protocol. Information Processing Letters, 56(3):131--136, November 1995. I got these refs from the Security Protocols Open Repositoty at http://www.lsv.ens-cachan.fr/spore/, which might be worth mentioning as well. David From stephen.farrell at baltimore.ie Thu Apr 24 16:15:37 2003 From: stephen.farrell at baltimore.ie (Stephen Farrell) Date: Sun Apr 27 22:21:21 2003 Subject: [saag] XML Key Management Specification Last Call - need review/feedback Message-ID: <3EA7F189.FF214073@baltimore.ie> Dear IETF security folks, Firstly, apologies if (or when) you get more than one copy of this. On behalf of the W3C XML Key Managment Service WG [XKMS-WG], we are pleased to announce the publication of the "XML Key Management Specification" Last Call Working Draft. This is one of the deliverables of the WG. The document address is: http://www.w3.org/TR/2003/WD-xkms2-20030418/Overview.html http://www.w3.org/TR/2003/WD-xkms2-bindings-20030418/Overview.html The Last Call review period will end on 23 May, 2003. Please send review comments by that date to the editor - pbaker@verisign.com and cc: www-xkms@w3.org Thanks, Stephen. [XKMS-WG] http://www.w3.org/2001/XKMS -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From uri at bell-labs.com Mon Apr 28 15:48:58 2003 From: uri at bell-labs.com (Uri Blumenthal) Date: Mon Apr 28 14:49:09 2003 Subject: [saag] More comments on draft-bellovin-mandate-keymgmt-00.txt References: <3EA50F22.2000002@piuha.net> Message-ID: <3EAD779A.7030900@bell-labs.com> Jari Arkko wrote: > I have some comments on Steven's key management draft. The comments > are embedded in the draft itself at the URL > > http://www.piuha.net/~jarkko/publications/ipsec/mandate_keymgmt_review.txt A quick reply to one of the comments: > JARI: What are the key change provisions in automatic key management? > Obviously, its easy to change session keys. But do we need > mechanisms for dealing with e.g. the change of an IKE preshared > secret? If yes, will the above mechanism be applicable? Is this > documented somewhere? No, the "automatic key management" in fact is just a session key agreement mechanism. Its purpose is to protect the "long-term" keys from vulterabilities they incur when used to protect one session after another. Now they will be used only to sign the session key agreement exchange - much safer. How these "long-term" keys get there in the first place is (and should be) beyond the scope of this document (IMHO). From jari.arkko at piuha.net Tue Apr 29 01:07:35 2003 From: jari.arkko at piuha.net (Jari Arkko) Date: Mon Apr 28 17:08:55 2003 Subject: [saag] More comments on draft-bellovin-mandate-keymgmt-00.txt In-Reply-To: <3EAD779A.7030900@bell-labs.com> References: <3EA50F22.2000002@piuha.net> <3EAD779A.7030900@bell-labs.com> Message-ID: <3EAD9817.2030708@piuha.net> Uri Blumenthal wrote: >> JARI: What are the key change provisions in automatic key management? >> Obviously, its easy to change session keys. But do we need >> mechanisms for dealing with e.g. the change of an IKE preshared >> secret? If yes, will the above mechanism be applicable? Is this >> documented somewhere? > > No, the "automatic key management" in fact is just a session key > agreement mechanism. Its purpose is to protect the "long-term" > keys from vulterabilities they incur when used to protect one > session after another. Now they will be used only to sign > the session key agreement exchange - much safer. How > these "long-term" keys get there in the first place > is (and should be) beyond the scope of this document (IMHO). I know the long-term secrets are protected from the usual "wear out" that keys for actual payload crypto get. But there might be other reasons to change secrets than that. Say, it might be a good idea to change your secrets once a year in any case. And when you do, it might not be possible to do an instantaneous change for both parties. So there might be a need to have two secrets at a time, I wasn't sure if IKE (for instance) could do that. Anyway, I agree that this is perhaps getting out of scope of the original discussion. My point was that there might be similar key change issues in automatic key management protocols as well, even if they are needed less frequently... --Jari From uri at bell-labs.com Mon Apr 28 19:04:56 2003 From: uri at bell-labs.com (Uri Blumenthal) Date: Mon Apr 28 18:05:17 2003 Subject: [saag] More comments on draft-bellovin-mandate-keymgmt-00.txt References: <3EA50F22.2000002@piuha.net> <3EAD779A.7030900@bell-labs.com> <3EAD9817.2030708@piuha.net> Message-ID: <3EADA588.6090808@bell-labs.com> Jari Arkko wrote: >>> JARI: What are the key change provisions in automatic key management? >> >> No, the "automatic key management" in fact is just a session key >> agreement mechanism. > > I know the long-term secrets are protected from the usual > "wear out" that keys for actual payload crypto get. But > there might be other reasons to change secrets than that. Of course. But it is not what this simple mechanism is for. Its main purpose IMHO is merely eliminate the abominable case of manually keyed sessions. That it does. IKE it is not. > Anyway, I agree that this is perhaps getting out of scope > of the original discussion. My point was that there > might be similar key change issues in automatic key > management protocols as well, even if they are needed > less frequently... And just one more small feature, and yet another tiny option... IKEv2 is the answer to those. From info at caitr.org Mon May 5 10:46:15 2003 From: info at caitr.org (CAITR) Date: Mon May 5 16:08:04 2003 Subject: [saag] Internetworking 2003: Call for Participation Message-ID: <20030505164615.39430.qmail@web41806.mail.yahoo.com> Internetworking 2003 International Conference Hilton San Jose & Towers Hotel, California June 22-June 24, 2003 http://www.caitr.org/internetworking03/index.htm You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.Registration for the conference is underway. Please visit http://www.caitr.org/internetworking03/registration.htm and follow instructions for registration. The early registration discounts are extremely attractive and are valid till June 1, 2003.Important Dates: --------------------- - Early Registration Rates Cut-Off Date: Sept 30 - Tutorials: Oct 27, 1:00-6:00 pm - Conference sessions: October 28-29 8:30am-6:00pmProgram: ------------- (visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)Sunday June 22 Tutorial-1: MPLS VPNs Tutorial-2: IPv6 Tutorial-3: Mobile Wireless Internet Architecture and Protocols Tutorial-4: Voice over Packet Monday June 23 Welcome and Keynote Session: Network Technology Trends - Forwarding Element and Control Separation - Evolution of Inter-Domain Routing - Network Processing Building Blocks: Enabling the Routers of the Future Session: Network Architecture - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6 - A new routing architecture: Atomised Routing - Internetworking MPLS Layer 2 Transport with an IP Services Network Session: Storage Area Networks - Storage as a Network Node - Object-Based Storage - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP - SANs Considerations Session: Mobile & Wireless Networks - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6 - Challenges and Roadmap of UMTS Network Deployment - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS - Mobile Authentication and QoS - Mobile Handoff Technologies Tuesday June 24 Session: Inter-Domain Routing - Optimizing Route Convergence - Traceroute and BGP AS Path Incongruities - Domain Constrained Multicast: A New Approach for IP Multicast Routing Session: Applications & Services - Securing the Web with Next Generation Encryption Technologies - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 - A novel EAC semantic for the RTSP protocol - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet Session: Network Management & Planning - Pseudowire OAM: A Mandatory Yet Often Overlooked Feature - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Probems - Design Of Fast Fault Restoration System For WDM Networks - Cross-domain multimedia service provisioning, the EVOLUTE solution Session: QoS Based Routing - QoS Routing in Networks with Non-Deterministic Information - Active Dynamic Routing - QoS routing for Differentiated Services: simulations and prototype experiments - Probabilistic routing for QoS improvement in GPS networks - Fluid flow network modeling for hop-by-hop feedback control design and analysis We look forward to seeing you at the Conference. Regards, Conference Technical Co-chairs: - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Marc Lobelle, UCL University, Belgium - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Dr. Tony Przygienda, Xebeo - Ran Canetti, IBM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://jis.mit.edu/pipermail/saag/attachments/20030505/20f33637/attachment.html From pekka.nikander at nomadiclab.com Tue Jun 10 12:22:29 2003 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Tue Jun 10 04:21:33 2003 Subject: [saag] Time to reconsider the role of IPsec AH? Message-ID: <3EE59545.3040106@nomadiclab.com> Folks, Based on our experiences with IPsec in Mobile IP, SEND, and some other working groups, I am seriously starting to think that it might be a good time to reconsider to role of AH in the Internet architecture. For example, in the SEND (Securing Neighbor Discovery) WG, which I am co-chairing with James Kempf, we have been attempting to use IPsec AH to secure IPv6 Neighbor Discovery messages in a public access network setting. The approach is based on public keys, as suggested by Steven Bellovin in his presentation at the SEND BoF in Yokohama. This work has certainly progressed, but the road has been fairly bumby due to the current practice on how IPsec has been implemented in most IP stacks. In general, it looks like the IPsec working group has mostly concentrated on perfecting ESP and IKE/IKEv2, and mostly for VPN use. The goal seem to have been securing *applications* end-to-end, and making IPsec as transparent to the applications as possible. The needs towards IPsec in Mobile IP, SEND, and other IP layer control protocols seem to be very different. In these protocols, there is no "application" in the traditional sense. Instead, the protocols create state at the IP layer, thereby affecting the overall operations of all applications. Furthermore, if an attacker can illegitly create such state, the effects can be devastating to the whole Internet, resulting in hijacked connections, untraceable denial-of-service attacks, mysteriously disconnected sessions, black holes, or other large scale malfunctions or security breaches. In some sense, the IP layer control protocols and their security needs resemble routing protocols. However, they are very different from the trust model point of view. Routing protocols usually exchange routing information between peering routers that have some level of trust. On the other hand, the IP layer control protocols often need to exchange IP layer state related information between peers that have no or only minimal trust. For example, in Mobile IP route optimization the mobile node and the corresponding node may have never communicated with each other before, and they may have no shared trust-root. Similarily, nodes running in an ad hoc network may have never met other nodes that they need to perform Neighbor Discovery with. Now, in the IPsec working group there seems to be a fairly large faction of people that want to kill AH. To them, AH seems like a completely useless feature. If I took a very limited VPN point-of-view, I most probably would agree with them. One can even argue that AH, in general, is not suitable for protecting end-to-end application level traffic, since ESP integrity protection makes it better and without less problems with IP headers being modified on the way. As I argued above, the situation is different with IP level control protocols. There the extension headers, and often the actual IP header, do carry information whose integrity is essential. Furthermore, the result of the integrity check is not necessarily a usual black/white result, but it may be necessary to pass additional information to the upper layer protocol, i.e., ICMP, Mobile IP, etc. The same applies to the packets sent out: it is sometimes necessary that the upper layer protocol is able to instruct the IP layer how exactly to protect the packet. The current IPsec policy mechanisms are too inflexible to properly fulfil these needs. Thus, I would propose that we should start to seriously reconsider the role of AH. In fact, I propose that we should effectively re-charter AH to be a security protocol for IP layer control functions only, and start working an in-stack API that AH would provide to the IP layer control protocols. I think that if such an idea sounds good, we should have a new working group for that. The attitude in the IPsec working group seems to be either negative or oblivious towards AH. Thus, it might make sense to move all AH related work the new working group, if one is formed. I would be happy to try to run a pre-BOF at Vienna if there is any support for this idea. --Pekka Nikander From rja at extremenetworks.com Tue Jun 10 10:55:13 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Tue Jun 10 09:55:24 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <3EE59545.3040106@nomadiclab.com> Message-ID: <28C99EBE-9B4B-11D7-9D51-00039357A82A@extremenetworks.com> Pekka, Thanks for your note. A very long standing problem with the IPsec WG membership is that it ended up (circa 1997) self-selecting for "VPN product vendors", whereas it started out with a much more general goal. The original design intent for both AH and ESP was to provide end-to-end security for co-operating hosts. Because it was trivial (both in spec and in running code) to add support for a tunnel-mode that would enable VPN applications, this was done quite early on (well before RFC-1825 -- RFC-1827 were published). It is correct that the current VPN-oriented membership of the IPsec WG is pretty openly hostile to AH -- mainly because AH is not a VPN-oriented protocol. There have also been some (incorrect) gripes that AH cannot be performed at high-speed because of its header design. However I know of ASICs that can perform AH (with key-agility for many streams concurrently) at multiple Gbps, so that claim has proved ill-founded. It would seem quite reasonable to me to make clear that a VPN product need not implement AH as part of its VPN service offering [1]. In the mid-90s there was still an IETF concept of a "mandatory standard", whereas now all IETF standards are considered "elective" (as near as I can tell from the sidelines). A number of applications (e.g. routing protocols, such as PIM and OSPFv3; IGMP, and ICMP) currently benefit from use of AH. In practice, the US Government (and some other governments) have been known to deny general export of authentication-only-ESP. All export applications for AH have been granted. So in practical terms, an authentication approach based on AH is much more likely to be globally deployable than one based on authentication-only-ESP. Beyond that, AH provides different security properties than ESP.[2] However, I would not want to lose the ability to protect my user traffic with AH-only or with a combined AH+ESP if I wished to do so (and my end-system supported that, which mine currently does). As Mike StJohns can confirm, NRL demonstrated the use of AH to protect IPv6 ICMP, including ND, in August 1995. The demo included secure bootstrapping on a LAN. AH is particularly well-suited to that application, not coincidentally since ESP/AH were originally undertaken within the then-SIP (later IPng) WG. I think it might well make sense to move work on AH outside of the IPsec WG. For that matter, I have for many years advocated that key management (e.g. IKE, ISAKMP, and successors) be undertaken in a separate WG; I still believe that would be helpful. Ran Atkinson rja@extremenetworks.com [1] One might, however, consider that a VPN product that implemented a control protocol (e.g. ICMPv6, IPv6 ND, routing protocol) that used AH for authentication would be required to support AH for those particular applications. [2] Some consider those differences important, others do not. I myself am among those who consider the differences important. From rja at extremenetworks.com Tue Jun 10 12:19:21 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Tue Jun 10 11:20:10 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <28C99EBE-9B4B-11D7-9D51-00039357A82A@extremenetworks.com> Message-ID: On Tuesday, Jun 10, 2003, at 09:55 America/Montreal, RJ Atkinson wrote: > A very long standing problem with the IPsec WG membership > is that it ended up (circa 1997) self-selecting for "VPN product > vendors", whereas it started out with a much more general goal. That text above is poorly phrased. The self-selection started whilst I was IPsec Co-Chair, so it should have said (circa 1996-1997) instead of the actual text above. And I don't know that the self-selection of the IPsec WG membership was an avoidable outcome given the actual circumstances on the ground in that era. So I never intended to blame either my co-chair or the successor co-chairs in the above (quoted) comment. I apologise if my poor initial wording erroneously led any folks to believe that was the intent of my words. Ran rja@extremenetworks.com From phoffman at imc.org Tue Jun 10 09:41:23 2003 From: phoffman at imc.org (Paul Hoffman / IMC) Date: Tue Jun 10 11:47:32 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: References: Message-ID: On Tuesday, Jun 10, 2003, at 09:55 America/Montreal, RJ Atkinson wrote: > A very long standing problem with the IPsec WG membership >is that it ended up (circa 1997) self-selecting for "VPN product >vendors", whereas it started out with a much more general goal. One can argue that having participation from lots of vendors who are actually deploying the security protocols under discussion in the WG is a good thing. There doesn't appear to have been any stifling of the use of IPsec by non-VPN applications, just not much WG support for it. I may have missed something. If there is a need for changes to AH or ESP for some host-to-host models, they should certainly be made. Given that the IPsec WG is now very close to shutting down (yes, really!), anyone who felt that an important protocol change couldn't get heard in the WG should start talking to the ADs about how to proceed. --Paul Hoffman, Director --Internet Mail Consortium From moore at cs.utk.edu Tue Jun 10 13:20:35 2003 From: moore at cs.utk.edu (Keith Moore) Date: Tue Jun 10 12:22:46 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: References: Message-ID: <20030610122035.4c98ac5b.moore@cs.utk.edu> > There doesn't appear to have been any stifling of > the use of IPsec by non-VPN applications, just not much WG support > for it. I may have missed something. IPsec is pretty much useless to applications without a) the ability to authenticate applications and users, rather than hosts b) an API that lets apps specify and obtain credentials as long as IPsec doesn't have those, apps will make do with TLS or roll their own. From rja at extremenetworks.com Tue Jun 10 13:56:08 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Tue Jun 10 12:57:38 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: Message-ID: <6EBFAEAC-9B64-11D7-B33E-00039357A82A@extremenetworks.com> On Tuesday, Jun 10, 2003, at 11:41 America/Montreal, Paul Hoffman / IMC wrote: > One can argue that having participation from lots of vendors who are > actually > deploying the security protocols under discussion in the WG is a good > thing. Yes, but having the WG be dominated by VPN box vendors -- somewhat to the exclusion of some host stack implementers -- has not in practice been a good thing with the IPsec WG, IMHO. > There doesn't appear to have been any stifling of the use of IPsec by > non-VPN applications, just not much WG support for it. I may have > missed something. I've seen a fair amount of "stifling of the use of IPsec by non-VPN applications". I'm not alone in that observation. AH hostility from the VPN crowd is merely one obvious example (noted by several folks repeatedly over the past several years). But please, lets focus on moving forward with the discussion that Pekka outlined, rather than continuing this narrow thread. Ran From rja at extremenetworks.com Tue Jun 10 14:08:35 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Tue Jun 10 13:09:23 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <20030610122035.4c98ac5b.moore@cs.utk.edu> Message-ID: <2BE48FAC-9B66-11D7-B33E-00039357A82A@extremenetworks.com> On Tuesday, Jun 10, 2003, at 12:20 America/Montreal, Keith Moore wrote: >> There doesn't appear to have been any stifling of >> the use of IPsec by non-VPN applications, just not much WG support >> for it. I may have missed something. > > IPsec is pretty much useless to applications without > > a) the ability to authenticate applications and users, rather than > hosts > b) an API that lets apps specify and obtain credentials > > as long as IPsec doesn't have those, apps will make do with TLS or > roll their own. True, though all those capabilities existed *in some form* as far back as 1995 with the NRL IPsec codebase. ESP/AH have *always* had the ability to authenticate applications or users, not just hosts. That's an integral part of the specs. Even the IKE DOI for IPsec has support for a wide range of identities. So I don't think the issues are with the protocol specifications, but rather are with the available host implementations. NRL IPsec had at least 2 APIs in its codebase circa 1995/1996: - PF_KEY for key management traffic, so that key management could be kept outside the kernel. I believe that a later version of this was documented in an RFC. This supported many kinds of identities, including individual users. It was not restricted just to host-granularity identities. - BSD Sockets extensions (and BSD sysctl knobs) to let applications request (and confirm the use of) security services from IPsec. This API supported a range of identities, including individual users. At one time, danmcd had an I-D on some of this, I think, though I'm not sure whether it made it into an RFC. The Sockets options let an application (1) request service, (2) confirm that security was in use for that socket's traffic, and (3) indicate the desired level of security. The BSD sysctl knobs let a privileged user set system-wide default policy settings for whether ESP/AH were always in use even if not specifically requested or were optional to use (i.e. only if the application specifically requested). These capabilities were tested and also were included in one (maybe more) demonstration for ARPA/CSTO during 1995. I believe that Sun probably has some APIs with those capabilities, though I don't have a Sun handy to go check the online manual pages. I'm not sure about other host vendors' implementations. I'm told that MS does not have a key management API -- nor support for manual keying. I've not heard whether MS has an application-enabling API for ESP/AH. Certainly lack of a common, widely deployed, API that is common across multiple vendors is a serious deployment problem for folks writing portable applications. It is entirely tractable to solve if folks are interested in doing so. Ran Atkinson rja@extremenetworks.com From rja at extremenetworks.com Tue Jun 10 15:19:10 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Tue Jun 10 14:22:21 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: Message-ID: <080A2FAC-9B70-11D7-B33E-00039357A82A@extremenetworks.com> On Tuesday, Jun 10, 2003, at 13:36 America/Montreal, Christian Huitema wrote: > I read Pekka's note, which relates to the use of AH in some scenarios, > e.g. SEND. The real issue is, do we need both AH and ESP, or can > something like ESP-NULL be used in lieu of AH and satisfy the AH > scenarios? AH is the right answer for IP-layer authentication, as Pekka noted. Anything using ESP-NULL is actually more complex to implement and less likely to interoperate for things like IPv6 ND or IPv6 ICMP (or IPv4 ICMP/IGMP) authentication. Free running code that interoperates today exists for AH with this application in *BSD and elsewhere. The only thing SEND really needs to address is the key-management. For the BSD stack in my local IPv6 systems, everything is is in place and interoperable today for authenticating IPv6 ND -- except for key management to get the appropriate SA(s) in place. > The question is thus, could ESP-NULL satisfy the SEND requirement? No. Ran rja@extremenetworks.com From pekka.nikander at nomadiclab.com Tue Jun 10 22:27:24 2003 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Tue Jun 10 14:26:32 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <2BE48FAC-9B66-11D7-B33E-00039357A82A@extremenetworks.com> References: <2BE48FAC-9B66-11D7-B33E-00039357A82A@extremenetworks.com> Message-ID: <3EE6230C.1060708@nomadiclab.com> Ran, Keith, Keith Moore wrote: >> IPsec is pretty much useless to applications without >> >> a) the ability to authenticate applications and users, rather than hosts >> b) an API that lets apps specify and obtain credentials RJ Atkinson wrote: > True, though all those capabilities existed *in some form* as far back > as 1995 with the NRL IPsec codebase. ... > Certainly lack of a common, widely deployed, API that is common across > multiple vendors is a serious deployment problem for folks writing portable > applications. It is entirely tractable to solve if folks are interested > in doing so. I agree with you both. However, the lack of an application level API was *not* the point of my message. From my point of view, the lack of such an API is an important but *distinct* problem. From my point of view, considering things like ICMPv6, Mobile IPv6, possibly multi6 solutions, and even HIP, there is a need to extend the *role* of IPsec AH. In SEND, we have designed a solution where we are using AH with RSA. However, in order to do so we have been forced to do some serious hoopla to get around limitations in the IPsec policy architecture. If there had been an in-stack API from IPsec to the upper layer protocols (ICMP in this case), the task would have been much easier. Each received, AH protected message could have been annotated with the public key that was used to protect it, allowing the IPv6 neighbor cache to include the public keys in addition to the IP addresses. When sending out, we could have easily sent both AH protected and unprotected messages, allowing easier interoperability between current IPv6 ND and the secure version of ND. Right now it was felt by the WG that assuming such API like facilities within the stack would be too much for many IPsec implementations, and hence we designed around these issues. The result is not the prettiest one, but seems to work well enough. With Mobile IPv6 there was a more-or-less similar story, with the result that MIPv6 Route Optimization does not use IPsec at all. Hence, I really think that we should consider how AH fits into the overall stack structure (architecture, if you will). I think that it could be a great tool for securing lots of ICMP/MIP/... kind of traffic, but currently it is not. The extensions are not necessarily that big; they would be mostly semantic. What I am asking for is to modify IPsec AH so that it can be used for more, and especially in situations where there is clear need to protect the IP layer or extension headers. There the case if often not only about integrity, but also about authorization, and therefore it is not sufficient to know whether a packet was AH protect or not. It is also needed who sent the packet, and to be able to determine what that principal is authorized for. --Pekka Nikander From rja at extremenetworks.com Tue Jun 10 15:32:02 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Tue Jun 10 14:32:08 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <3EE6230C.1060708@nomadiclab.com> Message-ID: On Tuesday, Jun 10, 2003, at 14:27 America/Montreal, Pekka Nikander wrote: > I agree with you both. However, the lack of an application level > API was *not* the point of my message. From my point of view, the lack > of such an API is an important but *distinct* problem. Agree. > From my point of view, considering things like ICMPv6, Mobile IPv6, > possibly multi6 solutions, and even HIP, there is a need to extend > the *role* of IPsec AH. AH was originally designed (pre-1995) to support ICMPv6, IPv6 ND, and similar applications. So that would not be an extension of its intended original role, but rather an application of AH for one of its intended roles. (Obviously) I think AH is a very good fit for those issues, while ESP is not a good fit. > Hence, I really think that we should consider how AH fits into the > overall stack structure (architecture, if you will). I think that > it could be a great tool for securing lots of ICMP/MIP/... kind of > traffic, but currently it is not. The extensions are not necessarily > that big; they would be mostly semantic. > > What I am asking for is to modify IPsec AH so that it can be used > for more, and especially in situations where there is clear > need to protect the IP layer or extension headers. There the case > if often not only about integrity, but also about authorization, > and therefore it is not sufficient to know whether a packet was > AH protect or not. It is also needed who sent the packet, and to > be able to determine what that principal is authorized for. What specific changes are you proposing ? AH was already designed to protect the IP header and IP-layer extension headers, so the change to the bits-on-the-wire that you are contemplating is not obvious to me from the above description. Ran rja@extremenetworks.com From ho at alum.mit.edu Tue Jun 10 13:44:30 2003 From: ho at alum.mit.edu (The Purple Streak, Hilarie Orman) Date: Tue Jun 10 14:43:22 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: Yourmessage <20030610122035.4c98ac5b.moore@cs.utk.edu> Message-ID: <200306101844.h5AIiU826580@localhost.localdomain> Watch IPSP for the PF_POLICY API. Hilarie > IPsec is pretty much useless to applications without > a) the ability to authenticate applications and users, rather than hosts > b) an API that lets apps specify and obtain credentials > as long as IPsec doesn't have those, apps will make do with TLS or > roll their own. From pekka.nikander at nomadiclab.com Tue Jun 10 22:57:05 2003 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Tue Jun 10 14:56:10 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: References: Message-ID: <3EE62A01.7020900@nomadiclab.com> RJ Atkinson wrote: > What specific changes are you proposing ? > > AH was already designed to protect the IP header and IP-layer > extension headers, so the change to the bits-on-the-wire that > you are contemplating is not obvious to me from the above description. As I wrote, it may be that after all there would be no bits-on-the-wire modifications. Well, using RSA is certainly such a modification, but that is already going on in the SEND context, and the first draft is out (draft-ietf-send-ipsec-01.txt) and in last call. Anyway, most of the issues relate to implementations, and to what one can reasonably expect from an implementation when designing new protocols or new security solutions for existing protocols. What comes to the the details of this, let me return to the issue tomorrow. It is already late here, and my brains are getting muddy. However, we had a paper at Cambridge Security Protocols workshop that is somewhat related and discusses some of the issues. If you want to have a copy, let me know. --Pekka From rja at extremenetworks.com Tue Jun 10 16:03:57 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Tue Jun 10 15:04:41 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <3EE62A01.7020900@nomadiclab.com> Message-ID: <49B14A38-9B76-11D7-B33E-00039357A82A@extremenetworks.com> On Tuesday, Jun 10, 2003, at 14:57 America/Montreal, Pekka Nikander wrote: > As I wrote, it may be that after all there would be no bits-on-the-wire > modifications. Well, using RSA is certainly such a modification, but > that is already going on in the SEND context, and the first draft is > out (draft-ietf-send-ipsec-01.txt) and in last call. Anyway, most > of the issues relate to implementations, and to what one can reasonably > expect from an implementation when designing new protocols or new > security solutions for existing protocols. Using RSA with AH ought not require any modification to the AH protocol itself. At least one prior AH implementation used public-key authentication with IPv6 ND in the past without any problems. To standardise this, one will need an open spec for exactly how one applies RSA to AH (e.g. an "RSA Transform" for AH), maybe also documentation on how one bootstraps into RSA (e.g. gets the needed public keys from someplace and binds them to end systems). There might also be documentation on the authorisation model, if one has been agreed upon. I would guess that if the key management approach being developed within the SEND WG is reasonably general, it might be reused for similar applications (e.g. PIM authentication) with little or no additional work. If there are other specifics, I'm all ears, either here on the SAAG list or off-list. Ran Atkinson rja@extremenetworks.com From huitema at windows.microsoft.com Tue Jun 10 11:36:53 2003 From: huitema at windows.microsoft.com (Christian Huitema) Date: Tue Jun 10 17:07:57 2003 Subject: [saag] Time to reconsider the role of IPsec AH? Message-ID: I read Pekka's note, which relates to the use of AH in some scenarios, e.g. SEND. The real issue is, do we need both AH and ESP, or can something like ESP-NULL be used in lieu of AH and satisfy the AH scenarios? The main difference between AH and ESP-NULL is the authentication coverage. Since the ESP-NULL transform only apply to the payload, the header is not protected. If header fields need to be verified, ESP-NULL forces the protocol designers to repeat these header fields in the payload. This can be perceived as a drawback because of the extra overhead, but it also has a solid advantage in terms of implementation and interoperability: there is no need for a "header canonization" procedure and the associated pitfalls. Header canonization can be a royal pain in practice: some header fields are variable, and in IPv6 intermediate elements can insert intermediate headers, e.g. source address options or routing options. SEND is in fact the exception: secure neighbor discovery is a single hop operation, and no router has a chance to intervene and mangle the header. So the SEND scenario is maybe the only one in which header canonization will not be an issue. The question is thus, could ESP-NULL satisfy the SEND requirement? In the SEND scenario, a key information is the link-local address, and it is actually repeated in the payload of the Neighbor advertisement message. It would be protected by ESP-NULL. The other key information is the IPv6 source address. It is not part of the payload, but it is linked to the credentials used to set up the association, and may well in practice be covered. Bottom line, we need to take a hard look at whether ESP-NULL would satisfy the SEND requirements. -- Christian Huitema From huitema at windows.microsoft.com Tue Jun 10 14:53:08 2003 From: huitema at windows.microsoft.com (Christian Huitema) Date: Tue Jun 10 17:07:59 2003 Subject: [saag] Is there such a thing as "IP superSEC"? Message-ID: In an interview to CNET, Jeff Jaffe, president of Lucent Technologies' Bell Labs, states: "So we had IPsec (a wireless security standard that's short for "Internet protocol security"), and we've since developed an approach called IP SuperSEC... It essentially is a standardized way of encrypting, to the edge of the network, that gives the service provider choices and access. We'd only use it once it's standardized... The standards process takes two years. It started two or three months ago, so it's fresh off the presses." (http://news.com.com/2008-1082_3-1014912.html?tag=lh) Does anybody know what this "IP superSEC" is? -- Christian Huitema From crawdad at fnal.gov Tue Jun 10 17:57:49 2003 From: crawdad at fnal.gov (Matt Crawford) Date: Tue Jun 10 17:57:52 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: Your message of Tue, 10 Jun 2003 10:36:53 PDT. Message-ID: <200306102157.h5ALvnV1017037@gungnir.fnal.gov> > If header fields need to be verified, ESP-NULL forces the protocol > designers to repeat these header fields in the payload. This can be > perceived as a drawback because of the extra overhead, but it also > has a solid advantage in terms of implementation and > interoperability: there is no need for a "header canonization" > [sic] procedure and the associated pitfalls. But then the protocol has to know all the valid discrepancies which may exist between the actual header and the repeated field copies inside the payload -- knowledge which is complex but constant and is already part of AH processing. From mcgrew at cisco.com Tue Jun 10 19:25:38 2003 From: mcgrew at cisco.com (David Mcgrew) Date: Tue Jun 10 21:44:01 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: Message-ID: <4.3.2.7.2.20030610181241.022120c8@mira-sjcm-1.cisco.com> Christian, At 10:36 AM 6/10/2003 -0700, Christian Huitema wrote: >I read Pekka's note, which relates to the use of AH in some scenarios, >e.g. SEND. The real issue is, do we need both AH and ESP, or can >something like ESP-NULL be used in lieu of AH and satisfy the AH >scenarios? > >The main difference between AH and ESP-NULL is the authentication >coverage. Since the ESP-NULL transform only apply to the payload, the >header is not protected. If header fields need to be verified, ESP-NULL >forces the protocol designers to repeat these header fields in the >payload. This can be perceived as a drawback because of the extra >overhead, but it also has a solid advantage in terms of implementation >and interoperability: there is no need for a "header canonization" >procedure and the associated pitfalls. > >Header canonization can be a royal pain in practice: some header fields >are variable, and in IPv6 intermediate elements can insert intermediate >headers, e.g. source address options or routing options. it is not clear to me how repeating some header fields within ESP NULL has an advantage over AH. Presumably we are authenticating those fields because we are going to parse them at the receiving end and make a security decision based on their contents. I can see that canonization can be a pain, but OTOH if we copy some fields into the ESP payload, we'll still need to marshal them on the sending side and to parse them and make the security check on the receiving side. I assume that this check would compare the authenticated values to the unauthenticated values, which implies that the headers would need to be parsed anyway. Also, we would have to standardize on a format for how the headers are stored within the ESP payload. Is there something that I'm missing here? David >SEND is in fact >the exception: secure neighbor discovery is a single hop operation, and >no router has a chance to intervene and mangle the header. So the SEND >scenario is maybe the only one in which header canonization will not be >an issue. > >The question is thus, could ESP-NULL satisfy the SEND requirement? In >the SEND scenario, a key information is the link-local address, and it >is actually repeated in the payload of the Neighbor advertisement >message. It would be protected by ESP-NULL. The other key information is >the IPv6 source address. It is not part of the payload, but it is linked >to the credentials used to set up the association, and may well in >practice be covered. Bottom line, we need to take a hard look at whether >ESP-NULL would satisfy the SEND requirements. > >-- Christian Huitema > > >_______________________________________________ >saag mailing list >saag@mit.edu >https://jis.mit.edu/mailman/listinfo/saag From pekka.nikander at nomadiclab.com Wed Jun 11 11:10:31 2003 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Wed Jun 11 03:09:37 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: References: Message-ID: <3EE6D5E7.7040906@nomadiclab.com> Christian, > ... or can something like ESP-NULL be used in lieu of AH and satisfy > the AH scenarios? The difficultiws with this were covered well by others, and I don't have anyting to add. However, ... > Header canonization can be a royal pain in practice: some header > fields are variable, and in IPv6 intermediate elements can insert > intermediate headers, e.g. source address options or routing options. > Agreed. > SEND is in fact the exception: secure neighbor discovery is a single > hop operation, and no router has a chance to intervene and mangle the > header. Well, I almost agree. There are certainly other link-local operations too, like MLD. Some of those don't have very good or scalable enough security yet. > So the SEND scenario is maybe the only one in which header > canonization will not be an issue. Here I must disagree. Even though SEND and other link local scenarios may be the only ones where header canonization is less an issue than in non-local protocols, there are still protocols that need to preserve the integrity of the information in the IPv6 header. Mobile IPv6 is certainly one which could benefit from that. I have a strong suspicion that some multi-address multi-homing scenarios may belong to that class, too. It is not always sufficient that you rely on routing to make sure that the destination address has not been changed on the route. You sometimes want to have something stronger. More importantly, there are situations where the integrity of the source address is important. With the current IPv6 architecture, AH is a perfect match for these needs. It is a completely different issue if you move to an architecture where the destination address is just a routing token and there is no (semantically meaningful) source address. (For some ramblings about that, see our 2001 Nordsec paper, "IPv6 Source addresses considered harmful", http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf) --Pekka NIkander From pekka.nikander at nomadiclab.com Wed Jun 11 11:17:22 2003 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Wed Jun 11 03:16:57 2003 Subject: Using RSA with AH (was Re: [saag] Time to reconsider the role of IPsec AH?) In-Reply-To: <49B14A38-9B76-11D7-B33E-00039357A82A@extremenetworks.com> References: <49B14A38-9B76-11D7-B33E-00039357A82A@extremenetworks.com> Message-ID: <3EE6D782.3080908@nomadiclab.com> RJ Atkinson wrote: > Using RSA with AH ought not require any modification to the AH > protocol itself. If "protocol" == bits-on-the-wire, agreed. If "protocol" is something more, including behaviour, I am not so sure. > At least one prior AH implementation used public-key authentication > with IPv6 ND in the past without any problems. Any pointers? > To standardise this, one will need an open spec for exactly how one > applies RSA to AH (e.g. an "RSA Transform" for AH), maybe also > documentation on how one bootstraps into RSA (e.g. gets the needed > public keys from someplace and binds them to end systems). There is text about both of these in the send spec, but I don't know if they are generic enough for anything else. Our focus has been on SEND only, at this stage, with the idea of looking at possible generalizations once we have something out. In fact, I personally expect largish changes to SEND on the road from PS to DS. > There might also be documentation on the authorisation model, if one > has been agreed upon. To me, it looks like authorization is always application dependent. Thus, the authorization model for SEND is probably not good, as such, for anything else. > I would guess that if the key management approach being developed > within the SEND WG is reasonably general, it might be reused for > similar applications (e.g. PIM authentication) with little or no > additional work. Maybe. However, currently the IETF politics makes it hard to consider that without the danger of slowing down the speed of the SEND WG. > If there are other specifics, I'm all ears, either here on the SAAG > list or off-list. I'll send a separate message about those (cc:ing to the list). --Pekka Nikander From rja at extremenetworks.com Wed Jun 11 09:55:08 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Wed Jun 11 08:55:22 2003 Subject: Using RSA with AH (was Re: [saag] Time to reconsider the role of IPsec AH?) In-Reply-To: <3EE6D782.3080908@nomadiclab.com> Message-ID: On Wednesday, Jun 11, 2003, at 03:17 America/Montreal, Pekka Nikander wrote: >> At least one prior AH implementation used public-key authentication >> with IPv6 ND in the past without any problems. > > Any pointers? NRL's reference implementation of IPsec and IPv6 for 4.4 BSD. And Mike StJohns can confirm seeing the demonstration of authenticated bootstrapping of IPv6 (including ND) in August 1995; he was at ARPA in those days. I noted all this publicly during the SEND BOF in Yokohama, so I'm surprised you haven't heard it before. Because of patent issues, the IETF was not interested (at that time) in standardising use of RSA with AH/ESP. >> To standardise this, one will need an open spec for exactly how one >> applies RSA to AH (e.g. an "RSA Transform" for AH), maybe also >> documentation on how one bootstraps into RSA (e.g. gets the needed >> public keys from someplace and binds them to end systems). > > There is text about both of these in the send spec, but I don't > know if they are generic enough for anything else. Our focus > has been on SEND only, at this stage, with the idea of looking > at possible generalizations once we have something out. In fact, > I personally expect largish changes to SEND on the road from PS to DS. Architecturally, it might be cleaner to have 2 documents, one with an "RSA transform" for AH and the second with the bootstrap process. This partitioning would facilitate other folks/protocols/WGs re-using the 'transform' piece in other contexts, for example. >> There might also be documentation on the authorisation model, >> if one has been agreed upon. > > To me, it looks like authorization is always application dependent. > Thus, the authorization model for SEND is probably not good, as such, > for anything else. I'm not convinced that authorisation is always application-dependent. It is easy to believe that someone might devise an authorisation model for SEND that might not be fully general. Ran rja@extremenetworks.com From mcr at sandelman.ottawa.on.ca Tue Jun 10 20:35:59 2003 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Wed Jun 11 09:17:12 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: Your message of "Tue, 10 Jun 2003 11:22:29 +0300." <3EE59545.3040106@nomadiclab.com> Message-ID: <200306102337.h5ANZxdK007890@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- A good message. Your points are all well taken to me. I have been saying for awhile that we need to keep AH - the reasons for it are not yet established, and have nothing to do with VPN. I do not know if we need an "AH" WG group. I'm not sure that it would be more effective than just doing the work in SEND. {I'd rather see a proper VPN profile of IPsec so that so that the *IP* security (not encryption) WG can progress on *securing* IP. But, that is a pipe dream.} ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPuZrXIqHRg3pndX9AQGClwP+N5x2NNi5NdG1gX1p+dj7iigYvOMT/TBv +Sm/37E4aV0/RotEp0oSrPawLuf5XVJr4It1gb0j8ax8PdcHkI88AQd/3bmTnmyY YSy37nHHTyqrW+xTzFz0aN9hQJj28kBHCf6ll5rH/U1xxjXecjmH0eEz4ih82hhf NAFyBgBn3Fg= =jsqE -----END PGP SIGNATURE----- From pekka.nikander at nomadiclab.com Wed Jun 11 17:56:39 2003 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Wed Jun 11 10:04:05 2003 Subject: Using RSA with AH (was Re: [saag] Time to reconsider the role of IPsec AH?) In-Reply-To: References: Message-ID: <3EE73517.6050601@nomadiclab.com> RJ Atkinson wrote: > ... I noted all this publicly during the SEND BOF in Yokohama, > so I'm surprised you haven't heard it before. Sorry, Ran, I remember now that you mention it. I am unfortunately one of those people who have real difficulty remembering afterwards what people have talked about, especially if it has *not* taken place in my mother tongue. I seem to remember things much much better when written (but details badly even then). Anyway, I was more looking for real references, i.e., publications or other publicly available material that I could study. Mostly to see if we are missing something in our current work. > Because of patent issues, the IETF was not interested (at that time) in > standardising use of RSA with AH/ESP. I see. >>> To standardise this, one will need an open spec for exactly how one >>> applies RSA to AH (e.g. an "RSA Transform" for AH), maybe also >>> documentation on how one bootstraps into RSA (e.g. gets the needed >>> public keys from someplace and binds them to end systems). >> > Architecturally, it might be cleaner to have 2 documents, one with an > "RSA transform" for AH and the second with the bootstrap process. This > partitioning would facilitate other folks/protocols/WGs re-using the > 'transform' piece in other contexts, for example. Architecturally, it would be cleaner if we had about 4 documents in SEND instead of the currently two. However, James is really pushing speed, and I don't mind. >> To me, it looks like authorization is always application dependent. >> Thus, the authorization model for SEND is probably not good, as such, >> for anything else. > > I'm not convinced that authorisation is always application-dependent. Would you care to clarify? I am somewhat surprised. --Pekka Nikander From derek at ihtfp.com Wed Jun 11 11:30:39 2003 From: derek at ihtfp.com (Derek Atkins) Date: Wed Jun 11 10:35:38 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <080A2FAC-9B70-11D7-B33E-00039357A82A@extremenetworks.com> References: <080A2FAC-9B70-11D7-B33E-00039357A82A@extremenetworks.com> Message-ID: Ran, It's time for me to play devil's advocate here. I don't have a strong preference about AH v. ESP-NULL, but at the same time I see a very strong "I'm right, you're wrong, this is the right way!" attitude from a number of people in this thread. So, please bear with me as I ask a few pointed (albeit short) questions herein.... RJ Atkinson writes: > On Tuesday, Jun 10, 2003, at 13:36 America/Montreal, Christian Huitema > wrote: > > I read Pekka's note, which relates to the use of AH in some scenarios, > > e.g. SEND. The real issue is, do we need both AH and ESP, or can > > something like ESP-NULL be used in lieu of AH and satisfy the AH > > scenarios? > > AH is the right answer for IP-layer authentication, as Pekka noted. Ok, _why_ is it "the right answer"? What particular features of AH, that do NOT exist in ESP-NULL, make it "the right answer"? Or vice-versa, what particular features of ESP-NULL make it "not the right answer"? Please be specific. > Anything using ESP-NULL is actually more complex to implement and > less likely to interoperate for things like IPv6 ND or IPv6 ICMP > (or IPv4 ICMP/IGMP) authentication. Free running code that > interoperates > today exists for AH with this application in *BSD and elsewhere. Ok.... On what basis do you conclude that ESP-NULL is less likely to interoperate? Why do you consider ESP-NULL more complex than AH? Why do you feel that using ESP-NULL for IPv6 ND or IPv6 ICMP is any less of an interop issue than ESP-NULL for TCP? In a similar vein, on what basis do you conclude that AH is any easier to implement? > The only thing SEND really needs to address is the key-management. > For the BSD stack in my local IPv6 systems, everything is is in place > and interoperable today for authenticating IPv6 ND -- except for key > management to get the appropriate SA(s) in place. > > > The question is thus, could ESP-NULL satisfy the SEND requirement? > > No. Ok, could you be more explicit? What feature(s) is(are) missing from ESP-NULL such that it does not satisfy the SEND requirements? I'm specifically looking for "it cannot do foo", not "AH does foo better". I'm trying to understand what is so intrinsically different about ESP-NULL (or about the SEND requirements) that resulted in such a terse reply. > Ran > rja@extremenetworks.com -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From mcr at sandelman.ottawa.on.ca Wed Jun 11 14:04:32 2003 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Wed Jun 11 13:04:49 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: Your message of "11 Jun 2003 10:30:39 EDT." Message-ID: <200306111704.h5BH4XFl007357@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Derek" == Derek Atkins writes: >> AH is the right answer for IP-layer authentication, as Pekka noted. Derek> Ok, _why_ is it "the right answer"? What particular features of AH, Derek> that do NOT exist in ESP-NULL, make it "the right answer"? Or Derek> vice-versa, what particular features of ESP-NULL make it "not the Derek> right answer"? Please be specific. AH *guarantees* that the data that follows the packet are not encrypted. As such, one can look at the things that follow, decide if they are even interesting, and *only* then, calculate the authenticator. (Which might involve doing RSA, finding the right public key, etc...) ESP does not make this guarantee. The recipient who assigned the SPI# possibly look up the algorithm in the SPD and find out that it was NULL, but nobody else can. (Nor can the recipient if they have rebooted since) So, AH is appropriate for securing things like ARP/ND, which are likely to be broadcast/multicast. ESP-null can only be used between consenting parties that know about each other already. Now, to backtrack a bit - an RSA Transform for AH would like use a well-known SPI#. That *could* be done for ESP-null, but I do not see the advantage of doing so, if the things you wanted to authenticate were extension headers. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPudhH4qHRg3pndX9AQGNsQP/RSpCQA4vEDFdHMxYkcMd+FM/cBt9BofS dljYCMXy7wnb7oVmm1/KFyQOOse3z/g1hHaBqn3apF0nQJ1ZtyI74nr9SLCrWW5E 0dw7v4/AJ/Fat/a0ElZb42Sm2IQrAfnIWIKs/pQCNOAfq61LPef712zUeHM84LF6 9HkDmxOnc4g= =NKhr -----END PGP SIGNATURE----- From pekka.nikander at nomadiclab.com Wed Jun 11 22:18:35 2003 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Wed Jun 11 14:17:40 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <3EE62A01.7020900@nomadiclab.com> References: <3EE62A01.7020900@nomadiclab.com> Message-ID: <3EE7727B.8090407@nomadiclab.com> RJ Atkinson wrote: >> What specific changes are you proposing ? >> >> AH was already designed to protect the IP header and IP-layer >> extension headers, so the change to the bits-on-the-wire that you >> are contemplating is not obvious to me from the above description. I wrote: > As I wrote, it may be that after all there would be no > bits-on-the-wire modifications. ... Anyway, most of the issues > relate to implementations, and to what one can reasonably expect from > an implementation when designing new protocols or new security > solutions for existing protocols. > > What comes to the the details of this, let me return to the issue > tomorrow. From my point of view, the big issue here is authorization. AH, as deployed today, protects the integrity and authenticity of the packet. That is, at AH layer it is known who sent the message and that the message was not modified while in transit. However, in many implementations this information is not available to the upper layers. The source IP address can act as a hint, but it is not an ideal identifier. One issue here is, of course, what I mean with authorization. Let me take a couple of examples. In SEND, the question to answer is to say who is authorized to say which MAC address to use when sending unicast messages to a given IP address. That is, the authority over creating IPv6 address -> MAC address bindings. Respectively, in Mobile IP the question is about the right to create IP address -> IP address bindings. In both of these cases, therefore, the question is on who is authorized to create state wrt. a given IP address, but the exact nature of the state is different. In other cases, the state and the right to create state could be different. One could argue that AH should completely perform the required authorization check and only pass authorized packets to the upper layer. However, that turns out to pretty hard, resulting in duplicating or moving some application specific code to AH. --Pekka Nikander From rja at extremenetworks.com Wed Jun 11 15:43:54 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Wed Jun 11 14:46:40 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <3EE7727B.8090407@nomadiclab.com> Message-ID: On Wednesday, Jun 11, 2003, at 14:18 America/Montreal, Pekka Nikander wrote: > From my point of view, the big issue here is authorization. > AH, as deployed today, protects the integrity and authenticity > of the packet. That is, at AH layer it is known who sent the > message and that the message was not modified while in transit. > However, in many implementations this information is not > available to the upper layers. The source IP address can act > as a hint, but it is not an ideal identifier. Implementation details vary of course. The NRL IPv6+IPsec code had (IPv6, IPv4, ICMP, IPv6 ND, ESP/AH, and hooks to key management) all inside a single "layer. The KAME code is different from NRL in details, but has a lot of similarities in terms of layering (no surprise since both KAME and NRL were working from 4.4 BSD sources). The cisco IOS IPv6 code that I wrote also had IPv6 ND and IPv6 ICMP as an integral part of the IPv6 "layer" (that code might have changed in the intervening years, of course, though I can't immediately think of why anyone would have changed that aspect of the code). Back when I was coding on cisco IOS IPv6, the ESP/AH code (then) only supported IPv4 and was written by other folks (in the security group; I was in the routing group) -- so I'm not sure how integrated/decoupled the ESP/AH code in IOS is from the IPv6 code. Most 4.3/4.4 BSD implementations do not have strict layering boundaries in their source code (e.g. between TCP and IP). Cisco IOS is not very BSDish, but also did not have rigid layering boundaries (at least when I was working with it). The absence of standardised APIs to make information such as "sender identity" or "packet was received and authentication succeeded" is a significant issue, though I view it as more of a concern for applications (e.g. SMTP, FTP) than for protocols (e.g. ND, ICMP) that are internal-to IPv6 or IPv4. Many ESP/AH implementations do have APIs for those things, though the details of such APIs probably vary annoyingly. I know that some folks are trying to sort out those API issues, but am not sure where that discussion stands today. > One issue here is, of course, what I mean with authorization. > Let me take a couple of examples. In SEND, the question to > answer is to say who is authorized to say which MAC address to > use when sending unicast messages to a given IP address. That > is, the authority over creating > > IPv6 address -> MAC address > > bindings. Since (IPv6 ND, IPv6 ICMP, AH, and ESP) are all inside the same layer, namely the IP layer, I would bet that most implementations have all the information resulting from receive-side AH processing fully available to the ND code without any API issues getting in the way. > Respectively, in Mobile IP the question is about > the right to create > > IP address -> IP address > > bindings. > > In both of these cases, therefore, the question is on who > is authorized to create state wrt. a given IP address, but > the exact nature of the state is different. In other cases, > the state and the right to create state could be different. > > One could argue that AH should completely perform the > required authorization check and only pass authorized > packets to the upper layer. However, that turns out to > pretty hard, resulting in duplicating or moving some > application specific code to AH. I have not myself ever coded up "Mobile IPv6". However, I still see this as (1) an API issue if Mobile IPv6 is implemented very separately from IPv6/ICMP/ND/AH/ESP or (2) not an issue if Mobile IPv6 is implemented as part of the IPv6 "layer". The issues you raise in this note are very important. To me, they seem mostly to be implementation-oriented concerns rather than "protocol spec"/"bits on the wire"/"protocol architecture" concerns. Maybe I've missed one of your points, not sure. If so, my apologies. Ran Atkinson rja@extremenetworks.com From rja at extremenetworks.com Wed Jun 11 15:58:35 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Wed Jun 11 15:02:09 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <200306111704.h5BH4XFl007357@sandelman.ottawa.on.ca> Message-ID: On Wednesday, Jun 11, 2003, at 13:04 America/Montreal, Michael Richardson wrote: > AH *guarantees* that the data that follows the packet are not > encrypted. > As such, one can look at the things that follow, decide if they are > even > interesting, and *only* then, calculate the authenticator. (Which might > involve doing RSA, finding the right public key, etc...) > > ESP does not make this guarantee. The recipient who assigned the SPI# > possibly look up the algorithm in the SPD and find out that it was > NULL, > but nobody else can. (Nor can the recipient if they have rebooted > since) > > So, AH is appropriate for securing things like ARP/ND, which are > likely > to be broadcast/multicast. ESP-null can only be used between consenting > parties that know about each other already. > > Now, to backtrack a bit - an RSA Transform for AH would like use a > well-known SPI#. That *could* be done for ESP-null, but I do not see > the > advantage of doing so, if the things you wanted to authenticate were > extension headers. All good points. I'll add a few more, though this is not by any means a comprehensive list yet. Additionally, IPv6 ICMP/ND uses the contents of the IPv6 base header (and potentially also some extension headers) in their processing. - ESP Null could only authenticate copies of those headers -- which means the sender has to copy all those fields (an extra step) and the receiver would need to compare all those fields (outer header contents against encapsulated header contents) (another extra step). No one has all this coded up today. The extra processing is complicated, easy to get wrong, and not likely to interoperate the first time. Most IPv6 implementations already support AH, interoperate today with AH, and AH already authenticates all those fields without any need for copying on the sending side or for comparison on the receiving side. Bottom line is that AH was *designed* to address the ND/ICMP/routing-protocol authentication problem space, while ESP-Null was designed for the authentication-only VPN problem space. The SEND archives are also worth reading if one wants to understand how that WG reached the conclusion that AH was the best approach. Ran rja@extremenetworks.com From jari.arkko at piuha.net Thu Jun 12 02:54:32 2003 From: jari.arkko at piuha.net (Jari Arkko) Date: Wed Jun 11 19:06:53 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: References: Message-ID: <3EE7B328.3060909@piuha.net> Hello folks, Thank you Pekka for raising this discussion. I think we need to seriously consider the fate of AH, and perhaps even more generally the use of IPsec in the context of IP layer control protocols or applications (the non-VPN uses). Over the last few years I've worked with securing ND using a number of alternative techniques techniques. I am also the editor of the current protocol specification for SEND. The discussion in this thread seems to be centered around three subjects so far: - the original question of refocusing AH for IP layer tasks - availability and properties of the required APIs - adequacy of null ESP vs. AH for the task in SEND - history for the focus of the IPsec WG Here's my take on the issues: I'm happy to hear that there's more work on the APIs than I realized before. I think we should resist the temptation to talk about the ESP vs. AH issue. The difference is largely insignificant from the 10.000 ft level, and we will miss more important issues while debating this. Say, how good match are SPD mechanisms for problems like SEND? I'd like to focus on Pekka's questions. The way he phrased it was: can we make AH more suitable for various IP layer control protocols? I'd like to suggest another question which allows us to look at the problem, not the hammer: How should we secure the IP layer control functions? And what are the alternatives and their respective advantages and disadvantages? 1) Use of IPsec -- some support from an existing protocol but also some extensions and implementation work needed. 2) "Application" specific security solutions -- a perfect match to the needs of the applications, but different and new solutions required for the different applications. I'm coming to the conclusion that approach 2 is the right choice. (I realize that this may be strange coming from the editor of the SEND document, but editors don't get to make decisions, WG consensus makes decisions.) But let me explain why I'm coming to this conclusion. Basically, all the IP level control protocols have very specific security needs. It is possible to satisfy them using IPsec, but I doubt that the cost(s) are worth it. As an example, in SEND the use of IPsec instead of ND options causes the following: - Need to extend AH with public key crypto algorithms. Also need to make a number of other smaller extensions, such as ICMP type selectors or making it possible to look up SAs based on the SPI and not the destination address (the latter I believe is a part of 2406bis work, too). - Need to rely on the existence of an API between the IPsec and ND parts. And not just a simple configuration API, but I fear that we may need a per-packet API. - Need to modify ND behaviour, since ND as-is uses addresses in a way that isn't representable in the SPD easily. - Need to provide a (small) part of the security solution anyway in the ND layer since some issues can not be handled at the IPsec layer due to their inter-packet nature. - Need to make compromises on how well the end result works in a mixed secure/non-secure environments. All of the above issues are solvable. In fact the current specification solves them. But I believe the alternative solution would have been simpler, would not imply so many implementation requirements, would be contained in a single module, would not be so fragile if something changes in the protocol to be secured, and could be deployed faster. --Jari From randy at psg.com Thu Jun 12 10:57:27 2003 From: randy at psg.com (Randy Bush) Date: Wed Jun 11 21:00:43 2003 Subject: [saag] Security Requirements Intnernet Draft (a request for comments) Message-ID: From: "George M. Jones" I've published an Internet Draft on "Security Requirements for Devices Implementing IP". You can view it at: http://www.ietf.org/internet-drafts/draft-jones-opsec-00.txt This is an outgrowth of a document used by UUNET (my former employer) to sanity check/security qualify equipment for connection to the backbone. The point of publishing the document is to start discussion. There is a mailing list set up: opsec@ops.ietf.org. Subscribe by sending a message to "majordomo@ops.ietf.org" with "subscribe opsec" in the body. The point of the document is to create a useful list that network operators can use to communicate their securtiy requirements to vendors. Please have a look and comment. Thanks, ---George Jones From rja at extremenetworks.com Wed Jun 11 22:04:32 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Wed Jun 11 21:09:34 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <3EE7B328.3060909@piuha.net> Message-ID: On Wednesday, Jun 11, 2003, at 18:54 America/Montreal, Jari Arkko wrote: > I'm happy to hear that there's more work on the APIs > than I realized before. As I noted in a note earlier today, the actual implementation of ND inside a single layer, along with IPv6, AH, and ESP, means that APIs are not generally a proximal issue for the use of either AH/ESP with IPv6 ND. > Say, how good match are SPD mechanisms for problems like > SEND? RFC-1825 through RFC-1827 don't mention "SPD" at all. SPDs are a useful conceptual construct to clarify aspects of AH/ESP. My understanding has been that the SPD was not intended to be restrictive so much as descriptive, maybe I've misread the current drafts for AH/ESP. In any event, adding selectors to the current draft ought not be difficult if folks felt it were useful/needed. > can we make AH more suitable for various IP layer > control protocols? Again, I repeat my earlier question: Which specific changes are being contemplated (beyond the AH transform for RSA and the boostrap process to get initial keys for ND to use) and why would those changes be needed ? > I'd like to suggest another question which > allows us to look at the problem, not the hammer: How > should we secure the IP layer control functions? And > what are the alternatives and their respective > advantages and disadvantages? 1) Use of IPsec -- some > support from an existing protocol but also some extensions > and implementation work needed. 2) "Application" specific > security solutions -- a perfect match to the needs of > the applications, but different and new solutions required > for the different applications. If one devised a general solution to applying Public Key cryptography for authentication with AH, that solution would likely be applicable (without substantial additional work) to at least: - OSPFv3 - PIM - IGMP - ICMP The SEND WG has chosen not to work on that general problem, but instead has focused on a very ND-centric approach. That's a legitimate choice for the WG to make. A side effect of that choice is that the approach in the SEND documents might not be the "general solution" I mentioned in the previous paragraph. > I'm coming to the conclusion that approach 2 is the right > choice. (I realize that this may be strange coming from the > editor of the SEND document, but editors don't get to make > decisions, WG consensus makes decisions.) But let me explain > why I'm coming to this conclusion. Basically, all the IP level > control protocols have very specific security needs. It is > possible to satisfy them using IPsec, but I doubt that the > cost(s) are worth it. As an example, in SEND the use of > IPsec instead of ND options causes the following: > > - Need to extend AH with public key crypto algorithms. This is a pretty modest amount of work -- and is useful for things well beyond ND/SEND, so ought to be done regardless, IMHO. Earlier on, patent issues were an impediment that they no longer are. > Also > need to make a number of other smaller extensions, such > as ICMP type selectors or making it possible to look up > SAs based on the SPI and not the destination address > (the latter I believe is a part of 2406bis work, too). Running code from NRL in 1995 showed that one could easily do the lookup using both Dest Addr and SPI (even when Dest Addr is a multicast group). We had AH-authenticated IPv6 ND running back in late August 1995, so there is strong experimental evidence that this can work fine without necessarily changing the SA lookup code. Of course alternate approaches probably also exist. I'm just noting that at least one approach doesn't necessarily require all those tweaks. > - Need to rely on the existence of an API between the > IPsec and ND parts. And not just a simple configuration > API, but I fear that we may need a per-packet API. Those "parts" are normally (always ?) implemented as a single layer inside real-world IPv6 software, so an API is not normally needed between them. > - Need to modify ND behaviour, since ND as-is uses addresses > in a way that isn't representable in the SPD easily. Again, we did not have to modify ND in 1995 to get AH to work with IPv6 ND. Now, ND has mutated a fair bit since 1995, but it still is not immediately obvious (to me) why such a modification to ND behaviour is really necessary today. > - Need to provide a (small) part of the security solution > anyway in the ND layer since some issues can not be > handled at the IPsec layer due to their inter-packet > nature. They aren't separate layers !!! > - Need to make compromises on how well the end result > works in a mixed secure/non-secure environments. Which compromises ? Why needed ? > All of the above issues are solvable. In fact the > current specification solves them. But I believe the > alternative solution would have been simpler, would > not imply so many implementation requirements, would > be contained in a single module, would not be so > fragile if something changes in the protocol to be > secured, and could be deployed faster. My impression from your note and Pekka's notes is that you all have done a very thorough theoretical analysis, but that a number of the issues raised exist only in theory, but not really in practice in deployed software. In at least the KAME and NRL codebases, many of the issues you identify above do not exist. I am pretty sure that KAME is the basis for a plurality (maybe even a majority) of the IPv6 implementations out there. KAME is in *BSD, MacOS, etc. KAME is also the basis for numerous other products built on various RTOSs (e.g. I know of several routers that include the KAME IPv6 stack). So the KAME implementation is a useful reference point, IMHO. Yours, Ran Atkinson rja@extremenetworks.com From mankin at psg.com Tue Jun 10 21:14:50 2003 From: mankin at psg.com (Allison Mankin) Date: Wed Jun 11 21:24:44 2003 Subject: [saag] Is there such a thing as "IP superSEC"? In-Reply-To: Message from "Christian Huitema" Message-ID: Christian, IPSuperSec is the Lucent name for approaching the problem of IPsec blocking the ability of networks to perform services such as RFC 3135 PEPs. SAAG saw a presentation in Atlanta on the original approach under this name, by Sneha Kasera from Lucent. This original approach was an extension of IPsec, and the SAAG recommendation was that this work not go forward. Lucent took the recommendation to change gears, while still aiming to work on the problem at IETF. The name just stayed on. In IETF, it seemed possible to some transport and security folks that the endsystem (or both endsystems) and the intermediary could have a new protocol approach for handling this problem, one at a transport level, so in Yokohama, Transport sponsored the Intersec BOF to begin discussing the problem in ways that would give transport services (and secure them) outside of IPsec, without being an IPsec extension. The group from Lucent wrote a requirements document, (draft-faynberg-transport-intermediary-00.txt) for the BOF. The BOF called for continued work in IETF, so there will be further developments. There's a mailing list (intersec-request@psg.com). Disclosure: I'm Transport Co-AD, but I also work for Bell Labs. I think the work is important, but I'm ensuring the BOFs etc are evaluated by others than myself to be careful about conflict of interest. Allison > > In an interview to CNET, Jeff Jaffe, president of Lucent Technologies' > Bell Labs, states: "So we had IPsec (a wireless security standard > that's short for "Internet protocol security"), and we've since > developed an approach called IP SuperSEC... It essentially is a > standardized way of encrypting, to the edge of the network, that gives > the service provider choices and access. We'd only use it once it's > standardized... The standards process takes two years. It started two or > three months ago, so it's fresh off the presses." > (http://news.com.com/2008-1082_3-1014912.html?tag=lh) > > Does anybody know what this "IP superSEC" is? > > -- Christian Huitema > > > > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag From smb at research.att.com Wed Jun 11 21:52:45 2003 From: smb at research.att.com (Steve Bellovin) Date: Wed Jun 11 21:57:35 2003 Subject: [saag] Security Requirements Intnernet Draft (a request for comments) (F orwarded) Message-ID: <20030612005245.8F3637B4D@berkshire.research.att.com> Comments welcome. ------- Forwarded Message Message-ID: <3EE7C8A6.8080706@mitre.org> Date: Wed, 11 Jun 2003 20:26:14 -0400 From: "George M. Jones" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nanog@merit.edu Subject: Security Requirements Intnernet Draft (a request for comments) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-nanog@merit.edu Precedence: bulk Errors-To: owner-nanog-outgoing@merit.edu X-Loop: nanog X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_MOZILLA_UA,X_LOOP autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) I've published an Internet Draft on "Security Requirements for Devices Implementing IP". You can view it at: http://www.ietf.org/internet-drafts/draft-jones-opsec-00.txt This is an outgrowth of a document used by UUNET (my former employer) to sanity check/security qualify equipment for connection to the backbone. The point of publishing the document is to start discussion. There is a mailing list set up: opsec@ops.ietf.org. Subscribe by sending a message to "majordomo@ops.ietf.org" with "subscribe opsec" in the body. The point of the document is to create a useful list that network operators can use to communicate their securtiy requirements to vendors. Please have a look and comment. Thanks, - ---George Jones ------- End of Forwarded Message --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) From jari.arkko at piuha.net Thu Jun 12 10:44:04 2003 From: jari.arkko at piuha.net (Jari Arkko) Date: Thu Jun 12 02:45:51 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: References: Message-ID: <3EE82134.5040901@piuha.net> RJ Atkinson wrote: > SPDs are a useful conceptual construct to clarify aspects > of AH/ESP. My understanding has been that the SPD was > not intended to be restrictive so much as descriptive, > maybe I've misread the current drafts for AH/ESP. In > any event, adding selectors to the current draft ought > not be difficult if folks felt it were useful/needed. Ok, great! > If one devised a general solution to applying Public Key > cryptography for authentication with AH, that solution > would likely be applicable (without substantial additional > work) to at least: > - OSPFv3 > - PIM > - IGMP > - ICMP > > The SEND WG has chosen not to work on that general problem, > but instead has focused on a very ND-centric approach. > That's a legitimate choice for the WG to make. A side > effect of that choice is that the approach in the SEND > documents might not be the "general solution" I mentioned > in the previous paragraph. Actually, I believe the solution we have is quite general. This is a bit visible in the name of the new transform which is AH_RSA_Sig rather than, say, AH_SEND. However, the documentation of the feature is in a section of the SEND spec, not its free standing specification. And we are not marketing the solution for a large number of folks, collecting their requirements, and getting everyone's agreements and so forth. This is so mainly in the interest of publishing the spec in a reasonable amount of time. Still, I believe the exact mechanism could be applied in other contexts as well. One technical thing that is not general is the retrieval of cert chains for the peer. We've chosen to do this outside AH for efficiency reasons (don't have to send it every time). This means that we still expect AH_RSA_Sig to get the necessary cert chains from ND. However, you could perhaps argue that in a different application there'd be something else that is feeding the same information to AH via an API. >> - Need to rely on the existence of an API between the >> IPsec and ND parts. And not just a simple configuration >> API, but I fear that we may need a per-packet API. > > > Those "parts" are normally (always ?) implemented as a > single layer inside real-world IPv6 software, so an API > is not normally needed between them. Well, an interface is probably internally needed in any case. But I agree this is easier given that they are in the same layer. What about BITS implementations? >> - Need to modify ND behaviour, since ND as-is uses addresses >> in a way that isn't representable in the SPD easily. > > > Again, we did not have to modify ND in 1995 to get AH to work > with IPv6 ND. Now, ND has mutated a fair bit since 1995, but > it still is not immediately obvious (to me) why such a modification > to ND behaviour is really necessary today. Part of the reason for the need of the changes is probably that we attempt to treat the authorization issues at a demanding level. In particular, it is not sufficient for us to use a good guys - bad guys separation. We are also making sure that one of the good guys doesn't spoof another good guy's addresses, for instance. Your model from 1995 may have had a slightly different security model so it didn't need to treat this. This translates into a need to worry about who is making what changes to Neighbor Caches etc. As a result, we are in some cases using a tentative address source rather than the currently mandated unspecified address. > My impression from your note and Pekka's notes is that you > all have done a very thorough theoretical analysis, but > that a number of the issues raised exist only in theory, > but not really in practice in deployed software. Well, like I said the current documents are based on the use of IPsec. I believe its implementable at least in most cases, and may even have some aspects of the generality that you wanted. That's not the question. I just believe it would be easier in another way. I also look it from this point: if we are not using SPDs like you suggest, if the application is in direct control of AH packet processing, if the current algorithms are not used, if the format for the Authentication Data field looks very different from current formats, if sequence number field is not used, why are we reusing AH? I mean it has to be not just possible, but also useful, right? Perhaps the generality aspects are the useful thing that justifies this? Maybe... and that's part of the reason we're having this discussion. But its still a tradeoff, and I think an "application" solution would produce an overall better result. --Jari From rja at extremenetworks.com Thu Jun 12 11:17:26 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Thu Jun 12 11:15:48 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <3EE82134.5040901@piuha.net> Message-ID: <9813572E-9CE0-11D7-A5E6-00039357A82A@extremenetworks.com> On Thursday, Jun 12, 2003, at 02:44 America/Montreal, Jari Arkko wrote: > One technical thing that is not general is the retrieval > of cert chains for the peer. We've chosen to do this outside > AH for efficiency reasons (don't have to send it every time). > This means that we still expect AH_RSA_Sig to get the necessary > cert chains from ND. However, you could perhaps argue that > in a different application there'd be something else that is > feeding the same information to AH via an API. My personal view is that it is architecturally sensible to separate this function out from AH. Other folks mileage might vary. At one time there was a Sun proposal for an lightweight protocol to push/pull certificates around. This was run over UDP, if I recall, and was a nicely general way to move certificates around for a variety of uses/applications. So I think that a general solution to that issue is possible, if folks choose to adopt one. >>> - Need to rely on the existence of an API between the >>> IPsec and ND parts. And not just a simple configuration >>> API, but I fear that we may need a per-packet API. >> Those "parts" are normally (always ?) implemented as a >> single layer inside real-world IPv6 software, so an API >> is not normally needed between them. > > Well, an interface is probably internally needed in any case. Maybe. In a typical BSD stack, one might not need a formal interface. And since this is clearly an implementation detail, there would not be any need for IETF to define such an interface -- the implementer can sort this all out her/himself without any IETF help. > What about BITS implementations? IPv6 requires that there be an in-stack implementation of AH/ESP. BITS doesn't meet that requirement, so it is safe to assume that AH/ESP will really be there for hosts implementing IPv6 ND. In practice, Bump-in-the-Stack has a bunch of flaws for this scenario. One of those flaws is that BITS is logically a kind of outboard VPN crypto, not an integrated part of the host IP stack. To protect ND, one needs something that is logically part of the host itself -- not outboard from the host. >>> - Need to modify ND behaviour, since ND as-is uses addresses >>> in a way that isn't representable in the SPD easily. >> Again, we did not have to modify ND in 1995 to get AH to work >> with IPv6 ND. Now, ND has mutated a fair bit since 1995, but >> it still is not immediately obvious (to me) why such a modification >> to ND behaviour is really necessary today. > > Part of the reason for the need of the changes is probably > that we attempt to treat the authorization issues at a > demanding level. In particular, it is not sufficient for > us to use a good guys - bad guys separation. We are also > making sure that one of the good guys doesn't spoof another > good guy's addresses, for instance. We assumed that no one was trusted, so we actually worried not only about the above, but also about hosts impersonating a router, a router impersonating a host, and a pretty comprehensive range of other threats. To put the 1995 work in context, consider that we were working for the US Navy and we assumed that there existed multiple hostile and well-funded parties wanting to attack USN operational networks. (Our paranoia level was reasonably high. :-) > This translates into a need to worry about who is making > what changes to Neighbor Caches etc. As a result, we are > in some cases using a tentative address source rather than > the currently mandated unspecified address. A range of design approaches can work for the ND problem. The SEND WG has picked one. That one might or might not be the best one, but "best" is irrelevant as a metric since the IETF operates on WG rough consensus. >> My impression from your note and Pekka's notes is that you >> all have done a very thorough theoretical analysis, but >> that a number of the issues raised exist only in theory, >> but not really in practice in deployed software. > > Well, like I said the current documents are based on the > use of IPsec. I believe its implementable at least in > most cases, and may even have some aspects of the generality > that you wanted. That's not the question. I just believe it > would be easier in another way. I wonder if you'd reach different conclusions if you spent more time considering the source code of some actual existing IPv6, AH/ESP implementations. Maybe you would not, but I really wonder if it wouldn't change your perspective somewhat to have a better understanding of how these pieces are all actually implemented (e.g. in KAME). > I also look it from this > point: if we are not using SPDs like you suggest, if the > application is in direct control of AH packet processing, > if the current algorithms are not used, if the format for > the Authentication Data field looks very different from > current formats, if sequence number field is not used, > why are we reusing AH? I mean it has to be not just > possible, but also useful, right? The solution we reached in 1995 did not require any architectural changes to AH, bottomline. So I believe that at least one approach exists that doesn't require such changes. That does not mean that SEND has to use such an approach. It does make one wonder about claims that those changes are required in order to address authentication for IPv6 ND. So far, I'm not persuaded that any significant architectural change to AH is needed or especially useful here. However, the IETF operates on rough consensus, so my opinion is literally not important -- the rough consensus of the SEND WG is the only thing that really matters. Ran rja@extremenetworks.com From jari.arkko at piuha.net Thu Jun 12 21:09:21 2003 From: jari.arkko at piuha.net (Jari Arkko) Date: Thu Jun 12 13:32:03 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <9813572E-9CE0-11D7-A5E6-00039357A82A@extremenetworks.com> References: <9813572E-9CE0-11D7-A5E6-00039357A82A@extremenetworks.com> Message-ID: <3EE8B3C1.2070804@piuha.net> RJ Atkinson wrote: > At one time there was a Sun proposal for an lightweight protocol > to push/pull certificates around. This was run over UDP, > if I recall, and was a nicely general way to move certificates > around for a variety of uses/applications. So I think that > a general solution to that issue is possible, if folks choose > to adopt one. Yes, our protocol is quite similar to that except that it runs on top of ICMP. It has both solicited and unsolicited mode, and it uses multicast to get the same chain to a number of receivers in the same go. > Maybe. In a typical BSD stack, one might not need a formal > interface. And since this is clearly an implementation detail, > there would not be any need for IETF to define such an interface > -- the implementer can sort this all out her/himself without > any IETF help. Yes, and generally IETF hasn't been that active on the API area anyway. Even if an interface is needed between different layers, it does not necessarily imply that such an interface has to be standardized. Of course, portability and so forth would be better with a standard interface. But I don't think that is an issue in this case. I wouldn't port, say, ND from one stack to another ;-) > We assumed that no one was trusted, so we actually worried > not only about the above, but also about hosts impersonating > a router, a router impersonating a host, and a pretty comprehensive > range of other threats. Yes, these threats were also considered by us. Perhaps the difference is then in the nature of the networks that we were thinking about? Our goal was public access networks where we couldn't know beforehand all the parties. Did you assume that as well, or fixed, known set of participants? > I wonder if you'd reach different conclusions if you spent > more time considering the source code of some actual existing > IPv6, AH/ESP implementations. Maybe you would not, but I > really wonder if it wouldn't change your perspective somewhat > to have a better understanding of how these pieces are all > actually implemented (e.g. in KAME). Perhaps, particularly a look at KAME might be useful. I really don't have any experience of that. But its not like I'd never seen that stuff... I have implemented IPsec myself, for instance. I think the same goes to the rest of our design team. Of course, I'm more or less the only one who thinks we should use "application" layer security, but at least the rest of the team felt that the extensions we did for IPsec were necessary. > That does not mean that SEND has to use such an approach. > It does make one wonder about claims that those changes > are required in order to address authentication for IPv6 ND. Well, I'm willing to learn new ways of doing it, if its written down somewhere, and documented how it addressed the various threats. It could well be that we have missed something. --Jari From rja at extremenetworks.com Thu Jun 12 14:59:18 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Thu Jun 12 14:09:51 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <3EE8B3C1.2070804@piuha.net> Message-ID: <9681B1A0-9CFF-11D7-A5E6-00039357A82A@extremenetworks.com> On Thursday, Jun 12, 2003, at 13:09 America/Montreal, Jari Arkko wrote: > Yes, our protocol is quite similar to that except that it > runs on top of ICMP. It has both solicited and unsolicited > mode, and it uses multicast to get the same chain to a number > of receivers in the same go. Sounds great. I don't recall that the previous proposal had that useful multicast feature, so this is probably better suited to SEND. :-) > Our goal was public access networks > where we couldn't know beforehand all the parties. Did you > assume that as well, or fixed, known set of participants? We assumed use over wireless links (e.g. HF radio) where an adversary would have direct access over the wire, so I suspect the assumptions were not very different from yours. No matter at this point what we did long ago, since our old implementation is very clearly dead at this point. The SEND WG's collective opinions are the opinions that matter now. > Perhaps, particularly a look at KAME might be useful. > I really don't have any experience of that. But its > not like I'd never seen that stuff... I have implemented > IPsec myself, for instance. I think the same goes to > the rest of our design team. Of course, I'm more or > less the only one who thinks we should use "application" > layer security, but at least the rest of the team felt > that the extensions we did for IPsec were necessary. Sounds like we just reached different conclusions from similar data. Not an unusual occurrence in IETF-land. :-) >> That does not mean that SEND has to use such an approach. >> It does make one wonder about claims that those changes >> are required in order to address authentication for IPv6 ND. > > Well, I'm willing to learn new ways of doing it, if its > written down somewhere, and documented how it addressed > the various threats. It could well be that we have missed > something. An excellent point and a very good reason to go forward with the current SEND approach. The old approach is not written down anyplace (or at least anyplace I'm likely to find in my basement anytime soon), while the SEND approach is clearly documented and has SEND WG consensus behind it. We all agree its important that WG consensus be the metric for moving forward. :-) Cheers, Ran rja@extremenetworks.com From rja at extremenetworks.com Thu Jun 12 16:01:50 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Thu Jun 12 15:15:05 2003 Subject: [saag] Retraction Re: IPv6 BITS IPsec In-Reply-To: <3EE8ADEC.7040002@piuha.net> Message-ID: <52CC8903-9D08-11D7-A5E6-00039357A82A@extremenetworks.com> On Thursday, Jun 12, 2003, at 12:44 America/Montreal, Jari Arkko wrote: Earlier Ran wrote: >> IPv6 requires that there be an in-stack implementation of AH/ESP. >> BITS doesn't meet that requirement, so it is safe to assume that >> AH/ESP will really be there for hosts implementing IPv6 ND. > > Really? Where does it say so? If this really is a requirement > written down somewhere, I could use that as an argument in > a certain other issue. But I haven't seen this written down > myself. Could have missed something, though. Retraction: Jari is correct that this is not written down anyplace; I was at least out-of-date (and possibly confused in the first place). In the course of updating both the ESP/AH specs and the IPv6 specs, things seem to have changed somewhat, at least with regards to clarity of requirements. In skimming RFC-2401 and RFC-2460 just now, there is nothing obviously prohibiting BITS as a sufficient implementation approach for IPv6 hosts. RFC-1825 thru RFC-1827 have several requirements that are roughly impossible for a BITS implementation to meet (this was no accident). RFC-2401 specifically allows BITS and BITW implementations of IPsec. That noted, I'm not aware of any specific IPv6 host implementations of ESP/AH that are either BITS or BITW. There might well be some out there; the most common IPv6 implementation (KAME) is neither BITS nor BITW. My mistake. Terribly sorry, Ran From derek at ihtfp.com Thu Jun 12 19:00:58 2003 From: derek at ihtfp.com (Derek Atkins) Date: Thu Jun 12 18:28:29 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <200306111704.h5BH4XFl007357@sandelman.ottawa.on.ca> References: <200306111704.h5BH4XFl007357@sandelman.ottawa.on.ca> Message-ID: Michael Richardson writes: > >>>>> "Derek" == Derek Atkins writes: > >> AH is the right answer for IP-layer authentication, as Pekka noted. > > Derek> Ok, _why_ is it "the right answer"? What particular features of AH, > Derek> that do NOT exist in ESP-NULL, make it "the right answer"? Or > Derek> vice-versa, what particular features of ESP-NULL make it "not the > Derek> right answer"? Please be specific. > > AH *guarantees* that the data that follows the packet are not encrypted. > As such, one can look at the things that follow, decide if they are even > interesting, and *only* then, calculate the authenticator. (Which might > involve doing RSA, finding the right public key, etc...) So? What does being unencrypted buy you? You shouldn't trust the packet unless you do verify the authenticator... If you don't follow that then I could easily feed you false packets that "look" right even if they don't authenticate properly./ > ESP does not make this guarantee. The recipient who assigned the SPI# > possibly look up the algorithm in the SPD and find out that it was NULL, > but nobody else can. (Nor can the recipient if they have rebooted since) Nobody else should... Nobody else should ever need to.. Nobody else can even verify that the packet is authentic, so they shouldn't trust it regardless. > So, AH is appropriate for securing things like ARP/ND, which are likely > to be broadcast/multicast. ESP-null can only be used between consenting > parties that know about each other already. Well, an intermediary cannot (indeed SHOULD not) be peering into a packet, even if it is known to be unencrypted. As I already said, one can certainly send a packet with an AH header that _looks_ correct but doesn't verify. An intermediary has no way to trust it is correct, so shouldn't even try. If you're using a broadcast/multicast, you should use GSAKMP for key agreement, or at least to publish the RSA key used to sign messages. > Now, to backtrack a bit - an RSA Transform for AH would like use a > well-known SPI#. That *could* be done for ESP-null, but I do not see the > advantage of doing so, if the things you wanted to authenticate were > extension headers. I'm not convinced that a well-known SPI would work well either. You're going to have to specify not only algorithm but also key information and traffic-selector information. So a single well-known spi wont work because there is no way to specify which keys/TSs are involved. That means you need to perform the SAD/SPD lookup on every packet anyways, so don't try to optimize around that. Similarly, you cannot optimize around the unencrypted nature of AH. As I mentioned, an intermediary cannot trust the packet regardless, and as I just showed the endpoint (recipient) still has to look up the SPI in the SAD. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From mouse at Rodents.Montreal.QC.CA Thu Jun 12 19:21:45 2003 From: mouse at Rodents.Montreal.QC.CA (der Mouse) Date: Thu Jun 12 19:42:42 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: References: <200306111704.h5BH4XFl007357@sandelman.ottawa.on.ca> Message-ID: <200306122243.SAA27919@Sparkle.Rodents.Montreal.QC.CA> > So? What does being unencrypted buy you? You shouldn't trust the > packet unless you do verify the authenticator... No, but in the presence of the right traffic statistics, it allows you to do a fast check and thereby identify some packets as being ones you don't care about the authenticator on, because their content indicates that they're either not what you're looking for or they're corrupted. If your traffic includes a significant proportion of packets with authentication info but which you don't care about, this can be a win. (As an example of a case where this can win: Suppose Alice has a connection with Bob which is protected with AH. Chris wants to DoS Alice but cannot sniff Alice<->Bob traffic. Chris sends Alice a flood of traffic with garbage AH headers. Alice could burn the cycles to check them all - but it's a lot cheaper for Alice to note that her only AH-protected connection is with Bob, so any packet not claiming to be from Bob doesn't even need to be checked. Even if Chris knows who Bob is, as long as Chris can't sniff Alice<->Bob traffic, the forged packets will probably have at least one port number wrong and thus can be discarded quickly. Even if Chris knows enough to know what range of ports is dynamically assigned by the relevant end, that's still at least a factor of a few hundred reduction in wasted work.) That is, it doesn't speed up processing of authenticated packets; it speeds up processing of unauthenticated packets. > Well, an intermediary cannot (indeed SHOULD not) be peering into a > packet, even if it is known to be unencrypted. As I already said, > one can certainly send a packet with an AH header that _looks_ > correct but doesn't verify. An intermediary has no way to trust it > is correct, so shouldn't even try. But if the action to be taken for a verified AH header equals the action to be taken for a forged packet, there's no reason not to. For example, a firewall that permits only TCP connections to port 22 doesn't need to authenticate packets not claiming to involve port 22; forged or not, the right thing to do is drop them. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From Michael.G.Williams at nokia.com Wed Jun 11 20:51:19 2003 From: Michael.G.Williams at nokia.com (Michael.G.Williams@nokia.com) Date: Fri Jun 13 17:31:53 2003 Subject: [saag] Security Requirements Intnernet Draft (a request for comments)(F orwarded) Message-ID: <59A36C4D2F9E7243BEB522274F72C303B0E09C@mvebe001.americas.nokia.com> A general comment, and a tangent. This seems to be very "wired" centric and could use another pass with the wireless world kept in mind side by side with the wired. There seems to be a tremendous emphasis on security (in all walks of life). There is an opening up to acknowledge that some of the current solutions for security get in the way of others, or aren't aware of others. Idealists vs. pragmatists debate how high to raise the bar for the next "jump." There is a fair amount of idealism in this draft. Best Regards, Michael -----Original Message----- From: Steve Bellovin [mailto:smb@research.att.com] Sent: Wednesday, June 11, 2003 5:53 PM To: saag@mit.edu Subject: [saag] Security Requirements Intnernet Draft (a request for comments)(F orwarded) Comments welcome. ------- Forwarded Message Message-ID: <3EE7C8A6.8080706@mitre.org> Date: Wed, 11 Jun 2003 20:26:14 -0400 From: "George M. Jones" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nanog@merit.edu Subject: Security Requirements Intnernet Draft (a request for comments) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-nanog@merit.edu Precedence: bulk Errors-To: owner-nanog-outgoing@merit.edu X-Loop: nanog X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_MOZILLA_UA,X_LOOP autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) I've published an Internet Draft on "Security Requirements for Devices Implementing IP". You can view it at: http://www.ietf.org/internet-drafts/draft-jones-opsec-00.txt This is an outgrowth of a document used by UUNET (my former employer) to sanity check/security qualify equipment for connection to the backbone. The point of publishing the document is to start discussion. There is a mailing list set up: opsec@ops.ietf.org. Subscribe by sending a message to "majordomo@ops.ietf.org" with "subscribe opsec" in the body. The point of the document is to create a useful list that network operators can use to communicate their securtiy requirements to vendors. Please have a look and comment. Thanks, - ---George Jones ------- End of Forwarded Message --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) _______________________________________________ saag mailing list saag@mit.edu https://jis.mit.edu/mailman/listinfo/saag From pekka.nikander at nomadiclab.com Mon Jun 16 11:23:02 2003 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Mon Jun 16 03:22:11 2003 Subject: [saag] Summary: Time to reconsider AH.... Message-ID: <3EED7056.9000306@nomadiclab.com> About a week ago I posted a message on this list, proposing that the role of AH should be considered in the Internet architecture. This message is an attempt to summarise the discussion that followed. In this message, I am ignoring those parts of the discussion that do not relate directly to the topic of my original message. However, please correct me if I am missing something important. My original proposal was to reposition AH as an IP layer control protection protocol, and not so much as an end-to-end application protection protocol. The difference is subtle, but important, IMHO. Ran Atkinson pointed out that AH has been used as an IP layer control protection protocol, already as early as in 1995. Thus, my request to reposition might be, in fact, very much in line with the original design of AH. It looks like that Ran's and my opinion differ in one sense, however. Ran wants to preserve AH as an end-to-end application layer protection protocol, in addition to using it to protect IP layer control functions. I do understand that desire, but don't consider it very important. Much of the discussion attempted to clarify whether AH, as such, already fulfils the requirements that we have in mind. One aspect here was that I tend to see IPsec as a separate "layer" within the IP stack, while Ran strongly suggested that we must consider AH as a part of the same "layer" together with IP, ICMP, MIP, etc. One real difference here turned out to be between the original set of IPsec RFCs (RFC1825-1827) and the current set of RFCs (at least RFC2401 and RFC2460). In particular, the new set of RFCs allow a BITS or BITW implementation, with considerably less control over AH/ESP than in the original design. From our point of view, the technical problem here is the amount of control an IP layer control protocol can assume to have over AH. If we stick with the SPD approach, requiring that the AH "layer" makes separately the decision whether to protect a packet or not, or whether to allow an unprotected packet to pass to the upper layerers or not, there will be some trouble. The information available in the typical SPD selectors, especially in the incoming packet case, are just not enough. The current set of RFCs do not forbid a typical implementation from allowing more control over AH. However, since such control is not required from an implementation, it is hard to assume such a facility in any protocol relying on IPsec. After all this technical discussion, I tend to consider the attitude towards AH more important. If we collectively continue to mostly consider AH as an almost useless cripled down version of ESP, an overly complex end-to-end application protection protocol whose only benefit is lack of export restrictions, we are missing some points. What I propose is that we must better recognize the potential role AH has in protecting IP layer functions, such as ICMP, MIP, etc, and work towards realizing them in a scalable way. To me, it looks like such an approach requires a change in the attitude people have towards AH. Correspondingly, AH should be repositioned in the IETF work, and the WG structure should be updated accordingly. --Pekka Nikander From rja at extremenetworks.com Mon Jun 16 11:34:26 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Mon Jun 16 10:34:38 2003 Subject: [saag] Summary: Time to reconsider AH.... In-Reply-To: <3EED7056.9000306@nomadiclab.com> Message-ID: On Monday, Jun 16, 2003, at 03:23 America/Montreal, Pekka Nikander wrote: > From our point of view, the technical problem here > is the amount of control an IP layer control protocol > can assume to have over AH. If we stick with the > SPD approach, requiring that the AH "layer" makes > separately the decision whether to protect a packet > or not, or whether to allow an unprotected packet > to pass to the upper layerers or not, there will > be some trouble. Merely having the SPD concept does NOT mean that "AH is a separate layer". The NRL AH/ESP implementation always had the equivalent of an SPD, but was totally integrated (layer-wise) with the rest of IP. The KAME implementation is similar to the NRL implementation in this architectural respect. A large percentage of current IPv6 implementations are KAME-based, perhaps over 50% of current implementations. So many/most existing IPv6 AH implementations do NOT have any of the hypothetical layer issues that Pekka perceives as problems. > The information available in > the typical SPD selectors, especially in the > incoming packet case, are just not enough. Adding more selectors ought to be easy and appears to be sufficient to address your concern. Ran Atkinson rja@extremenetworks.com From rja at extremenetworks.com Mon Jun 16 11:38:01 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Mon Jun 16 10:38:27 2003 Subject: [saag] Summary: Time to reconsider AH.... In-Reply-To: <3EED7056.9000306@nomadiclab.com> Message-ID: <21C97DC6-A008-11D7-842C-00039357A82A@extremenetworks.com> On Monday, Jun 16, 2003, at 03:23 America/Montreal, Pekka Nikander wrote: > After all this technical discussion, I tend to > consider the attitude towards AH more important. > If we collectively continue to mostly consider AH > as an almost useless cripled down version of ESP, > an overly complex end-to-end application protection > protocol whose only benefit is lack of export > restrictions, we are missing some points. Agree. Certainly I've never viewed AH as a crippled version of ESP. In fact, I would never willingly use ESP without also using AH on those sessions. > What I propose is that we must better recognize > the potential role AH has in protecting IP layer > functions, such as ICMP, MIP, etc, and work towards > realizing them in a scalable way. To me, it looks > like such an approach requires a change in the > attitude people have towards AH. Correspondingly, > AH should be repositioned in the IETF work, and > the WG structure should be updated accordingly. I'm unable to understand exactly what you are proposing in the above paragraph. Maybe it is just me, but I'm not sure what action/change you are requesting. :-) Ran Atkinson rja@extremenetworks.com PS: And I would not be upset with banning BITS/BITW implementations of ESP/AH for IPv6 hosts, either. No BITS/BITW implementation can have sufficient data to provide the same security properties as an integrated in-stack implementation -- which seems sufficient reason to discard BITS/BITW for IPv6 hosts. From kent at bbn.com Tue Jun 17 14:37:09 2003 From: kent at bbn.com (Stephen Kent) Date: Tue Jun 17 13:57:11 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <20030610122035.4c98ac5b.moore@cs.utk.edu> References: <20030610122035.4c98ac5b.moore@cs.utk.edu> Message-ID: At 12:20 PM -0400 6/10/03, Keith Moore wrote: > > There doesn't appear to have been any stifling of >> the use of IPsec by non-VPN applications, just not much WG support >> for it. I may have missed something. > >IPsec is pretty much useless to applications without > >a) the ability to authenticate applications and users, rather than hosts >b) an API that lets apps specify and obtain credentials > >as long as IPsec doesn't have those, apps will make do with TLS or >roll their own. >_______________________________________________ IPsec can authenticate a person, not just a device, so "a" above is not a valid criticism. It has been said many time previously, but it's still not correct :-) Steve From mcr at sandelman.ottawa.on.ca Tue Jun 17 16:40:07 2003 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Tue Jun 17 15:42:10 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: Your message of "Tue, 17 Jun 2003 13:37:09 EDT." Message-ID: <200306171940.h5HJe7XB011840@sandelman.ottawa.on.ca> Keith and others, >b) an API that lets apps specify and obtain credentials work is underway (finally!) in the IPSP WG on this. Expect drafts RSN. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From rgm-sec at htt-consult.com Tue Jun 17 17:43:27 2003 From: rgm-sec at htt-consult.com (Robert Moskowitz) Date: Tue Jun 17 16:45:19 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: References: <20030610122035.4c98ac5b.moore@cs.utk.edu> <20030610122035.4c98ac5b.moore@cs.utk.edu> Message-ID: <5.1.0.14.2.20030617163529.02d4fea8@localhost> At 01:37 PM 6/17/2003 -0400, Stephen Kent wrote: >At 12:20 PM -0400 6/10/03, Keith Moore wrote: >> > There doesn't appear to have been any stifling of >>> the use of IPsec by non-VPN applications, just not much WG support >>> for it. I may have missed something. >> >>IPsec is pretty much useless to applications without >> >>a) the ability to authenticate applications and users, rather than hosts >>b) an API that lets apps specify and obtain credentials >> >>as long as IPsec doesn't have those, apps will make do with TLS or >>roll their own. >>_______________________________________________ > >IPsec can authenticate a person, not just a device, so "a" above is not a >valid criticism. It has been said many time previously, but it's still not >correct :-) This is a problem in implementation, not is the standard. Though tying IPsec to an app **IS** a problem and the reason why you see many in AAA perfering TLS to IPsec for Diameter's security. But ESP in transport mode, with IKE using 2 user certificates definitely ties to the user. And most client implementations support this to some extent. For an app, there is no API to use to query if there is an IPsec SA for the app. This is an API issue, not normally a selector issue. But given my current work in 802-land, this work to secure what are basically layer2 frames with layer3 security is, well, interesting. Of course in layer2-land we are discussing how to protect 'sub-MAC' (MAC management) frames!!! I suggest that people here look over in the 802.1 task group and the LinkSec study group. Robert Moskowitz TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com From pbaker at verisign.com Tue Jun 17 18:47:28 2003 From: pbaker at verisign.com (Hallam-Baker, Phillip) Date: Tue Jun 17 20:47:48 2003 Subject: [saag] Time to reconsider the role of IPsec AH? Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2248@mou1wnexm02.verisign.com> > This is a problem in implementation, not is the standard. > Though tying > IPsec to an app **IS** a problem and the reason why you see > many in AAA > perfering TLS to IPsec for Diameter's security. On the contrary it is a basic limitation of the architecture. Security at the packet layer is not going to be accessible to the application for good reasons of structured layered architecture. Each layer in the stack should only be communicating to the layers immediately above and below it. Trying to wormhole information through the layers is not recommended. Phill From pekka.nikander at nomadiclab.com Wed Jun 18 11:57:39 2003 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Wed Jun 18 04:42:27 2003 Subject: [saag] Summary: Time to reconsider AH.... In-Reply-To: References: Message-ID: <3EF01B73.3000706@nomadiclab.com> Ran, RJ Atkinson wrote: > So many/most existing IPv6 AH implementations > do NOT have any of the hypothetical layer issues > that Pekka perceives as problems. YMMV. I am working with KAME code myself. IMHO, in KAME the IPsec code is quite neatly separated into a "sublayer", or a subsystem with a fairly small interface with the rest of the IP stack. I think that it is a good design. Making the interface larger between the subsystems is not an easy decision; there must be a reason for adding such complexity. Now, I think that there is a reason for adding such complexity. Furthermore, I think that such reasons should be discussed within the IETF, and that such discussion most probably will result in slight changes into the current IPsec architecture document (RFC2401). > Adding more selectors ought to be easy and > appears to be sufficient to address your > concern. Adding more selectors does not seem to be easy, as you may have noticed from the on-going discussion at the IPsec WG. --Pekka Nikander From pekka.nikander at nomadiclab.com Wed Jun 18 12:03:31 2003 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Wed Jun 18 04:45:42 2003 Subject: Preliminary BOF proposal (was Re: [saag] Summary: Time to reconsider AH....) In-Reply-To: <21C97DC6-A008-11D7-842C-00039357A82A@extremenetworks.com> References: <21C97DC6-A008-11D7-842C-00039357A82A@extremenetworks.com> Message-ID: <3EF01CD3.9080708@nomadiclab.com> RJ Atkinson wrote: >> What I propose is that we must better recognize >> the potential role AH has in protecting IP layer >> functions, such as ICMP, MIP, etc, and work towards >> realizing them in a scalable way. To me, it looks >> like such an approach requires a change in the >> attitude people have towards AH. Correspondingly, >> AH should be repositioned in the IETF work, and >> the WG structure should be updated accordingly. > > I'm unable to understand exactly what you are proposing > in the above paragraph. Maybe it is just me, but > I'm not sure what action/change you are requesting. I think that we should have a BOF, and discuss the future of AH, among other things. People are hoping that IPsec will be finally closed. Maybe so, but I tend to doubt. Independent of that, I propose that all future work of AH would be moved to a separate, new WG. The BOF should be in the security area, and should focus on how to secure IP layer signalling protocols, including ICMP, IPv6 ND (part of ICMP), MIP, etc. I think that it would be possible to come up with a fairly unified solution for security all or at least most of these, using AH and recent ideas. However, much work needs to be done. I think that it would be beneficial to continue such work in a single security area WG instead of distributing it over several Internet area WGs. One of the purposes of this discussion has been to see if there is any support for having such a BOF. So far I haven't seen any real interest, but lots of discussion on related aspects, without any clear conclusions. --Pekka Nikander From rja at extremenetworks.com Wed Jun 18 08:52:10 2003 From: rja at extremenetworks.com (RJ Atkinson) Date: Wed Jun 18 07:53:53 2003 Subject: [saag] Summary: Time to reconsider AH.... In-Reply-To: <3EF01B73.3000706@nomadiclab.com> Message-ID: <4B0260CE-A183-11D7-BF35-00039357A82A@extremenetworks.com> On Wednesday, Jun 18, 2003, at 03:57 America/Montreal, Pekka Nikander wrote: > YMMV. I am working with KAME code myself. IMHO, > in KAME the IPsec code is quite neatly separated > into a "sublayer", or a subsystem with a fairly > small interface with the rest of the IP stack. I would not agree with the notion that KAME's implementation is rigidly layered or makes it in any way difficult to use AH to protect ND. Clearly milage varies on this. I'd encourage folks to examine the code for themselves and draw their own conclusions, which ought to be straight forward since the code is freely distributed as source. Ran rja@extremenetworks.com From derek at ihtfp.com Wed Jun 18 13:04:35 2003 From: derek at ihtfp.com (Derek Atkins) Date: Wed Jun 18 12:04:53 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2248@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D2248@mou1wnexm02.verisign.com> Message-ID: "Hallam-Baker, Phillip" writes: > > This is a problem in implementation, not is the standard. > > Though tying > > IPsec to an app **IS** a problem and the reason why you see > > many in AAA > > perfering TLS to IPsec for Diameter's security. > > On the contrary it is a basic limitation of the architecture. > > Security at the packet layer is not going to be accessible to > the application for good reasons of structured layered architecture. > > Each layer in the stack should only be communicating to the layers > immediately above and below it. Trying to wormhole information through > the layers is not recommended. Eh? This is what meta-data is for! Sure, each layer shouldn't pass it's transport data up/down the layers, however that doesn't imply that ancillary metadata cannot be stored alongside the packet. For example, an application at layer 7 can CERTAINLY get the IP Address (from layer 3)... How does this not violate your assertion? Similarly, if an app can obtain the layer-3 IP Address, why not also the "later 3.5" IPsec SA information? No, this is not an architectural problem; it is an implementation problem. Granted, it requires an integrated IPsec stack, but it's a perfectly reasonable goal and easily implementable using the current specifications. > Phill -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From derek at ihtfp.com Wed Jun 18 13:17:42 2003 From: derek at ihtfp.com (Derek Atkins) Date: Wed Jun 18 12:18:18 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <200306122243.SAA27919@Sparkle.Rodents.Montreal.QC.CA> References: <200306111704.h5BH4XFl007357@sandelman.ottawa.on.ca> <200306122243.SAA27919@Sparkle.Rodents.Montreal.QC.CA> Message-ID: If you make the assumption that Chris cannot sniff the Alice<->Bob link, then the liklihood that Chris will choose a valid SPI to spoof Alice<->Bob is approximately 1 in 2^-24 (I'm assuming that Chris knows that Alice and Bob are using SPI values >= 256). This means that if Alice is _just_ looking for valid SPI values, Chris will only get Alice to accept one in 16 million packets. That's doing pretty well just by checking the SPI value. Note that we haven't even verified the IP Address or performed ANY cryptographic verification yet. So, I think any argument that you need to look into the packet to verify it's authenticity is fallacious. You don't need to look at the transport headers to see if they are valid, you can start with the SPI. As Alice<->Bob will be changing SPIs periodically (every rekey), if Chris cannot see the traffic she cannot find the proper SPI. So again I ask you, what does being unencrypted buy you? Based on your assumption about Chris' abilities, and that Alice is only talking to Bob, Alice can throw out 99.99999% of Chris' packets just by looking at the SPI... So, why does Alice need to look inside the packet? -derek der Mouse writes: > > So? What does being unencrypted buy you? You shouldn't trust the > > packet unless you do verify the authenticator... > > No, but in the presence of the right traffic statistics, it allows you > to do a fast check and thereby identify some packets as being ones you > don't care about the authenticator on, because their content indicates > that they're either not what you're looking for or they're corrupted. > > If your traffic includes a significant proportion of packets with > authentication info but which you don't care about, this can be a win. > (As an example of a case where this can win: Suppose Alice has a > connection with Bob which is protected with AH. Chris wants to DoS > Alice but cannot sniff Alice<->Bob traffic. Chris sends Alice a flood > of traffic with garbage AH headers. Alice could burn the cycles to > check them all - but it's a lot cheaper for Alice to note that her only > AH-protected connection is with Bob, so any packet not claiming to be > from Bob doesn't even need to be checked. Even if Chris knows who Bob > is, as long as Chris can't sniff Alice<->Bob traffic, the forged > packets will probably have at least one port number wrong and thus can > be discarded quickly. Even if Chris knows enough to know what range of > ports is dynamically assigned by the relevant end, that's still at > least a factor of a few hundred reduction in wasted work.) > > That is, it doesn't speed up processing of authenticated packets; it > speeds up processing of unauthenticated packets. > > > Well, an intermediary cannot (indeed SHOULD not) be peering into a > > packet, even if it is known to be unencrypted. As I already said, > > one can certainly send a packet with an AH header that _looks_ > > correct but doesn't verify. An intermediary has no way to trust it > > is correct, so shouldn't even try. > > But if the action to be taken for a verified AH header equals the > action to be taken for a forged packet, there's no reason not to. For > example, a firewall that permits only TCP connections to port 22 > doesn't need to authenticate packets not claiming to involve port 22; > forged or not, the right thing to do is drop them. > > /~\ The ASCII der Mouse > \ / Ribbon Campaign > X Against HTML mouse@rodents.montreal.qc.ca > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From moore at cs.utk.edu Wed Jun 18 14:24:45 2003 From: moore at cs.utk.edu (Keith Moore) Date: Wed Jun 18 13:32:54 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2248@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D2248@mou1wnexm02.verisign.com> Message-ID: <20030618132445.0c0e4e84.moore@cs.utk.edu> On Tue, 17 Jun 2003 17:47:28 -0700 "Hallam-Baker, Phillip" wrote: > Each layer in the stack should only be communicating to the layers > immediately above and below it. I don't know who came up with that idea, but it's not grounded in sanity. There needs to be clear separation of function between layers. That doesn't mean that layers should only communicate with immediately higher or lower layers. Indeed, if layer 7 needs to specify some layer 3 functionality, it makes a lot more sense for the layers to communicate directly than for each layer to have to tunnel the requests, or for layer 3 to have to guess what layer 7 needs. From mouse at Rodents.Montreal.QC.CA Wed Jun 18 17:26:40 2003 From: mouse at Rodents.Montreal.QC.CA (der Mouse) Date: Wed Jun 18 16:31:27 2003 Subject: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: References: <200306111704.h5BH4XFl007357@sandelman.ottawa.on.ca> <200306122243.SAA27919@Sparkle.Rodents.Montreal.QC.CA> Message-ID: <200306182030.QAA12143@Sparkle.Rodents.Montreal.QC.CA> > [...choosing SPI values...] > So again I ask you, what does being unencrypted buy you? Hmm. All I can think of then are debuggability and legality. There are places where encryption is illegal (last I heard, at least) and thus ESP cannot be used for legal reasons. (I can easily imagine similar restrictions being placed administratively in places like companies, so that corporate security can sniff traffic.) And debugging networking problems is a lot easier when you can actually see what's on the wire. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From kent at bbn.com Wed Jun 25 15:25:30 2003 From: kent at bbn.com (Stephen Kent) Date: Wed Jun 25 18:41:46 2003 Subject: Preliminary BOF proposal (was Re: [saag] Summary: Time to reconsider AH....) In-Reply-To: <3EF01CD3.9080708@nomadiclab.com> References: <21C97DC6-A008-11D7-842C-00039357A82A@extremenetworks.com> <3EF01CD3.9080708@nomadiclab.com> Message-ID: At 11:03 AM +0300 6/18/03, Pekka Nikander wrote: >RJ Atkinson wrote: >>>What I propose is that we must better recognize >>>the potential role AH has in protecting IP layer >>>functions, such as ICMP, MIP, etc, and work towards >>>realizing them in a scalable way. To me, it looks >>>like such an approach requires a change in the >>>attitude people have towards AH. Correspondingly, >>>AH should be repositioned in the IETF work, and >>>the WG structure should be updated accordingly. >> >>I'm unable to understand exactly what you are proposing >>in the above paragraph. Maybe it is just me, but >>I'm not sure what action/change you are requesting. > >I think that we should have a BOF, and discuss the future >of AH, among other things. People are hoping that IPsec >will be finally closed. Maybe so, but I tend to doubt. >Independent of that, I propose that all future work of >AH would be moved to a separate, new WG. > >The BOF should be in the security area, and should focus >on how to secure IP layer signalling protocols, including >ICMP, IPv6 ND (part of ICMP), MIP, etc. I think that >it would be possible to come up with a fairly unified >solution for security all or at least most of these, >using AH and recent ideas. However, much work needs to >be done. I think that it would be beneficial to continue >such work in a single security area WG instead of distributing >it over several Internet area WGs. > >One of the purposes of this discussion has been to see >if there is any support for having such a BOF. So far >I haven't seen any real interest, but lots of discussion >on related aspects, without any clear conclusions. > i think it would be a god idea to have a BOF on the topic of securing IP layer, inbadn signalling. I think it would not be a good idea to refer to this as a "future of AH" BOF. Steve