From ipsec-request@ans.net Mon Nov 1 16:29:00 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14337 (5.65c/IDA-1.4.4 for ); Mon, 1 Nov 1993 12:11:43 -0500 Received: by interlock.ans.net id AA23386 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 1 Nov 1993 12:00:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 1 Nov 1993 12:00:12 -0500 Message-Id: <199311011700.AA16726@interlock.ans.net> Date: 1 Nov 93 16:29:00 GMT-0:01 From: "Paul Hopkins" Subject: Addition to list To: "ipsec" To Joost Meijers, You have been booked into the hotel COTFORD in Graham Road in Malvern. The booking is for 3 nights commencing on Monday the 1st of March. In order to arrange a car to pick you up from Birmingham Airport I need to know your arrival time. Yet I regret, dependent upon arrival times, that this may not be possible. I have been experiencing problems when trying to contact you by telephone, is the following number correct? +31 70 3264221. Thanks Paul Hopkins. From ipsec-request@ans.net Tue Nov 2 08:22:00 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18118 (5.65c/IDA-1.4.4 for ); Tue, 2 Nov 1993 04:17:35 -0500 Received: by interlock.ans.net id AA15157 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 2 Nov 1993 04:14:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 2 Nov 1993 04:14:11 -0500 Message-Id: <199311020914.AA07985@interlock.ans.net> Date: 2 Nov 93 08:22:00 GMT-0:01 From: "Paul Hopkins" Subject: Addition to list To: "ipsec" To all that it may concern, Please could you add me to the mailing list Thanks Paul Hopkins DRA Malvern From ipsec-request@ans.net Wed Nov 3 04:50:49 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13578 (5.65c/IDA-1.4.4 for ); Wed, 3 Nov 1993 10:03:28 -0500 Received: by interlock.ans.net id AA23454 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 3 Nov 1993 09:49:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Nov 1993 09:49:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Nov 1993 09:49:33 -0500 Date: Wed, 3 Nov 93 09:50:49 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9311031450.AA16777@itd.nrl.navy.mil> To: ipsec@ans.net Subject: Comments on Tuesday's meeting It seems to me that having _many_ packet formats is undesirable because it tends to lead to non-interoperability. However, it is not immediately clear that having more than one format is _necessarily_ intolerable. For example, users wishing to have "authentication without confidentiality" might well use a different format than users having "confidentiality and authentication" because of the differing requirements. It is possible that IANA would seriously consider allocating a very small number of different protocol IDs for the different packet formats if a solid technical case were made. Having separate protocol IDs for different formats appears likely to make implementation of multiple formats easier. Please note that I am not advocating multiple packet formats at this time. I am just trying to discuss certain items relating to that open issue. Other folks' comments are solicited. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Tue Nov 9 18:32:16 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13610 (5.65c/IDA-1.4.4 for ); Tue, 9 Nov 1993 13:43:35 -0500 Received: by interlock.ans.net id AA15518 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 9 Nov 1993 13:31:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 9 Nov 1993 13:31:04 -0500 Message-Id: <199311091831.AA04506@interlock.ans.net> To: Ran Atkinson Cc: ipsec@ans.net Subject: Re: Comments on Tuesday's meeting In-Reply-To: Your message of Wed, 03 Nov 93 09:50:49 -0500. <9311031450.AA16777@itd.nrl.navy.mil> Date: Tue, 09 Nov 93 13:32:16 -0500 From: Steve Kent Ran, The protocol ID space is fairly small under IPv4, so I don't know if Jon will be willing to issue two IDs for this protocol. Having optional header fields to accommodate confidentiality vs. integrity/authenticity seems more reasonable. Steve From ipsec-request@ans.net Tue Nov 9 09:07:50 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12877 (5.65c/IDA-1.4.4 for ); Tue, 9 Nov 1993 14:15:46 -0500 Received: by interlock.ans.net id AA05052 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 9 Nov 1993 14:02:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 9 Nov 1993 14:02:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 9 Nov 1993 14:02:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 9 Nov 1993 14:02:23 -0500 Message-Id: <9311091907.AA12203@shredin.reston.ans.net> To: Steve Kent Cc: Ran Atkinson , ipsec@ans.net Subject: Re: Comments on Tuesday's meeting In-Reply-To: Your message of "Tue, 09 Nov 93 13:32:16 EST." <199311091831.AA04506@interlock.ans.net> Date: Tue, 09 Nov 93 14:07:50 EST From: Robert Hagens > Ran, > > The protocol ID space is fairly small under IPv4, so I don't > know if Jon will be willing to issue two IDs for this protocol. > Having optional header fields to accommodate confidentiality vs. > integrity/authenticity seems more reasonable. > > Steve It seems that the degree of security "confidentiality vs. integrity/authenticity" is an attribute of the security association. Thus, could this be carried in the SAID ? Rob From ipsec-request@ans.net Tue Nov 9 19:31:34 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18172 (5.65c/IDA-1.4.4 for ); Tue, 9 Nov 1993 14:36:48 -0500 Received: by interlock.ans.net id AA05112 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 9 Nov 1993 14:30:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 9 Nov 1993 14:30:37 -0500 Message-Id: <199311091930.AA25332@interlock.ans.net> To: Robert Hagens Cc: Ran Atkinson , ipsec@ans.net Subject: Re: Comments on Tuesday's meeting In-Reply-To: Your message of Tue, 09 Nov 93 14:07:50 -0500. <9311091907.AA12203@shredin.reston.ans.net> Date: Tue, 09 Nov 93 14:31:34 -0500 From: Steve Kent Rob, Certainly the specific set of security services that will be employed for each association will be negotiated and the SAID provides and index that can be used by each end of the association to relate these services to the packets on that association. I think Ran was suggesting that we could have distinct (static) packet formats for different sets of services, rather than using optional fields in a unified format to accommodates different service selections. Steve From ipsec-request@ans.net Wed Nov 10 03:48:44 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15952 (5.65c/IDA-1.4.4 for ); Wed, 10 Nov 1993 08:52:07 -0500 Received: by interlock.ans.net id AA02931 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 10 Nov 1993 08:47:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 10 Nov 1993 08:47:03 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 10 Nov 1993 08:47:03 -0500 Date: Wed, 10 Nov 93 08:48:44 EST From: K. Robert Glenn Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9311101348.AA07409@sloth.ncsl.nist.gov> To: ipsec@ans.net Subject: Re: Comments on Tuesday's meeting Cc: glenn@sloth.ncsl.nist.gov I tend to agree that using optional fields is probably a better way to go, but complex TLV encoding should be avoided. Using an internal identifier (internal to the packet, or inferred by the SAID) that specifies which security services have been selected and in what particular format/order they exist (ISN->ICV->Data->Pad, ISN->DATA->Pad->ICV, etc) would provide this functionality in an efficient manner. Sort of a packet identifier within the IPSEC packet. This way we would only, 1) have to agree on a standard header format, and 2) have a table of recognized data format types (with room for expansion/private use). Example table: Data Format Type Value Format 0000 0001 DATA+PAD+ICV 0000 0010 ENC-DATA+PAD+ICV 0000 0011 ENC-DATA+PAD 0000 0100 ENC-DATA+PAD+TrafficPad . . . ETC. (BTW, DATA is an entire IP packet) One problem that I can forsee with a standard header format (and was brought up at the Tuesday meeting) is the issue of CPU vs. Bandwidth efficiency. For low bandwidth networks, padding for word-boundary efficiency is not acceptable, but for high speed, high bandwidth networks it is extremely desirable. So it would seem that we need a very efficient (for both worlds) and fairly flexible packet format (forgive me for stating the obvious). The above should provide the flexibility and efficiency for the data portion of the packet. I don't think we have agreed on what the header should contain (other than a SAID) let alone the header format. Should the SAID be fixed in length? If so, what is the length? I'd like to propose something like the following VER+H-LEN+SAID+OPTIONS. The VER is included in case we don't get the packet format perfect the first time (ie. requirements change). The OPTIONS field would only need to be processed if it is present (similar to IP). Options could include keys, sequence numbers, padding, special flags, labels and anything else that might be required to meet a users special requirements. It seems to me that if we are going to have one protocol and one packet, we need to at least come to some kind of agreement on the packet header. Anyone care to comment? Rob G. glenn@osi.ncsl.nist.gov From ipsec-request@ans.net Thu Nov 11 22:13:59 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12788 (5.65c/IDA-1.4.4 for ); Thu, 11 Nov 1993 17:29:33 -0500 Received: by interlock.ans.net id AA08376 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 11 Nov 1993 17:21:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 11 Nov 1993 17:21:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 11 Nov 1993 17:21:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 11 Nov 1993 17:21:01 -0500 Message-Id: <9311112213.AA06970@skidrow.lkg.dec.com> To: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Cc: ipsec@ans.net (ip security mailing list) Subject: Re: key distribution In-Reply-To: Your message of "Wed, 13 Oct 93 16:54:10 MST." <00112.2833376247.50044@poncho.phx.sectel.mot.com> Date: Thu, 11 Nov 93 17:13:59 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I think it's a big mistake to believe that a single means of negotiating secure IP connections and authenicating your peet will covera all circumstances. DNS may still have a roll to play. Donald From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) >>From INTERNET RE>key distribution > >> I agree that DNS feels like the right way to store these things. It >> would be nice if someone could convey to the people doing the next >> generation of DNS that setting the record size high enough that this >> could be done would be a big win. Presently, records can't be large >> enough to accomodate future key lengths. > >DNS may seem attractive at first, but obtaining the destinations certificate >is not the only requirement that we need to consider. Here are some ideas >on a few requirements: > >- Multiple certificates may be supported by a single > IPSEC Key Management Agent. I don't see that this point has much to do with anything. You can store multiple RR's of any type in DNS... >- IPSP will support multiple algorithms. Determination of the > algorithm (for integrity, confidentiality, etc.) could be provided > by the same mechanism that establishes the cryptographic keying > relationship. It could but if you can get a good public key for your peer, you can then negotiate all this. >- The IPSEC Key Management (IP-KM) should provide Rpeer-entityS > authentication. A real-time authentication is required to > ensure that the keying relationship is established correctly. This does not say much about how you initally get and authenicate your peer's pubic key. >- The establishment of keying relationships for broadcast and > multicast communications need to be supported by IP-KM. I'm not sure of all the ramifications here but there are currently DNS entries for some multicast addresses. >- A mapping of the destination address to the address of an > intermediate IPSEC device must be supported. The address of > the decrypting device may not be the same as the final > destination. An interesting point where its seems like some amount of external configuration is going to be required. Just where this configuration information is going to be stored is a question. >Using DNS to retrieve the destination certificate would allow a key to be >created by sending only the initiators certificate to the destination. This >one-step key certificate exchange may appear to be a useful hack, but it >does not provide any way to support all of the requirements. As soon as you >consider exchanging more than one PDU, you might as well allow for the >destination to send its own certificate. I have nothing against the peers sending each other certificates. IPSEC should cerainly have a mode which works in the absence of the DNS service. >There may also be some problems using DNS to distribute certificates for >mobile hosts. The dynamics of a mobile-IP configuration would favor the use >of key management mechanisms that are peer-to-peer. That's fine. I don't think the DNS is the solution to all problems. From ipsec-request@ans.net Wed Nov 17 14:36:09 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17734 (5.65c/IDA-1.4.4 for ); Thu, 18 Nov 1993 00:05:18 -0500 Received: by interlock.ans.net id AA17015 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 17 Nov 1993 23:33:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 17 Nov 1993 23:33:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 17 Nov 1993 23:33:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 17 Nov 1993 23:33:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 17 Nov 1993 23:33:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 17 Nov 1993 23:33:17 -0500 Message-Id: <00112.2836417121.54892@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list), minutes@CNRI.Reston.VA.US (minutes) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Wed, 17 Nov 1993 21:36:09 MST Subject: IPSEC Minutes - IETF28 Subject: IPSEC Minutes - IETF28 Message: Minutes of the IP Security (IPSEC) WG at the Twenty-Eighth IETF (November 2,3, 1993) The IPSEC Working Group met twice during the Twenty-Eighth IETF. On Tuesday, November 2 the IPSEC working group met and discussed the IP Security Protocol (IPSP). On Wednesday, November 3 the working group held a demonstration of two IPSP implementations and then discussed the key management requirements of IPSEC. Tuesday, 2 November 93 IPSEC Meeting Paul Lambert started with a review of the charter and WG status. - The WG is behind schedule. - Only I-NLSP has been submitted as an Internet Draft (ID). - It is important to track the IPng candidates. Since I-NLSP is the only ID so far, it may be used as the template for a document from the entire group. That does not mean that its concepts would be adopted, just that it provides the WG with a starting point. Richard Thomas stated that the NLSP spec may be electronically available soon. It is on the list of documents to be made available from ISO. Requirements review (Jim Zmuda): We need agreement on the requirements before we can start to evaluate the contending proposals. Requirements were discussed in Amsterdam, but the decisions made were not final due to the small number of participants. Since the minutes from that meeting weren't published, the WG as a whole did not have a chance to comment. The following comments reflect points from the Amsterdam and Houston meetings. The issues discussed were: 1. Encapsulation vs. IP option - encapsulation was selected 2. Limited coupling between key mgmt and IPSP - agreed; the only coupling will be the SAID 3. Use of TLV encoded fields - rejected (speed favored over flexibility) 4. SAID implies the label to minimize the information carried per packet (key mgmt exchanges are far less frequent). The label can also be carried as part of the protected data (i.e. normal IPSO in protected IP header). 5. Sequence numbering is an open issue. 6. A flags field in the clear header is an open issue. Donald Eastlake will post something to the mailing list stating his view of its usage. 7. A protocol field in the IPSP header is probably needed. It could be eliminated by having the SAID imply that information also, but there is controversy about using the SAID for this purpose. 8. An ICV will be included in IPSP. 9. Peek-through (to see the upper level protocol/ports) will not be supported. Mechanisms such as mapping this information into QOS can be used to meet the needs of firewalls (although firewalls themselves were not universally liked in the WG). 10. Multicast was listed as an issue but not discussed due to lack of time. 11. No decision was reached about fragmentation & reassembly support in IPSP. Fragmentation was the major item addressed in the discussion, and remains as an open issue. Protocols such as NFS send maximum-sized UDP datagrams, and the encapsulation done by IPSP in ISs frequently results in additional fragmentation. MTU Discovery can be a solution (provided the routers account for the IPSP encapsulation in their ICMP messages), but MTU Discovery is not commonly used today. NFS 3 runs over TCP, so this might not be so large an issue when that version is available. Reassembly is not required in IPSP as long as layering is maintained. For example, in the case of IPSP between two ISs, reassembly is handled by the normal IP processing since the added IP header specifies the remote IS as the IP destination. Jim Zmuda and Bill Simpson volunteered to write a requirements document based on the discussions. Review of Experimental Implementations I-NLSP - (Rob Glenn/NIST) - NLSP is a starting point for reaching concensus within the WG - I-NLSP is NLSP-CL along with any enhancements the WG specifies - Including a content length field in the protected data is useful with random padding - A sample implementation is done (CLNP only), but it is not optimized swIPe - (Phil Karn/Qualcomm) - Authentication is faster than decryption, so the authentication field is in the unprotected header and is checked first - Minimal header size is emphasized over good alignment of fields since Phil's application involves low-bandwidth lines - With a single system sometimes being an IS and sometimes being an ES, potential problems arise depending on where in the IP logic IPSP is placed. - The WG probably won't be able to agree on a single IPSEC PDU format because of the wide range of bandwidths being discussed. - Sequence numbers are used to guarantee different packet contents for seeding the CBC (essentially acting as an IV). Future uses for the field are still up in the air. KeyRing - (Rob Hagens/ANS) - Target application is gateway-gateway (IS-IS). - Small window of valid sequence numbers is allowed to prevent replay. - Fragmentation is not an issue since it always does IP over IP with a remote IS as the outer IP destination TANDU/Cryptonette - Charlie Kaufman/DEC - Target is cheap universal encryption running at LAN speeds. - HW solution in a chip to be added to interface cards. - No performance penalties (including extra copies). - Stateless encryption by including the algorithm and session key in the clear header. The session header is encrypted under the recipient's master key. The session key field must be large (8 bytes for DES). - Fragmentation/reassembly has been imnplemented in this layer for performance reasons. - The ICV is at the end of the packet to minimize processing latency. - Any fragmentation of the datagram by routers in between the encryption systems causes a large performance penalty because of the stateless decryption LAN Guardian (Mike O'Dell/UUNET) - Uses UDP as part of the encapsulation mechanism because of fragmentation and reassembly issues. In the future, it may tunnel over TCP to facilitate CBC. Several people in the WG expressed concerns about this because of possible TCP attacks. Also, adding TCP would impact real-time protocols. SP3 (Paul Lambert/Motorola) - In the SP3 specification the SP3-D and SP3-A are the modes of most interest to the WG. SP3-D is a version of dual-IP encapsualtion. SP3-A provides a dual address space without the duplication of the IP header. Another open issue is the question of supporting multiple PDU formats as part of the IPSP specification. Arguments in favor are that different media types will need different formats to be efficient, and that ES-ES IPSP could do TCP-UDP over IPSP instead of IP over IP encapsulation. Arguments opposed are that the added complexity will make IPSP more difficult to specify and implement. One possible approach is to specify a negotiation mechanism with defaults (like PPP). Wednesday, 3 November 93 IPSEC Meeting Jim Zmuda and Phil Karn gave demonstrations of their implementations. Jim's implementation was based on the ISO 11577 specification for Network Layer Security Protocol (NLSP) and used the NLSP specification of a Security Exchange Protocol (SAEP) for key management. The implementation demonstrated by Phil Karn was based on Phil's KA9Q software running on a protable computer (80386 based). This demonstration ran between Houston and Phil's home. Key management was based on the manual entry of DES key variables. After the demonstration the group reconviened and focused discussions on key management requirements. What is key management and what is the groups charter for key management? - A protocol and cryptographic techniques - Application layer protocol for IPSP - Independent of IPSP - Initially supporting public key techniques (not patent issues!) - Later adding Key Distribution Center (e.g., Kerberos) and/or manual Existing work we might be able to take advantage of: - There is nothing that directly applies, but many pieces exist - SNDS KMP - Missing some things like algorithms and algorithm negotiation - IEEE 802.10C - Available in draft form, still very rough and is based on GULS - ISO GULS - Specifies generic envelopes, very complex, no specific algorithms or option negotiation - PEM - Not real-time, but does address certificates and public keys - X.509 - IPSEC will likely use X.509 certificate formats - X9.17 - Private keys, now working on public keys - SAMP - 2nd generation SDNS KMP, may be posted to net soon - SAEP - Embedded in NLSP, network layer protocol - Kerberos - Private keys centrally managed - CATS-GSSAPI - IPSP KMP might be able to use their interface to pass information to IPSP; also an outstanding question of whether IPSP will meet their needs from a user perspective Key Management Liaisons: IEEE 802.10C - Peter Yee Kerberos - John Linn others still required for ISO, and ANSI Key Management Requirements This meeting was the first attempt to list the requirements for a KMP. The requirements fall into two categories - Peer-to-Peer Exchanges and Security Management. Peer-to-Peer Exchanges - Authentication Mechanism/Algorithm Negotiation - we will support multiple algorithms - Peer-Entity Authentication - often built into the key exchange - Key Establishment - obtain or create a key for use by IPSP - Security Association Negotiation - we need to agree on a definition of a Security Association (SA). It's more than just keys, especially since we are trading off simplicity in IPSP for added context implied by the SA. The SA probably includes the algorithm, key, label, and services. - Termination of SA - what is a "session", what is its lifetime? IPSEC is mixing a connectionless IPSP with a connection-oriented SA. What are the recovery mechanisms (e.g., do "aborts" have to be authenticated)? Security Management - Certificate Distribution - Peer-to-Peer or via a third party - CRL List - Possibly support through SNMP - Centralized Key Distribution - Used for shared keys/multicast. We may defer work on this item until later. - Access Control Attributes Issues: - Device name and address implications for directories and certificates - Authorization List/Delegation - what hosts is an IPSP router permitted to act as a proxy for? Is this information dynamically discovered or statically configured? Dynamic is more flexible but potentially adds much more complexity. - How are IPSP access lists for routers distributed and maintained? - Can a SA change, or is a change accomplished by terminating an old SA and establishing a new one?? - Shared keys - used for multicast or (possibly) multiple IPSP routers serving a site Existing hosts have to be able to take advantage of IPSP services in routers without any change to the host (i.e., IPSP is transparent to non-IPSP end systems) Dave Solo volunteered to write a requirements document for IPSEC Key Management Concern was expressed about supporting public keys first in the IPSEC goals because of possible delays from patent issues (a lesson learned by PEM). Having a standard API for communicating keys from the KMP entity to IPSP would facilitate support for private/shared keys. Presentations on Existing Key Management Implementations Rob Hagens/ANS gave a presentation on KeyMan product. - The routers have a pre-configured list of peer entities - A Key Encryption Key is used in the current Beta release; a new version using public/private keys is in development - Traffic key lifetimes are dynamically specified - Different TEKs are used in each direction; setup can be done in two messages, but four are normally used - All PDUs have the same format (48 bytes) - Public keys are currently locally stored (manual distribution) - TEK generation does not use Diffie-Hellman, so recorded traffic could be decrypted if the private keys are ever learned - If a router crashes, it establishes new SAs; the other routers discard the old SA when a new setup is requested Jim Zmuda/Hughes gave a presentation of key management in the NetLock product. It uses SAEP and a trusted Certification Authority on at least one of the systems. A Diffie-Hellman exchange is used to generate a secret for shared keys. The secret is also encrypted with the sender's private key for authentication. Many thanks to Tom Benkart who served as recording secretary for these meetings. ------------------------------------------------------------------------ IPSEC Working Group Roster 28th IETF - November 2 and 3 1993 Garrett D. Alexander gda@tycho.ncsc.mil Ran Atkinson atkinson@itd.nrl.navy.mil Ali Bahreman bahreman@bellcore.com Steve Bellovin smb@research.att.com Tom Benkart teb@saturn.acc.com Larry Blunk larryljb@merit.edu Ken Carlberg carlburg@cseic.saic.com Cheng Chen chen@accessworks.com Richard Colella colella@nist.gov Steve Crocker crpcker@tis.com Waychi Doo wcd@berlioz.nsc.com Bob Downs bob@combinet.com Donald E. Eastlake, III dee@lkg.dec.com Antonio Fernandez afa@bellcore.com Rich Fox rfox@metricom.com Dan Frommer frommer@isv.dec.com Vince Gebes vgebes@spin.ad(i?)p Rob Glenn glenn@osi.ncsl.nist.gov M. J. Goh goh@mpr.ca Chris Gorsuch chrisg@lobby.ti.com Jisoo Greiter geiter@mitre.org Phill Gross pgross@ans.net Robert Hagens hagens@ans.net Phil Karn karn@qualcomm.com Charlie Kaufman kaufman@zk3.dec.com Elizabeth Kaufman kaufman-elizabeth@yale.edu Steve Kent kent@bbn.com Ed King eek@atc.boeing.com Michael L. Kornegay mlk@bnr.com David Kristol dmk@research.att.com Paul Lambert lambert@email.mot.com John Linn linn@security.ov.com Brian Lloyd brian@lloyd.com Kanckei Loa loa@nddsunz.sps.mot.com Steve Lunt lunt@bellcore.com Gary Malkin gmalkin@xylogics.com Glenn McGregor ietf_ipsec@lloyd.com Mike Michnikov mbmg@mitre.org Greg Minshall minshall@wc.novell.com Sandra Murphy murphy@tis.com Andrew Myles andrew@mpre.mg.edu.au Mike O'Dell mo@uunet.uu.net Steve Parker sparket@ossi.com Hanning Schalzinre hgs@research.att.com Vincent Shekher vin@sps.mot.com Frank Solensky solenksy@ftp.net Bill Simpson bsimpson@um.cc.umich.edu David Solo solo@bbn.com Jim Solomon solomon@comm.mot.com Don Stephenson dons@eng.sun.com Mike StJohns StJohns@arpa.mil Richard Thomas rjthomas@bnr.com Sue Thomson set@bellcore.com Dean Throop throop@dg-rtp.dg.com Jerry Toporek jt@mentat.com Paul Traina pst@cisco.com Ted Ts'o tytso@mit.edu Tony Valle valle@huntsville.sparta.com Chuck Warlick warlick@pscni.nasa.gov David Woodgate davidw@its.csiro.au Ruixi Yuan yuan@syl.dl.nec.com Peter Yee yee@atlas.arc.nasa.gov Jim Zmuda zmuda@mls.hac.com From ipsec-request@ans.net Thu Nov 18 04:45:20 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12691 (5.65c/IDA-1.4.4 for ); Thu, 18 Nov 1993 09:49:04 -0500 Received: by interlock.ans.net id AA19976 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 18 Nov 1993 09:44:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 18 Nov 1993 09:44:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 18 Nov 1993 09:44:10 -0500 Date: Thu, 18 Nov 93 09:45:20 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9311181445.AA13166@itd.nrl.navy.mil> To: ipsec@ans.net Subject: Re: IPSEC Minutes - IETF28 My hand-written notes from the 2nd IPsec meeting indicate that we talked some about key management protocol algorithms. I thought we had reached rough consensus on using a hybrid Diffie-Hellman with RSA Key Certificates used to mitigate against a man-in-the-middle attack for the KMP. Since this is apparently ambiguous, I'd like to formally suggest that we use that approach and open discussion on that proposal on this list. If someone prefers another approach, it would be good to hear about it now. Does this use of hybrid Diffie-Hellman cause anyone heartburn ? Which of the existing key mgmt protocols (if any) use this ? Secondly, I think it would be ideal if the need for key management APIs were raised with the CAT working group as something that we'd like to see as an optional extension to their existing Generic Security Services Application Programming Interfaces (GSS-APIs). They are already dealing with APIs and our identified need fits neatly with their existing work. Lastly, after sitting in on a number of different meetings at the IETF, I was struck by the large amount of progress that could be made soon if we had an Internet Key Mgmt Protocol (IKMP). There are a fair number of protocols (e.g. routing protocols, DHCP) that could use keyed MD5 to add authentication very rapidly once we had a key mgmt protocol. Perhaps it would be in the best interest of the Internet if we were to concentrate on that piece first. In looking at my work for SIPP security, it is clear that because of differences in the protocol design, I'll have to use a slightly different syntax from IPv4 Security Protocol anyway. However, it appears likely that I could reuse the IKMP for SIPP as is. Again, this to me speaks for rearranging our priorities to do the IKMP specification first. Other thoughts are solicited. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Nov 18 15:32:08 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12926 (5.65c/IDA-1.4.4 for ); Thu, 18 Nov 1993 10:35:52 -0500 Received: by interlock.ans.net id AA39023 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 18 Nov 1993 10:30:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 18 Nov 1993 10:30:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 18 Nov 1993 10:30:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 18 Nov 1993 10:30:25 -0500 Message-Id: <9311181532.AA22927@winkl.aktis.com> To: ipsec@ans.net Cc: linn@security.ov.com Subject: Re: IPSEC Minutes - IETF28 Date: Thu, 18 Nov 1993 10:32:08 -0500 From: John Linn Ran Atkinson writes: > Secondly, I think it would be ideal if the need for key management APIs >were raised with the CAT working group as something that we'd like to >see as an optional extension to their existing Generic Security Services >Application Programming Interfaces (GSS-APIs). They are already dealing >with APIs and our identified need fits neatly with their existing work. Many of the key management technologies being discussed in ipsec could fit, I believe, as GSS-API mechanisms. Perhaps a sufficient extension would be a single call which allows a caller to extract an established session key for arbitrary use? I think it would be a very Good Thing to avoid duplication of effort by enabling the same technologies being built to establish keys for ipsec to also be consumed by other applications. --jl From ipsec-request@ans.net Mon Nov 22 19:04:08 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06833 (5.65c/IDA-1.4.4 for ); Mon, 22 Nov 1993 14:06:23 -0500 Received: by interlock.ans.net id AA08229 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 22 Nov 1993 14:03:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 22 Nov 1993 14:03:02 -0500 Message-Id: <199311221903.AA40993@interlock.ans.net> To: Ran Atkinson Cc: ipsec@ans.net Subject: Re: IPSEC Minutes - IETF28 In-Reply-To: Your message of Thu, 18 Nov 93 09:45:20 -0500. <9311181445.AA13166@itd.nrl.navy.mil> Date: Mon, 22 Nov 93 14:04:08 -0500 From: Steve Kent Ran, I don't think there was concensus on the topic you cited. Certainly the use of DH followed by RSA (or DSS) certificates has a number of features, and it is the style of the key exchange adopted by by the CONS version of NLSP and demonstrated by Jim. However, its primary benefit relative to straight certificate exchange seems to be in concealing the DNs of the communicants and in generating a one-time key that cannot be recovered even if both communicants' private keys (the complements of the public keys in their certificates) are disclosed. The first feature may be of some traffic flow security value, but its effectiveness may be quite limited in practice (I don't know if we can really predict) and it is subject to active attacks. The second feature is nice, but we can get close to it by having each communicant contribute 1/2 of the bits for the (symmetric) "association" key, so that BOTH communicant's private keys would have to be compromised in order to recover the "association" key. The I think the use of DH to begin the key exchange does add steps to the process, i.e., fewer exchanges could be effected if the DH didn't have to be done first. Also, until a few more years pass, use of DH calls for yet another license (in the U.S.). Finally, I worry a bit about the slippery slope that might arise, i.e., "let's just do the DH exchange and not bother with certificates," as an alternative key management protocol that forgoes authentication. I don't mean to suggest that the key management protocol we saw demonstrated and described is a bad proposal. However, I do think it premature to suggest that there was concensus on adopting it for IPSEC at this point, given the relatively little discussion and analysis the proposals have received so far. Steve From ipsec-request@ans.net Mon Nov 22 04:38:28 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18479 (5.65c/IDA-1.4.4 for ); Mon, 22 Nov 1993 15:45:16 -0500 Received: by interlock.ans.net id AA19572 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 22 Nov 1993 15:37:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 22 Nov 1993 15:37:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 22 Nov 1993 15:37:50 -0500 X-Ns-Transport-Id: 08003700A332ECD730A1 Date: Mon, 22 Nov 1993 12:38:28 PST From: Russ_Housley.McLean_CSD@xerox.com Subject: Re: IPSEC Minutes - IETF28 In-Reply-To: <199311221903.AA40993@interlock.ans.net> To: atkinson@itd.nrl.navy.mil, kent@bbn.com Cc: ipsec@ans.net Message-Id: <"22-Nov-93 15:38:18".*.Russ_Housley.McLean_CSD@Xerox.com> Ran and Steve: I was not at the IPSEC meeting, so I was reluctant to jump into this discussion. However, this topic was also discussed at the IEEE 802.10 meeting, nd I thought that I might be able to add some information. As most of you know, IEEE 802.10 is workig on a key management standard. In that context, Jim Zmuda presented the Diffie-Helman (DH) approach used in NLSP and TLSP. Steve gave a very nice summary of the DH properties, so I will not repeat them here. In IEEE 802.10, key establishment goes through two phases: key generation and attribute negotiation. When Jim presented DH, we all noticed that six exchanges are needed to complete key establishment; four are used by DH, and two are used for attribute negotiation. By the way, the attribute negotiation step is encrypted in the key that was generated to ensure that both parties generated the same key. This verification provides authentication. IEEE 802.10 is looking at modified DH approaches that only need two exhanges. Of course, this requires that the certificates be passed in the clear. We do not see this as a problem. If any of you see this as a problem, please explain. Russ From ipsec-request@ans.net Mon Nov 22 09:04:34 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14018 (5.65c/IDA-1.4.4 for ); Mon, 22 Nov 1993 20:09:05 -0500 Received: by interlock.ans.net id AA03436 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 22 Nov 1993 20:07:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 22 Nov 1993 20:07:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 22 Nov 1993 20:07:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 22 Nov 1993 20:07:26 -0500 Date: Mon, 22 Nov 93 17:04:34 PST From: ward@mls1.hac.com (Ward Bathrick) Message-Id: <9311230104.AA20552@mls1.HAC.COM> To: Russ_Housley.McLean_CSD@xerox.com Subject: Re: IPSEC Minutes - IETF28 Cc: ipsec@ans.net Russ, Just to clarify......... > attribute negotiation. When Jim presented DH, we all noticed that six > exchanges are needed to complete key establishment; four are used by DH, and > two are used for attribute negotiation. By the way, the attribute negotiation > step is encrypted in the key that was generated to ensure that both parties > generated the same key. This verification provides authentication. The number of exchanges used in the Hughes implementation is 4. Two are used forthe Diffie-Helman, the remaining two are used for certificate exchange and attribute negotiation. > IEEE 802.10 is looking at modified DH approaches that only need two exhanges. > Of course, this requires that the certificates be passed in the clear. We do > not see this as a problem. If any of you see this as a problem, please > explain. Sounds interesting. Can you explain more? Ward From ipsec-request@ans.net Mon Nov 22 11:47:18 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12817 (5.65c/IDA-1.4.4 for ); Mon, 22 Nov 1993 20:47:37 -0500 Received: by interlock.ans.net id AA03393 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 22 Nov 1993 20:46:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 22 Nov 1993 20:46:10 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 22 Nov 1993 20:46:10 -0500 Date: Mon, 22 Nov 1993 18:47:18 MST From: "Hilarie Orman" Message-Id: <199311230147.AA10140@umbra.cs.arizona.edu> Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 22 Nov 1993 20:46:10 -0500 To: Russ_Housley.McLean_CSD@xerox.com Cc: ipsec@ans.net In-Reply-To: Your message <"22-Nov-93 15:38:18".*.Russ_Housley.McLean_CSD@Xerox.com> Subject: Re: IPSEC Minutes - IETF28 I was not at the IPSEC meeting, and I would like to see documents that describe how DH is used in NLSP and TLSP. What is the best way to obtain them? Has the time for the DH computation been discussed? It can be somewhat taxing to perform this with large enough numbers to provide good protection. From ipsec-request@ans.net Mon Nov 22 20:54:02 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12755 (5.65c/IDA-1.4.4 for ); Tue, 23 Nov 1993 07:55:31 -0500 Received: by interlock.ans.net id AA08136 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 23 Nov 1993 07:53:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 23 Nov 1993 07:53:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 23 Nov 1993 07:53:31 -0500 X-Ns-Transport-Id: 08003700A332ECE530A1 Date: Tue, 23 Nov 1993 04:54:02 PST From: Russ_Housley.McLean_CSD@xerox.com Subject: Re: IPSEC Minutes - IETF28 In-Reply-To: <199311230147.AA10140@umbra.cs.arizona.edu> To: ho@cs.arizona.edu Cc: ipsec@ans.net Message-Id: <"23-Nov-93 7:53:52".*.Russ_Housley.McLean_CSD@Xerox.com> Hilarie: The key management for NLSP and TLSP are now full ISO standards. You should be able to get them from your usual sources. IS 10736, Transport Layer Security Protocol. The first addendum (a separate document) describes the key management. IS 11577, Network Layer Security Protocol. There is an annex within the base document that describes the key management. Russ From ipsec-request@ans.net Wed Nov 24 04:03:05 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12602 (5.65c/IDA-1.4.4 for ); Wed, 24 Nov 1993 09:15:29 -0500 Received: by interlock.ans.net id AA05490 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 24 Nov 1993 09:02:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 24 Nov 1993 09:02:01 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 24 Nov 1993 09:02:01 -0500 Date: Wed, 24 Nov 93 09:03:05 EST From: martin@spica.disa.mil (Cynthia E. Martin) Message-Id: <9311241403.AA00299@spica.disa.mil> To: ipsec@ans.net, martin@spica.disa.mil Subject: SP3/NLSP Implementations I am looking for information on SP3 and NLSP implementations and the problems related to each. Also, are there any publications that compare them? Cynthia E. Martin DISA From ipsec-request@ans.net Wed Nov 24 02:10:27 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19066 (5.65c/IDA-1.4.4 for ); Wed, 24 Nov 1993 13:12:30 -0500 Received: by interlock.ans.net id AA11947 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 24 Nov 1993 13:09:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 24 Nov 1993 13:09:55 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 24 Nov 1993 13:09:55 -0500 X-Ns-Transport-Id: 08003700A332ED2A30A1 Date: Wed, 24 Nov 1993 10:10:27 PST From: Russ_Housley.McLean_CSD@xerox.com Subject: Re: IPSEC Minutes - IETF28 In-Reply-To: <9311230104.AA20552@mls1.HAC.COM> To: ward@mls1.hac.com Cc: ipsec@ans.net Message-Id: <"24-Nov-93 13:10:24".*.Russ_Housley.McLean_CSD@Xerox.com> Ward: RECAP In the IEEE 802.10 draft key management standard, key establishement goes through two phases. First, a key is generated. We support many techniques, including Diffie-Hellman, Needham-Schroder, and selecting keys from a manually distributed cache. Second, attributes are negotiated. These attributes determine how the key will be used; they include the algorithm and the security protocol that will be used. The attribute negotiation exchange are encrypted under the key that was generated to ensure that both parties have the same key. When they do have the same key, authentication is achieved. DIFFIE-HELLMAN Diffie-Hellman is a four step process. I our protocol, these four steps would be followed by two attribute negotiation steps. Step 1) A to B: aX mod p Step 2) B to A: aY mod p Step 3) A to B: ENCRYPT {SIGN {aXY mod p, certificate of A}} Step 4) B to A: ENCRYPT {SIGN {aXY mod p, certificate of B}} Diffie-Hellman can be shortened to three key generation steps (again followed by two attribute negotiation steps). Step 1) A to B: aX mod p Step 2) B to A: aY mod p, ENCRYPT {SIGN {aXY mod p}, certificate of B} Step 3) A to B: ENCRYPT {SIGN {aXY mod p, certificate of A}} PROPOSAL BEING INVESTIGATED We really want to get the process down to two steps (again followed by two attribute negotiation steps). Clearly, this the certificates are not kept confidential in this approach. The question being researched is wheteher or not some other weakness is introduced. Step 1) A to B: aX mod p, SIGN {aX mod p}, certificate of A Step 2) B to A: aY mod p, SIGN {aY mod p}, certificate of B --Russ From ipsec-request@ans.net Wed Nov 24 05:24:59 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16834 (5.65c/IDA-1.4.4 for ); Wed, 24 Nov 1993 14:26:14 -0500 Received: by interlock.ans.net id AA24699 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 24 Nov 1993 14:24:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 24 Nov 1993 14:24:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 24 Nov 1993 14:24:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 24 Nov 1993 14:24:04 -0500 Date: Wed, 24 Nov 93 12:24:59 MST From: colin@nyx10.cs.du.edu (Colin Plumb) Message-Id: <9311241924.AA10520@nyx10.cs.du.edu> X-Disclaimer: Nyx is a public access Unix system run by the University of Denver. The University has neither control over nor responsibility for the opinions or correct identity of users. To: Russ_Housley.McLean_CSD@xerox.com Subject: Diffie-Hellman Cc: ipsec@ans.net RECAP > In the IEEE 802.10 draft key management standard, key establishement > goes through two phases. First, a key is generated. We support many > techniques, including Diffie-Hellman, Needham-Schroder, and selecting > keys from a manually distributed cache. Second, attributes are > negotiated. These attributes determine how the key will be used; they > include the algorithm and the security protocol that will be used. The > attribute negotiation exchange are encrypted under the key that was > generated to ensure that both parties have the same key. When they do > have the same key, authentication is achieved. As long as this negotiation can detect someone replaying an old message (or some sort of timestamp is included in the signature), then > Step 1) A to B: aX mod p, SIGN {aX mod p}, certificate of A > Step 2) B to A: aY mod p, SIGN {aY mod p}, certificate of B is secure. I am unclear about the point of encrypting the certificates in these protocols. The whole point to having them in the first place is to provide security against an active (tampering) eavesdropper. With the other protocols, such an eavesdropper can spoof one end and enter into negotiation with A. E will be unable to give a good signature from B, but since E generated Y, E can compute aXY, which is the encryption key, and thus capture A's certificate. Is there some advantage to denying additional information to passive eavesdroppers? DIFFIE-HELLMAN Diffie-Hellman is a four step process. I our protocol, these four steps would be followed by two attribute negotiation steps. Step 1) A to B: aX mod p Step 2) B to A: aY mod p Step 3) A to B: ENCRYPT {SIGN {aXY mod p, certificate of A}} Step 4) B to A: ENCRYPT {SIGN {aXY mod p, certificate of B}} Diffie-Hellman can be shortened to three key generation steps (again followed by two attribute negotiation steps). Step 1) A to B: aX mod p Step 2) B to A: aY mod p, ENCRYPT {SIGN {aXY mod p}, certificate of B} Step 3) A to B: ENCRYPT {SIGN {aXY mod p, certificate of A}} Of course, steps 1 and 2 can take place simultaneously, so it's really just one stage. Each side sends aX and receives aY, or vice versa. -- -Colin