The IPSEC working group met on Thursday, April 2nd, 1998, at the IETF meeting in Los Angeles, California.
The Agenda was as follows: (with hypertext links to the slides, where available)
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.
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 eg. 2 octets was required for IP Compression.
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)
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"
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)
Some implementations were sending a replay prevention value of 0 when doing manually keying.
In the discussion which followed, Steve Kent noted that this was incorrect behavior, since the replay prevention field must be incremented.
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
Some vendors were using the old isakmp-08 certificate request format
Some vendors did not like getting a key hash payload in rsa encryption mode
Some vendors were discarding entire ISAKMP packet when an unknown notify payload was received (ie. INITIAL-CONTACT). Only the single Notify payload should be discarded
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
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.
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
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."
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
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.
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 . This will eventually become an IPSEC internet draft.
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.
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 .
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 tranport. There is currently a draft proposal available: draft-ietf-ipsec-isakmp-mode-cfg-03.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 futher 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 orthagonal, but more investigation into this issue is necessary.
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.
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 .
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 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.
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.
Back to Ted's IPSEC Resources.