Minutes for IPsec WG
November 18, 2002
Agenda was considered and accepted
Minutes taker: Paul Hoffman, VPN Consortium
Apologies in advance for spelling errors, particularly in people's names.
ID Status
AES Related Drafts
draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt
in IESG wait (AD writeup)
draft-ietf-ike-modp-groups-04.txt
in IESG wait (AD writeup)
draft-ietf-ipsec-ciph-sha-256-01.txt
not going to be advanced
draft-ietf-ipsec-ciph-aes-cbc-04.txt
submitted for IETF last call
Extended sequence number docs
draft-ietf-ipsec-esp-v3-03.txt
ready for wg last call (one last round of editing by authors)
draft-ietf-ipsec-rfc2402bis-01.txt
ready for wg last call (one last round of editing by authors)
draft-ietf-ipsec-esn-addendum-00.tx
ready for wg last call
NAT Traversal docs
draft-ietf-ipsec-udp-encaps-04.txt
ready for IETF last call for proposed standard
draft-ietf-ipsec-nat-t-ike-04.txt
ready for IETF last call for proposed standard
draft-ietf-ipsec-udp-encaps-justification-01.txt
ready for IETF last call for informational RFC
MIB docs
Discussion has been non-existent since November.
Plan to forward all of them to WG last call
draft-ietf-ipsec-doi-tc-mib-06.txt
draft-ietf-ipsec-flow-monitoring-mib-02.txt
draft-ietf-ipsec-ike-monitor-mib-04.txt
draft-ietf-ipsec-isakmp-di-mon-mib-05.txt
draft-ietf-ipsec-monitor-mib-06.txt
Others
draft-ietf-ipsec-ike-ecc-groups-04.txt
Moribund; no WG interest
draft-ietf-ipsec-sctp-04.txt
Proposed standard
IESG wait (point raised by some AD; awaiting writeup)
DPD draft - to WG last call soon
IPsec properties - prepared to help with SOI
Needs more work to be publishable
Andrew wants to do work
Ted and Barb view as a distraction
VoIP Security Requirements - Eric Nielsen
draft-jacobs-signaling-security-requirements
VoIP is really across many protocols
How can they leverage IPsec as the underlying security mechanism?
Describes the view of a consumer of IPsec
Please review it
SIGMA paper announcement - Hugo Krawczyk
New paper was published
http://www.ee.technion.ac.il/~hugo/sigma.ps
Gives the crypto rationale for IKEv1 signature modes and IKEv2 cryptographic key exchange.
Covered ancient history (1995-1996) regarding the development of SIGMA and its inclusion in IKE
Summary: don't just do a signature, also MAC the identity of the signer (the MAC is essential for the key exchange security!).
This paper is informal and intended to a broad audience of designers and practitioners. A formal mathematical analysis was done in a paper with Ran Canetti presented at Crypto'2002.
PKI profile draft - Brian Korver
Profile PKIX for IKE
Compliments IKE
-00 and -01 were straw proposals
Types of issues
CRL processing
Empty CERTREQ
Using ID payload for policy
Which fields in the cert should be used as ID
Out of band exchange of keying material
Want comments for -02
Gregory Lebovitz - Project DPloy earlier this year did much of the requirements
Paul Hoffman talked about previous document in this space. This should not make IKEv1 implementations non-conformant. Brian said he wasn't sure how he wanted it to apply to v1 or v2
Michael Richardson - thinks it should apply to IKEv1 and IKEv2
Digital signatures for ESP and AH - Brian Weis
Main need for this is source origin authentication
This is needed for multicast or anycast
ESP and AH don't specify any particular authentication mechanism, they just say where to do it.
Digital signatures are very well understood
RSA is widely implemented and is free
Also fast for verification, which is good in multicast because the receivers do less work
Still some issues
Authentication data is larger
Performance is big issue, but not so much if you have hardware acceleration
DoS vulnerability: RSA verification is much slower than HMAC
Bill Sommerfeld - Key size needs to be balanced against how long you are going to use the key
Hilarie Orman - It's about time! The demultiplexing is done in a different place. And why not use elliptic curves?
Andrea Colegrove - How do you tell IPsec who can send (and therefore sign) the messages?
Is this of interest to the WG?
IPv6 and IPsec Deployment Issues - Tomoaki KOBAYAKAWA
Deployment scenario, not a proposal for a solution
Need a solution in order to help IPv6 get deployed
IPv6 deployment status
Definitely been deployed, especially in Japan
Lots of home appliances using it
But many IPv4 users think that IPv4 is enough
If IPv6 is cheaper than IPv4, it will cause greater IPv6 deployment
IPv6 plug-and-play can be help
Authentication can come from the ISP instead of from the end user, making devices and games easier to start from scratch
IPv6 autoconf can also help with sensors and devices that need strong authentication
If we make IPv6 always use IPsec, it will appear to be more secure
Security policy should be maintained by an external trusted third party
PKI avoidance is good
Need plug-and-play IPsec for IPv6 for peer-to-peer, so please think about proposals
Hugh Daniel - Won't buy a device that he cannot set the keys in
Scott Fanning - How do you get a credential for a device from the factory?
Steve Bellovin - Doubts about plug-and-play because the lack of authorization. How would an ISP know who is the end user for connecting particular devices?
Charlie Kaufman - Protect against passive eavesdropping but others in the crypto field don't want this
Gregory Lebovitz - Consumer devices already have less security and people buy it all the time
Eric Nielsen - VoIP has similar problems of weighing the plug-and-play vs. flexibility
Atsushi Inoue - What is the next step for this proposal? Will you make a key management protocol that matches this? Kobayakawa wants to do this.
Counter Mode Security Analysis and Recommendations - Dave McGrew
Wants to raise issues for discussion
CM can be implemented securely
Properties are different but not worse
CM is more vulnerable to some precomputation attacks
Lacks per-packet random input that CBC has
Attacker precomputes and stores a database
Amortizes the computation across many breaks lowering the expected work per break
Protections against this attack
It has to be unpredictable to the adversary
To do this, use a larger key
Use AES-192 to get 128-bit strength
This requires more computation and mandates using multiple key sizes
Instead, use a random or uniform field in the initial counter
Shrink the SPI field
Won't allow protection of jumbograms
Comparison
Table showed comparison of equivalent strengths
Asked for limits of memory, some disagreement was heard
Requires a very, very rich advisory
Questions
Is 85 or fewer bits of security acceptable?
Is inability to encrypt jumbograms OK?
Is it OK to require AES-192 acceptable?
Is an explicit IV needed?
For 10 Gbs message authentication, CM is the only non-encumbered system known
Uri Blumenthal - Not related to the A5 attack. Wants more time to review the numbers to see if this is really an 85-bit attack.
Russ Housley - Appreciates bringing the issue to the wider group.
Ron Rivest said just the longer key.
Ted Ts'o - Wants people who know crypto to help analyze whether it is really a practical attack.
IKEv2 status discussion - Charlie Kaufman
New draft in October
Changed many things that became controversial:
Suites replaced ala carte
Went to always 4 messages
Simplified traffic selector (no one has complained)
Other controversies
NAT traversal
Tunnel vs. transport negotiation
Key sizes and algorithms
Legacy auth not covered
Revised identity proposal
NAT Traversal
Not in IKEv1, but now there is a draft
Should the new extensions be included in IKEv2?
Tunnel vs. transport
No negotiation in IKEv2
Charlie needs to understand why this is needed
If inner and outer IP addresses are the same,
MAY use transport
MUST key size and algorithms
1024 vs. 1023 bit keys
It's hard to have this debate until we know suites vs. ala carte
Number of messages
4 messages except a few cases
Always-4 is more complicated to be stateless
Messages are larger, which causes UDP fragmentation issues
May impact legacy authentication
CRACK-style does better with 4/6 than with always-4
Legacy authentication
Road warrior configurations
Passwords, SecureID, challenge-response cards, etc.
All have subtle differences
History includes, XAUTH, CRACK, PIC
Use legacy auth to get a cert
Recursion problem
Need a PKI
What to do
Ignore it -- not
Don't hold up IKEv2: do it later
Use password as a shared key
Has dictionary attack
Design it in
Reference an existing multiplexer like SASL/EAP or GSSAPI
Modify one of the IKEv1 solutions
Start over
Suites vs. ala carte
IKEv1: propose a subset and responder selects
Old IKEv2: same things but with a better encoding
JFK: responder decrees
Current IKEv2: defines suites, responder selects
Why people like suites
Easier to implement if the number is manageable
Why people like ala carte
Easier to implement if the number is large
Easier to add new parts
Options
Leave it as suites
Change it back to ala carte
Cleverly-chosen multi-byte suite IDs
Do both: MUST do suites but can do ala carte
Only good idea if believe many implementations don't do ala carte
Revised identity
Several proposals wrapped together
CERTREQ renamed TrustedRoot
Used to listing trust anchors
Instead of DN of trust anchor, use SHA1 of public key
Charlie wants to copy TLS
Allow URLs to certificates instead of the certs themselves
Some certs are very large
The other end might know it
But can't always use the URL
What are the MUST/MAY/SHOULDs to guarantee interop
Negotiate authentication algorithms
New IDAccepted field
Needed if there are multiple ways that you are capable of authenticating and want to autoselect
Merge ID and CERT into FullID
Today IDs is required but CERT is optional
Unstated what the relation between ID and cert are
Whatever is in the cert is the ID: need to translate for your SADB
OK, how do we become an RFC?
Choose between multiple bales of hay (bad joke elided)
Integrate NAT traversal now or later?
Integrate legacy auth now or later?
Charlie's preference
Add some crypto tweaks from Hugo
Decide now on the choices
Work on other things in parallel that can be folded into this document if it doesn't hold up the document
Ted Ts'o - If it is NAT-traversal friendly, we can do that in another document that describes how. If you leave holes in the spec, it has to be filled fast, otherwise a vendor will do it for us and we won't be able to fix it.
Tero Kivinen - It isn't NAT-traversal friendly now but it can be made so easily.
David Black - People designing suites have forgotten some things, so we need either ala carte or have a well-defined extension mechanism.
Phil Hallam-Baker- Must work with NATs or don't bother. We should think about keys, not certs. Get rid of policy from key negotiation.
Hilarie Orman - AA Milne was quoted. Suggested negotiating key policy in protocol from the IP Security Policy WG.
Eric Rescorla - TLS doesn't negotiate trust anchors at all; this is not a raging success. Maybe assume that you only have one certificate.
Cheryl Madsen - If we split off items from a single document, we lose momentum and it can take years.
William Dixon - Noticed that requirements draft died. No one was giving any feedback so there was no interest in a requirements document. The requirements are inherent in the protocol design and on the mailing list, but he wanted to be sure that the WG wanted this.
Jeff Schiller wearing his AD hat - Rest of the IETF wants to consume this technology soon. It's time. If this effort is to succeed, it must terminate. If this doesn't finish soon, we will terminate the WG and everyone has to use IKEv1. Wants a timeline that finishes by Feb. 15, 2003.
Ted Ts'o - We negotiated that date.
Cheryl Madsen - The scope of IKEv2 is VPNs and remote access.
William Dixon - What are doing that is different than IKEv1?
Paul Hoffman - We need remote access or else it looks like IKEv1.
Jeff Schiller - Can the WG decided between always-4 or 4/6 in the next 15 minutes?
Paul Hoffman - 4/6 is much better for CRACK-like.
Michael Richardson - Doesn't care about always-4 or 4/6. We should embed remote access, just take it from IPSRA. If we got good cert stuff, we don't need legacy auth, but if we are going to do it, do it now.
Bill Sommerfeld - Good if we can do always-4 if we don't do legacy auth. This might push against legacy auth.
Tero Kivinen - NAT traversal is more complicated if we do always-4, but simple to add in 4/6. We need to do port floating.
Eric Rescorla - Because 4/6 takes less thinking, we should use it.
Ted Ts'o took a straw poll. Humming happened. The consensus was 4/6.
Barbara Fraser wanted to have a meeting about legacy authentication this week.
Gregory Lebovitz - Are we also including remote configuration?
Jeff Schiller - Can you decided suites vs. ala carte in 4 minutes?
David Black and Cheryl Madsen - There is also a way to do a hybrid mechanism.
William Dixon - Needs to be able to swap in a different algorithm.
Magnus Nystrom - Prefers suites because of interaction between algorithms.
Jeff Schiller - Just decide between suites or ala carte for crypto only; other items will be decided later.
Ted Ts'o took a straw poll on crypto suite or suites. Humming happened, but it sounded close. Hands were raised. The chairs saw three times as many for suites than for ala carte.
Jeff Schiller asked who cared a great deal about the way that they voted. Only a few hands went up.
Meeting was adjourned only a few minute over time. Many folks said they would work on the remote access problem, the suites extension issue, NAT traversal, and other problems.