[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPSEC meeting minutes
Enclosed please find the minutes for the IPSEC wg meeting in LA.
There are also the following slide submissions which should be included
in the minutes. The URL's follow below:
http://web.mit.edu/tytso/www/ipsec/los_angeles/agenda.ps
http://web.mit.edu/tytso/www/ipsec/los_angeles/ji.ps
http://web.mit.edu/tytso/www/ipsec/los_angeles/canetti.ps
(An HTTP version of the minutes can also be found at
http://web.mit.edu/tytso/www/ipsec/los_angeles/index.html)
- Ted
Los Angeles IETF (March/April 1998) Working Group Meeting Minutes
The IPSEC working group met on Thursday, April 2nd, 1998, at the
IETF meeting in Los Angeles, California.
The Agenda was as follows:
* Agenda Bashing
* Final Document Edits
* Whither AH?
* Free IPSEC Implementation survey
* Raleigh interoperability issues
* CA Interoperability issues
* IPsec Web-based Interoperability Tool
* IPSec configuration (isakmp-cfg)
* Smart card/RADIUS support in ISAKMP
* IPSec policy modeling
* Elliptic Curve Cryptography in IPSec
* Secure Multicast Issues
Final Document Edits
====================
Ted Ts'o asked the IPSEC document editors who had any final editorial
changes to submit them ASAP.
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.
Free IPSEC Implementation survey
================================
John Ioannidis from AT&T was 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.
Raleigh interoperability issues
===============================
Roy Pereira from TimeStep presented a list of issues that were found
at the Raleigh interoperability workshop. This list included:
1. ISAKMP SPI Sizes
Some implementations got upset (i.e. crash) when offered different
sizes of SPIs eg. 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 which 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 (ie. 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
13. IP4_ADDR_RANGE
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.
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.
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
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 tranport. 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 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.
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.
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.
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 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.
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.