2.6.3 IP Security Protocol (ipsec)

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 01-Apr-98


Theodore Ts'o <tytso@mit.edu>
Robert Moskowitz <rgm-ietf@htt-consult.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion:ipsec@tis.com
To Subscribe: ipsec-request@tis.com
Archive: ftp://ftp.tis.com/pub/lists/ipsec OR ftp.ans.net/pub/archive/ipsec

Description of Working Group:
Goals and Milestones:



Post as an Internet-Draft the IP Security Protocol.



Post as an Internet-Draft the specification for Internet key management.



Submit the Internet Key Management Protocol to the IESG for consideration as a Proposed Standard.



Conduct initial interoperability testing of Encapsulating Security payload (ESP) and Authentication Header (AH).



Submit revised Internet-Drafts for ESP, AH, and IP Security Architecture.



Submit revised Internet-Drafts of IP Security Architecture, ESP, and AH to the IESG for consideration as Draft Standards.

Dec 96


Submit revised Internet-Drafts of IP Security Architecture, ESP, and AH to the IESG for consideration as Draft Standards.



Submit Internet-Draft of the Internet Key Management Protocol (IKMP) based on ISAKMP/Oakley to the IESG for consideration as a Proposed Standard.



Submit Internet-Draft of Internet Key Management Protocol to the IESG for consideration as a Proposed Standard.

Jul 97


Submit IKMP to IESG for consideration as a Draft Standard.


Request For Comments:







IP Authentication using Keyed MD5



IP Authentication Header



Security Architecture for the Internet Protocol



IP Encapsulating Security Payload (ESP)



The ESP DES-CBC Transform



HMAC: Keyed-Hashing for Message Authentication



HMAC-MD5 IP Authentication with Replay Prevention

Current Meeting Report

Minutes of the IP Security Protocol (ipsec) Working Group

The IPSEC working group met on Thursday, April 2nd, 1998, at the IETF meeting in Los Angeles, California.


I. Agenda Bashing
II. Final Document Edits
III. Whither AH?
IV. Free IPSEC Implementation survey
V. Raleigh interoperability issues
VI. CA Interoperability issues
VII. IPsec Web-based Interoperability Tool
VIII. IPSec configuration (isakmp-cfg)
IX. Smart card/RADIUS support in ISAKMP
X. IPSec policy modeling
XI. Elliptic Curve Cryptography in IPSec
XII. Secure Multicast Issues

I. Final Document Edits

Ted Ts'o asked the IPSEC document editors who had any final editorial changes to submit them ASAP.

II. Whither AH?

Bob Moskowitz presented the question of "Whither AH"? There are a some folks who would like AH to be optional; others want to keep it. There are some technical issues with AH --- the fact that the checksum is at the beginning of the AH packet makes it hard to do AH in hardware. However, there is a real requirement for the AH mechanism for IPv6. Making AH a "should" for IPv4 and a "must" for IPv6 doesn't seem to work, since the same problems with IPV4 will be faced for IPv6.

Peter Ford from Microsoft commented that the useful functionality of AH has been moved to ESP. He recommended that AH to be dropped entirely, but willing to live with a "should."

Steve Bellovin noted that he had recommended removing AH 3 years ago in Stockholm. After much discussion, the working group decided to keep it. He saw no reason to re-open the discussion.

Steve Kent made the following comments: ESP is fine as it is, and ESP can be used in an authentication mode with null encryption. However, there is a legitimate functionality that AH supports.

Others noted that everyone in the Raleigh interoperability testing was doing AH, and we should just do it. There was a concern expressed that if we didn't get rid of it now, it would never go away. Also, that IPSEC was too complex and anything to reduce complexity would be a good thing. On the other hand, AH is a very small part of a complete IPSEC implementation, and it doesn't cost much to test. It was noted that the IPV6 router renumbering relies on AH.

Peter Ford said that it was Microsoft's desire to ship a product that is 100% IETF compliant. The implementations will be much simpler and drive it to the smallest possible set of features. If AH is a "should", will Microsoft support it? Microsoft not willing to make that statement at this point. Jeff Schiller pointed out that there was a difference between "SHOULD" and "MAY", and that although folks were talking about changing AH to be a "SHOULD", their arguments and statements indicated that they were treating it as a "MAY".

Jeff Schiller, as Area Director, took the floor. He pointed out that were at the proposed standard stage, the first step in the standardization process. Normally this doesn't even require working implementations, which we already have here. At the proposed standard status, whether something is a "SHOULD" or "MUST" it not that important; we can change it either way later. However, what we cannot do is NOT move forward at all.

Jeff proposed compromise of making AH a "SHOULD" but that vendors would be put on notice that we might change this in the future. Vendors would be warned that this "SHOULD" would be a real "SHOULD" that they should really implement, and not just a "MAY". As we go to draft standard, this might become a "MUST". Jeff took a straw poll to determine if people wanted to make such a change, or to leave the document alone and keep AH a "MUST". Jeff declared a clear consensus to keep AH mandatory.

III. Free IPSEC Implementation Survey

John Ioannidis from AT&T is interested in doing a survey of "free" IPSEC implementations. He asked those with free implementations of IPsec code to send him e-mail to: ji@research.att.com with the subject line "FREE IPSEC." He would summarize the responses to the ipsec mailing list.

IV. Raleigh Interoperability Issues

Roy Pereira from TimeStep presented a list of issues that were found at the Raleigh interoperability workshop. This list included:


Some implementations got upset (i.e. crash) when offered different sizes of SPIs e.g. 2 octets was required for IP Compression.

2. Correctly Ordered Payloads

For some vendors, ISAKMP payloads had to be in the order that they are documented. Most ISAKMP payloads may be sent in any order (except for the SA, Proposal and Transform payloads)

3. IP Addresses in Certificates

Some people expected strings, other expected 4 octets in ipAddress "It is never a string when encoded in subjectAltName"

"... consensus was that if IP Addresses (or dns name or rfc822 name) were going to be added to an X.509 certificate then they should go into the subjectAltName extension (that is after all what it is for). This is consistent with work done in the PKIX WG."

4. No IP Address in Certificate

An IP Address does not have to be within the certificate if the IPSec entity is mobile and uses a dynamic address. But, there must be some other type of identity within the certificate (rfc822name, domain name, X.500 DN)

5. Replay of Zero

Some implementations were sending a replay prevention value of 0 when doing manually keying.

In the discussion that followed, Steve Kent noted that this was incorrect behavior, since the replay prevention field must be incremented.

6. AH & Auth Attribute

Some vendors were not sending both the AH Transform type (e.g., AH_MD5) and the Authentication Algorithm attribute (e.g. HMAC-MD5) Some vendors would not accept receiving both the Transform type and the Authentication Algorithm attribute

7. New CertReq Format

Some vendors were using the old isakmp-08 certificate request format

8. Hash in RSA Encryption

Some vendors did not like getting a key hash payload in rsa encryption mode

9. Unknown Notify Payloads

Some vendors were discarding entire ISAKMP packet when an unknown notify payload was received (i.e. INITIAL-CONTACT). Only the single Notify payload should be discarded

10. Handling CertReq

Some vendors did not like receiving certificate request payloads when using pre-shared keys The isakmp draft says certificate requests payloads can exist in any message Some vendors did not like receiving certificate request payloads at any time

11. Packet Padding

Some vendors did not like ISAKMP packets to be padded to a multiple of 4 byte. The ISAKMP draft states that the ISAKMP message MUST be 4-octet aligned.

12. IDui & Idur

Some vendors expected to see client ID's in phase 2 (QuickMode), even though they are optional This caused QuickMode to complete, but fail to setup the correct Sas


Some vendors do not accept a QuickMode ID type of IP4_ADDR_RANGE while they do accept IP4_ADDR and IP4_ADDR_SUBNET

14. Nonce Sizes

Some vendors could not handle larger sized nonces (40 bytes) and would only allow 20 byte nonces The new IKE document does state: "The length of nonce payload MUST be between 8 and 256 bytes inclusive."

15. Overlapping SAs

Some vendors did not support having a SA with the whole subnet at the same time as another SA with one host in that subnet

16. CONNECT Notify Message

Due to QuickMode's 1.5 exchanges, the initiator might not know that the responder did not receive the 3rd message One vendor suggested we should send a Notify CONNECT message for the responder's 2nd quickmode message

When this item was discussed, it was noted that this was not necessary because of the COMMIT bit in the ISAKMP header.

V. CA Interoperability Issues

Rodney Thayer gave a presentation of the requirements which IPSEC places on a Public Key Infrastructure. (This presentation was also given at the PKIX working group.) Rodney has written a draft document which is currently available at: ftp://module-one.tillerman.nu/pub/draft-thayer-ipsec-pki-00.txt

After Rodney finished his presentation, a developer from Microsoft noted that there were speed/performance problems with the certificate verifications; the time needed to do the certificate processing was causing TCP SYN's to get queued up and be dropped. Discussion followed, with participants noting that IPSEC implementors need to collect timing requirements and give that experience to the PKIX people. A volunteer is needed to collect this information.

VI. IPsec Web-based Interoperability Tool

Rob Glen presented a web-based interoperability testing tool developed by NIST to test the IPSEC protocols. The URL for this service is: http://IPsec-wit.antd.nist.gov/

The testing tool is semi-automated, and driven using WWW forms. There are currently 70 test cases covering AH and ESP using IPV4, and there are plans to expand the service to include test cases for IKE, PKIX, and IPv6.

The tool is based on the NIST Cerberos IPsec implementation. The source code to the testing tool is available for those who would like to port the tool to be based on other IPSEC implementations.

In the discussion that followed it was noted that SSH Communications Security has a web-based service to test IKE (nee ISAKMP/Oakley) implementations. This was announced at the last IETF meeting. The URL for this testing site is: http://isakmp-test.ssh.fi

VI. IPSec Configuration (isakmp-cfg)

Roy Pereira from Timestep presented a proposal for doing configuration under ISAKMP. This proposal was conceieved to request an internal IP address from a security gateway in a secure fashion. (Since this needs to happen before the IKE negotiation is completed, it is not possible to use protocols such as Radius or DHCP.) Instead, it uses ISAKMP for management and transport. There is currently a draft proposal available: draft-ietf-ipsec-isakmp-mode-cfg-02.txt. This work is currently not part of the working group charter, but this is an important work item to consider for the new working group charter for further work for this working group.

During the discussion, there was a question raised of how this would impact Mobile IP, especially in light of RFC-2002. One person thought that this might be orthogonal, but more investigation into this issue is necessary.

VII. Smart card/RADIUS Support in ISAKMP

Roy Periera also discussed his proposal to extend IKE to accept the use of extended authentication techniques such as time-variant smart cards, two factor authentication, challenge/response and other user-based authentication schemes. An initial draft of his work is available at: draft-ietf-ipsec-isakmp-xauth-01.txt.

During the discussion, the working group asked Roy why this was done inside IKE; the answer was so that it could be done securely. One person suggested that Roy look at EAP. Roy noted that more discussion was needed for his proposal, which was still in the early design phase.

VIII. IPSec Policy Modeling

Finally, Roy presented a proposed IPsec Policy Data Model. The goal is to provide implementers sufficient information on the base IPsec negotiation mechanism so that they can create a correct enterprise policy architecture. There is an initial Internet Draft describing this model: draft-ietf-ipsec-policy-model-00.txt.

IX. Elliptic Curve Cryptography in IPSec

Paul Lambert from Certicom gave a presentation of Elliptical Curve (EC) cryptography. EC systems are much faster, and so are popular in implementations driven by constrained devices (e.g., Windows CE, pagers, etc.) Certicom's web site has tutorials on the technology. Certicom has suggested that IPSEC use "better curves" based on prime fields.

Discussion centered over two main issues. The first are the IPR/patent issues in the EC space, of which there are many. Certicom has a large number of patents optimizing EC cryptography. Not all patents have been issued yet, so Certicom can not disclose all of them. It was suggested that Certicom put together an internet draft that discusses or describes what portions are available for public use.

More discussion also centered around the optimizations which can be applied to EC. Some optimizations only apply to hardware implementations. The current curves proposed in the Oakley draft are not prime fields and have software speedups which do not apply if the fields used are prime fields, as Certicom proposes. (There are hardware optimizations, which may be patented by Certicom, which do apply to prime fields, however.) Furthermore, there is disagreement amongst mathematicians as to whether prime fields are more secure than non-prime fields. Ted Ts'o observed than when comparing the speed of EC's, it is important to consider both software and hardware implementations, as well as comparing the speed with and without the use of patented optimization techniques.

X. Secure Multicast Issues

Ron Cannetti from IBM research gave a presentation sketching the scope of the Secure Multicast problem. Different applications may have very different group characteristics, security requirements, performance requirements, etc. Ran ended with a survey of existing solutions with differing properties.

Bob Moskowitz observed that the working group will have to decide on a specific scope before we will be able to profitably tackle the secure multicast as a tractable problem. Ideally, some customers would ask the IETF to solve a specific problem.


IPSEC - Agenda
Security Multicast: A Taxonomy

Attendees List

go to list