[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Minutes for the SLC IPSEC meeting
Enclosed please find draft minutes of the IPSEC wg meeting in Salt Lake
City. My apologies for the lateness of these minutes; between the
holidays and my also serving on nomcom, things have been just a little
hectic as of late.
Please look these over and make any comments as soon as possible, as
minutes are due at the Secretariat by 5:00 Eastern on Monday. Many
thanks!!
- Ted
Minutes of IPSEC wg Meeting, December 2001
These minutes were based off of notes graciously taken and submitted by
David Black, from EMC.
Wednesday, December 12, 2001 (15:30 -- 17:30)
Agenda Bashing (Ts'o)
The following agenda was presented and discussed:
Wednesday, December 12, 2001 (15:30 -- 17:30)
* Agenda Bashing (Ts'o)
* SCTP/IPsec draft (Angelos)
* IPSEC over NAT (Dixon)
* IP Storage Security (Aboba)
* AES Cipher document(s) (Herbert / Frankel)
* Revised ESP (Kent)
* IPSEC performance (Angelos)
* Suggested Identity draft (Sommerfeld)
* Transport Mode for Virtual Networks (Touch)
* IKE Implementation Issues (Richardson)
* Son-Of-Ike Requirements (Madson)
Thursday, December 13, 2001 (9:00 -- 11:30)
* JFK proposal (Angelos / Bellovin)
* IKE V2 proposal (Radia / Dan Harkins)
* IKE-SIGMA (Hugo / Bitan)
* Requirements and Comparison of SOI approaches (Kaufman)
* SOI Performance comparison (Rescorla)
* Son-Of-Ike Requirements (Madson)
* Open Mike Period
SCTP/IPsec draft (Angelos Keromytis, Columbia University)
=========================================================
Slides available in postscript.
Angelos gave a description of the issues raised in WG last call. The main
issue was to rename ID_RECURSE to ID_LIST for clarity. A new draft will be
issued to address this and a few other minor issues, and the document will
then be sent to the IESG.
IPSEC over NAT (William Dixon, Microsoft)
The NAT Traversal documents are in last call. There was recently
implementation testing among 8 vendors against various NAT devices. What was
tested was L2TP in IPsec transport mode and in tunnel mode based on IKE
extensions of IKE-CFG/XAUTH or IPSRA DHCP.
The results from this testing revealed some problems. Certificate
fragmentation was a major cause of problems. In addition, some devices seem
to be looking at IKE cookie states and hence cause NAT traversal not to
work.
A list of possible approaches to avoid fragmentation was discussed. Some
testers implemented fragmentation avoidance via multiple UDP packets
(fragment above UDP to avoid IP fragmenting below UDP). Something will
likely need to be done here, since fragmentation will be a real deployment
obstacle.
IP Storage Security (Bernard Aboba, Microsoft)
==============================================
Slides available in Powerpoint format.
IP Storage WG has adopted IKE and IPsec as basic security mechanisms. The
IPS working group has dependencies on various IPSEC and IPSRA wg I-D's,
including IPsec transforms (3DES, HMAC-SHA1, AES-CTR, and AES CBC MAC
w/XCBC), and tunnel mode config/auth (draft-ietf-ipsec-dhcp-13.txt - being
done in IPSRA WG)
A number of issues are under discussion. Please read
draft-ietf-ips-security-06.txt and send comments to the IPS WG mailing list
(ips@ece.cmu.edu) or the draft authors (iscsi-security@external.cisco.com).
AES Cipher document(s) (Sheila Frankel, NIST and Howard Herbert, Intel)
Three AES Cipher documents were discussed (one encryption, and two MAC
algorithms):
1. AES cipher: CBC with random IV. 128 bit key is mandatory, 192 and 256
are optional, key length attribute is mandatory in IKE Phase 1 and
Phase 2. Have suggested DH groups for various AES key lengths, and
authors will resolve this with other different key length
recommendations (e.g., Hilary Orman's key length comparison draft).
2. HMAC-SHA-256: Motivation is to increase the key space so that rekeying
frequency can be reduced. The hash is truncated to 96 bits to avoid
packet size changes.
3. AES-XCBC-MAC-96: Problem is that CBC MAC isn't secure for variable
length messages. XCBC corrects this and has no patent issues --- do not
confuse this with a new proposed "combined" AES
confidentiality+integrity mode that does have serious IP issues.
Comments from one of the original XCBC authors will be incorporated,
test vectors added, and next version of draft is due in January 2002.
Revised ESP (Steve Kent, BBN/Verizon)
=====================================
Steve presented some proposed changes to ESP. The changes had a few
clarifications (such as using "integrity" instead of "authentication"), and
a number of substantive changes:
* Sequence number extension - This is needed to support higher speed
systems, and anticipates AES and its longer lived connections. New
sequence numbers are 64 bits, but only 32 bits are carried in each
packet. The next version of the draft will have in its appendix a
suggestion on how to deal with the rare case where 2^32 packets from
one SA are dropped.
* Support for combined modes - New algorithms have emerged that can do
integrity and confidentiality in one pass. This requires slight changes
to ESP packet format - algorithm has to specify how it checks
integrity, as this can't be specified once for all possible combined
modes.
* Improved traffic flow confidentiality - only for tunnel mode, most
effective between a pair of security gateways. Have expanded the
allowed padding (put "junk" behind the IP packet, and encapsulated IP
header's length field will automatically cause receiver to ignore the
"junk"). Also suggest a convention that the next header field of "59"
in the ESP frame be used to indicate that there is no IP packet ---
this allows dummy packets to be sent and discarded quickly to obfuscate
traffic analysis.
There were some discussions about fragmentation, and whether we can "just
say no" to fragments. Steve Kent observed that fragmentation in IPsec has
disastrous performance implications, and causes receiver administration
issues because port selectors can't be applied to fragments (have to
reassemble), which in turn leads to a denial of service vulnerability based
on consumption of reassembly resources (e.g., buffers). Also see NAT
discussion about other problems caused by fragments.
Several problems with simply getting rid of fragments were raised as the
discussion continued:
* Some systems still don't do Path MTU discovery and this is made worse
by firewalls that discard ICMP and hence break Path MTU discovery.
* IKE/NAT problem only affects IKE messages that carry certificates.
That's a much smaller scope than ESP in general.
* We have no choice but to deal with fragments on reception, as one can't
be sure sender send DF or some intermediate system paid attention to
it. Not sending fragments is a good idea.
* Some firewalls don't like either fragmentation or ICMP, making the
situation impossible as fragments get dropped and Path MTU discovery
doesn't work. (Steve Kent observed that if the firewall is broken
regardless, we should do the simplest thing in ESP.
Steve then discussed other document revisions which he is planning to do:
* AH - revision early next year based on ESP revisions (e.g., extended
sequence numbers)
* Architecture document - revision before Yokohama to simplify processing
model, reduce requirements for nested SAs, remove MUST for AH, selector
changes (e.g., along lines SCTP needs, plus allow ICMP selectors).
There was a discussion about whether or not the distinction between tunnel
and transport modes could be eliminated. Steve Kent responded that the
problem is making sure that the right selector checks happen; Joe Touch's
VPN draft is a good model to follow. Steve rejected a proposal to remove the
tunneling specification from IPSEC, and to simply reference some other
specification (such as IP-IP tunnel), on the grounds that
encapsulation/decapsulation decision on whether or not to propagate fields
have security consequences, and thus need to be made based on local security
policy decisions.
IPSEC performance (Angelos Keromytis, Columbia University)
==========================================================
Slides available in postscript format.
Angelos gave a presentation which measured the performance of IPSEC using
DES, 3DES, and AES in various scenarios, using both hardware and software
implementations.
Suggested Identity draft (Bill Sommerfeld, Sun)
===============================================
Bill Sommerfeld discussed an individual I-D submission
(draft-keromytis-ike-id-00.txt) which adds a suggested identity field to the
IKE negotiation. This addresses the problem of how to figure out which IKE
identity to use when there's more than one. The field is added to
initiator's message 5 and HASH_I. Allows initiator to suggest which id
responder should use to avoid confusion. This is needed for for User-to-User
keying and Responder-initiated rekeying.
Bill would like this to be adopted as a WG draft. He requested that the
working group read the I-D and comment on mailing list.
Transport Mode for Virtual Networks (Joe Touch, USC/ISI)
========================================================
Slides are available in Powerpoint and PDF format.
Joe gave a presentation on issues relating to using tunnel-mode IPSEC and
hop-by-hop routing. This causes complications because you either need to
violate layering one way or another (for example, the routing layer has to
update IPSEC configuration as the routing changes).
Joe presented a solution which uses IP-IP encapsulation (RFC 2003) and IPSEC
transport mode. The result is syntactically identical to IPSEC tunnel mode,
although security checks which are done upon receipt and decapsulation of
the packet are different.
Joe then asked the question of how the working group should handle
draft-touch-ipsec-vpn-*.txt. Should it become an informational RFC, or a
BCP? He also requested that the next revision of RFC2401 require transport
mode in gateways and allow the approach which he outlined. He also requested
that in the son-of-ike proposals, that tunnel configuration be separated
from keying.
There was then a discussion about the order in which key selection and
forwarding should be done. The resolution is that having forwarding select a
virtual interface and using SPD per virtual interface is allowable by
current documents (this is what Joe wants), but the current 2401 text could
be clarified.
IKE Implementation Issues (Michael Richardson)
==============================================
Slides available in Postscript format.
Michael Richardson discussed draft-spencer-ike-implementation-00.txt, which
documents a number of implementation issues noted by the Free S/WAN
developers. The first major issue is whether "unique" IKE message Id's have
to be truly unique, or whether they just need to be generated in a
pseudo-random fashion, and simply "probably unique". Many implementations do
the latter, and the RFC's are ambiguous on this point. Michael would like
the RFC's to be changed to make it clear that implementations must keep
track of every message id ever issued by an implementation to guarantee
uniqueness.
The second issue related to how rekeying phase 2 SA's should be handled, and
Michael proposed a scheme where the new Phase 2 SA is starts getting used
immediately for transmission as it is negotiated, but the old SA is kept for
in-flight messages.
The Draft also contains a bunch of other things about IKE (e.g., pieces of
IKE that Free S/WAN didn't implement, and whose absence has not caused
interoperability issues).
Son-Of-Ike Requirements (Cheryl Madson, Cisco)
==============================================
Cheryl Madson discussed her I-D,
draft-ietf-ipsec-son-of-ike-requirements-00.txt. The goals of this document
were to describe the characteristics of an optimal protocol, and to provide
scoping by describing the scenarios which the protocol must be able to
accommodate. Explicit non-goals were (a) discussing security requirements
(which is tough to do in a fashion which is meaningful, but which doesn't
favor one proposal or another), and (b) determining the exact split of
responsibility between Son-of-Ike and other protocols for the entire set of
things that are needed to set up a secure connection.
Cheryl listed the following desirable characteristics:
1. Extensibility. Can't add payloads to IKEv1, as it results in failure of
negotiation. Vendor-ID has been used to work around this, but it's not
a good solution.
2. Modularity.
3. Improved Convergence. It's too easy for IKEv1 participants to get out
of sync with each other (e.g., SA deletion, error conditions)
4. Simplicity, both in terms of overall protocol functionality extent, and
ease of accomplishing a particular function.
5. Better discussion/specification of authentication to deal with "IKE
requires X.509" myth and remove sources of interoperability problems.
A proposed way of accommodating this would be to allow authentication
to be plugged in via companion drafts, while keeping the base draft as
simple as possible.
Document currently contains the following scenarios (list is incomplete):
* Site to site VPN
* Remote access
* End to end
* Mobile IP
The working group is asked to review the document, and propose additional
scenarios as appropriate.
Thursday, December 13, 2001 (9:00 -- 11:30)
==========================================
JFK proposal (Angelos / Bellovin)
=================================
JFK Design Process - Steve Bellovin, AT&T Labs - Research
---------------------------------------------------------
Slides available in Postscript and PDF format.
Steve Bellovin started by describing the design principles that were used in
writing JFK.
The JFK team decided that patching code to preserve IKE is the wrong thing
to do - IKE is already too complex, and complexity leads to security bugs.
Wanted provable correctness, DoS mitigation, no negotiation. Orthogonal
design and clean, well-defined interfaces to cryptographic core. IKEv2
authors have done a great job in simplifying IKE, but the result is still
too complex.
Current draft documents only the cryptographic core, if WG views this
direction as valuable, a complete version of the draft will be available for
Minneapolis.
JFK currently requires certificates. IKE's multiple modes were also removed.
Current pre-shared (secret) key approaches are to be replaced with
self-signed certificates or IPSRA certificate retrieval. For legacy
authentication, IPSRA or KINK should be used.
Phase 1 vs. phase 2 distinction was also removed. This was motivated in part
by DES weakness that required frequent rekeying - AES does not have this
problem.
The JFK design team is prepared to modify JFK to match developing state of
requirements, since the requirements draft is still a work-in-progress.
JFK Protocol - Angelos Keromytis, Columbia University
-----------------------------------------------------
Slides available in Postscript format.
Angelos described the actual details of the JFK protocol. In essence, JFK
uses a two round trip protocol. The responder keeps no state between receipt
of messages 1 and 3 to avoid denial of service attacks. More details are
present in the slides and in JFK I-D. Angelos noted that the draft describes
keying a unidirectional SA, but it would be straightforward to key a pair of
keys (one for each direction) as IKEv2 does.
One notational error was noted in the slides; there were four exponentials
used (g^x, g^y, g^i, and g^r), but there should have been only two
exponentials in use. (g^x and g^y should have been g^i and g^j,
respectively).
In JFK, the Responder exposes her identity in Message 2, but the Initiator's
identity is protected. To protect responder's identity, pick up Hugo
Krawczyk and Ran Cannetti's suggestion to incorporate SIGMA ideas into JFK -
this protocol is being called LBJ.
4 implementations of JFK are being done by students at Columbia - 2 in Java,
1 in C, 1 in Perl. The Java implementations are interoperating, C and Perl
aren't quite there yet. About 3 weeks of student effort so far. C and Perl
implementations are running into crypto library issues (e.g., padding is
different in different libraries). Converting a JFK implementation to LBJ
took a student about a day.
The sizes of the messages are at most a few hundred bytes plus the
certificates. Comment: JFK has imperfect forward secrecy. Same D-H exponent
used across multiple exchanges with forward secrecy established once that
exponent is replaced. Perfect forward secrecy would require state to be kept
after receipt of message 1.
Comment: Can IKE payload formats be used? Yes, message format in JFK draft
was chosen for expediency and is simpler than IKE's, but can use IKE's
payload formats.
Comment: Phase 2 can be useful for more than rekeying, and ability to
amortize cost of public key operations is valuable. This needs to be taken
up in requirements discussion.
Proof of security is in the works - not completely done yet.
IKE V2 proposal (Radia / Dan Harkins)
=====================================
Slides available in Postscript format.
Most of the work in IKEv2 was in the rest of the stuff that surrounds the
cryptographic exchange. IKEv2 also has a 4-message exchange, but this other
stuff is at least as important.
The goals of IKEv2 were listed as follows:
* Consolidate RFCs 2407, 2408, and 2409 into a single document.
* No gratuitous changes, but simplify as appropriate (e.g., phase 2 has
been kept, now 1 possible phase 1 exchange as opposed to 8 in IKEv1).
* Fix ambiguities and bugs.
* Add flexibility where necessary (e.g., selectors)
* Reduce latency by reducing message count.
* Allow stateless cookies
IKE SA + IPsec SA in established in 4 messages based on public signature
keys. Both identities are hidden from passive attackers. Subsequent child
SA's require two messages to set up. All messages are request/response, and
messages have sequence numbers. Multiple concurrent requests can be issued
in parallel.
Version numbers and critical flag defined to enable future changes and
extensions, to provide for forward compatibility.
Traffic selectors have been generalized. Responder can narrow ranges.
Cookies (initiator-responder pair) are used to identify IKE SAs.
In IKEv2 SA lifetimes are NOT negotiated. Either side can rekey at any time,
and rekeying the IKE SA inherits all of the child SA's. No dangling SA's are
allowed. If an unauthenticated ICMP/IKE message raises a suspicion about a
dead peer, this is checked by sending a reliable IKE message; if there is no
response, the SA is deleted.
The way IKEV2 messages are encrypted and integrity protected is done using
the ESP format, but this was simply a reuse of the syntax, and not the
protocol. This caused some confusion because some people thought this
resulted in a bootstrapping problem, where as it was merely the intention of
the document authors to be lazy and not need to reinvent the wheel. The next
version of the IKEv2 draft will copy the ESP syntax by value instead of by
reference to eliminate this confusion.
IKEv1 has a problem with security parameter negotiation in that each
additional parameter to be negotiated results in an exponential explosion of
possibilities. To address this, IKEv2 uses a "chinese menu" approach ---
i.e., any of these encryption transforms with any of these integrity
transforms.
The following comments were made by members of the working group:
* Rekeying IKE SA should use PFS.
* Critical bit on options has been abused to defeat interoperability in
other protocols
IKE-SIGMA (Sara Bitan, Technion)
================================
Sara Bitan gave this presentation since Hugo was not able to attend the IETF
meeting.
The focus of IKE-SIGMA is crypto design, similar to JFK. Get this right,
then add the rest of the structure, which is orthogonal to the core key
exchange crypto protocol.
SIGMA supplies full or windowed PFS, identity protection (against active or
passive attacks) and DoS resistance. The protocol is flexible to allow
choices in these areas.
The presentation was a walk through of the cryptographic thinking that leads
to the design of the SIGMA exchanges. Strong binding of identities of the
participants to the key exchange is an important theme - leads to a
requirement for each sender to MAC its own identity in the protocol. Several
variants of SIGMA protocol based on different choices of security
properties/features were described.
Requirements and Comparison of SOI approaches (Kaufman)
=======================================================
Slides available in Powerpoint format.
Charlie Kaufman gave a presentation which compared the security properties
of the various SOI approaches, as described in the I-D at the time of the
meeting.
The differences between the various protocols' security properties can be
broken into a number of different areas:
Performance - number of messages, number of exponentiations, size of
messages, amount of data that needs processing. There were no major
performance difference in computational time among proposed new protocols.
Stateless cookie - defense against computational denial of service attack.
This is easy to do with two extra messages. IKEv1 doesn't support this. JFK
can piggyback this (no extra messages). SIGMA puts in two extra messages
when under attack. IKEv2 can do either.
Identity hiding - again, easy to do with extra messages. Discussion of
identity hiding properties, consequences. JFK exposes Bob's identity, no
other protocol exposes either identity. JFK and SIGMA as published are
subject to polling attacks (poll IP address, discover Bob is there), but
IKEv1 and IKEv2 allow Alice to be tricked into revealing her identity - this
is a "no-free-lunch" tradeoff as one or the other has to be possible based
on who reveals their identity first.
Dead Peer detection - relying on ICMP opens up a denial of service attack
based on forging ICMP messages. IKEv2 bans dangling SAs and relies on ping
over IKE SA to avoid this. Other protocols don't say anything, but this is
also not a problem in practice (yet). Putting ping into ESP and AH may be an
alternative.
Plausible Deniability. JFK - can prove that the two named parties
intentionally talked to each other. Others can prove that each named party
talked to someone. Use of pre-shared key (or IKE encryption key) can make it
impossible to ever prove anything.
Parameter Negotiation - seems to be necessary for various reasons. Need to
avoid active attack that results in weakened crypto. JFK has Bob choose IKE
parameters, will add ESP/AH negotiation later. IKEv2 has same abilities as
IKEv1, SIGMA continues IKEv1 approach.
IKEv2 intends to replace RFC 2407, 2408, and 2409. Other two currently
supplement them, but JFK intends to get to same level of completeness as
IKEv2
SOI Performance comparison (Eric Rescorla)
==========================================
Eric Rescorla gave a presentation which counted the number of messages and
cryptographic operations (i.e., D-H key agreement, RSA private key
operations, etc.) to give a comparison of the various SOI proposals.
Son-Of-Ike Requirements (Cheryl Madson, Cisco)
==============================================
After the presentation of the SOI proposals, Cheryl Madson returned to lead
a continued discussion on the requirements draft. One of the key areas which
still needs more effort in the requirements draft is the scenarios
description to provide protocol scoping. The individual scenarios need
refinement; in addition a model to evaluate the scenario is still needed.
There is also a need to figure out where the homes are for things that IKE
will not do that are still important and get those specs done in the same
timeframe as Son-of-IKE. If some of this is involved in connection
establishment, the state machine specification should accommodate this.
In general, we want minimal message size and count, minimal processing
expense (including light-weight devices and restart hit after crash on a
large server).
Open Mike Period
================
Jeff Wong (Cisco): Limit amount of policy provisioning in IKE to stuff
absolutely required to set up IPsec SA and tunnel (if used). Policy
provisioning in general is arbitrarily complex.
Hilarie Orman (Novell/Volera): Move all policy stuff into a separate
protocol, e.g., see the IPSRA work.
William Dixon (Microsoft): Scenarios are the most important piece of the
requirement discussion.
Cheryl: Want all the help that I can get in this area.
Michael Thomas (Cisco): Most IKE problems are in the mundane protocol
operations stuff, not the crypto itself. Recovery from restart avalanches is
an important issue in practice today - KINK is in better shape on this than
IKE, and needs to be looked to for examples.
Phil Hallam-Baker (Verisign): XKASS is a serious proposal in XML world - may
or may not be appropriate for IPsec based on requirements. Need to think
about whether credential needs to include identity information, as identity
hiding is easy if there's no identity to hide.
Paul Hoffman (VPN Consortium): Transition from and coexistence with IKEv1 in
a non-confusing fashion is important.
Steve Bellovin (AT&T Labs Research): Strongly agree that the non-crypto
stuff needs attention (Steve is one of the JFK folks).
Cathy Meadows (??): Wants clarity on JFK vs. IKEv2
requirements/philosophies/approaches to SA negotiation.
Steve Bellovin: Can WG please tell us what the requirements are? Absent
that, JFK will pursue an approach of "here's what I want" responded to with
"Yes" or "No and here's why". Aim is to reduce options/negotiations.
Radia Perlman: IKEv2 follows general approach of IKEv1 with compaction and
simplification. Could also follow TLS approach of offering entire suites as
opposed to independently negotiating components. Locking down to a single
crypto suite seems to be too restrictive.
William Dixon (Microsoft): A real scenario for identity hiding is that
Microsoft would not like to reveal that a home PC is owned by MS and used by
an MS employee, as hackers are specifically targeting those.
Eric Rescorla (??): Have seen four key exchange protocols and four variants,
and they are similar at a high level (e.g., number of round trips). What if
we started with the protocol infrastructure and then plugged in the crypto
(any of these proposals seems workable)?
Uri Blumenthal (Lucent Bell Labs): Legacy authentication will live on for a
long time - please do not limit new algorithm to public key.
Markku Saavla (sp? Siemens): Can we identify scenarios that are out-of-scope
in addition to scenarios that we do need to support?
Cheryl: Something like that - scenarios in requirements draft were intended
as the "absolutely crucial to support" ones.
Charlie Kaufman (IBM): IKEv2 copied IKEv1 syntax to avoid changing things.
JFK picked up a new, cleaner syntax, but this issue is fundamentally a
matter of taste. How can we avoid spending too much time in this sort of
rathole? Suggests that negotiation approach needs to be resolved early
(e.g., reduce everything to a small number of crypto suites, and force
things like "vanity crypto" to use vendor payloads).
Cheryl: Use of suites simplifies protocol analysis.
???: Managed IP service provider is concerned about credential management
and delivery - need a pre-shared mode of some form, as this is easy to
manage. Please consider credential delivery and management as part of
Son-of-IKE.
John Ionnadis (??): Split requirements into three categories -
Cryptographic, Operational, and Policy (e.g., negotiation). Pursue these
more or less independently and in parallel.
Barbara Fraser (Cisco, co-chair): Yes, something like that is important to
structuring the discussion and draft (or drafts). Scenario discussion is
also important to this.
Ted Ts'o (IBM, co-chair): Yes, discuss these independently on mailing list
and close them independently.
Dan Harkins (??): Would like to delete some of the proposal parsing stuff
from IKE (AH and/or ESP and/or IPcomp).
Kathy Meadows (??): Supports this, suggests formal language for expressing
proposals.
Jeff Schiller (Security AD): If WG spends too long debating proposals, AD
will consider shutting it down. This area is reasonably well-understood and
hence coming up with a reasonable solution should happen in short order. WG
chairs will be asked to come up with a schedule, and hold WG to it.