Editor's note: These minutes have not been edited.
IETF 37, December 1996, San Jose
IP Security WG (IPsec) Meeting Minutes
Co-Chairs:
Paul Lambert <palamber@us.oracle.com>
Ran Atkinson <rja@inet.org>
INTRODUCTION
As is customary, Paul Lambert moderated the meeting. Paul first
went over the agenda and charter. He displayed a list of the 20 current
drafts and emphasized key management: ISAKMP, Oakley, and the IPsec DOI for
ISAKMP. The ISAKMP/Oakley specifications are in WG Last Call that will end
in very early January. Comments should be sent to the list.
Jeff Schiller, IESG Security Area Director, pointed out that some
of the IDs are already going to RFCs, and therefore not easily changed by
the WG.
STATUS OF DRAFTS AND RFCs
(1) ARCHITECTURE DOCUMENT UPDATE (Presented by Steve Kent)
He started with an introduction. The idea is to protect IP, whether
in a host, outboard processor, or gateway. Router to router security, for
example, can protect all of the traffic between two networks. IPsec Security
associations (SAs) may be nested as well. A tunnel-mode SA can exist along
with a transport-mode SA. The AH and ESP specs are now being revised.
The AH sequence number for replay detection (optional to use) can
be 4 or 8 bytes. The authentication data may be 16 or 20 bytes. The total
AH size is 28, 32, or 36, which in IPv6 has to be 64 bit aligned (i.e., a
multiple of 8 bytes). The notion of using SHA-1 with less than the
standard 160 bits was not discussed here. In the proposed new unified ESP
header (SPI, IV, sequence #, payload, pad, pad length, type, authentication
data [optional and including padding]), particular feature combinations can
be registered and used without writing a new document.
IPSEC outbound processing can be complicated; the recommendation is
that a processing selection function first look at source and destination
addresses, next protocol, and ports (where applicable). The decision
resulting from examining these items can be SA processing, bypass
processing, or discard and audit. In the first case, an SA might need to
be created. Packet selection parameters can include IP addresses, next
protocol, ports, and sensitivity labels. The granularity can be a fully
specified selector, * name selector, or ranges. Compliance specifications
include protocol modes, mode combinations (e.g., nesting levels),
administrative interfaces, and perhaps MIBs or some other administrative
mechanisms. Nesting can accommodate both security gateway and end user
security requirements.
(2) HMAC SPECIFICATION STATUS (Presented by Hugo Krawczyk)
The HMAC ID will become an informational RFC. Hugo had previously
suggested using 128 bits of output from SHA-1. HMAC is also being used for
key derivation. He recommends using a more substantial mechanism than the
Oakley counter increment when this is applied repeatedly.
He made another pitch for truncation of the SHA-1 HMAC output when
used within AH. He also argued that the Novell patent is not an issue.
Bellovin and Simpson supported truncation of the 160 bit MAC as well.
Schiller will discuss this with Hugo and the WG chairs after the meeting.
(The post-meeting conclusion was to truncate SHA-1 to 128-bits to avoid
issues relating to 64-bit alignment; 64-bit alignment is mandated by IPv6
and IPsec is required to support/comply with IPv6).
(2) COMPRESSION (Presented by Rodney Thayer and Bob Monsour)
The talk covered (1) why compression, (2) two approaches, and (3)
next steps. The presenters argued compression is important because
compression must be at a higher protocol processing level than encryption
if it is to be effective. They assert that compression might actually
reduce CPU time when DES and MD5 are used and also assert that 2:1
compression is possible.
The two approaches presented were (1) as an ESP feature and (2) as
an orthogonal transform. The former causes compression to be tied into
IPsec key management. They believe the sender could choose whether to
compress each packet (e.g., based on packet size) on a packet-by-packet
basis, one header byte indicates compression was done prior to encryption;
for IP, it is memoryless. The one byte has a compress bit (used now) and
history bit (unused for now). There was no clear explanation of where the
"one byte" would come from and how this would be done such that existing
conforming implementations would not be made non-conforming. The rationale
for the the first approach is minimal overhead, minimal change, compression
only needed when encryption is used. It is described in the two drafts:
draft-sabin-esp-des3-lzs-md5-00.txt and draft-sabin-lzs-payload-00.txt.
The second method, described by Rodney Thayer, added a new
transform, allowed history, didn't change ESP, and could be planned to be
deprecated later. The draft draft-thayer-seccomp-00.txt describes this. The
header is 8 bytes: (next payload(1), type(1), options(2), identity(2),
length(2)). Compressed data follows. The next steps would be to add
compression parameters and algorithms to the ISAKMP DOI.
During open discussion, Bellovin and Kent objected to adding the
"one byte at the beginning". Some other comments were that much of the
Internet is already compressed and that TCP level compression makes using
history sensible. But this, it was said, does not help UDP. A straw pole
indicated there is no current consensus on how to proceed. Further
discussion was deferred to the IPsec list.
KEY MANAGEMENT
(1) ISAKMP Base Specification (Presented by Doug Maughan)
The ISAKMP architecture now has ISAKMP relying on a separate
(security-protocol-specific) DOI specification and a separate key exchange
definitions (e.g. the Oakley resolution document). All the IPSEC specific
information is in the DOI document. Another DOI could be written for TLS,
SSH, or another security protocol. Also, this document approach permits
the substitution of another key exchange for Oakley if that were ever
desirable for some reason.
The main changes in the ISAKMP base specification were described
as:
1. ISAKMP header: version was expanded from 4 to 8 bits
(major and minor); pre -06 it is (0,1), draft-06 is
(1,0); exchange type field was expanded (4 to 8
bits), flags shortened a byte (no collate bit, added
commit bit for key exchange synchronization); added
a 32 bit message ID field to keep multiple phase 2
negotiations straight.
2. SA identification: the two phases are now clearly
delineated and the process of filling in the fields
<left to right> and defining the keyid with the
cookies or the SPI was clearly documented.
3. SA negotiation format: proposal and transform
payloads were added; envelope payload and collate
bit were removed. Proposal can negotiate entire
protocol suites at once (logical AND) or multiple
suites (logical OR).
4. Certificate and certificate request payloads:
deleted CA information, shortened type to one byte,
supports PKCS #7, wrapped X.509, PGP, DNS, X.509,
and Kerberos tokens. CRLs and ARLs need to be
discussed and resolved, as requested by Greg Carter.
Certificate request payload can request specific
certificate of CAs.
5. Exchanges: added nonce payload to base exchange and
identity protect exchange; moved nonce payload in
auth only; added aggressive exchange combining SA ,
KE, and auth. This consolidates unidirectional
notify and delete in informational exchange.
-06 had major editing in Sect 2; new 3.3, 3.10, 4.1,
4.1.1, 4.7, 5.4.1, 5.4.2, 5.8, and changes to appendices.
(2) INLINE KEYING WITH ISAKMP (Presented by Bill Sommerfeld)
The goals are to borrow technology from SKIP, assume 2-way
communication, produce a lightweight child SA, keep the overhead to 100-200
extra bytes, avoid extra messages, and be compatible with ISAKMP-Oakley.
Applications include per connection keying between hosts, per
connection keying at tunnel endpoints, zero packet overhead for sporadic
communications, and compatibility with RSVP (credited to Ran).
The proposal starts with an existing SA; the initiator creates an
inbound SA for the reply, and combines the SA creation notice with a
request for the responder to do the same.
It can use stock ISAKMP/Oakley or publish DH public values (as in
SKIP). Consensus was to use ISAKMP/Oakley. The items required are: SPI,
Nonce, IV, next payload, authenticator, sequence #, reply-creation goop,
payload. A separate key is needed for protecting headers. There are
two methods, one with 3 messages and one with 2 messages using Quick Mode.
Issues are exact encapsulation of fat packet (ESP vs. new IP-layer
protocol as in SKIP), short lifetime SAs, and MTU discovery. Bill
solicited additional ideas and feedback; the proposal is still sketchy.
A more detailed proposal will be published before the Spring 1997 IETF
meeting.
(3) GKMP AND MULTICAST KEY MANAGEMENT (Presented by Hugh Harney)
The goal is to make ISAKMP work well with IP Multicasting
by adoption of GKMP-derived extensions into ISAKMP.
Requirements include support for:
ATM and IP style multicast groups,
mutual suspicion,
re-keying,
group compromise recovery,
non-compromising "leaves,"
and late joins.
ISAKMP defines only pairwise SAs. With groups, the other endpoints
are not clearly identified. Keys are usually "handed out." Algorithms and
group permissions also have to be defined. See the two GKMP
Internet-Drafts. The standalone GKMP specification is pending as an
Informational RFC. The ISAKMP/GKMP work is intended for the
standards-track and will be undertaken within the IPsec WG.
IPSEC-RELATED APIs
(1) SIMPLE IPSEC API (Presented by Dan McDonald)
He described the contents of his Internet-Draft
(draft-mcdonald-simple-ipsec-00.txt), which specifies IPsec extensions to
the BSD Sockets API.
Most of this work was done at NRL and is available in every public
snapshot of the NRL IPv6+IPsec code (http://web.mit.edu/network/isakmp/)
These extensions apply to both IPv4 and IPv6. The API implements the
notion of a "Security Level" and the notion of a "Security Category". A
Security Level value is associated with each Security Category in an array.
The system administrator can configure a system-wide minimum security level
value for each security category. An IPsec-aware application can also
request a particular security level value on its socket(s). If the system
security level and the per-socket security level are different, the more
paranoid setting is used for traffic to/from that socket. The API uses
Socket-options to set the levels.
Possible Security Level values implemented in the NRL code include:
None
Use IPsec if it is available,
Must use IPsec on outbound traffic,
Require IPsec both inbound and outbound
Require IPsec both inbound and outbound,
and require that the IPsec SA be session-oriented
rather than host-oriented
Possible security categories are:
AH (transport-mode),
ESP (transport-mode),
and ESP (network-mode)
A revised version is expected to be published before the Spring 1997 IETF
in Memphis. Dan solicited other comments to be sent to him via email.
(2) PF_KEYv2 KEY MANAGEMENT API
PF_KEY is a BSD Sockets API used for key management services. It
is not limited to IPsec, but can be used for any sort of key management
(e.g. RIPv2 MD5, OSPFv2 MD5, RSVP MD5). The general notion is that the key
management protocol is implemented as an application-layer daemon outside
of the kernel. This daemon communicates with the kernel via the PF_KEY
API. The kernel can send up requests for new SAs and the daemon can send
new SAs down into the kernel after they are established. PF_KEYv1 is
implemented in the NRL IPv6+IPsec software distribution and is supported by
the cisco ISAKMP+Oakley daemon, for example. Parts of SKIP could also
be built using PF_KEY.
This was not a formal presentation. Someone in the audience
asked about status of this document. Dan McDonald, one of the PF_KEYv2
authors, responded. Dan reported that there are some unresolved comments
that need to be resolved before this can be published as an Internet-Draft.
He hopes to have this out before the Spring 1997 IETF in Memphis.
INTEROPERABILITY
The IPsec Implementation Survey is being recirculated and should be
sent out to the list again thereafter. The AIAG plans to sponsor
multi-vendor IPsec interoperability testing during the Spring of 1997.
OPEN ISSUES
IPSEC MIBs (controversial because of missing SNMP security),
How to deal with compression,
MAC truncation (raised by Hugo),
ISAKMP CRL and ARL distribution (supported by Kent and Wiener)
----------------------------------------------------------------------