[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Draft minutes from the WG meeting
Greetings. Below are the draft minutes of the IPsec WG meeting last
week in Atlanta. If you were at the meeting and spoke, please review
them and send any corrections to me. I will change these draft
minutes into a final version to be sent to the IETF Secretariat for
inclusion in the official minutes of the meeting.
If you read somthing here that you want to discuss on the mailing
list, please change the subject line to indicate the specific topic
you want to talk about. Thanks!
----------
Minutes for IPsec WG
November 18, 2002
Agenda was considered and accepted
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.
Minutes taker: Paul Hoffman, VPN Consortium
Apologies in advance for spelling errors, particularly in
people's names.