Protocol Action: Security Architecture for the Internet Protocol to Proposed Standard
The IESG <iesg-secretary@CNRI.Reston.VA.US> Sat, 08 July 1995 20:46 UTC
Received: from interlock.ans.net by ftp.ans.net with SMTP id AA07656 (5.65c/IDA-1.4.4 for <archive-ipsec@ftp.ans.net>); Sat, 8 Jul 1995 16:46:58 -0400
Received: by interlock.ans.net id AA15279 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 8 Jul 1995 16:43:05 -0400
Message-Id: <199507082043.AA15279@interlock.ans.net>
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 8 Jul 1995 16:43:05 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 8 Jul 1995 16:43:05 -0400
To: IETF-Announce:;
Cc: RFC Editor <rfc-editor@isi.edu>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: ipsec@ans.net
From: The IESG <iesg-secretary@CNRI.Reston.VA.US>
Subject: Protocol Action: Security Architecture for the Internet Protocol to Proposed Standard
Date: Sat, 08 Jul 1995 14:51:38 -0400
Sender: scoya@CNRI.Reston.VA.US
The IESG has approved the Internet-Drafts as a Proposed Standards: 1. Security Architecture for the Internet Protocol <draft-ietf-ipsec-arch-02.txt> 2. IP Authentication Header <draft-ietf-ipsec-auth-02.txt> 3. IP Encapsulating Security Payload (ESP) <draft-ietf-ipsec-esp-01.txt> 4. IP Authentication using Keyed MD5 <draft-ietf-ipsec-ah-md5-03.txt> 5. The ESP DES-CBC Transform <draft-ietf-ipsec-esp-des-cbc-04.txt> These documents are the product of the IP Security Protocol Working Group. The IESG contact person is Jeffrey Schiller. Technical Summary These documents specify mechanisms for providing Authentication, Integrity, and Confidentiality of data traveling at the IP (both IPv4 and IPv6) layer. Although not intended as a replacement for security services at other layers of the protocol stack, this technology provides significant benefit to the many applications that today use the network with little or no security protection. Working Group Summary After an extended period of discussion and debate, the Working Group has come to consensus around these five documents. More work remains to be done, including the development of an Internet key management protocol, which the working group is currently addressing. Although an automated key management protocol is not yet specified, the above documents do not require a specific mechanism, by design. As such they are implementable as they stand. Protocol Quality Jeff Schiller reviewed these protocols for the IESG. The need for security services on the Internet is now well known and these protocols provide an effective and in many cases transparent solution for many of the Internet Security problems we are experiencing today. Several implementations are currently underway and there is high confidence that these protocols will operate properly. Note: A formal response to the comments raised during the Last Call period will be forthcoming.