From atkinson@tengwar.itd.nrl.navy.mil Sun Mar 7 06:19:15 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA37828 (5.65c/IDA-1.4.4 for ); Sun, 7 Mar 1993 20:06:14 -0500 Received: from tengwar.itd.nrl.navy.mil by interlock.ans.net with SMTP id AA10180 (InterLock SMTP Gateway 1.1 for ); Sun, 7 Mar 1993 20:03:11 -0500 Message-Id: <199303080103.AA10180@interlock.ans.net> Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA09482; Sun, 7 Mar 93 11:19:15 -0500 Date: Sun, 7 Mar 93 11:19:15 -0500 From: Ran Atkinson To: ipsec@ans.net Subject: ISO NLSP comments & suggestions Folks, I've spent much of the last week really studying this specification. It seems to badly suffer from ISO-ese in its documentation and also in its design. For example, the way that many of the fields were designed makes them extremely expensive to parse (variable length, variable presence, etc.). I understand that some of the fields will have to be variable in order to support different algorithms. However, it seems to me that there ought to be a way to streamline some of the fields. I think we should have the design objective that (exclusive of the performance cost of the security algorithm) the IPv4 Security Protocol support very fast implementations. I've got experimental ATM circuits at OC-3C rates (155 Mbps) right now and NASA/DoE are reportedly going to an ATM-based OC-3C backbone during 1993. In 2-3 years these fast circuits will be fairly common. It is important that the IPSP itself (as distingished from whichever algorithm one uses) not be the performance bottleneck. The DIS NLSP specification is much less readable and clear than the SP3 specification was (probably due to ANSI/ISO rules). A number of the changes from SP3 are not obviously needed and could use some public clarification in Ohio. Ideally someone very familiar with both could highlight the technical differences along with some high-level clarification on why each change was made. Also, I think it would be very very helpful if someone could make a first cut at adapting the mechanisms of NLSP into a more streamlined format usable for IPv4 and put that out as a basis for discussion. If this happened before Ohio, I think that would also help focus the discussions in Ohio. Ran atkinson@itd.nrl.navy.mil From Russ_Housley.McLean_CSD@xerox.com Sun Mar 7 22:52:34 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04712 (5.65c/IDA-1.4.4 for ); Mon, 8 Mar 1993 09:53:58 -0500 Received: from alpha.Xerox.COM by interlock.ans.net with SMTP id AA20013 (InterLock SMTP Gateway 1.1 for ); Mon, 8 Mar 1993 09:52:35 -0500 Received: from ADFMail1.ADFMcLean_CSD.Xerox.xns by alpha.xerox.com via XNS id <11594>; Mon, 8 Mar 1993 06:52:56 PST X-Ns-Transport-Id: 0000AA00A8ECC82D2EAF Date: Mon, 8 Mar 1993 06:52:34 PST From: Russ_Housley.McLean_CSD@xerox.com Subject: Forwarding: ISO/IEC/JTC1/SC6 London Meeting ( OSI v TCP/IP status update ) To: ipsec@ans.net Cc: psrg-interest@isi.edu Message-Id: <" 8-Mar-93 9:52:27".*.Russ_Housley.McLean_CSD@Xerox.com> IPSECers: As you can see from the attached trip report, there is a possibility that CLNP will be adopted as IPv7. At the next IETF meeting we should try an determine the likelihood of this alternative. If CLNP is in the Internet's future, then I suggest that NLSP-CL is the correct security protocol. If CLNP/NLSP-CL is the long term solution, the I suggest that IP/NLSP-CL/Convergence Protocol is the correct short term solution. Russ ----- Begin Forwarded Messages ----- Date: Sun, 7 Mar 93 07:44:55 PST From: Jim_Long.Bridge_House@rxuk.Xerox.com Subject: ISO/IEC/JTC1/SC6 London Meeting ( OSI v TCP/IP status update ) To: ExtStds.All_Areas@Xerox.com Reply-to: Jim_Long.Bridge_House@rxuk.Xerox.com Message-ID: <" 7-Mar-93 15:44:50".*.Jim_Long.Bridge_House@rxuk.Xerox.com> An ad-hoc meeting to progress the initiative to establish liaison between ISO/IEC and the Internet Society was held during the SC6 interim working group meetings in London, February 8 -12th. 1993. The initiative is not one-sided, as the Internet Society has also written to the ISO Central Secretariat requesting Category A liaison status, and this request will be progressed as quickly as possible through the ISO/IEC Management Committee JTC1. The lively and enthusiastic London meeting attracted over 40 delegates from the SC6 working groups, and was chaired by Jack Houldsworth who has accepted the responsibility to progress the initiative on behalf of SC6. ( Jack has been chairman of the BSI IST/6 committee for many years, and is well known in the industry as one of the founding fathers of OSI ). A. Lyman Chapin, chairman of the IAB ( Internet Architecture Board ), represented the Internet Society by agreement with Vinton Cerf, the President of the Board of Trustees of the Internet Society. Jack Houldsworth opened the meeting by crystallising the key objectives of liaison as:- "the convergence of the existing TCP/IP and OSI interconnection and interworking protocols, and the ongoing joint development of a common platform to support future multimedia and hypermedia applications". He highlighted the benefits of a converged scenario, which are the reduction of development effort required by the industry and an easier route to global interconnection. He was particularly anxious to halt the current media rhetoric about the rumoured "battle of attrition" between TCP/IP and OSI which is confusing users and tearing the industry apart. He urged all delegates to ensure that the liaison initiative is promulgated to all possible areas of the media on the grounds that this is a better story than the worn out open warfare rhetoric. He also believes that suppliers of other proprietry protocols will follow suit if Internet and OSI are seen to be converging, and that convergence is the only route to an "all-pervasive" global network. Lyman Chapin cautioned that many Internet members come from an academic background and enjoy a lively experimental environment. They have no commercial commitment to deliver products to customers for global interconnection and there is a requirement to convince them about the benefits of a converged solution. ( Some Internet members actually believe that competition between two solutions is a good thing.) Lyman went on to report that the Internet community is currently reviewing protocol enhancements to solve some known problems with TCP/IP, and that several alternative solutions are on the table. One of these is to run the Internet TCP and UDP protocols over the OSI Internet Protocol, this proposal being known as TUBA ( TCP / UDP over Bigger Addresses ). It was agreed that SC6 should support the TUBA proposal, and that this view should be conveyed to the IAB as quickly as possible to make sure that the window of opportunity is not missed. ( Several delegates offered to contact the Network OSI Operations Working Group ( noop@merit.edu) to convey this view on behalf of their parent organisations.) The meeting also agreed to examine "fast track" operating methods for collaborative projects with Internet. This could be similar to the way that ISO / IEC and the IEEE work together on LAN standards. A joint programme to create a platform for multimedia and hypermedia applications would have similar content to the Enhanced Communications Functions and Facilities ( ECFF) programme which is just getting under way in SC6, and a major share of the protocol enhancement work could be handled by the Internet community to share the load. The "fast track" initiative will be progressed with the ISO / IEC Management Committee JTC1. It was also agreed that ISO / IEC needs to release relevant ISO documents to the Internet Community for use within their electronic distribution system if collaboration is to work. ( This does not imply release of copywrite, but it is accepted that relevant ISO documents should be available electronically in the same way as RFC's). SC6 will request the release of key documents through JTC1. Jack Houldsworth will attend the next IAB meeting ( to be held during the IETF meeting in Columbus, Ohio at the end of March) on behalf of SC6 to convey the enthusiasm of ISO/IEC for future collaboration, and will also make it known that the TUBA proposals would be favourably received by ISO / IEC. Jack will also attend the European IETF meeting in Amsterdam in July to maintain liaison impetus and continuity as SC6 runs up to its Plenary meeting in Seoul next September. Jim ----- End Forwarded Messages ----- From atkinson@tengwar.itd.nrl.navy.mil Mon Mar 8 05:43:41 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA40081 (5.65c/IDA-1.4.4 for ); Mon, 8 Mar 1993 10:43:07 -0500 Received: from tengwar.itd.nrl.navy.mil by interlock.ans.net with SMTP id AA23564 (InterLock SMTP Gateway 1.1 for ); Mon, 8 Mar 1993 10:42:57 -0500 Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA09953; Mon, 8 Mar 93 10:43:41 -0500 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9303081043.ZM9951@tengwar.itd.nrl.navy.mil> Date: Mon, 8 Mar 1993 10:43:41 -0500 In-Reply-To: Russ_Housley.McLean_CSD@xerox.com "Forwarding: ISO/IEC/JTC1/SC6 London Meeting ( OSI v TCP/IP status update )" (Mar 8, 6:52) References: <" 8-Mar-93 9:52:27".*.Russ_Housley.McLean_CSD@Xerox.com> Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: Russ_Housley.McLean_CSD@xerox.com, ipsec@ans.net Subject: Re: Forwarding: ISO/IEC/JTC1/SC6 London Meeting ( OSI v TCP/IP status update ) Cc: psrg-interest@isi.edu I don't like the approach of the convergence protocol because I'm going to need to have Secure IP running over very low bandwidth tactical links (circa 2.4Kbps). I just cannot afford any overhead that can be avoided. If we adopt the NLSP _mechanisms_ but adapt them for IPv4, there should be less overhead and my tactical links will be much better off. I should note that TCP/IPv4 is currently used successfully over RF links. Let's not get distracted as a group into the IPv6/7/8 issues. Let's avoid the convergence approach and just adopt the security mechanisms. Regards, Ran atkinson@itd.nrl.navy.mil From ji@cedar.cs.columbia.edu Wed Mar 10 05:35:45 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26730 (5.65c/IDA-1.4.4 for ); Wed, 10 Mar 1993 10:57:12 -0500 Received: from cs.columbia.edu by interlock.ans.net with SMTP id AA11648 (InterLock SMTP Gateway 1.1 for ); Wed, 10 Mar 1993 10:52:02 -0500 Received: from cedar.cs.columbia.edu by cs.columbia.edu (5.65c/0.6/jba+ad) with SMTP id AA13568; Wed, 10 Mar 1993 10:35:46 -0500 Received: by cedar.cs.columbia.edu (4.1/SMI-4.1+) id AA04022; Wed, 10 Mar 93 10:35:45 EST Date: Wed, 10 Mar 93 10:35:45 EST From: ji@cedar.cs.columbia.edu (John Ioannidis) Message-Id: <9303101535.AA04022@cedar.cs.columbia.edu> To: ipsec@ans.net Cc: crocker@tis.com Subject: our "secure ip" protocol Sender: John "Heldenprogrammer" Ioannidis Reply-To: ji@cs.columbia.edu Organization: Columbia University Department of Computer Science X-Date: 20 Ventose An CCI I have been working on IP-level security with Matt Blaze and Phil Karn, and it is at a stage where we can present it to the community. We have developed swIPe (note the typography), a network-level security protocol for IP. swIPe provides IP-level authentication and encryption (A&E), and cleanly separates A&E mechanism (the protocol itself) from key management and policy enforcement. We have built a prototype implementation of swIPe which runs under SunOS and Mach, using DES for encryption, MD5 for authentication, a simple key management scheme, and IPIP encapsulation for the actual transmission. We hope to give a demo (hardware permitting) at the upcoming IETF in Columbus. An Internet-Draft is also in the making. Can we have a slot at the ipsec WG meeting at the Columbus IETF to present this work? Thanks, /ji -- In-Real-Life: John "Heldenprogrammer" Ioannidis E-Mail-To: ji@cs.columbia.edu V-Mail-To: +1 212 939 7029 or 7038 P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027 From Paul_Lambert@poncho.phx.sectel.mot.com Fri Mar 12 02:10:25 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA45246 (5.65c/IDA-1.4.4 for ); Fri, 12 Mar 1993 11:08:51 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA17371 (InterLock SMTP Gateway 1.1 for ); Fri, 12 Mar 1993 11:07:03 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.11 for ) id AA25602; Fri, 12 Mar 1993 10:07:12 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.11 for ) id AA19080; Fri, 12 Mar 1993 10:07:09 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA14998; Fri, 12 Mar 93 09:07:43 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA34874; Fri, 12 Mar 1993 9:17:00 MST Message-Id: <00112.2814772620.34874@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list), ji@cs.columbia.edu (ji) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Fri, 12 Mar 1993 9:10:25 MST Subject: Re: our "secure ip" protocol Reply to: RE>our "secure ip" protocol ji, It sounds great! I'll reserve a slot on the agenda! >Organization: Columbia University Department of Computer Science >X-Date: 20 Ventose An CCI >I have been working on IP-level security with Matt Blaze and Phil >Karn, and it is at a stage where we can present it to the community. > >We have developed swIPe (note the typography), a network-level >security protocol for IP. swIPe provides IP-level authentication and >encryption (A&E), and cleanly separates A&E mechanism (the protocol >itself) from key management and policy enforcement. > >We have built a prototype implementation of swIPe which runs under >SunOS and Mach, using DES for encryption, MD5 for authentication, a >simple key management scheme, and IPIP encapsulation for the actual >transmission. We hope to give a demo (hardware permitting) at the >upcoming IETF in Columbus. An Internet-Draft is also in the making. > >Can we have a slot at the ipsec WG meeting at the Columbus IETF to >present this work? > >Thanks, > >/ji For now the time for the presentation will have to be fairly short - about 10 to 15 minutes. We currently have at least three other implementations that will be presented! We also need to spend some time on key management to establish our groundwork. Perhaps we will need two slots at the IETF. If anyone els wnats time on the agenda please let me know very soon. I'll try to post a agenda late next week. Paul From smb@research.att.com Sat Mar 13 03:16:50 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA33452 (5.65c/IDA-1.4.4 for ); Sat, 13 Mar 1993 08:19:12 -0500 Received: from research.att.com by interlock.ans.net with SMTP id AA18156 (InterLock SMTP Gateway 1.1 for ); Sat, 13 Mar 1993 08:18:41 -0500 Message-Id: <199303131318.AA18156@interlock.ans.net> From: smb@research.att.com Received: by gryphon; Sat Mar 13 08:16:51 EST 1993 To: ji@cs.columbia.edu Cc: ipsec@ans.net, crocker@tis.com Subject: Re: our "secure ip" protocol Date: Sat, 13 Mar 93 08:16:50 EST I have been working on IP-level security with Matt Blaze and Phil Karn, and it is at a stage where we can present it to the community. We have developed swIPe (note the typography), a network-level security protocol for IP. swIPe provides IP-level authentication and encryption (A&E), and cleanly separates A&E mechanism (the protocol itself) from key management and policy enforcement. We have built a prototype implementation of swIPe which runs under SunOS and Mach, using DES for encryption, MD5 for authentication, a simple key management scheme, and IPIP encapsulation for the actual transmission. We hope to give a demo (hardware permitting) at the upcoming IETF in Columbus. An Internet-Draft is also in the making. Can we have a slot at the ipsec WG meeting at the Columbus IETF to present this work? At Interop, there were at least two vendors showing IP-level encryptors, UUNET and Xerox Semaphore. Both use DES chips to do the encryption. Currently, the UUNET device uses a floppy for rekeying, while the Xerox unit uses RSA and dynamic session key generation between pairs of encryptors. --Steve Bellovin From Paul_Lambert@poncho.phx.sectel.mot.com Wed Mar 24 07:30:42 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34333 (5.65c/IDA-1.4.4 for ); Wed, 24 Mar 1993 16:21:09 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA35473 (InterLock SMTP Gateway 1.1 for ); Wed, 24 Mar 1993 16:19:24 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.13 for ) id AA04213; Wed, 24 Mar 1993 15:19:31 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.12 for ) id AA26067; Wed, 24 Mar 1993 15:19:29 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA07772; Wed, 24 Mar 93 14:19:06 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA36079; Wed, 24 Mar 1993 14:31:14 MST Message-Id: <00112.2815828274.36079@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Wed, 24 Mar 1993 14:30:42 MST Subject: Presentations Subject: Presentations Message: It may be short notice but ... for those of you wishing to present overheads at the IPSEC WG - here are some guidelines attached below. Paul ------------------------------------------------------------------- I'd like to make a few requests to those of you who expect to use overheads in your working group/bof sessions. This only applies to overheads that you want included in the Proceedings along with the Minutes. Please pass this information along to any individuals you may ask to give presentations. a. Please place a border around your slides. Flat dark borders are best as they maintain their appearance even when reduced. Thin borders fade after only one reduction and we usually go through several before they make it into the Proceedings. b. Please use a fairly large font, so that information isn't lost during reduction. c. The more detailed your slides the less clear they are when reduced. Chances are too much detail on the orginal gets lost even during the presentation. d. If you have the means to do this, please provide me with a reduced set of the slides you intend to present. Cyndi Mills was able to do this for her Accounting Presentation in DC, though I'm not certain how. Cyndi? a. Landscape (horizontal) slides are typically arranged six to a page in the Proceedings (see back issues for exact layout). b. Vertical slides can be reduced to fit four to a page. Again refer to a back issue of the Proceedings for examples. c. Please allow for the following margins: a. top margin: 1/2" b. left/right margins: 3/4" c. bottom margin: 1/2" to 2" I'd really appreciate your help with this as we continue to work to improve the quality of the Proceedings and the timeliness of their mailing. Thanks, Megan From Paul_Lambert@poncho.phx.sectel.mot.com Wed Mar 24 07:46:41 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20999 (5.65c/IDA-1.4.4 for ); Wed, 24 Mar 1993 16:42:02 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA26161 (InterLock SMTP Gateway 1.1 for ); Wed, 24 Mar 1993 16:40:08 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.13 for ) id AA05143; Wed, 24 Mar 1993 15:40:16 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.12 for ) id AA27477; Wed, 24 Mar 1993 15:40:14 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA07827; Wed, 24 Mar 93 14:39:50 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA36085; Wed, 24 Mar 1993 14:51:52 MST Message-Id: <00112.2815829512.36085@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Wed, 24 Mar 1993 14:46:41 MST Subject: Draft IPSEC Agenda Subject: Draft IPSEC Agenda Message: There will be a IP Security (IPSEC) WG Meeting on Wednesday 31 March at the Ohio IETF (9:30 to 12:00 noon). This will be the first meeting of IPSEC as a Working Group. Draft IPSEC Agenda for March 31, 1993 9:30 Introduction o Review and Approve Agenda o Minutes of Washington DC Meeting 9:35 Review of Charter and Schedule 9:45 Liaisons o What liaisons are needed? o Solicit volunteers for liaisons 9:50 Review of Initial Experimental Implementations o swIPe John "ji" Ioannidis o SP3 Paul Lambert o NLSP Jim Zmuda o Tandu Dan Frommer o Convergence Protocol Jim Zmuda 11:00 Summarize Approaches and Recommendations o Features and Requirements (host-to-host) o Clear Header Format o Security Transformation (encryption, MAC. etc.) o Protected Header o Labels o RPeek-ThroughS o Interaction with IP clients (including IP/IPSP/IP) o Host-to-Subnet and Subnet-to-Subnet Considerations - Fragmentation o Multicast and Conferencing o Solicit Writing Assignments for IPSP 11:20 Key Management o Basic Assumptions o Background and References o Multicast and Conference Control Considerations o Solicit Writing Assignments 11:50 Summary o Next Meeting, Amsterdam? o Review Action Items 12:00 Close From Paul_Lambert@poncho.phx.sectel.mot.com Sun Mar 28 13:26:41 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09850 (5.65c/IDA-1.4.4 for ); Sun, 28 Mar 1993 22:14:55 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA18398 (InterLock SMTP Gateway 1.1 for ); Sun, 28 Mar 1993 22:15:07 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.13 for ) id AA05698; Sun, 28 Mar 1993 21:15:56 -0600 Received: from phx.sectel.mot.com (rambo.phx.sectel.mot.com) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.12 for ) id AA17293; Sun, 28 Mar 1993 21:15:51 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA14096; Sun, 28 Mar 93 20:15:31 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA36355; Sun, 28 Mar 1993 20:27:05 MST Message-Id: <00112.2816195225.36355@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Sun, 28 Mar 1993 20:26:41 MST Subject: Updated IPSEC Charter Subject: Updated IPSEC Charter Message: The following is a draft of an updated charter for the IPSEC Working Group. Three additional issue areas were added to the chater - the realationship of IPSEC to the IP suite of protocols, Rpeek throughS, and labeling. Note also some small changes in the schedule. Paul ---------------------------------------------------------------- Draft of Updated IPSEC Charter ---------------------------------------------------------------- Internet Protocol Security Protocol (ipsec) Charter Chair(s): Al Hoover Paul Lambert Security Area Director(s) Steve Crocker Mailing lists: General Discussion:ipsec@ans.net To Subscribe: ipsec-request@ans.net Archive: ftp.ans.net:~/pub/archive/ipsec Description of Working Group: Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security Protocol Working Group (IPSEC) will develop mechanisms to protect client protocols of IP. The IPSEC Working Group will develop a security protocol in the network layer to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality. The protocol formats for the IP Security Protocol (IPSP) will be independent of the cryptographic algorithm. The preliminary goals will specifically pursue host-to-host security followed by subnet-to-subnet and host-to-subnet topologies. The working group will examine the relationship of network security the suite of IP protocols. This investigation will include the examination of IP as a client of IPSP running over IP. Recommendations documented in the IPSP specification will provide guidelines to protect the IP suite of protocols. The cryptographic encapsulation may hide information that is useful to network. This information may include security labels, addresses, and protocol identifiers. The working group will examine the mapping of encapsulated protocol information onto unprotected fields and guidelines for any required Rpeek-throughS of information. Protocol and cryptographic techniques will also be developed to support the key management requirements of the IPSP. The key management will be specified as an application layer protocol that is independent of the lower layer security protocol. The protocol will initially support public key based techniques. Flexibility in the protocol will allow eventual support of Key Distribution Center (KDC -- such as Kerberos) and manual distribution approaches. Goals and Milestones: Mar 93 Review distributed documents and status of related activities. Establish liaisons to IPSO/CIPSO and IPv7 working groups. Mar 93 Review pilot experiments with cryptographic network security. Mar 93 Post as an Internet-Draft a preliminary version of the IP Security Protocol that supports host-to-host security. Mar 93 Review pilot experiments with cryptographic network security. Discuss, debate, and refine the framework for IPSP based on pilot experiments. Assign writing tasks, and identify issues to be resolved. Action items will include will include labels (IPSO/CIPSO), Rpeek-through,S support of IP suite, and IP over IPSP over IP. Mar 93 Establish baseline goals and starting points for Internet Key Management. Jul 93 Update the IPSP Internet-Draft to include subnet-to-subnet and host-to-subnet topologies. Include preliminary text on labels, Rpeek-through,S and protection of IP suite. Jul 93 Review related key management activities, preliminary proposals, and pilot experiments for Internet Key Management. Nov 93 Discuss, debate, and establish approaches for third-party interactions for key management (e.g., Kerberos like Key Distribution Center). Nov 93 Post as an Internet-Draft a preliminary specification for Internet Key Management. The specification will support a public key based key establishment mechanism. Nov 93 Discuss, debate, and establish approaches for third-party interactions for key management (e.g., Kerberos like Key Distribution Center). Nov 93 Report on Pilot Implementation of the IP Security Protocol. Update Protocol as needed. Mar 94 Report on Pilot implementation of the Internet Key Management Protocol. Update Internet-Draft to include third-party interactions for KDC support. Jul 94 Submit the IP Security Protocol to the IESG for consideration as a Proposed Standard. Jul 94 Report on Pilot implementation of the Internet Key Management with KDC support. Nov 94 Submit the Internet Key Management Protocol to the IESG for consideration as a Proposed Standard.