From dee@ranger.enet.dec.com Mon Apr 1 06:41:56 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09164 (5.65c/IDA-1.4.4 for ); Mon, 29 Mar 1993 11:42:39 -0500 Received: from inet-gw-2.pa.dec.com by interlock.ans.net with SMTP id AA10654 (InterLock SMTP Gateway 1.1 for ); Mon, 29 Mar 1993 11:43:23 -0500 Received: by inet-gw-2.pa.dec.com; id AA09007; Mon, 29 Mar 93 08:44:11 -0800 Received: by us1rmc.bb.dec.com; id AA15381; Mon, 29 Mar 93 11:41:56 -0500 Message-Id: <9303291641.AA15381@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Mon, 29 Mar 93 11:41:56 EST Date: Mon, 29 Mar 93 11:41:56 EST From: "Donald E. Eastlake 3rd, LJO2/I4, 1-508-486-2358 29-Mar-1993 1143" To: ipsec@ans.net Apparently-To: ipsec@ans.net Subject: FWD: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) An the connection should remain secure during all this: From: US1RMC::"ses@tipper.oit.unc.edu" "Simon Spero" 28-MAR-1993 07:03 To: big-internet@munnari.oz.au Subj: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) [ sorry if people get this twice; I read this list via news, and the gateway screwed up. ] From: dcrocker@Mordor.Stanford.EDU (Dave Crocker) Newsgroups: info.big-internet Date: 27 Mar 93 17:32:15 GMT John, I don't take the scenario you describe as wild-eyed. I wish, in fact, we had a series of scenarios (ok, class. can we all say 'requirements analysis'?) on which to base discussions like these. It would give us When I think of Nomadic IP and EID/addressing, I have a mental image of a few scenarios. Imagine this situation: I'm getting ready to go to Amsterdam for the IETF. I sit down and write a quick note to a list on my "Air Newton" personal digital basketball shoe, which is connected via ISDN to CONCERT (open channel B). I start an FTP going, but before it finishes, the taxi to the airport arrives. I disconnect the isdn cable, and go the taxi. In the meantime, the PDBS has switched over to it's build in cellular telephone (hell, I smoke, so I'm going to die of cancer anyway). The FTP finishes, and I arrive at the airport. The flight is delayed, so I go to a connection point in the airport and jack in connecting to (say) the Murphy Brown backbone, which is cheaper than the cellular rates. I log in to my computer at work and start some program running. My flight is called, so I board the plane. I can't use the cell phone on the plane, and GTE seat-net is unbelievably expensive, so I just tell it where I'm sitting, so that I can be reached if urgent email arrives. Take off occurs, and the plane leaves North America, switching from a local network to a more exensive atlantic satellite net. Passengers in 1st class can afford to keep their netnews flowing in; back here in geek class, a couple of kids have strung a porta-fiber link and are playing an annoyingly loud game of net-trek. I stuff the free earplugs into the appropriate orifices, drain the last of the minature scotch, and doze off. Just as I get to sleep, the PDBS buzz gently, informing me that a report from back home is ready for downloading when I get to a cheaper connection. Finally, we touch down at Schipol. As I step into the terminal, the cellphone configures itself for the local service, and establishes a connection. the PDBS grabs some important, but non urgent mail which has been waiting for me; the connection charge is still too high to grab the report. Finally I make it to the hotel. I stagger to the terminal room and hook into the show net, taking advantage of the free bits to catch up on all the backed up traffic. Now it's time to sleep. Upstairs to the hotel room, where I set the shoes for a wakeup call, and let them connect to Hyatt-net. During this night, the program I started back at the airport completes and prints the result (42) to the waiting telnet session. Simon Hackers Local 42- National Union of Computer Operatives, Chapel Hill section - ------------------------------------------------------------------------------ "Arise you users of compression, though the | WAIS/Z39.50 spoken here tarfiles hold you down" - The Internetworkale | DoD #612 | Tel: +1-919-962-9107 From ahoover@ans.net Mon Apr 1 06:06:11 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07892 (5.65c/IDA-1.4.4 for ); Mon, 29 Mar 1993 14:07:45 -0500 Received: by interlock.ans.net id AA12938 (InterLock SMTP Gateway 1.1 for ipsec@ans.net); Mon, 29 Mar 1993 14:07:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 29 Mar 1993 14:07:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 29 Mar 1993 14:07:31 -0500 Date: Mon, 29 Mar 1993 14:06:11 -0800 From: Alton Hoover Message-Id: <199303292206.AA00240@hoovermac.ans.net> To: ipsec@ans.net Subject: Minutes of IPSEC 25th IETF Notes from the IPSEC BOF 11-17-92 Hosted by Steve Crocker, TIS & Al Hoover ANS CO+RE Systems, Inc Presentation: Network Security for Internet Protocols Paul A. Lambert, Motorola, Inc. Secure Telecommunications Strategic Business Unit 8220 E. Roosevelt Rd. Scottsdale, AZ (602) 441-3646 Paul_Lambert@email.mot.com Paul's presentation started out with an overview of "What is Network Security" including an explanation of ISO 7498-2 which defines security services for: Authentication, Access Control, Integrity, Confidentiality and Non-repudiation and mention of other security mechanisms (Physical isolation, Audit trails and Trusted Functionality) Paul presented a slide entitled Threats provided a definition "A threat is a potential violation of security" and identified the following categories: Masquerade/Impersonation, Unauthorized behavior and access, Leakage of information, Integrity threats including: Modification of information, Message sequencing (Replay, Pre-play, Delay), Repudiation (Denial of origin, Denial of delivery) and Denial of Service. Paul then presented a series of slides covering authentication mechanisms including: passwords, PINs, biometrics, symmetric cryptography (e.g. DES based message authentication codes), asymmetric cryptography (e.g. X.509 public key based authentication) and implicit authentication (physical connectivity). Paul presented an overview of security in the OSI reference model with discussion of X.509, X.411 and a focus on NLSP and TLSP. Paul gave a detailed presentation on Network Layer Security Protocol Model (NLSP) and contrasted it to Transport Layer Security Protocol Model (TLSP) including stack diagrams. Paul then presented an overview on IEEE 802.10 Standard for Secure Interoperable LAN Security (SILS) and Secure Data Exchange (SDE). Next Paul presented a slide which summarized the applicable security standards: ISO/IEC DIS 11577 Network Layer Security Protocol, ISO/IEC DIS 10736 Transport Layer Security PROTOCOL Paul also provided copies of the following publications as handouts: ISO/IEC JTC1/SC6 Project: 1.06.49 DTR Ballot Text of the Second Edition of ISO/IEC TR 9577:1990 - Information Technology - Telecommunications and Information Exchange Between Systems - Protocol Identification in the Network Layer. ISO/IEC JTC1/SC6 Project: 1.06.59 Information Technology - Telecommunications and Information Exchange Between Systems - Network Layer Security Protocol. ISO.IEC JTC1/SC6 Project: 1.06.35.06, 1.06.59 and 1.06.60 - FOR COMMENTS - Third Working Draft Text for Lower Layers Security Guidelines. Layer Wars: Protect the Internet with Network Layer Security - Author, Paul Lambert, Motorola, Inc., Secure Telecommunications. Corrections were announced to the IPSEC mailing list and archive as follows: ipsec@ans.net - posting to mailing list ipsec-request@ans.net - request for addition to the mailing list ftp.ans.net ~pub/archive/ipsec - ipsec list archive A poll during the meeting indicated the desire and support to establish a formal working group for IPSEC. A secondary meeting was scheduled where the proposed charter for IPSEC WG was discussed among attendees. The decision was made to submit a revised charter which was discussed on the mailing list and request the establishment of IPSEC as a formal working group with Paul Lambert and Al Hoover acting as co-chairs. This meeting was attended by 37 persons. All registered attendees have been added to the list. James M. Galvin Paul Lambert Russell Housley James Zmuda Robert Shirey Bill Edison Chuck Warlick Andrew Knudsen Jim Barnes Phil Karn Sean O'Malley Hilarie Orman Morton Taragin Art Dertke Dean Throop Warren Vik Tang Tang Roland Acra Steve Crocker Merike Kaeo Mike St. Johns Terry Gray Sam Schaen Paul Sangster Mohammad Mirhakkak Rob Hagens Neil Haller Rich Graveman Tom Benkart Brad Rhoades Noel Chiappa Donald Eastlake Barbara Fraser Cynthia Dellatorre Ran Atkinson Paulina Knibbe Al Hoover From Paul_Lambert@poncho.phx.sectel.mot.com Fri Apr 2 07:00:40 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13582 (5.65c/IDA-1.4.4 for ); Fri, 2 Apr 1993 18:51:21 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA14135 (InterLock SMTP Gateway 1.1 for ); Fri, 2 Apr 1993 18:51: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 AA27607; Fri, 2 Apr 1993 17:51: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 AA09520; Fri, 2 Apr 1993 16:34:46 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA05512; Fri, 2 Apr 93 15:34:00 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA00382; Fri, 2 Apr 1993 15:26:59 MST Message-Id: <00112.2816609219.382@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: Fri, 2 Apr 1993 14:00:40 MST Subject: FWD> Report from London SC6 From INTERNET FWD> Report from London SC6 For your information ... a report on recent SC6 work on lower layer security is attached. Note that comments to ANSI on NLSP are due in April. Paul --------------------------------------------------------- Date: 30 Mar 1993 10:51:15 -0500 (EST) From: walters@osi.ncsl.nist.gov (Dale L. Walters) Subject: Re: Report from London To: /PN=JOHN.WHEELER/O=OMNET/ADMD=TELEMAIL/C=US/@sprint.com Cc: x3s33@merit.edu Message-Id: <9303301551.AA02725@osi.ncsl.nist.gov> Content-Transfer-Encoding: 7BIT Report of the Interim Meeting of ISO/IEC JTC1/SC6 Lower Layer Security London 8-12 February 1993 A. General The interim meeting of SC6 Working Groups (Lower Layer Security) was held at BSI in London on 8-12 February. Mr. Richard Thomas (BNR, Canada) presided over this meeting. The minutes of this meeting are contained in document SC6 N7962. B. U.S. Delegates Dale Walters (NIST) Steve Sherman (Hughes) C. Recommendations The following resolutions were all unanimously approved at a joint WG1, WG2, and WG4 plenary. 1) The Lower Layer Security Model (This had been called a Guidelines document prior to this meeting) has been registered as a PDTR (type 3) as authorized by the SC6 San Diego resolution #108. This is a three month ballot. The US comments concerning LAN security were incorporated into this revised version. 2) Five documents were circulated to SC6 member bodies with comments due by July 30, 1993. a) N7953 Use of NILS with NLSP-CO b) N7954 Application of generic abstract security interface for both TLSP and NLSP c) N7955 A contribution capturing the ad hoc groups understanding of Protection Qos as it relates to security policy d) N7956 A Lan security requirements document requesting comments on whether the LAN security protocol (developed by IEEE) or NLSP should be used to protect LAN data. e) A US contribution on managed objects for NLSP and TLSP 3) A liaison statement to CCITT was sent stating that since the NLSP and TLSP amendment ballots will not close before the next CCITT meeting, SC6 proposes that the joint publishing schedule for these two documents be postponed until early 1994. 4) Three liaison contributions were sent to other ISO committees. a) N7958 A document concerning Security of OSI Systems Management was forwarded to SC21/WG4. b) N 7960 A document concerning Security information objects was forwarded to SC27/WG1. c) N7961 A document concerning QoS, Definition of the security abstract interface, and OSI Reference Model was forwarded to SC21/WGs 1 and 8. D. U.S.Positions There were no cases in which the Lower Layer Security ad hoc group approved a recommendation that did not agree with the U.S. position on the corresponding subject. E. Actions Required by X3S3. X3S3 will be requested to review and approve proposals from its task groups for responses to the security issues identified in the above mentioned documents plus the ballot comments on DIS NLSP and the DAM 1 to TLSP. The two ballot responses will be handled at the next X3S3.3 meeting in late April with the other documents handled in time for the next SC6 meeting. F. This report prepared and submitted by Dale Walters on 30 March 1993. From Paul_Lambert@poncho.phx.sectel.mot.com Tue Apr 6 03:31:04 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11647 (5.65c/IDA-1.4.4 for ); Tue, 6 Apr 1993 13:33:17 -0400 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA25959 (InterLock SMTP Gateway 1.1 for ); Tue, 6 Apr 1993 13:33:19 -0400 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 AA10092; Tue, 6 Apr 1993 12:34:09 -0500 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 AA01660; Tue, 6 Apr 1993 12:34:06 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA11607; Tue, 6 Apr 93 10:33:01 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA00548; Tue, 6 Apr 1993 10:33:35 MST Message-Id: <00112.2816937215.548@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: Tue, 6 Apr 1993 10:31:04 MST Subject: ISO/IEC JTC1/SC6 Subject: ISO/IEC JTC1/SC6 Message: From INTERNET FWD> Report from London SC6 For your information ... a report on recent SC6 work on lower layer security is attached. Note that comments to ANSI on NLSP are due in April. Paul --------------------------------------------------------- Date: 30 Mar 1993 10:51:15 -0500 (EST) From: walters@osi.ncsl.nist.gov (Dale L. Walters) Subject: Re: Report from London To: /PN=JOHN.WHEELER/O=OMNET/ADMD=TELEMAIL/C=US/@sprint.com Cc: x3s33@merit.edu Message-Id: <9303301551.AA02725@osi.ncsl.nist.gov> Content-Transfer-Encoding: 7BIT Report of the Interim Meeting of ISO/IEC JTC1/SC6 Lower Layer Security London 8-12 February 1993 A. General The interim meeting of SC6 Working Groups (Lower Layer Security) was held at BSI in London on 8-12 February. Mr. Richard Thomas (BNR, Canada) presided over this meeting. The minutes of this meeting are contained in document SC6 N7962. B. U.S. Delegates Dale Walters (NIST) Steve Sherman (Hughes) C. Recommendations The following resolutions were all unanimously approved at a joint WG1, WG2, and WG4 plenary. 1) The Lower Layer Security Model (This had been called a Guidelines document prior to this meeting) has been registered as a PDTR (type 3) as authorized by the SC6 San Diego resolution #108. This is a three month ballot. The US comments concerning LAN security were incorporated into this revised version. 2) Five documents were circulated to SC6 member bodies with comments due by July 30, 1993. a) N7953 Use of NILS with NLSP-CO b) N7954 Application of generic abstract security interface for both TLSP and NLSP c) N7955 A contribution capturing the ad hoc groups understanding of Protection Qos as it relates to security policy d) N7956 A Lan security requirements document requesting comments on whether the LAN security protocol (developed by IEEE) or NLSP should be used to protect LAN data. e) A US contribution on managed objects for NLSP and TLSP 3) A liaison statement to CCITT was sent stating that since the NLSP and TLSP amendment ballots will not close before the next CCITT meeting, SC6 proposes that the joint publishing schedule for these two documents be postponed until early 1994. 4) Three liaison contributions were sent to other ISO committees. a) N7958 A document concerning Security of OSI Systems Management was forwarded to SC21/WG4. b) N 7960 A document concerning Security information objects was forwarded to SC27/WG1. c) N7961 A document concerning QoS, Definition of the security abstract interface, and OSI Reference Model was forwarded to SC21/WGs 1 and 8. D. U.S.Positions There were no cases in which the Lower Layer Security ad hoc group approved a recommendation that did not agree with the U.S. position on the corresponding subject. E. Actions Required by X3S3. X3S3 will be requested to review and approve proposals from its task groups for responses to the security issues identified in the above mentioned documents plus the ballot comments on DIS NLSP and the DAM 1 to TLSP. The two ballot responses will be handled at the next X3S3.3 meeting in late April with the other documents handled in time for the next SC6 meeting. F. This report prepared and submitted by Dale Walters on 30 March 1993. From dee@ranger.enet.dec.com Wed Apr 7 13:14:38 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07402 (5.65c/IDA-1.4.4 for ); Wed, 7 Apr 1993 17:48:46 -0400 Received: from inet-gw-2.pa.dec.com by interlock.ans.net with SMTP id AA09784 (InterLock SMTP Gateway 1.1 for ); Wed, 7 Apr 1993 17:46:46 -0400 Received: by inet-gw-2.pa.dec.com; id AA18027; Wed, 7 Apr 93 14:47:07 -0700 Received: by us1rmc.bb.dec.com; id AA20698; Wed, 7 Apr 93 17:06:32 -0400 Message-Id: <9304072106.AA20698@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Wed, 7 Apr 93 17:14:38 EDT Date: Wed, 7 Apr 93 17:14:38 EDT From: "Donald E. Eastlake 3rd (LJO2/I4, +1 508 486 2358) 07-Apr-1993 1708" To: paul_lambert@poncho.phx.sectel.mot.com Cc: ipsec@ans.net Apparently-To: ipsec@ans.net, paul_lambert@poncho.phx.sectel.mot.com Subject: RE: Updated IPSEC Charter I'm sorry I couldn't make it to IETF in Columbus. Attending the IPSEC meeting would have been one of my highest priorities. It is my impression that a variety of proposals and implementation experiences were going to be presented and I hope that minutes can be distributed relatively soon. The main write up below looks good. I think the schedule needs to be moved into the future. See questions with schedule. In general, it seems to me that there has been very little traffic on the working group mailing list. I don't know if this is because little is happening or because it is mostly being done person-to-person or in small subgroups within the WG. I would urge people to post more material, including "incomplete" or "pre-draft" material to the working group list to get earlier feedback. Donald -------------- From: US1RMC::"Paul_Lambert@poncho.phx.sectel.mot.com" "Paul Lambert" 28- MAR-1993 22:20 To: ipsec@ans.net (ip security mailing list) Subj: 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. >What is the status of this? Mar 93 Review pilot experiments with cryptographic network security. >What is the status of this? Mar 93 Post as an Internet-Draft a preliminary version of the IP Security Protocol that supports host-to-host security. >Do people believe there is a consensus on the above yet? I sure haven't seen >any detailed discussion. 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. >What is the status of all this? Mar 93 Establish baseline goals and starting points for Internet Key Management. >What is the status of this? 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. From dee@skidrow.ljo.dec.com Thu Apr 8 18:56:18 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12767 (5.65c/IDA-1.4.4 for ); Thu, 8 Apr 1993 14:53:43 -0400 Received: from inet-gw-2.pa.dec.com by interlock.ans.net with SMTP id AA11512 (InterLock SMTP Gateway 1.1 for ); Thu, 8 Apr 1993 14:54:03 -0400 Received: by inet-gw-2.pa.dec.com; id AA06198; Thu, 8 Apr 93 11:54:32 -0700 Received: by skidrow.ljo.dec.com (5.57/fma-100391/rcb-930105) id AA28311 for ipsec@ans.net; Thu, 8 Apr 93 14:56:18 -0400 Message-Id: <9304081856.AA28311@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: Domain Names WG Cc: IP Secrity WG , Beast (Donald E. Eastlake,III) Subject: DNS Security Date: Thu, 08 Apr 93 14:56:18 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp Hello, I am writing to strongly urge that the DNS Working Group formulate its security requirements and provide them as input to the IP Security Working Group. This is motivated by two concerns: (1) I am concerned by the ever growing number of different cryptographic security protocols in the IP protocol suite. Certainly I do not think that a single protocol could cover all requirements. For example, e-mail security has many special considerations and its traffic extends well beyond the IP Internet so it is reasonable that its needs are different from those of TELNET, for example. But do TELNET and FTP and NNTP and DNS and NFS and NTP and so on, seemingly without limit, all require the addition of a specially crafted security protocol, new commands, etc.? The IPSEC WG is concentrating initially on host-to-host network level security which seems to fit the bill exactly for DNS. In fact, DNS to me to be a relatively simple case where hosts are the parties of interest and possible questions of identifying individual users are the like do not complicate things. (2) I am concerned that there may be a lack of attention in the IPSEC WG to requirements related to sporadic datagram traffic, such as UDP DNS queries, ICMP redirects from routers, etc. The IPSEC WG seems to be concentrating mainly on proposals patterned after "connection oriented" ISO protocols. By this I do not mean that the proposals will only work for a connection protocol like TCP but rather that they always require set-up, critical state at both ends, and tear down, even if all you are tying to do is push through one secure datagram. I believe an IP network level security protocol should have efficient ways of handling isolated datagram traffic, including DNS transactions, router originated ICMPs or various sorts, etc. Even if there have to be "two protocols", one for isolated datagram traffic and one for more connection like continuous traffic between hosts (or subnets), it would be good to consider them simultaneously to maximize their alignment. I believe consideration of the DNS security requirements by the IPSEC WG would be beneficial to both and now is the time for requirements to be fed into the IPSEC working group. Donald PS: I have sent mail to namedroppers-request asking to be added to the DNS WG mailing list but don't know just when this will happen. In the mean time please CC me. *+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+- Donald E. Eastlake, III 1-508-486-2358(w) dee@skidrow.ljo.dec.com PO Box N, MIT Branch PO dee@ranger.enet.dec.com Cambridge, MA 02139 USA 1-617-244-2679(h) From zmuda@mls1.hac.com Thu Apr 8 07:35:51 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14512 (5.65c/IDA-1.4.4 for ); Thu, 8 Apr 1993 17:39:52 -0400 Received: from hac2arpa.hac.com by interlock.ans.net with SMTP id AA24841 (InterLock SMTP Gateway 1.1 for ); Thu, 8 Apr 1993 17:38:39 -0400 Received: from mls1.HAC.COM ([147.19.21.53]) by hac2arpa.hac.com (4.1/SMI-DDN) id AA25483; Thu, 8 Apr 93 14:38:43 PDT Received: by mls1.HAC.COM (4.1/SMI-4.0) id AA07856; Thu, 8 Apr 93 14:35:51 PDT Date: Thu, 8 Apr 93 14:35:51 PDT From: zmuda@mls1.hac.com (Jim Zmuda) Message-Id: <9304082135.AA07856@mls1.HAC.COM> To: dee@skidrow.ljo.dec.com Subject: Re: DNS Security Cc: ipsec@ans.net Don, You raise a number of interesting issues. I wholeheartedly agree with the notion of defining one protocol to provide security transparently for many client protocols, rather than have each application protocol provide his own security mechanisms, excluding, of course, E-mail. But I disagree with your assertion that the IPSEC WG is "concentrating mainly on proposals patterned after 'connection oriented' ISO protocols." Actually, I disagree with your assertion that the ISO security protocols that have been discussed in the IPSEC WG "...always require set-up, critical state at both ends, and tear down, even if all you are trying to do is push through one secure datagram." In fact, the security protocols as such are simply encapsulation protocols, and any mechanism may be utilized to establish the shared keying material at both ends, which may include sending it in the clear header as the value (or a permutation of the value - there was a gentleman from DEC at the last meeting who used just such a method) of the Security Association Identifier (conceptually, this field contains an identifier that identifies the particular "Security Association" (Key and Attributes) that needs to be referenced to understand this PDU), or using a previously established Security Association of long standing (yes, a separate set-up step in thus required, but comparing this, as you did, with the overhead of a communications association establishment is misleading, since the set-up exchange required for establishing a communications association is required each time communications is initiated, whereas the security association may be left in place for a long, long time....thus "tear-down" may also not be necessary...) In conclusion, I think the requirements that you have brought up will have to be considered. But I don't think they impact the Security Protocol that much (perhaps they require a different interpretation of he SAID field), rather I think they have to be kept in mind as we try to settle upon a key management and authentication scheme. (Perhaps we should insure that we can prepare long lived keying material?) I would firmly hope they don't entail developing another, separate security protocol. Anyway, you brought up some good issues to keep in mind. I think we should add these to the list of requirements* from the last meeting that we are supposed to be coming to closure on. Jim Zmuda * Has anyone got the complete list from the last meeting? I got the following down: * Clear Header - Security Association Identifier - PID (Issue for debate!) * basing formats on NLSP (a rancorous issue for debate!) * Sequence integrity (swIPe has, NLSP-CL doesn't. Almost agreed to drop. Still an "issue" for E-mail debate.) * Fragmentation. (We all agree to not handle within the security protocol. Not needed for ES implementation.) * "peak through" (filtering routers problem) * Word alignment (needed for efficient implementation of some upper layer protocols, like NFS.) * Padding * ICV * works with CLNP, as well as IP * Overhead * efficiency * Encipherment * key Managment * Negotiation of services and Don's requirement * support infrequent, isolated "connectionless application" traffic efficiently etc..... From ho@cs.arizona.edu Thu Apr 8 07:57:38 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07691 (5.65c/IDA-1.4.4 for ); Thu, 8 Apr 1993 17:56:47 -0400 Received: from optima.CS.Arizona.EDU by interlock.ans.net with SMTP id AA11145 (InterLock SMTP Gateway 1.1 for ); Thu, 8 Apr 1993 17:56:51 -0400 Received: from umbra.CS.Arizona.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA24070; Thu, 8 Apr 1993 14:57:39 MST Date: Thu, 8 Apr 1993 14:57:38 MST From: "Hilarie Orman" Message-Id: <199304082157.AA17312@umbra.cs.arizona.edu> Received: by umbra.cs.arizona.edu; Thu, 8 Apr 1993 14:57:38 MST To: dee@skidrow.ljo.dec.com Cc: namedroppers@nic.ddn.mil, ipsec@ans.net In-Reply-To: Your message <9304081856.AA28311@skidrow.ljo.dec.com> Subject: Re: DNS Security While applauding the call for consolidation of security services into appropriate layers, I think I see a counter-argument to the need to feed datagram security requirements into the IP layer. The services themselves can easily be configured to use host-to-host signed, private datagrams that provide the authentication required for securing their services. Perhaps they would share some sort of certificate or key information with the IP layer, but there is no need to be dependent on the IP layer itself for security. In fact, it is somewhat awkward to do this, because some services will accept requests (reads) from any host, but accept changes (writes) only from a trusted subset. Upon receiving a datagram, they might have to query the IP layer as to its provenance --- was this an authenticated datagram or not? Hilarie Orman From dee@skidrow.ljo.dec.com Fri Apr 9 17:55:40 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09437 (5.65c/IDA-1.4.4 for ); Fri, 9 Apr 1993 14:26:09 -0400 Received: from inet-gw-2.pa.dec.com by interlock.ans.net with SMTP id AA40081 (InterLock SMTP Gateway 1.1 for ); Fri, 9 Apr 1993 14:19:31 -0400 Received: by inet-gw-2.pa.dec.com; id AA01436; Fri, 9 Apr 93 10:53:52 -0700 Received: by skidrow.ljo.dec.com (5.57/fma-100391/rcb-930105) id AA01477 for ipsec@ans.net; Fri, 9 Apr 93 13:55:40 -0400 Message-Id: <9304091755.AA01477@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: "Hilarie Orman" Cc: dee@skidrow.ljo.dec.com, namedroppers@nic.ddn.mil, ipsec@ans.net Subject: Re: DNS Security In-Reply-To: Your message of "Thu, 08 Apr 93 14:57:38 MST." <199304082157.AA17312@umbra.cs.arizona.edu> Date: Fri, 09 Apr 93 13:55:40 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp Hilarie, You are correct in that one argument I can see for doing security services in a protoocol above the IP layer is that you can make use of them without requiring an update of or more interfaces with the IP layer. However, this still requires that the other party you are talking protocol x with (say ftp for an example) updates. If you want secure ftp between machine h1 and h2, is it more likely that you have an updated ftp server and client for those machines with a special ftp security protocol or is it more likely that they both have an updated IP? It's hard to say in general but sooner or later I think the proliferation of higher level security protocols will slow down and more and more dependence will be put on al IP level protocol. Note that, when this happens, (1) further implementations of the higher level protocol security (ie, ftp security) will slow down or cease and (2) you will then be faced with adding links to the IP level security to ftp implementations resulting in two distinct sets of secruity services in your ftp. This sort of duplication and confusion points to dropping additional higher level services and concentrating on IP security unless there is a very good reason to add the particular higher level security service. The IP security protocol (IPSP) will no doubt be used in many ways. On would be to secure all or almost all of the packets coming in or out of a host (or subnet, etc.). This could have the effect of carving out a private net where users could not communicate outside a limited circle. But I think more commonly the facilties will be available and the security services needed (authentication and/or encryption and/or time stamps and/or etc.) will be requested as needed by applications and the services used by a remote sender will be flagged and provided to higher level protocols on unsolicited incoming packets. Certainly some services, like DNS, are mostly happy to respond to anyone's UDP request packet coming in. But I think that many users of DNS services would like authenticated responses so they can't be spoofed. There are also places that prohibits zone transfers to "outsiders" for security reasons who would like authentication and maybe even encryption of such transfers. And if you permited update transactions to change the DNS database, you would certainly want authentication. So yes, there are many cases where you would want to act differently depending on the security services that were provided with an incoming datagram. But that is no reason to duplicate those services in every protocol above raw IP. Communication between the higher levels and IP, which exists now, will just have to be slightly expaned. Donald From: "Hilarie Orman" In-Reply-To: Your message <9304081856.AA28311@skidrow.ljo.dec.com> >While applauding the call for consolidation of security services into >appropriate layers, I think I see a counter-argument to the need to >feed datagram security requirements into the IP layer. The services >themselves can easily be configured to use host-to-host signed, >private datagrams that provide the authentication required for >securing their services. Perhaps they would share some sort of >certificate or key information with the IP layer, but there is no need >to be dependent on the IP layer itself for security. In fact, it is >somewhat awkward to do this, because some services will accept >requests (reads) from any host, but accept changes (writes) only from >a trusted subset. Upon receiving a datagram, they might have to query >the IP layer as to its provenance --- was this an authenticated >datagram or not? > Hilarie Orman From atkinson@tengwar.itd.nrl.navy.mil Wed Apr 14 18:41:43 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07379 (5.65c/IDA-1.4.4 for ); Wed, 14 Apr 1993 14:41:56 -0400 Received: from tengwar.itd.nrl.navy.mil by interlock.ans.net with SMTP id AA29433 (InterLock SMTP Gateway 1.1 for ); Wed, 14 Apr 1993 14:40:49 -0400 Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA11187; Wed, 14 Apr 93 14:41:43 -0400 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9304141441.ZM11185@tengwar.itd.nrl.navy.mil> Date: Wed, 14 Apr 1993 14:41:43 -0400 In-Reply-To: zmuda@mls1.hac.com (Jim Zmuda) "Re: DNS Security" (Apr 8, 14:35) References: <9304082135.AA07856@mls1.HAC.COM> Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: ipsec@ans.net Subject: Re: IPv4 Security On Apr 8, 14:35, Jim Zmuda wrote: [ much stuff deleted ] * basing formats on NLSP (a rancorous issue for debate!) I think there are a fair number of us who have real problems with ISO OSI syntax and format conventions. One of the major advantages of the Internet suite has been its streamlined syntax. Several of the IP:TNG proposals (e.g. SIP, PIP) have been streamlining things even more than IPv4. Note that I distinguish "syntax/format" from "mechanism". I would also assert that before we could even decide on NLSP mechanisms, we would need someone to write a "plain English" version of the NLSP specification and discuss it based on that readable document. NLSP is not at all readable even to people who understand SP3 fairly well. * works with CLNP, as well as IP This is most certainly NOT a requirement for me. My GOSIP transition plan is from IPv4 to IP:TNG only. I think this is unduly restrictive and it isn't clear to me that there was consensus that this was a requirement. It is clear that ISO will be using NLSP and the IETF should avoid trying to compete with ISO on protocols owned by ISO. I think that there was consensus that the IPSP needed to be scalable such that it would work reasonably well over low bandwith links (e.g. dialup IP) all the way through higher bandwidths such as Gigabit networks currently in research and development (e.g. ATM at OC-48). I would very much like to see a full spec for swIPe made available as an Internet Draft or by some other similar mechanism. I would like to see consideration of SDNS KMP for the basis of key management protocol development. Is there an electronic copy of the KMP spec that could be made available somewhere ? Regards, Ran atkinson@itd.nrl.navy.mil From tytso@Athena.MIT.EDU Wed Apr 14 21:04:20 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07953 (5.65c/IDA-1.4.4 for ); Wed, 14 Apr 1993 17:03:53 -0400 Received: from Athena.MIT.EDU (ATHENA-AS-WELL.MIT.EDU) by interlock.ans.net with SMTP id AA17942 (InterLock SMTP Gateway 1.1 for ); Wed, 14 Apr 1993 17:03:30 -0400 Received: from SOS.MIT.EDU by Athena.MIT.EDU with SMTP id AA08160; Wed, 14 Apr 93 17:04:22 EDT Received: by SOS (5.57/4.7) id AA17438; Wed, 14 Apr 93 17:04:20 -0400 Date: Wed, 14 Apr 93 17:04:20 -0400 From: Theodore Ts'o Message-Id: <9304142104.AA17438@SOS> To: ipsec@ans.net In-Reply-To: Ran Atkinson's message of Wed, 14 Apr 1993 14:41:43 -0400, <9304141441.ZM11185@tengwar.itd.nrl.navy.mil> Subject: Re: IPv4 Security Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Date: Wed, 14 Apr 1993 14:41:43 -0400 > * works with CLNP, as well as IP > > This is most certainly NOT a requirement for me. My GOSIP > transition plan is from IPv4 to IP:TNG only. I think this is unduly What does this requirement *mean*? Does it mean that whatever mechanism which comes out of the IPSEC wg has to be byte-for-byte identical to whatever security protocol CLNP uses? If so, then the requirements have basically been rigged so that the only possible answer is NLSP, despite whatever other advantages or disadvantages it might have. Or does it mean that there has to be a way to build gateways that can interoperate between the IP and CLNP security protocols? I would think that it should be the latter, since if you're going to interoperate, there will have to be a gateway that strips off the IP header and stick on a CLNP header --- all you'd need to do is have that gateway translate the IPSEC header to a NLSP header as well. Sure, this might not work at ATM speeds, but as Ran pointer out at the wg meeting, NLSP doesn't work ATM speeds anyway. (because of its use of TLV encoding, I believe). - Ted From zmuda@mls1.hac.com Mon Apr 19 07:33:11 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA08598 (5.65c/IDA-1.4.4 for ); Mon, 19 Apr 1993 20:27:23 -0400 Received: from hac2arpa.hac.com by interlock.ans.net with SMTP id AA22300 (InterLock SMTP Gateway 1.1 for ); Mon, 19 Apr 1993 20:23:27 -0400 Received: from mls1.HAC.COM ([147.19.21.53]) by hac2arpa.hac.com (4.1/SMI-DDN) id AA27686; Mon, 19 Apr 93 17:23:37 PDT Received: by mls1.HAC.COM (4.1/SMI-4.0) id AA23817; Mon, 19 Apr 93 14:33:11 PDT Date: Mon, 19 Apr 93 14:33:11 PDT From: zmuda@mls1.hac.com (Jim Zmuda) Message-Id: <9304192133.AA23817@mls1.HAC.COM> To: atkinson@tengwar.itd.nrl.navy.mil Subject: Re: IPv4 Security Cc: ipsec@ans.net All, On Apr 14, 14:41, Randall Atkinson wrote in reply to an earlier message of mine. In his message Ran took exception to a couple of the requirements for IPSP that I had listed in my message. The requirements that Ran took exception to were: 1. >>* basing formats on NLSP (a rancorous issue for debate!) > > I think there are a fair number of us who have real problems with >ISO OSI syntax and format conventions. One of the major advantages of >the Internet suite has been its streamlined syntax... NLSP formats are not really all that bad. Any protocol that can be described in one viewgraph*, as NLSP can, can't be that overly complex. I agree with you, the real problem with the NLSP spec is that it is written in ISOese and not plain english. However, we shouldn't let that color acceptance of the protocol if it, in fact, is useful. As far as the inefficiencey of TLV encoded fields goes, most of the NLSP fields are fixed format. In fact, if we do some reasonable profiling (limit PDU lengths to 30,000 bytes or less) we find that the first 14 bytes (excluding the Sync overhead in this count) of the NLSP header are fixed format (including the Clear Header, and up through the Data Type byte of the Protected Contents). TLV encoded fields are used only to encode the address fields, label field, data field (a mistake, I'll grant that - which I'm working to change), and pad field. Depending upon how we profile the NLSP-CL, we could eliminate the address fields. (They are implicit in the use of a particular association, and therefore add no value). This leaves the label fields, data, and pad as TLV encoded. I maintain that any approach that allows explicit labels to be carried is likely to end up with a TLV encoded value for its label field as well. Witness the IPSO. Therefore the delta in terms of encoding format is minimal. In short, NLSP-CL really isn't that bad, once you profile out the useless parts. 2. >>* works with CLNP, as well as IP > > This is most certainly NOT a requirement for me. My GOSIP >transition plan is from IPv4 to IP:TNG only. I think this is unduly >restrictive and it isn't clear to me that there was consensus that >this was a requirement... Well, the idea of putting this on the list was to find out if it was desirable to include this as a requirement. Please note that this requirement doesn't imply that we choose the same protocol as the ISO folks, but just that whatever we do can be made to work in the ISO world - and I do recall a consensus being reached that this was a requirement - explicitely that whatever we do now not will not have to be redone when IP:TNG comes along. If one includes the possibility that that could be CLNP, then one has to include the capability to grow to CLNP...things which NLSP's Protocol ID byte, and TLV-encoded address fields directly support. And unfortunately, it is not a simple matter of just slapping on a convergence protocol containing a PID in front of IPSP, because that would screw up word orientation for upper level protocols - something you don't want to do, even in this context (apparently byte-oriented network layer protocol). Finally, my intent in putting forward the list of requirements from the IPSEC WG meeting was to get the ball rolling on coming to closure as a group on the set of requirements that we thought should be addressed by IPSP. Achieving a consensus on the requirements for IPSP first (before moving to a discussion of formats and implementations) is a good place to start, for the obvious reason, as well as the fact that it looks like we wouldn't get far with any other approach. My list of the requirements I thought (and still do) we had agreed to review for inclusion in IPSP looked like this: * Clear Header - Security Association Identifier - PID (Issue for debate!) * basing formats on NLSP (a rancorous issue for debate!) * Sequence integrity (swIPe has, NLSP-CL doesn't. Almost agreed to drop. Still an "issue" for E-mail debate.) * Fragmentation. (We all agree to not handle within the security protocol. Not needed for ES implementation.) * "peak through" (filtering routers problem) * Word alignment (needed for efficient implementation of some upper layer protocols, like NFS.) * Padding * ICV * works with CLNP, as well as IP * Overhead * efficiency (including emphasis on compact encoding suitable for low-speed links) * Encipherment * key Managment * Negotiation of services I'd add one: * Explicit per PDU labelling/versus implicit labelling Regards, Jim Zmuda *I regret not handing out my slides From nmh@thumper.bellcore.com Mon Apr 19 17:29:24 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06242 (5.65c/IDA-1.4.4 for ); Mon, 19 Apr 1993 21:42:27 -0400 Received: from thumper.bellcore.com by interlock.ans.net with SMTP id AA25158 (InterLock SMTP Gateway 1.1 for ); Mon, 19 Apr 1993 21:39:07 -0400 Received: from latour.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ipsec@ans.net; Mon, 19 Apr 93 21:29:24 EDT Received: by latour.bellcore.com (4.1/4.7) id for ipsec@ans.net; Mon, 19 Apr 93 21:29:24 EDT Date: Mon, 19 Apr 93 21:29:24 EDT From: nmh@thumper.bellcore.com (Neil Haller) Message-Id: <9304200129.AA22018@latour.bellcore.com> To: ipsec@ans.net Subject: Re: IPv4 security I can't see any reason to include basing formats on NLSP as a requirement. If it works out that the NLSP formats are best, fine. If not, that's fine too. My view is we should start with swIPe and go from there. Neil Haller From atkinson@tengwar.itd.nrl.navy.mil Tue Apr 20 01:31:13 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04342 (5.65c/IDA-1.4.4 for ); Mon, 19 Apr 1993 22:06:05 -0400 Received: from tengwar.itd.nrl.navy.mil by interlock.ans.net with SMTP id AA24468 (InterLock SMTP Gateway 1.1 for ); Mon, 19 Apr 1993 22:03:20 -0400 Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA25283; Mon, 19 Apr 93 21:31:13 -0400 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9304192131.ZM25281@tengwar.itd.nrl.navy.mil> Date: Mon, 19 Apr 1993 21:31:13 -0400 In-Reply-To: zmuda@mls1.hac.com (Jim Zmuda) "Re: IPv4 Security" (Apr 19, 14:33) References: <9304192133.AA23817@mls1.HAC.COM> Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: ipsec@ans.net Subject: Re: IPv4 Security It isn't clear to me that Jim's claims about NLSP having streamlinable syntax are clearly substantiated and supported technically. I do understand that Hughes has significant investment in an existing NLSP product and that it is in Hughes financial interest to influence this group to adopt an IPSP that looks a whole lot like NLSP. Fortunately, we in the IETF can ignore such political concerns and focus more on the technical problem. My suggestion would be that Jim write up an Internet Draft describing in detail what his proposed "NLSP Profile" would look like, including a readable English-language description of the whole protocol. Then post that I-D to this list. If we had such an item, then we could better focus our technical discussions. For that matter, we need a detailed online specificaton of swIPe as well so we can evaluate alternatives. If someone has an electronic copy of SP3-D, that would also be useful to post. I disagree with the assertion that using IPSP and a very thin convergence protocol won't work with CLNP. It should work fine and have no worse performance than regular NLSP already has with its horrible-to-parse syntax. Word alignment is the least of the problems that NLSP faces. From hallway conversations, I understand that some vendors have been told by a part of the US Government that they should be implementing NLSP for the government market. Let me just say that I really really personally believe that the de facto government demand for an IPSP product will greatly exceed demand for an NLSP product. Most of the government (including the US Navy) is heavily invested in IPv4 and is unlikely to move quickly towards anything beginning with "ISO OSI" or "GOSIP". This is not official policy, but it is my personal evaluation of reality. People planning to sell products and make money doing so would be wise to pay due attention to reality. I pay attention to reality because I'm paid to help ensure that real Navy communications technology needs are met. :-) :-) Regards, Ran atkinson@itd.nrl.navy.mil From Paul_Lambert@poncho.phx.sectel.mot.com Mon Apr 19 04:02:38 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04344 (5.65c/IDA-1.4.4 for ); Tue, 20 Apr 1993 03:33:18 -0400 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA05073 (InterLock SMTP Gateway 1.1 for ); Tue, 20 Apr 1993 03:30:09 -0400 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 AA03963; Mon, 19 Apr 1993 13:15:51 -0500 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 AA06986; Mon, 19 Apr 1993 13:15:43 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA03394; Mon, 19 Apr 93 11:13:31 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA32913; Mon, 19 Apr 1993 11:15:33 MST Message-Id: <00112.2818062933.32913@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: Mon, 19 Apr 1993 11:02:38 MST Subject: FWD>I-D on Security Questio From INTERNET FWD>I-D on Security Questions f FYI, Here's a cross posting from saag & big-internet. My appologies to those who've already seen this before. Paul ----- Begin Included Message ----- From saag-interest-request@sleepy.TIS.COM Mon Apr 19 07:47:30 1993 From: Ran Atkinson Date: Mon, 19 Apr 1993 10:37:56 -0400 Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: saag-interest@tis.com, big-Internet@munnari.oz.au Subject: I-D on Security Questions for IP:TNG Content-Length: 8333 At the Columbus IETF meeting, I was volunteered to write up an Internet Draft on security questions and issues relating to the various IP: The Next Generation proposals. I apologise for the delay in posting this draft. I would like to actively solicit corrections/additions/clarifications for this document. The document is being cross-posted between the SAAG-Interest list and the big-Internet list in an effort to obtain wider review of this draft. I probably won't actually put this draft out for ftp until people have had some chance to comment on the (probably numerous) deficiencies in this version. TRUTH IN ADVERTISING: I've been doing some examination of how ISO NLSP and SP3 might be adapted to secure the SIP/IPv6 proposal using mechanisms very similar to those being discussed for the IPv4 Security Protocol. I think I've been proposal-neutral in this draft, but if you think bias is showing, please tell me about it... Ran atkinson@itd.nrl.navy.mil ----- Network Working Group Randall Atkinson Request for Comments: DRAFT Naval Research Laboratory April 1993 Security Questions for IP: The Next Generation Proposals Status of this Memo This RFC is being distributed to members of the Internet SAAG in order to solicit their corrections and enhancements of this internet-draft. The goal of this memo is to help focus the discussions of the security-related features of each of the proposals for next generation IP. INTRODUCTION There are several existing proposals for a follow-on protocol to replace the current version of IP (IP version 4). These are all somewhat different and it would be nice if the Internet community could find some rational way to evaluate and compare those proposals before any one of them were selected. Craig Partridge and Frank Kastenholz have circulated an Internet Draft that describes some "Criteria for Choosing IP Version 7". [IPv7-ID] Their draft includes some security-related questions but was intended to be a general set of criteria rather than specific to any technical area. Some people believe that it would be helpful to come up with a more specific and detailed list of critera for next generation IP (IP:TNG). This Internet Draft attempts to list such security-related criteria and is being circulated for comment, correction, and enhancement by others who are interested in network security issues. SECURITY PROPERTIES There are several security properties which are desirable in any internetwork or distributed system. Among these properties are integrity, authentication, and confidentiality. It is important that each IP:TNG proposal be able to provide these properties to users who desire to use them. Ideally, such support should not be limited to a single transmission mode (e.g. unicast) but should support all transmission modes (e.g. multicast and broadcast). It should be possible to protect not only the user data being transported, but also the network control information and header information. If this latter kind of information cannot be protected adequately, the kinds of Atkinson [Page 1] Internet Draft April 1993 problems identified by Bellovin [Bellovin89, also see Kent89] and others will continue to plague the Internet. There are several specific questions which are posed in an effort to clarify the security properties provided by each proposal. These questions include: Which security properties are provided in normal operation of the proposal ? Which additional security properties are available to users who desire enhanced security ? Which security properties are normally provided to related critical protocols such as the Domain Name System, ICMP, and routing protocols ? Are there other optional or enhanced security properties that are provided with this proposal ? If so, please describe them. SECURITY MECHANISMS The above properties must be provided by some set of security mechanisms. In order to evaluate the effectiveness and quality of the security provided, it is important to understand which mechanisms have been used and how they fit in with the protocol. To clarify this, the following questions are proposed: What mechanisms are there to provide users with enhanced security in the proposed protocol ? What mechanisms are in place to adequately protect ICMP or its equivalent and what properties are provided by those mechanisms ? What mechanisms are in place to provide authentication and integrity to other critical protocols (e.g. Domain Name System, Routing protocols) ? Are the above mechanisms different for each protocol or is there a common mechanism used with all protocols ? How is an end system or intermediate system uniquely identified (e.g. IPv4 address) ? How are those identifiers administered ? Atkinson [Page 2] Internet Draft April 1993 If any cryptological mechanisms are used, are they algorithm independent ? If any cryptological mechanisms are used, how are keys managed ? How does host mobility affect use of the above mechanisms ? If IP:TNG supports information "flows" across the internetwork, what provisions are made to ensure that any reserved resources are reasonably available to the flows making those reservations ? What are the other security considerations,if any, with this IP:TNG proposal ? IPv4 COMPATIBILITY It is desirable that the IP:TNG security mechanisms not interfere with the IPv4 security mechanisms during the transition period from IPv4. This is important because it is highly unlikely that there will be a "flag day" where all sites convert to exclusive use of the new protocol from IPv4. Ideally it would be possible to provide security over a connection from an IP:TNG host to an IPv4 host in a manner compatible with the IPv4 host and compatible with the backwards compatibility mechanism proposed for the transition period. It is also desirable to reuse mechanisms from IPv4 to IP:TNG where that is practical and does not impair either security or operational utility. How similar are the IP:TNG security mechanisms to the various proposals for the IPv4 Security Protocol (e.g. NIST's SP3, ISO NLSP, swIPe) ? Is the IP:TNG security mechanism compatible with any of the proposed starting points for the IPv4 Security Protocol (if so, which) ? Is the security mechanism used for IPv4-compatibility also compatible with pure IP:TNG systems? Is it possible for a host only capable of using IP:TNG to securely communication with a host only capable of using IPv4 ? If so, how does this work ? SECURITY CONSIDERATIONS Security considerations are discussed throughout this memo. Atkinson [Page 3] Internet Draft April 1993 REFERENCES [Bellovin89] Steve Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Volume 19, Number 2, March 1989. [ISO-NLSP] ISO/IEC, ISO OSI Network Layer Security Protocol, ISO DIS 11577, November 1992. [Kent89] Steve Kent, "Comments on 'Security Problems in the TCP/IP Protocol Suite'", ACM Computer Communications Review, Volume 19, Number 3, July 1989. [IPv7-ID] Craig Partridge & Frank Kastenholz, Criteria for Choosing IP Verson 7 (IPv7), Internet Draft (work in progress), 14 December 1992. [SDNS90] Charles Dinkel (ed.), Secure Data Network System (SDNS) Network, Transport, and Message Security Protocols, NIST IR 90-4250, NIST, Gaithersburg, MD. February 1990. [swIPe] ...TBD... Author's Address: Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375 Atkinson [Page 4] ----- End Included Message ----- From atkinson@tengwar.itd.nrl.navy.mil Tue Apr 20 16:53:23 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09757 (5.65c/IDA-1.4.4 for ); Tue, 20 Apr 1993 13:06:51 -0400 Received: from tengwar.itd.nrl.navy.mil by interlock.ans.net with SMTP id AA21466 (InterLock SMTP Gateway 1.1 for ); Tue, 20 Apr 1993 13:03:20 -0400 Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA25604; Tue, 20 Apr 93 12:53:23 -0400 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9304201253.ZM25602@tengwar.itd.nrl.navy.mil> Date: Tue, 20 Apr 1993 12:53:23 -0400 In-Reply-To: zmuda@mls1.hac.com (Jim Zmuda) "Re: IPv4 Security" (Apr 19, 14:33) References: <9304192133.AA23817@mls1.HAC.COM> Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: ipsec@ans.net Subject: Re: IPv4 Security redux On Apr 19, 14:33, Jim Zmuda wrote: > Subject: Re: IPv4 Security % Well, the idea of putting this on the list was to find out if it was % desirable to include this as a requirement. Please note that this % requirement doesn't imply that we choose the same protocol as the ISO % folks, but just that whatever we do can be made to work in the ISO % world - and I do recall a consensus being reached that this was a % requirement - explicitely that whatever we do now not will not have to % be redone when IP:TNG comes along. If one includes the possibility % that that could be CLNP, then one has to include the capability to % grow to CLNP...things which NLSP's Protocol ID byte, and TLV-encoded % address fields directly support. And unfortunately, it is not a % simple matter of just slapping on a convergence protocol containing a % PID in front of IPSP, because that would screw up word orientation for % upper level protocols - something you don't want to do, even in this % context (apparently byte-oriented network layer protocol). Let me briefly revisit the above. In particular, using NLSP syntax favours one of the IP:TNG proposals at the expense of the other proposals. This is not a legitimate thing to do -- we must be careful to be proposal-neutral with respect to IP:TNG. A convergence protocol WILL work fine for NLSP. Adding PIDs and such ISO-centric items to the IPv4 Security Protocol is biasing towards ISO and against not only IPv4 but also the other IP:TNG proposals (e.g. SIP, which uses a payload-pointer scheme). I think that reuse of the IPv4 Security Protocol work for IP:TNG should be limited in scope to the mechanisms and not include syntax reuse because several of the IP:TNG streamline syntax even more from the IPv4 syntax (which is a WHOLE LOT easier to parse than ISO syntax). I really thought we had agreed to mechanism-reuse rather than syntax-reuse during the Ohio meeting. ISO-centric items such as PIDs are syntactic glue rather than being real security mechanisms and should not appear anywhere in the IPv4 Security Protocol. Agreeing fully on all requirements in a legalistic style is certainly conventional in the ISO world. However, here in the IETF the process is "rough consensus" and avoidance of rigid definitions. I think we should be careful not to let ourselves get bogged down into a legalistic style of operation and instead should use the conventional more flexible IETF style. After all, we are working on security for _IPv4_ in this group. % My list of the requirements I thought (and still do) we had agreed to % review for inclusion in IPSP looked like this: - PID (Issue for debate!) There was NO consensus in favour of the PID and in fact there has been consistent vocal objection to its inclusion. It should not appear in the "list of requirements [that] we had agreed to" include. * basing formats on NLSP (a rancorous issue for debate!) See above. There was clear vocal opposition to basing anything on NLSP syntax. * Sequence integrity (swIPe has, NLSP-CL doesn't. Almost agreed to drop. Still an "issue" for E-mail debate.) Did not "almost agreed to drop". Did discuss at length with no real consensus either way. Several comments that an online spec of swIPe is needed soon. * works with CLNP, as well as IP Absolutely did NOT agree to. Strong, clearly expressed objections to this, though there was consensus that the _mechanisms_ (e.g. datagram encapsulation) should be reusable for ALL of the IP:TNG proposals (certainly not just CLNP). This MUST NOT appear as an agreed upon requirement because it most assuredly was NOT agreed to in the form presented above. * Overhead Almost certainly this should read "Low Overhead" ??? * efficiency (including emphasis on compact encoding suitable for low-speed links) Best expressed as "Scalability -- protocol viability over low-speed links scaling upwards and also being viable over very high-speed gigabit/second links. I'd add one: * Explicit per PDU labelling/versus implicit labelling Ran atkinson@itd.nrl.navy.mil P.S. Someone in private email noted that there is apparently some DoD directive saying that we must move towards OSI. Let me observe (not speaking officially of course) that exemptions from that for backwards compatibility with IPv4 are easier to obtain than Ada exemptions. Rate of installation of IPv4 continues to be much faster than rate of GOSIP installation in all parts of the government that I deal with... From zmuda@mls1.hac.com Tue Apr 20 03:42:13 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09300 (5.65c/IDA-1.4.4 for ); Tue, 20 Apr 1993 13:48:38 -0400 Received: from hac2arpa (hac2arpa.hac.com) by interlock.ans.net with SMTP id AA30788 (InterLock SMTP Gateway 1.1 for ); Tue, 20 Apr 1993 13:45:52 -0400 Received: from mls1.HAC.COM ([147.19.21.53]) by hac2arpa (4.1/SMI-DDN) id AA01064; Tue, 20 Apr 93 10:46:01 PDT Received: by mls1.HAC.COM (4.1/SMI-4.0) id AA24395; Tue, 20 Apr 93 10:42:13 PDT Date: Tue, 20 Apr 93 10:42:13 PDT From: zmuda@mls1.hac.com (Jim Zmuda) Message-Id: <9304201742.AA24395@mls1.HAC.COM> To: atkinson@tengwar.itd.nrl.navy.mil Subject: Re: IPv4 Security Cc: ipsec@ans.net Ran, I have to take exception to some points in your reply. First, the proper focus for our discussion is requirements. And the requirement I was placing on the table for discussion was simply: "Is it worth rolling our own format, or can the NLSP format work for IPSP (without objectionable performance penalty, of course)?" Believe me, I am not politically motivated to favor one format over another. Especially since the impact on any implementation of a format change is minimal, anyhow. Certainly not something I'm going to get worked up about. Of much greater impact are the functions being provided, and here all the proposals are in fairly broad agreement already. My interest in formats is limited to picking one which satisfies the broadest set of requirements. And if those requirements include the flexibility to support future growth, then I think the NLSP formats may have value. Please argue with my rationale if I'm wrong, but please don't attack my motivation. I also maintain that there _is_ a really significant performance penalty to be paid if word alignment is not maintained, and that in fact this is a more important issue for efficient implementations of NLSP than it's TLV encoding. But that is really an NLSP issue, and we should return to pruning requirements for IPSP from the set we arrived at during the last IETF meeting. Regards, Jim Zmuda From teb@saturn.sys.acc.com Tue Apr 20 11:34:10 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA08142 (5.65c/IDA-1.4.4 for ); Tue, 20 Apr 1993 15:37:36 -0400 Received: from POLLUX.SYS.ACC.COM by interlock.ans.net with SMTP id AA02852 (InterLock SMTP Gateway 1.1 for ); Tue, 20 Apr 1993 15:34:25 -0400 Received: from asteroid.sys.acc.com by pollux.sys.acc.com (4.1/SMI-4.1) id AA15625; Tue, 20 Apr 93 12:32:32 EDT Received: from saturn.sys.acc.com by asteroid.sys.acc.com (4.1/SMI-4.1) id AA23323; Tue, 20 Apr 93 15:35:24 EDT Received: by saturn.sys.acc.com (4.1/SMI-4.1) id AA03291; Tue, 20 Apr 93 15:34:10 EDT Date: Tue, 20 Apr 93 15:34:10 EDT From: teb@saturn.sys.acc.com (Tom Benkart) Message-Id: <9304201934.AA03291@saturn.sys.acc.com> To: ipsec@ans.net Subject: IPSP requirements As long as we all seem to agree that we are trying to identify the requirements for IPSP, and that we agree that conformance to NLSP is definitely not one of those requirements, then isn't it premature to consider using the NLSP formats? Shouldn't we agree on the requirements first, then decide what format to use to implement those requirements? Once we do get to the format specification stage, I agree with Ran - forget NLSP. But, what about SP3? At least it has a readable spec. Tom Benkart ACC Systems From tytso@Athena.MIT.EDU Tue Apr 20 20:09:02 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02366 (5.65c/IDA-1.4.4 for ); Tue, 20 Apr 1993 16:12:04 -0400 Received: from Athena.MIT.EDU (ATHENA-AS-WELL.MIT.EDU) by interlock.ans.net with SMTP id AA19923 (InterLock SMTP Gateway 1.1 for ); Tue, 20 Apr 1993 16:08:14 -0400 Received: from SOS.MIT.EDU by Athena.MIT.EDU with SMTP id AA19959; Tue, 20 Apr 93 16:09:04 EDT Received: by SOS (5.57/4.7) id AA04893; Tue, 20 Apr 93 16:09:02 -0400 Date: Tue, 20 Apr 93 16:09:02 -0400 From: Theodore Ts'o Message-Id: <9304202009.AA04893@SOS> To: zmuda@mls1.hac.com Cc: atkinson@tengwar.itd.nrl.navy.mil, ipsec@ans.net In-Reply-To: Jim Zmuda's message of Tue, 20 Apr 93 10:42:13 PDT, <9304201742.AA24395@mls1.HAC.COM> Subject: Re: IPv4 Security Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Tue, 20 Apr 93 10:42:13 PDT From: zmuda@mls1.hac.com (Jim Zmuda) First, the proper focus for our discussion is requirements. And the requirement I was placing on the table for discussion was simply: "Is it worth rolling our own format, or can the NLSP format work for IPSP (without objectionable performance penalty, of course)?" My feeling is that the NLSP format should _not_ be considered a requirement. If it meets the desired requirements and is otherwise technically better than the other formats, then fine. But at this stage, it doesn't seem apropriate to make NLSP a requirement --- as you said, the proper focus for our discussion is requirements, and there does not seem to be a technical justification for such a requirement at this point in time. - Ted From colella@emu.ncsl.nist.gov Tue Apr 20 12:22:05 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA08060 (5.65c/IDA-1.4.4 for ); Tue, 20 Apr 1993 16:21:27 -0400 Received: from EMU.NCSL.NIST.GOV by interlock.ans.net with SMTP id AA29714 (InterLock SMTP Gateway 1.1 for ); Tue, 20 Apr 1993 16:18:34 -0400 Received: by emu.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA07970; Tue, 20 Apr 93 16:22:05 EDT Date: Tue, 20 Apr 93 16:22:05 EDT Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9304202022.AA07970@emu.ncsl.nist.gov> To: ipsec@ans.net Subject: Re: IPSP requirements Cc: colella@nist.gov From: colella@nist.gov Reply-To: colella@nist.gov Folks, > As long as we all seem to agree that we are trying to identify the > requirements for IPSP, and that we agree that conformance to NLSP > is definitely not one of those requirements, then isn't it premature > to consider using the NLSP formats? Shouldn't we agree on the > requirements first, then decide what format to use to implement > those requirements? It's certainly sensible to decide on the requirements first. I assume from the email I've been watching that this part of the discussion is in progress. > Once we do get to the format specification stage, I agree with Ran - > forget NLSP. .... I find this statement a bit curious, given the above. This certainly sounds like a proposal about formats to me :^). --Richard From zmuda@mls1.hac.com Tue Apr 20 07:57:46 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09608 (5.65c/IDA-1.4.4 for ); Tue, 20 Apr 1993 18:26:14 -0400 Received: from hac2arpa (hac2arpa.hac.com) by interlock.ans.net with SMTP id AA14410 (InterLock SMTP Gateway 1.1 for ); Tue, 20 Apr 1993 18:23:32 -0400 Received: from mls1.HAC.COM ([147.19.21.53]) by hac2arpa (4.1/SMI-DDN) id AA06077; Tue, 20 Apr 93 15:23:38 PDT Received: by mls1.HAC.COM (4.1/SMI-4.0) id AA24647; Tue, 20 Apr 93 14:57:46 PDT Date: Tue, 20 Apr 93 14:57:46 PDT From: zmuda@mls1.hac.com (Jim Zmuda) Message-Id: <9304202157.AA24647@mls1.HAC.COM> To: tytso@Athena.MIT.EDU Subject: Re: IPv4 Security Cc: ipsec@ans.net Ted, You're right. I shouldn't have included a phrase like that in a list of requirements. I should have merely stated the requirement as: "* Flexibility to support growth to different protocol profiles (e.g., IP:TNG, CLNP, etc)" And then we focus on defining just what profiles we care to provide support for. Jim Zmuda From karn@qualcomm.com Tue Apr 20 22:13:09 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA10276 (5.65c/IDA-1.4.4 for ); Tue, 20 Apr 1993 21:31:07 -0400 Received: from qualcomm.com (qualcom.qualcomm.com) by interlock.ans.net with SMTP id AA24547 (InterLock SMTP Gateway 1.1 for ); Tue, 20 Apr 1993 21:28:13 -0400 Received: from servo.qualcomm.com by qualcomm.com; id AA24826 sendmail 5.65/QC-main-2.1 via SMTP Tue, 20 Apr 93 18:29:06 -0700 for ipsec@ans.net Received: by servo; id AA15797 sendmail 5.67/QC-subsidiary-2.1 Tue, 20 Apr 93 18:29:04 -0700 for ipsec@ans.net Date: Tue, 20 Apr 93 15:13:09 -0700 Message-Id: <9304210129.AA15797@servo> To: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) From: karn@qualcomm.com (Phil Karn) Subject: Re: IPv4 Security redux Cc: ipsec@ans.net X-Attachments: I strongly agree that the ipsec charter ought to be strictly limited to IPv4. It's impossible to anticipate every future need of anything that could conceivably become a new IP, and attempting to do so is the surest path to OSIfication (i.e., producing lots of paper but no usable product). Our protocol may need replacement some day, but so what? To my knowledge, we're the first to talk about network layer security in the Internet. There's no experience base, so gaining one is a worthwhile goal in itself. And what we learn will put us in a much better position to design its replacement if that should become necessary. I advocate a highly pragmatic approach here, with a strong emphasis on ease of implementation and on solving immediate, known problems. Even though this is nominally a host-to-host protocol, I see the first implementations being in encapsulating gateways used to join trusted networks (e.g., internal corporate subnets) via untrusted ones (e.g., public Internet carriers). This means supporting every existing transport protocol and application, robustly designed or not. In particular, I think we need sequence numbering to protect against replay attacks. Although it is theoretically correct to cite layering and argue that internet transport protocols are supposed to protect against packet duplication, in practice a lot of existing Internet transport protocols and hosts rely on non-intentional duplication being rare, which it fortunately is, especially for long-delayed duplicates. A good example is the ARNS package when used to encapsulate Appletalk packets inside UDP. It's my understanding that Appletalk doesn't handle duplication very well at all. Even TCP, whose designers had an almost pathological obsession with duplicate packets, has problems when hosts lose state (e.g., when they're rebooted). Many TCPs reuse the same sequence of port numbers and initial sequence numbers each time they're rebooted, creating an opportunity to replay packets recorded from before the reboot. If the ipsec protocol ran on a host-to-host basis, this problem could be avoided by simply requiring the hosts to rekey each time they reboot. But given the likely popularity of intermediate encapsulating gateways, I don't see any easy way to solve this problem without sequence numbering. Re some of the other fields, I question the need for a "security association identifier" (or key identifier, or whatever you call it). Given that every modern operating system I'm aware of has a trusted kernel that applications already rely on to protect themselves from each other and from the outside, I really don't see the point of having more than one active cryptographic key per host pair managed by these kernels. A host can determine the appropriate key to use for each packet solely from the address of the other host; it doesn't need an explicit key ID. So as I see it, here is what should be in the ip security header: Flags - indicating the presence or absence of an authenticator in this packet, and whether the packet is encrypted. 1 byte. Sent in the clear, included in the authentication computation. Protocol - the value that would have gone into the IP Protocol field had the security protocol not been used. This could be, eg., 17 (UDP) or 6 (TCP) if the ip security protocol is implemented on the end host, or it could be 4 or 94 (two different values for IP-in-IP encapsulation) if this system is providing secure IP encapsulation on behalf of other hosts. 1 byte. Sent encrypted, and included in the authenticator. Packet serial number - used to thwart replay attacks. When this number is lost (e.g., due to a reboot) or wraps around, rekeying is required. Given this last rule, 2 bytes should be plenty. Included in the authenticator. Not sure whether it should be encrypted or not; leaving this in the clear makes it easier to filter out a heavy flood of replays without spending cycles decrypting them first. Authenticator - Optional, possibly variable length. Algorithm could be negotiated during key exchange. It would probably be something like the MD-5 hash of the protected portion of the packet, seeded with the current shared key. Up to 8 bytes. Not included in the authenticator (e.g., considered to be zero when computing and verifying the authentication). Should probably be sent in the clear, since encrypting it doesn't seem to buy anything, and would again make it easier to filter a flood of malicious traffic without spending cycles on decryption (which is likely to be much slower than MD5 hashing). So, that means 4 bytes of fixed overhead, plus possibly 8 more for the authenticator. And everything lands on the right boundaries for performance. What else do we need? Phil From teb@asteroid.sys.acc.com Wed Apr 21 04:58:38 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05512 (5.65c/IDA-1.4.4 for ); Wed, 21 Apr 1993 09:00:07 -0400 Received: from POLLUX.SYS.ACC.COM by interlock.ans.net with SMTP id AA28037 (InterLock SMTP Gateway 1.1 for ); Wed, 21 Apr 1993 08:57:34 -0400 Received: from asteroid.sys.acc.com by pollux.sys.acc.com (4.1/SMI-4.1) id AA16489; Wed, 21 Apr 93 05:55:47 EDT Received: by asteroid.sys.acc.com (4.1/SMI-4.1) id AA23884; Wed, 21 Apr 93 08:58:38 EDT Date: Wed, 21 Apr 93 08:58:38 EDT From: teb@asteroid.sys.acc.com (Tom Benkart) Message-Id: <9304211258.AA23884@asteroid.sys.acc.com> To: ipsec@ans.net Subject: Re: IPv4 Security redux In the government/military environment, different security levels are frequently required to use different keys (between the same host pairs). That argues for including a SAID, assuming we are trying to address that user community. The SAID could be a single byte to satisfy that use. Tom Benkart ACC Systems From fran@zk3.dec.com Wed Apr 21 15:21:44 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09115 (5.65c/IDA-1.4.4 for ); Wed, 21 Apr 1993 11:25:54 -0400 Received: from decvax.dec.com (decvax.zk3.dec.com) by interlock.ans.net with SMTP id AA19891 (InterLock SMTP Gateway 1.1 for ); Wed, 21 Apr 1993 11:22:02 -0400 Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA07025; Wed, 21 Apr 1993 11:21:50 -0400 Received: by wasted.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91); id AA26067; Wed, 21 Apr 1993 11:21:44 -0400 Message-Id: <9304211521.AA26067@wasted.zk3.dec.com> To: ipsec@ans.net Subject: Re: IPv4 Security redux Date: Wed, 21 Apr 93 11:21:44 -0400 From: fran@zk3.dec.com X-Mts: smtp >In the government/military environment, different security levels are >frequently required to use different keys (between the same host pairs). >That argues for including a SAID, assuming we are trying to address >that user community. The SAID could be a single byte to satisfy that >use. > >Tom Benkart >ACC Systems I have seen this requirement too. Also, in the commercial arena there may well be a desire to have a low-overhead security option, and a high security (presumably higher overhead) security option for different types of traffic between the same two hosts. A case in point might be that an application that uses DCE RPC with encryption would not need (or desire) much in the way of network security, whereas an FTP session that did not provide its own security could benefit from network provided security. I expect that a single byte would do for this too. From zmuda@mls1.hac.com Wed Apr 21 07:01:50 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA10323 (5.65c/IDA-1.4.4 for ); Wed, 21 Apr 1993 17:12:11 -0400 Received: from hac2arpa (hac2arpa.hac.com) by interlock.ans.net with SMTP id AA27972 (InterLock SMTP Gateway 1.1 for ); Wed, 21 Apr 1993 17:05:33 -0400 Received: from mls1.HAC.COM ([147.19.21.53]) by hac2arpa (4.1/SMI-DDN) id AA00918; Wed, 21 Apr 93 14:05:43 PDT Received: by mls1.HAC.COM (4.1/SMI-4.0) id AA25216; Wed, 21 Apr 93 14:01:50 PDT Date: Wed, 21 Apr 93 14:01:50 PDT From: zmuda@mls1.hac.com (Jim Zmuda) Message-Id: <9304212101.AA25216@mls1.HAC.COM> To: ipsec@ans.net Subject: FYI: NLSP comments... All, Here is a copy of the NLSP comments which I have submitted to ANSI. Jim Zmuda ______________ Date: 4/20/93 2:55 PM To: Dale Walters From: Jim Zmuda Subject: NLSP spec comments updated... Dale, Here are my comments on the latest NLSP DIS: (Mine is dated November 29th, 1992.) Jim Zmuda ______________________________________________________ Comment Number: 1 Comment Type: Major Editorial Section: Figure 9.7 and section 13.4.2.1 Concern: The description of the content length field in section 13.4.2.1 states that this field is the length of the Unprotected Octet string as well as everything up to, but not including the ICV. Figure 9.7 erroneously labels this field "Unprotected Length Indicator". This implies that the field includes only the length of the Uprotected Octet string. This is a direct contradiction to section 13.4.2.1. Proposed Solution: Change the name of field in Figure 9.7 from "Unprotected Length Indicator" to "content length field" to match the text in section 13.4.2.1. Or in some manner reconcile the picture to the words in section 13.4.2.1. (See also section 13.3.1, as it indicates there is, in addition to the Protected Data Length Indicator, an Unprotected Octet String Length field as well that follows it. This is not reflected in the figure.) ______________________________________________________ Comment Number: 2 Comment Type: Major Technical Section: Section 9.3 Concern: The NLSP specification as it now stands does not provide any "word pad" field. "Word pad" may be used to align the beginning of the data field on a convenient boundary, for example a computer word. The CLNP prototocol specification, IS 8473 contains a "word pad" function (see IS 8473, clause 6.12 and 7.5.2) that provides precisely this function. It is the responsibility of the NLSP protocol to not degrade the service provided by the network layer by not also supporting this service. Therefore, the NLSP specification requires a "word pad" capability specifically to allow the alignment of the first byte of the NLSP User Data field to be adjusted. Proposed Solution: Provide a "word pad" field expressly for the purpose of supporting the alignment of the first byte of the NLSP User Data field. ______________________________________________________ Comment Number: 3 Comment Type: Major Technical Section: Section 9.3.2.2.1 Concern: The NLSP Userdata field as it now stands is a type- length-value (TLV) encoded field. It is also capable of being placed anywhere within the NLSP unprotected contents. A significant simplification would result by using a simple field instead of a TLV encoded field, and placing it at the end of the other parts of the NLSP protected data. The justification for this is that it would significantly simplify any operation on the Userdata field, in particular it would make the computation of the word pad field mentioned in comment 2 above much simpler. Proposed Solution: Utilize a plain field for the NLSP Userdata and place it at the end of the protected data. I.E., after the ICV pad. This is, in effect, bringing back the former division of the NLSP PDU into three parts: 1) Unprotected Header, 2) Protected Header, and 3) Userdata, instead of the two part form it is in now: 1) Unprotected Header, and 2) Protected Contents. ______________________________________________________ Comment Number: 4 Comment Type: Major Technical Section: Section 9.3.1 Concern: The NLSP unprotected header as it now stands has the Length Indicator field placed before the PDU type byte. A cleaner separation of function would result from a format which places the PDU type byte before the Length Indicator. In particular, it would be conceivable to augment the NLSP specification with additional PDU types which might require a completely different encoding without conflicting with the current encodings if this change were made. Proposed Solution: Reverse the order of the Length Indicator and the PDU Type Byte within the NLSP unprotected header.. From karn@qualcomm.com Thu Apr 22 01:17:42 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09232 (5.65c/IDA-1.4.4 for ); Wed, 21 Apr 1993 23:00:24 -0400 Received: from qualcomm.com (qualcom.qualcomm.com) by interlock.ans.net with SMTP id AA14319 (InterLock SMTP Gateway 1.1 for ); Wed, 21 Apr 1993 22:56:55 -0400 Received: from servo.qualcomm.com by qualcomm.com; id AA22015 sendmail 5.65/QC-main-2.1 via SMTP Wed, 21 Apr 93 19:57:38 -0700 for ipsec@ans.net Received: by servo; id AA22614 sendmail 5.67/QC-subsidiary-2.1 Wed, 21 Apr 93 19:57:35 -0700 for teb@asteroid.sys.acc.com Date: Wed, 21 Apr 93 18:17:42 -0700 Message-Id: <9304220257.AA22614@servo> To: teb@asteroid.sys.acc.com (Tom Benkart), ipsec@ans.net From: karn@qualcomm.com (Phil Karn) Subject: Re: IPv4 Security redux Cc: X-Attachments: At 08:58 AM 4/21/93 EDT, Tom Benkart wrote: >In the government/military environment, different security levels are >frequently required to use different keys (between the same host pairs). >That argues for including a SAID, assuming we are trying to address >that user community. The SAID could be a single byte to satisfy that >use. I don't really see the point of having multiple keys that are going to be stored right next to each other in the same trusted kernel anyway, but I guess if it's a real requirement we might as well add it. The only case where I think it really makes sense to have multiple keys is when you have multiple ciphers with different performance/security tradeoffs. A question here is how applicable the military multi-level compartmental security model is to commercial applications. Phil From smb@research.att.com Thu Apr 22 00:30:45 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01688 (5.65c/IDA-1.4.4 for ); Thu, 22 Apr 1993 04:34:38 -0400 Received: from research.att.com by interlock.ans.net with SMTP id AA15816 (InterLock SMTP Gateway 1.1 for ); Thu, 22 Apr 1993 04:32:07 -0400 Message-Id: <199304220832.AA15816@interlock.ans.net> From: smb@research.att.com Received: by bigbird.zoo.att.com; Thu Apr 22 04:30:49 EDT 1993 To: karn@qualcomm.com (Phil Karn) Cc: ipsec@ans.net Subject: Re: IPv4 Security redux Date: Thu, 22 Apr 93 04:30:45 EDT I don't really see the point of having multiple keys that are going to be stored right next to each other in the same trusted kernel anyway, but I guess if it's a real requirement we might as well add it. The only case where I think it really makes sense to have multiple keys is when you have multiple ciphers with different performance/security tradeoffs. Exactly. The Motorola SP3 box I saw at Interop runs at ~600 packets/sec. The DES encryptors there ran at or near Ethernet speeds. If you want another example, just consider triple-DES vs. DES. A question here is how applicable the military multi-level compartmental security model is to commercial applications. Well, given CIPSO, I'd say it does apply. From atkinson@tengwar.itd.nrl.navy.mil Thu Apr 22 11:31:20 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05926 (5.65c/IDA-1.4.4 for ); Thu, 22 Apr 1993 07:32:56 -0400 Received: from tengwar.itd.nrl.navy.mil by interlock.ans.net with SMTP id AA15854 (InterLock SMTP Gateway 1.1 for ); Thu, 22 Apr 1993 07:30:25 -0400 Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA27204; Thu, 22 Apr 93 07:31:20 -0400 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9304220731.ZM27202@tengwar.itd.nrl.navy.mil> Date: Thu, 22 Apr 1993 07:31:20 -0400 In-Reply-To: smb@research.att.com "Re: IPv4 Security redux" (Apr 22, 4:30) References: <199304220832.AA15816@interlock.ans.net> Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: ipsec@ans.net Subject: Re: IPv4 Security & MLS To give an example from a previous life, GE uses 6 vertical levels ("Class 1" thru "Class 6") for company information. The lowest level is releasable information, as I recall, and the highest is very very closely held trade secrets. We should not get locked into using CIPSO because it is not the only game in town. In particular, most of the DoD has invested in IPSO (RFC-1108). We need to avoid getting locked into any particular IP labelling scheme. Actually, there are very serious trust issues with any unprotected IP option in this context. We need to be careful to distinguish "trusted" from "trustworthy". Ran atkinson@itd.nrl.navy.mil From smb@research.att.com Thu Apr 22 03:53:13 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05529 (5.65c/IDA-1.4.4 for ); Thu, 22 Apr 1993 07:56:39 -0400 Received: from research.att.com by interlock.ans.net with SMTP id AA15676 (InterLock SMTP Gateway 1.1 for ); Thu, 22 Apr 1993 07:54:19 -0400 Message-Id: <199304221154.AA15676@interlock.ans.net> From: smb@research.att.com Received: by bigbird.zoo.att.com; Thu Apr 22 07:53:15 EDT 1993 To: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Cc: ipsec@ans.net Subject: Re: IPv4 Security & MLS Date: Thu, 22 Apr 93 07:53:13 EDT To give an example from a previous life, GE uses 6 vertical levels ("Class 1" thru "Class 6") for company information. The lowest level is releasable information, as I recall, and the highest is very very closely held trade secrets. We should not get locked into using CIPSO because it is not the only game in town. In particular, most of the DoD has invested in IPSO (RFC-1108). We need to avoid getting locked into any particular IP labelling scheme. Actually, there are very serious trust issues with any unprotected IP option in this context. We need to be careful to distinguish "trusted" from "trustworthy". I'm not advocating CIPSO as a syntax, or even as a model. I'm merely citing it as an example of how the commercial world is moving towards sensitivity labels, too, and that we should not standardize on an encryption format that does not recognize that. Hmm -- I think GE needs a new label, Class 0, for ``information we want to leak''. The encryptor should pass the data through a Clipper chip.... From hagens@reston.ans.net Thu Apr 22 06:56:03 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09930 (5.65c/IDA-1.4.4 for ); Thu, 22 Apr 1993 10:56:18 -0400 Received: from interlock.reston.ans.net by interlock.ans.net with SMTP id AA13359 (InterLock SMTP Gateway 1.1 for ); Thu, 22 Apr 1993 10:53:27 -0400 Received: by interlock.reston.ans.net id AA18110 (InterLock SMTP Gateway 1.1 for ipsec@ans.net); Thu, 22 Apr 1993 10:54:22 -0400 Received: by interlock.reston.ans.net (Internal Mail Agent-1); Thu, 22 Apr 1993 10:54:22 -0400 Message-Id: <9304221456.AA19276@shredin.reston.ans.net> To: karn@qualcomm.com (Phil Karn) Cc: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson), ipsec@ans.net Subject: Re: IPv4 Security redux In-Reply-To: Your message of "Tue, 20 Apr 93 15:13:09 PDT." <9304210129.AA15797@servo> Date: Thu, 22 Apr 93 10:56:03 EDT From: Robert Hagens > > > Packet serial number - used to thwart replay attacks. When this number > is lost (e.g., due to a reboot) or wraps around, rekeying is required. > Given this last rule, 2 bytes should be plenty. Included in the > authenticator. Not sure whether it should be encrypted or not; leaving > this in the clear makes it easier to filter out a heavy flood of replays > without spending cycles decrypting them first. > I don't understand how 2 bytes is plenty. If you increment the sequence number on every packet you send, and you want to re-key when you wrap around, you run the risk of rekeying very often. Consider sending 200 byte packets on a T1 link - you will wrap around in alittle over a minute. I don't want to rekey every minute. I think 3 bytes is the minimum you need. Rob Hagens ANS Reston From shirey@mitre.org Thu Apr 22 16:52:12 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA10314 (5.65c/IDA-1.4.4 for ); Thu, 22 Apr 1993 11:53:46 -0400 Received: from mwunix.mitre.org by interlock.ans.net with SMTP id AA10710 (InterLock SMTP Gateway 1.1 for ); Thu, 22 Apr 1993 11:50:39 -0400 Return-Path: Received: from smiley.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA10149; Thu, 22 Apr 93 11:51:33 -0400 Received: from [128.29.140.100] (shirey-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA26199; Thu, 22 Apr 93 11:50:51 EDT Message-Id: <9304221550.AA26199@smiley.mitre.org.sit> Date: Thu, 22 Apr 1993 11:52:12 -0500 To: Robert Hagens From: shirey@mitre.org (Robert W. Shirey) X-Sender: shirey@smiley.mitre.org Subject: Re: IPv4 Security redux Cc: ipsec@ans.net At 10:56 AM 4/22/93 -0400, Robert Hagens wrote: >> >> >> Packet serial number - used to thwart replay attacks. When this number >> is lost (e.g., due to a reboot) or wraps around, rekeying is required. >> Given this last rule, 2 bytes should be plenty. Included in the >> authenticator. Not sure whether it should be encrypted or not; leaving >> this in the clear makes it easier to filter out a heavy flood of replays >> without spending cycles decrypting them first. >> > >I don't understand how 2 bytes is plenty. If you increment the sequence number >on every packet you send, and you want to re-key when you wrap around, >you run the risk of rekeying very often. Consider sending 200 byte packets >on a T1 link - you will wrap around in alittle over a minute. I don't want >to rekey every minute. I think 3 bytes is the minimum you need. > >Rob Hagens >ANS Reston The last time the community thought about this was some time ago, when data rates were much lower, at the time the TCP was spec'ed. The conclusion then was that 4 bytes were needed. Check my arithmetic (please!), but 1.544 million bits per second (Mbps) in 200 byte packets causes the 32-bit TCP sequence number to wrap in 464 hours, 45 Mbps wraps in 16 hours, 155 Mbps wraps in 4.6 hours, and 622 Mbps wraps in 1.15 hours. Dividing by 2^8=256, we see that a three-byte space would wrap in 1501 minutes, 51 minutes, 15 minutes, and 3.72 minutes. This hardly seems adequate. Regards, -Rob- Robert W. Shirey, The MITRE Corporation, Mail Stop Z202 7525 Colshire Dr., McLean, Virginia 22102-3481 USA shirey@mitre.org * tel 703-883-7210 * fax 703-883-1397 From karn@qualcomm.com Thu Apr 22 21:04:45 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02527 (5.65c/IDA-1.4.4 for ); Thu, 22 Apr 1993 18:23:10 -0400 Received: from qualcomm.com (qualcom.qualcomm.com) by interlock.ans.net with SMTP id AA27849 (InterLock SMTP Gateway 1.1 for ); Thu, 22 Apr 1993 18:20:41 -0400 Received: from servo.qualcomm.com by qualcomm.com; id AA13677 sendmail 5.65/QC-main-2.1 via SMTP Thu, 22 Apr 93 15:21:33 -0700 for ipsec@ans.net Received: by servo; id AA01896 sendmail 5.67/QC-subsidiary-2.1 Thu, 22 Apr 93 15:21:31 -0700 for ipsec@ans.net Date: Thu, 22 Apr 93 14:04:45 -0700 Message-Id: <9304222221.AA01896@servo> To: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) From: karn@qualcomm.com (Phil Karn) Subject: Re: IPv4 Security & MLS Cc: ipsec@ans.net X-Attachments: I don't know much about how labeling and encryption interact, but isn't it the case that once you encrypt something it becomes unclassified? Otherwise you would never be able to send ciphertext over radio, open phone lines, etc. Once you decrypt the information, of course, it again becomes classified. So it seems that any security labels would be logically part of the data "inside" an encrypting security protocol, and thus not a direct concern of the security protocol itself. Phil From karn@qualcomm.com Thu Apr 22 16:42:23 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA08676 (5.65c/IDA-1.4.4 for ); Thu, 22 Apr 1993 18:23:19 -0400 Received: from qualcomm.com (qualcom.qualcomm.com) by interlock.ans.net with SMTP id AA18375 (InterLock SMTP Gateway 1.1 for ); Thu, 22 Apr 1993 18:20:34 -0400 Received: from servo.qualcomm.com by qualcomm.com; id AA13621 sendmail 5.65/QC-main-2.1 via SMTP Thu, 22 Apr 93 15:21:27 -0700 for ipsec@ans.net Received: by servo; id AA01864 sendmail 5.67/QC-subsidiary-2.1 Thu, 22 Apr 93 15:21:25 -0700 for ipsec@ans.net Date: Thu, 22 Apr 93 09:42:23 -0700 Message-Id: <9304222221.AA01864@servo> To: shirey@mitre.org (Robert W. Shirey) From: karn@qualcomm.com (Phil Karn) Subject: Re: IPv4 Security redux Cc: ipsec@ans.net X-Attachments: Well, frequent rekeying caused by a small sequence number is a problem only if rekeying is expensive. By "rekeying" I mean the automatic establishment of a new crypto key for the host pair. Ideally this would be the product of a Diffie-Hellman exchange, but a scheme based on a symmetric cipher and a shared master key would also work. The communication overhead from rekeying is negligible with a 16 bit sequence number; I can't get excited about adding, say, 3 packets to every 65,536 data packets. On the other hand, I do get excited about every additional byte that we add to every packet (see later). Depending on the key generation algorithm, the compute overhead of rekeying may or may not be a problem. Comments? I wonder if we could somehow use the existing IP ID field as the security protocol sequence number, instead of adding one explicitly to the security header. This may complicate some implementations where the IP level adds the ID field automatically. But I think it's supposed to be possible for the upper layer protocol to specify an ID field to IP when it sends a datagram (my code does, although I don't use this feature yet). This would be one way to get a 16-bit sequence field without spending two bytes on it in the security header. Few seem to agree with me that the key ID is superfluous. So given that we want it, how big does it have to be? Could it share a byte with the flags that indicate whether the packet is encrypted and/or authenticated? Is a 4 bit key ID enough? I should say where I'm coming from on all this. I run the Internet protocols over some very slow and expensive links, such as dialup modems and cellular radio. Header overhead is an absolutely critical concern to me. We're already starting with a significant disadvantage because the kind of protocol we're discussing will break Van Jacobsen TCP/IP header compression. So I'm trying to avoid making things even worse by adding an overly large security header. At the same time, I'm sensitive to performance concerns on fast networks, so I like fixed-sized, aligned fields. This means making some tough choices about exactly what goes where into the security header. The OSI approach of tossing in everything but the kitchen sink and making everything optional and variable length is not my idea of an efficient solution. Phil From teb@saturn.sys.acc.com Fri Apr 23 02:29:20 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA10159 (5.65c/IDA-1.4.4 for ); Fri, 23 Apr 1993 08:40:57 -0400 Received: from POLLUX.SYS.ACC.COM by interlock.ans.net with SMTP id AA21979 (InterLock SMTP Gateway 1.1 for ); Fri, 23 Apr 1993 08:29:01 -0400 Received: from asteroid.sys.acc.com by pollux.sys.acc.com (4.1/SMI-4.1) id AA20092; Fri, 23 Apr 93 05:27:15 EDT Received: from saturn.sys.acc.com by asteroid.sys.acc.com (4.1/SMI-4.1) id AA28579; Fri, 23 Apr 93 08:30:05 EDT Received: by saturn.sys.acc.com (5.51/5.17) id AA06646; Fri, 23 Apr 93 07:29:20 EST Date: Fri, 23 Apr 93 07:29:20 EST From: teb@saturn.sys.acc.com (Tom Benkart) Message-Id: <9304231229.AA06646@saturn.sys.acc.com> To: ipsec@ans.net Subject: Re: IPv4 Security redux Phil, perhaps an approach we should examine is coming up with two variants of a single IPSP - orient the "mainstream" variant for the high-speed line, but specify in parallel a "header compressed" form for low-speed lines. Having both efforts go on in parallel should ensure that compression considerations are adequately covered. Tom Benkart Acc Systems From smb@research.att.com Fri Apr 23 05:36:32 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07414 (5.65c/IDA-1.4.4 for ); Fri, 23 Apr 1993 09:58:54 -0400 Received: from research.att.com by interlock.ans.net with SMTP id AA07435 (InterLock SMTP Gateway 1.1 for ); Fri, 23 Apr 1993 09:49:13 -0400 Message-Id: <199304231349.AA07435@interlock.ans.net> From: smb@research.att.com Received: by bigbird.zoo.att.com; Fri Apr 23 09:36:35 EDT 1993 To: karn@qualcomm.com (Phil Karn) Cc: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson), ipsec@ans.net Subject: Re: IPv4 Security & MLS Date: Fri, 23 Apr 93 09:36:32 EDT I don't know much about how labeling and encryption interact, but isn't it the case that once you encrypt something it becomes unclassified? Otherwise you would never be able to send ciphertext over radio, open phone lines, etc. Once you decrypt the information, of course, it again becomes classified. So it seems that any security labels would be logically part of the data "inside" an encrypting security protocol, and thus not a direct concern of the security protocol itself. Yes and no. In an environment where labels exist, the key management protocol has to generate keys for each label and host pair, and the host encryption software has to know that there is a key per label and destination or source. From karn@qualcomm.com Sat Apr 24 04:15:52 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09050 (5.65c/IDA-1.4.4 for ); Sat, 24 Apr 1993 02:08:25 -0400 Received: from qualcomm.com (qualcom.qualcomm.com) by interlock.ans.net with SMTP id AA10462 (InterLock SMTP Gateway 1.1 for ); Sat, 24 Apr 1993 01:56:01 -0400 Received: from servo.qualcomm.com by qualcomm.com; id AA08545 sendmail 5.65/QC-main-2.1 via SMTP Fri, 23 Apr 93 22:56:47 -0700 for ipsec@ans.net Received: by servo; id AA09331 sendmail 5.67/QC-subsidiary-2.1 Fri, 23 Apr 93 22:56:45 -0700 for teb@saturn.sys.acc.com Date: Fri, 23 Apr 93 21:15:52 -0700 Message-Id: <9304240556.AA09331@servo> To: teb@saturn.sys.acc.com (Tom Benkart), ipsec@ans.net From: karn@qualcomm.com (Phil Karn) Subject: Re: IPv4 Security redux Cc: X-Attachments: At 07:29 AM 4/23/93 EST, Tom Benkart wrote: >Phil, perhaps an approach we should examine is coming up with two >variants of a single IPSP - orient the "mainstream" variant for >the high-speed line, but specify in parallel a "header compressed" >form for low-speed lines. Having both efforts go on in parallel >should ensure that compression considerations are adequately covered. > >Tom Benkart >Acc Systems Hmm. An intriguing idea, but it's not clear to me how easy this is. TCP/IP could be header compressed because many of the fields are either nonchanging or change in easily predictable ways. Much of the security protocol, by design, will change in ways that are completely unpredictable to anyone without the appropriate crypto key (the authentication field, for example, will appear to be completely random). While some of the other fields (such as the key ID) are in principle compressible, the job is complicated by the possibility that the network can reorder packets. (VJ TCP/IP compression assumes in-sequence delivery over the path that packets are compressed). Also, VJ compression peeks at the TCP headers to determine when it should resynchronize the recieiver; in purely connectionless environments such as UDP/IP or anything using secure IP, a separate back channel would be required for this purpose. Phil From karn@qualcomm.com Sat Apr 24 04:15:52 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07263 (5.65c/IDA-1.4.4 for ); Sat, 24 Apr 1993 02:08:25 -0400 Received: from qualcomm.com (qualcom.qualcomm.com) by interlock.ans.net with SMTP id AA11424 (InterLock SMTP Gateway 1.1 for ); Sat, 24 Apr 1993 01:55:37 -0400 Received: from servo.qualcomm.com by qualcomm.com; id AA08437 sendmail 5.65/QC-main-2.1 via SMTP Fri, 23 Apr 93 22:56:22 -0700 for ipsec@ans.net Received: by servo; id AA09236 sendmail 5.67/QC-subsidiary-2.1 Fri, 23 Apr 93 22:56:20 -0700 for teb@saturn.sys.acc.com Date: Fri, 23 Apr 93 21:15:52 -0700 Message-Id: <9304240556.AA09236@servo> To: teb@saturn.sys.acc.com (Tom Benkart), ipsec@ans.net From: karn@qualcomm.com (Phil Karn) Subject: Re: IPv4 Security redux Cc: X-Attachments: At 07:29 AM 4/23/93 EST, Tom Benkart wrote: >Phil, perhaps an approach we should examine is coming up with two >variants of a single IPSP - orient the "mainstream" variant for >the high-speed line, but specify in parallel a "header compressed" >form for low-speed lines. Having both efforts go on in parallel >should ensure that compression considerations are adequately covered. > >Tom Benkart >Acc Systems Hmm. An intriguing idea, but it's not clear to me how easy this is. TCP/IP could be header compressed because many of the fields are either nonchanging or change in easily predictable ways. Much of the security protocol, by design, will change in ways that are completely unpredictable to anyone without the appropriate crypto key (the authentication field, for example, will appear to be completely random). While some of the other fields (such as the key ID) are in principle compressible, the job is complicated by the possibility that the network can reorder packets. (VJ TCP/IP compression assumes in-sequence delivery over the path that packets are compressed). Also, VJ compression peeks at the TCP headers to determine when it should resynchronize the recieiver; in purely connectionless environments such as UDP/IP or anything using secure IP, a separate back channel would be required for this purpose. Phil From karn@qualcomm.com Sat Apr 24 03:08:25 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA10336 (5.65c/IDA-1.4.4 for ); Sat, 24 Apr 1993 02:08:25 -0400 Received: from qualcomm.com (qualcom.qualcomm.com) by interlock.ans.net with SMTP id AA09414 (InterLock SMTP Gateway 1.1 for ); Sat, 24 Apr 1993 01:55:48 -0400 Received: from servo.qualcomm.com by qualcomm.com; id AA08497 sendmail 5.65/QC-main-2.1 via SMTP Fri, 23 Apr 93 22:56:39 -0700 for ipsec@ans.net Received: by servo; id AA09291 sendmail 5.67/QC-subsidiary-2.1 Fri, 23 Apr 93 22:56:37 -0700 for atkinson@tengwar.itd.nrl.navy.mil Date: Fri, 23 Apr 93 20:08:25 -0700 Message-Id: <9304240556.AA09291@servo> To: smb@research.att.com From: karn@qualcomm.com (Phil Karn) Subject: Re: IPv4 Security & MLS Cc: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson), ipsec@ans.net X-Attachments: At 09:36 AM 4/23/93 EDT, smb@research.att.com wrote: >Yes and no. In an environment where labels exist, the key management >protocol has to generate keys for each label and host pair, and the >host encryption software has to know that there is a key per label >and destination or source. Okay, so how many different labels are there? Are 4 bits enough to index them all? Phil From karn@qualcomm.com Sat Apr 24 03:08:25 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09820 (5.65c/IDA-1.4.4 for ); Sat, 24 Apr 1993 02:08:25 -0400 Received: from qualcomm.com (qualcom.qualcomm.com) by interlock.ans.net with SMTP id AA04240 (InterLock SMTP Gateway 1.1 for ); Sat, 24 Apr 1993 01:55:24 -0400 Received: from servo.qualcomm.com by qualcomm.com; id AA08397 sendmail 5.65/QC-main-2.1 via SMTP Fri, 23 Apr 93 22:56:14 -0700 for ipsec@ans.net Received: by servo; id AA09196 sendmail 5.67/QC-subsidiary-2.1 Fri, 23 Apr 93 22:56:13 -0700 for atkinson@tengwar.itd.nrl.navy.mil Date: Fri, 23 Apr 93 20:08:25 -0700 Message-Id: <9304240556.AA09196@servo> To: smb@research.att.com From: karn@qualcomm.com (Phil Karn) Subject: Re: IPv4 Security & MLS Cc: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson), ipsec@ans.net X-Attachments: At 09:36 AM 4/23/93 EDT, smb@research.att.com wrote: >Yes and no. In an environment where labels exist, the key management >protocol has to generate keys for each label and host pair, and the >host encryption software has to know that there is a key per label >and destination or source. Okay, so how many different labels are there? Are 4 bits enough to index them all? Phil From Russ_Housley.McLean_CSD@xerox.com Mon Apr 26 01:03:54 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA10230 (5.65c/IDA-1.4.4 for ); Mon, 26 Apr 1993 11:06:35 -0400 Received: from alpha.Xerox.COM by interlock.ans.net with SMTP id AA02925 (InterLock SMTP Gateway 1.1 for ); Mon, 26 Apr 1993 11:03:22 -0400 Received: from Mail4_McLean.McLean_CSD.Xerox.xns by alpha.xerox.com via XNS id <11524>; Mon, 26 Apr 1993 08:04:09 PDT X-Ns-Transport-Id: 0000AA00B806A33E2F9F Date: Mon, 26 Apr 1993 08:03:54 PDT From: Russ_Housley.McLean_CSD@xerox.com Subject: Re: IPv4 Security & MLS In-Reply-To: <9304240556.AA09196@servo> To: karn@qualcomm.com Cc: ipsec@ans.net Message-Id: <"26-Apr-93 11:03:44".*.Russ_Housley.McLean_CSD@Xerox.com> Phil: Please look at RFC 1108, the IP Security Option. This is the format for DoD labels in TCP/IP networks. From this you can see that there is not a simple answer to your question. The number of security labels that might be supported by a single host could be hundreds. Russ From teb@saturn.sys.acc.com Mon Apr 26 08:19:58 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06230 (5.65c/IDA-1.4.4 for ); Mon, 26 Apr 1993 12:22:59 -0400 Received: from POLLUX.SYS.ACC.COM by interlock.ans.net with SMTP id AA25762 (InterLock SMTP Gateway 1.1 for ); Mon, 26 Apr 1993 12:19:47 -0400 Received: from asteroid.sys.acc.com by pollux.sys.acc.com (4.1/SMI-4.1) id AA22606; Mon, 26 Apr 93 09:18:01 EDT Received: from saturn.sys.acc.com by asteroid.sys.acc.com (4.1/SMI-4.1) id AA02041; Mon, 26 Apr 93 12:20:51 EDT Received: by saturn.sys.acc.com (5.51/5.17) id AA28607; Mon, 26 Apr 93 12:19:58 EDT Date: Mon, 26 Apr 93 12:19:58 EDT From: teb@saturn.sys.acc.com (Tom Benkart) Message-Id: <9304261619.AA28607@saturn.sys.acc.com> To: ipsec@ans.net Subject: RFC1108 vs SAID Be careful about distinguishing between different RFC1108 labels and SAID values. 1108 only specifies 4 levels to be used in the Basic Option. The Authority field is sometimes re-used as a poor-man's compartment field, but I'm not sure if that results in different keys. The Extended Option is clearly for compartments, but again I'm not sure that requires different keys. Summary - if different keys are only required for different hierarchical levels, then 1108 only defines 4 values. Backing up a little bit, let's rethink the requirements again. It seems like a single level is adequate for commercial concerns from Phil's point of view. The CIPSO people included support for more levels than 1108. Which user community are we trying to solve this problem for? We can't say how large the SAID would be (or even if it is needed) without that answer. Tom Benkart Acc Systems From atkinson@tengwar.itd.nrl.navy.mil Mon Apr 26 16:41:49 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09939 (5.65c/IDA-1.4.4 for ); Mon, 26 Apr 1993 12:43:31 -0400 Received: from tengwar.itd.nrl.navy.mil by interlock.ans.net with SMTP id AA25634 (InterLock SMTP Gateway 1.1 for ); Mon, 26 Apr 1993 12:40:54 -0400 Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA29537; Mon, 26 Apr 93 12:41:49 -0400 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9304261241.ZM29535@tengwar.itd.nrl.navy.mil> Date: Mon, 26 Apr 1993 12:41:49 -0400 In-Reply-To: teb@saturn.sys.acc.com (Tom Benkart) "RFC1108 vs SAID" (Apr 26, 12:19) References: <9304261619.AA28607@saturn.sys.acc.com> Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: ipsec@ans.net Subject: Re: RFC1108 vs SAID We should keep IPv4 Security Protocol completely independent of the IP labelling scheme. This means that the SAID should be reasonably large. GE has 6 vertical levels for internal information, other commercial users will vary. US DoD nominally has 5 vertical levels, but I've seen as many as 8 vertical levels used on some trusted systems. Ran atkinson@itd.nrl.navy.mil From Paul_Lambert@poncho.phx.sectel.mot.com Mon Apr 26 03:08:13 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09911 (5.65c/IDA-1.4.4 for ); Mon, 26 Apr 1993 13:12:26 -0400 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA17086 (InterLock SMTP Gateway 1.1 for ); Mon, 26 Apr 1993 13:09:07 -0400 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.14 for ) id AA16873; Mon, 26 Apr 1993 12:10:01 -0500 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.14 for ) id AA18392; Mon, 26 Apr 1993 12:10:00 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA18537; Mon, 26 Apr 93 10:07:16 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA33654; Mon, 26 Apr 1993 10:09:01 MST Message-Id: <00112.2818663741.33654@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: Mon, 26 Apr 1993 10:08:13 MST Subject: Re: >RFC1108 vs SAID Reply to: RE>>RFC1108 vs SAID >From: Ran Atkinson >We should keep IPv4 Security Protocol completely independent of the IP >labelling scheme. This means that the SAID should be reasonably large. >GE has 6 vertical levels for internal information, other commercial users >will vary. US DoD nominally has 5 vertical levels, but I've seen as many >as 8 vertical levels used on some trusted systems. > >Ran >atkinson@itd.nrl.navy.mil What is the requirement for linking the SAID with labeling in the manner you are implying? A key per label has never been a requirement or desireable feature of SP3 or NLSP. There may be some confusion about this due to the key per connection requirement imposed by SP4. SP4 required unique keys because of sequence number space considerations. Paul From Paul_Lambert@poncho.phx.sectel.mot.com Mon Apr 26 03:32:07 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11162 (5.65c/IDA-1.4.4 for ); Mon, 26 Apr 1993 13:36:43 -0400 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA16980 (InterLock SMTP Gateway 1.1 for ); Mon, 26 Apr 1993 13:33:47 -0400 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.14 for ) id AA18300; Mon, 26 Apr 1993 12:34:42 -0500 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.14 for ) id AA20073; Mon, 26 Apr 1993 12:34:40 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA18577; Mon, 26 Apr 93 10:31:58 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA33662; Mon, 26 Apr 1993 10:33:44 MST Message-Id: <00112.2818665224.33662@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) Cc: smb@research.att.com (smb) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Mon, 26 Apr 1993 10:32:07 MST Subject: Re: >IPv4 Security & MLS Reply to: RE>>IPv4 Security & MLS > > So it seems that any security labels would be logically part > of the data "inside" an encrypting security protocol, and thus > not a direct concern of the security protocol itself. > >Yes and no. In an environment where labels exist, the key management >protocol has to generate keys for each label and host pair, and the >host encryption software has to know that there is a key per label >and destination or source. No. You do not always need a key per label. This is not a requirement it is one mechanism that we could consider. An SAID (per NLSP, TLSP, and IEEE 802.10) provides the information required to select the algorithm and key to decrypt a packet. This information may include an implicit label. When implicit labels are used between the same host pairs some threats may require a key per labels. Other mechanisms could be used besides multiple keys per host pair to ensure the integrity of the label information. The requirements we are discussing seems to be: * support the binding of a security label to the IPSEC protected packets * provide integrity protection for the security labels bound to the protected packets Optional features we are discussing: * provide a mechanism to efficiently carry labeling information Mechanisms to bind the security label to the IPSP packet include: - explicitly in protected header as a variable length field (CIPSO, IPSO) - implicitly bound to the packet, the label is determined when a Security Association (SA) is created - carried in the protected header in a compressed form, label mapping to the reduced representation must usually be established when the SA is created Hopefully when the secretary posts the minutes from the March meeting (hint, hint) we can try to focus on the requirements and issues we identified in Ohio. Also, sorry for responding backwards on this discussion thread, but I tend to treat by mail as a FILO queue. Paul From teb@saturn.sys.acc.com Mon Apr 26 10:39:18 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02555 (5.65c/IDA-1.4.4 for ); Mon, 26 Apr 1993 14:41:55 -0400 Received: from POLLUX.SYS.ACC.COM by interlock.ans.net with SMTP id AA04941 (InterLock SMTP Gateway 1.1 for ); Mon, 26 Apr 1993 14:38:59 -0400 Received: from asteroid.sys.acc.com by pollux.sys.acc.com (4.1/SMI-4.1) id AA22795; Mon, 26 Apr 93 11:37:15 EDT Received: from saturn.sys.acc.com by asteroid.sys.acc.com (4.1/SMI-4.1) id AA02344; Mon, 26 Apr 93 14:40:05 EDT Received: by saturn.sys.acc.com (5.51/5.17) id AA29973; Mon, 26 Apr 93 14:39:18 EDT Date: Mon, 26 Apr 93 14:39:18 EDT From: teb@saturn.sys.acc.com (Tom Benkart) Message-Id: <9304261839.AA29973@saturn.sys.acc.com> To: ipsec@ans.net Subject: MLS and keys Any systems I am aware of which support multiple hierarchical levels require different keys for the different levels. That means some type of key ID must be carried in the SAID, since addresses alone are not sufficient to distinguish between the different keys for different levels. Different keys may not be desirable, but they are required in every MLS situation I know of. Short of persuading the current users to back off on that requirement, I don't see what other choice we have besides supporting it. That feature does not have to be used, but the mechanism should exist. This is really a separate (albeit related) issue from binding the label to the protected data. The SAID can not include any information which would reveal the original classification of the datagram. You could detect that multiple keys are being used (presumably for different levels), but you have no idea what those levels are. Tom Benkart ACC Systems From Russ_Housley.McLean_CSD@xerox.com Mon Apr 26 05:04:14 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02481 (5.65c/IDA-1.4.4 for ); Mon, 26 Apr 1993 15:06:32 -0400 Received: from alpha.Xerox.COM by interlock.ans.net with SMTP id AA14540 (InterLock SMTP Gateway 1.1 for ); Mon, 26 Apr 1993 15:03:57 -0400 Received: from Mail4_McLean.McLean_CSD.Xerox.xns by alpha.xerox.com via XNS id <11641>; Mon, 26 Apr 1993 12:04:24 PDT X-Ns-Transport-Id: 0000AA00B806A3612F9F Date: Mon, 26 Apr 1993 12:04:14 PDT From: Russ_Housley.McLean_CSD@xerox.com Subject: Re: RFC1108 vs SAID In-Reply-To: <9304261241.ZM29535@tengwar.itd.nrl.navy.mil> To: ipsec@ans.net Message-Id: <"26-Apr-93 15:04:14".*.Russ_Housley.McLean_CSD@Xerox.com> IPSECers: Remember how we got here? There was a question about whether or not IPSP needed an SAID or whether the IP address pair could be used instead. The security label issue was brought up as one example showing that an SAID is required and that the IP address pair is insufficient. Based on this example, some folks are suggesting that this is a military requirement, not a commercial one. Le me suggest another example that has a commercial flavor (and a military one too). Assume that there is alot of traffic flowing between two hosts, and that the traffic falls into four categories: 1. Requires no protection. 2. Requires protection from disclosure. 3. Requires protection from modification. 4. Requires protection from disclosure and modification. IPSP is not needed for category 1, but it should be able to support categories 2, 3, and 4 simultaneously. The IP address pair does not provide enough information for the destination host to determine how to process the IPSP packet (decrypt, ICV check, or both). The SAID provides the missing information. Anyway, we now have two examples where IP address pair is insufficient: security labels and security services. Two examples should be enough to show that an SAID should be included in IPSP. I recommend that we used a 32 bit SAID. The IEEE 802.10 Secure Data Exchange (SDE) protocol uses a 32 bit SAID, and the high order bit is used to distinguish between pairwise SAIDs and multicast SAIDs. If we intend to support IP multicast, then I suggest that we adopt this convention too. Russ From atkinson@tengwar.itd.nrl.navy.mil Mon Apr 26 19:23:43 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05378 (5.65c/IDA-1.4.4 for ); Mon, 26 Apr 1993 15:25:51 -0400 Received: from tengwar.itd.nrl.navy.mil by interlock.ans.net with SMTP id AA05937 (InterLock SMTP Gateway 1.1 for ); Mon, 26 Apr 1993 15:22:48 -0400 Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA29661; Mon, 26 Apr 93 15:23:43 -0400 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9304261523.ZM29659@tengwar.itd.nrl.navy.mil> Date: Mon, 26 Apr 1993 15:23:43 -0400 In-Reply-To: Russ_Housley.McLean_CSD@xerox.com "Re: RFC1108 vs SAID" (Apr 26, 12:04) References: <"26-Apr-93 15:04:14".*.Russ_Housley.McLean_CSD@Xerox.com> Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: ipsec@ans.net Subject: Re: IPv4 SP & SAID Russ's comments make a lot of sense to me. I consider it desirable to support IP multicasting. Also, there has been discussion in the Remote Conferencing community about the desirability of optional security for the networked conference traffic (as differentiated from the conference control traffic which is somewhat separate). Ran From Paul_Lambert@poncho.phx.sectel.mot.com Mon Apr 26 06:10:03 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06261 (5.65c/IDA-1.4.4 for ); Mon, 26 Apr 1993 16:15:40 -0400 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA04980 (InterLock SMTP Gateway 1.1 for ); Mon, 26 Apr 1993 16:12:30 -0400 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.14) id AA27965; Mon, 26 Apr 1993 15:13:25 -0500 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.14) id AA02650; Mon, 26 Apr 1993 15:13:22 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA19015; Mon, 26 Apr 93 13:10:35 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA33688; Mon, 26 Apr 1993 13:13:25 MST Message-Id: <00112.2818674805.33688@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) Cc: ahoover@ans.net (Al Hoover), karn@qualcomm.com (Phil Karn) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Mon, 26 Apr 1993 13:10:03 MST Subject: Re: >IPv4 Security redux Reply to: RE>>IPv4 Security redux >From: Phil Karn >Date: 20 Apr 93 15:13:09 -0700 > > ... > >I strongly agree that the ipsec charter ought to be strictly limited to >IPv4. It's impossible to anticipate every future need of anything that >could conceivably become a new IP, and attempting to do so is the surest >path to OSIfication (i.e., producing lots of paper but no usable >product). At the last meeting I thought that the group had a rough consensus to consider the implications of IPtng. This didnUt imply that we had to solve all future security problems, but at a minimum we should at least be aware of the impact of IPSP on IPtng. I do not think that this should be all that difficult since we are pursuing a simple encapsulation protocol for IPSP. Hopefully when the secretary posts the minutes (hint, hint, again) we will have some documentation of our initial decisions on the groups direction. >Our protocol may need replacement some day, but so what? To my >knowledge, we're the first to talk about network layer security in the >Internet. There's no experience base, so gaining one is a worthwhile >goal in itself. And what we learn will put us in a much better position >to design its replacement if that should become necessary. But there is an experience base. SP3 has been fielded for years. NLSP has been demonstrated by Jim Zmuda and give or take a few field formats is not all that different from SP3. We need to built from this experience base rather than starting from scratch. > >I advocate a highly pragmatic approach here, with a strong emphasis on >ease of implementation and on solving immediate, known problems. Even >though this is nominally a host-to-host protocol, I see the first >implementations being in encapsulating gateways used to join trusted >networks (e.g., internal corporate subnets) via untrusted ones (e.g., >public Internet carriers). This means supporting every existing >transport protocol and application, robustly designed or not. I agree mostly, but I would like to point out that IPSP is intended to support both host-to-host, subnet-to-host, and subnet-to-subnet protection. We attempted to prioritize the host-to-host solution first just to limit the scope of the initial work. >In particular, I think we need sequence numbering to protect against >replay attacks. Although it is theoretically correct to cite layering >and argue that internet transport protocols are supposed to protect >against packet duplication, in practice a lot of existing Internet >transport protocols and hosts rely on non-intentional duplication being >rare, which it fortunately is, especially for long-delayed duplicates. A >good example is the ARNS package when used to encapsulate Appletalk >packets inside UDP. It's my understanding that Appletalk doesn't >handle duplication very well at all. An interesting proposal. The suggestions to add sequence integrity at the network layer did seem to strongly divide our group in Ohio. >Even TCP, whose designers had an almost pathological obsession with >duplicate packets, has problems when hosts lose state (e.g., when >they're rebooted). Many TCPs reuse the same sequence of port numbers and >initial sequence numbers each time they're rebooted, creating an >opportunity to replay packets recorded from before the reboot. > >If the ipsec protocol ran on a host-to-host basis, this problem could be >avoided by simply requiring the hosts to rekey each time they reboot. >But given the likely popularity of intermediate encapsulating gateways, >I don't see any easy way to solve this problem without sequence >numbering. > >Re some of the other fields, I question the need for a "security >association identifier" (or key identifier, or whatever you call it). >Given that every modern operating system I'm aware of has a trusted >kernel that applications already rely on to protect themselves from each >other and from the outside, I really don't see the point of having more >than one active cryptographic key per host pair managed by these >kernels. A host can determine the appropriate key to use for each packet >solely from the address of the other host; it doesn't need an explicit >key ID. It took me a while to respond to this because the many possible uses of the SAID are not always obvious. IPSP could simply use the lower layer source and destination addresses to imply the Security Association (SA) for host-to-host protection. This works fine as long as you only have a single key per source/destination pair. The problem is that the cryptographic key and even the security services may eventually change for that pair. You need a mechanism to differentiate the new protection from the old. Because of this all protected source/destination pairs need to support at least two SAs. Note that the unprotected destination address may not be the final destination for packets that travel through IPSP protected routers. In this case the final adresses may be determined by the SAID (e.g. SP3-N at a router). These addresses could also be carried explicitly in the IPSP protected header (e.g. SP3-A), or a complete IP packet can be encapsulated inside the protected IPSP datagram (e.g. SP3-I). > >So as I see it, here is what should be in the ip security header: > >Flags - indicating the presence or absence of an authenticator in this >packet, and whether the packet is encrypted. 1 byte. Sent in the clear, >included in the authentication computation. I seem to be missing something here. I do not see why you need an authenticator field or encrypted flag. > >Protocol - the value that would have gone into the IP Protocol field had >the security protocol not been used. This could be, eg., 17 (UDP) or 6 >(TCP) if the ip security protocol is implemented on the end host, or it >could be 4 or 94 (two different values for IP-in-IP encapsulation) if >this system is providing secure IP encapsulation on behalf of other >hosts. 1 byte. Sent encrypted, and included in the authenticator. > >Packet serial number - used to thwart replay attacks. When this number >is lost (e.g., due to a reboot) or wraps around, rekeying is required. >Given this last rule, 2 bytes should be plenty. Included in the >authenticator. Not sure whether it should be encrypted or not; leaving >this in the clear makes it easier to filter out a heavy flood of replays >without spending cycles decrypting them first. > >Authenticator - Optional, possibly variable length. Algorithm could be >negotiated during key exchange. It would probably be something like the >MD-5 hash of the protected portion of the packet, seeded with the >current shared key. Up to 8 bytes. Not included in the authenticator >(e.g., considered to be zero when computing and verifying the >authentication). Should probably be sent in the clear, since encrypting >it doesn't seem to buy anything, and would again make it easier to >filter a flood of malicious traffic without spending cycles on >decryption (which is likely to be much slower than MD5 hashing). How is this different than the use of the Integrity Check Value (ICV) field in NLSP, SP3, SP4, or IEEE 802.10. Why is authentication with a hash different than any other cryptographic transformation applied to the data? I would recommend that whatever you are trying to do with the authentication could be accomplished with an SAID. The SAID would simply imply the type of service provided by the cryptographic encapsulation - confidentiality, integrity, integrity and authentication, confidentiality and integrity, etc. > >So, that means 4 bytes of fixed overhead, plus possibly 8 more for >the authenticator. And everything lands on the right boundaries >for performance. > >What else do we need? > A SAID field in the IPSP clear header. > >Phil Paul From Paul_Lambert@poncho.phx.sectel.mot.com Mon Apr 26 06:21:38 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11145 (5.65c/IDA-1.4.4 for ); Mon, 26 Apr 1993 16:24:23 -0400 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA06059 (InterLock SMTP Gateway 1.1 for ); Mon, 26 Apr 1993 16:21:47 -0400 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.14 for ) id AA28492; Mon, 26 Apr 1993 15:22:42 -0500 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.14 for ) id AA03409; Mon, 26 Apr 1993 15:22:40 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA19230; Mon, 26 Apr 93 13:19:57 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA33692; Mon, 26 Apr 1993 13:21:45 MST Message-Id: <00112.2818675305.33692@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) Cc: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Mon, 26 Apr 1993 13:21:38 MST Subject: Re: >>RFC1108 vs SAID Reply to: RE>>>RFC1108 vs SAID Ran, I noticed that you keep refering to our efforts in the IP Security (IPSEC) working group as the RIPv4 Security Protocol.S >My phrasing was "keep IPv4 Security Protocol completely independent of >the IP labelling scheme". That is to say, the two issues should be > ... ... > >Ran Maybe IUm getting too picky, but this is not correct. The IPSEC charter does not bind us solely to IPv4. At the last meeting we even extended the charter to include investigations of the interaction of the IP Security Protocol (IPSP) with IPtng. Paul From atkinson@tengwar.itd.nrl.navy.mil Mon Apr 26 20:46:44 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA10260 (5.65c/IDA-1.4.4 for ); Mon, 26 Apr 1993 16:48:22 -0400 Received: from tengwar.itd.nrl.navy.mil by interlock.ans.net with SMTP id AA14414 (InterLock SMTP Gateway 1.1 for ); Mon, 26 Apr 1993 16:45:52 -0400 Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA29765; Mon, 26 Apr 93 16:46:45 -0400 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9304261646.ZM29763@tengwar.itd.nrl.navy.mil> Date: Mon, 26 Apr 1993 16:46:44 -0400 In-Reply-To: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) "Re: >>RFC1108 vs SAID" (Apr 26, 13:21) References: <00112.2818675302.33691@poncho.phx.sectel.mot.com> Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Subject: Re: >>RFC1108 vs SAID Cc: ipsec@ans.net Paul, Your assertion is not correct. Firstly, we don't have a formally approved charter from the IESG yet, to the best of my knowledge. Secondly, the draft text says we are to design and specify a security protocol for IPv4 with consideration to possible adaptation for IP:TNG. We do not currently have a charter to design a security protocol for any of the IP:TNG proposals. We may and should consider the IP:TNG proposals, but we are NOT chartered to design any IP:TNG Security Protocol. Ran P.S. I didn't start this line of discussion and wish it would drop with this note.