ipsec@conference.ietf.jabber.com - 2002/11/18
[09:11] %% logger has arrived.
[09:17] %% logger has arrived.
[09:24] %% logger has arrived.
[09:31] %% logger has arrived.
[10:39] %% bensons has arrived.
[10:58] %% bensons has left.
[11:51] %% logger has arrived.
[17:42] %% jis has arrived.
[17:45] %% hartmans has arrived.
[17:50] %% smb@research.att.com has arrived.
[17:52] %% paul.knight has arrived.
[17:54] %% smb@research.att.com has left.
[17:54] %% smb@research.att.com has arrived.
[17:54] %% smb@research.att.com has left.
[17:54] %% smb@research.att.com has arrived.
[17:57] %% avri has arrived.
[17:57] <smb@research.att.com> Hugo talking about http://www.ee.technion.ac.il/~hugo/sigma.ps (or .pdf)
[17:59] <paul.knight> SIGMA underlies IKE and IKEv2
[17:59] %% mrose has arrived.
[18:07] <paul.knight> Gregory Lebovitz mentions "Project Deploy" in relation to the profile draft
[18:11] <paul.knight> Brian Weis on draft-bew-ipsec-signatures-00.txt
[18:13] %% jis has left.
[18:13] <paul.knight> digital signature better than HMAC for authentication for groups...
[18:15] %% jis has arrived.
[18:15] %% avri has left.
[18:16] <paul.knight> RSA with relatively small keys (496 bits) may work for a digital signature
[18:18] <paul.knight> Issues include possibly more susceptibility to DoS attack due to higher processing needed for RSA
[18:20] <paul.knight> Hillary Orman - It's about time! ... demultiplexing how about elliptic curves as a threat?
[18:21] %% pjnesser has arrived.
[18:22] <paul.knight> anyone else can add notes too!
[18:24] <paul.knight> Tomoaki Kobayakawa - IPv6 and IPsec Deployment Issues
[18:28] <paul.knight> NTT and others already deploying IPv6 in Japan, to support peer-to-peer communiction using global IP addresses .. "grandma in the country" - to share high-resolution media; also online gaming
[18:30] <paul.knight> Control multiple small sensors - needs confidentiality and strong authentication - example: buy 1000 sensors and scatter them around a farm with no configuration
[18:31] <paul.knight> Issue : need to promote ubiquitous encryption for general IPv6 communication
[18:32] * smb@research.att.com has changed the subject to: http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/ipsec/
[18:33] <paul.knight> Goal - virtually zero configuration for end users - plug-and-play features - not mandate PKI
[18:33] <paul.knight> Commercial IPv6 players need a solution
[18:34] <jis> Hugh: I want to set the keys in my devices
[18:34] <paul.knight> Hugh Daniels
[18:36] <paul.knight> Steve Belovin: do't think these devices will be plug-and-play ... the hard part is authorization
[18:39] <paul.knight> Kobayakawa-san: examples progressive application of IPsec; using a trusted third party (not proposals, just possible examples)
[18:39] <paul.knight> jis and others, keep adding notes!
[18:41] <paul.knight> Gregory Lebovitz: it has a market, like a phone answering machine with pre-set key
[18:42] <paul.knight> Q: next step for draft? Key management protocol?
[21:09] %% logger has arrived.
[21:44] %% logger has arrived.
[06:33] %% mrose has arrived.
[06:43] <mrose> here is what the logger missed:
2035 <paul.knight> A: I want a protocol to be proposed to address this...
2037 <jis> David McGrew: Analysis of AES Counter Mode...
2037 <paul.knight> David McGrew - Counter Mode Security: Analysis and Recommendations
2037 <jis> Cm Can be implemented securely
2037 <jis> But is more vulnerable to precomputation attacks
2038 <jis> Because each packet doesn't have a random input (IV)
2039 <jis> Attacker can precompute data to use in attacking many traffic encrypting keys
2039 <jis> But it can be made better
2040 <jis> Need non-predicable initialization or use larger key
2040 <jis> (i.e., use random value field in initial counter)
2042 <paul.knight> Proposal is to use a randomizer in the initial counter value - it replaces the SPI, and is larger than the SPI field, using smaller IV and counter
2043 <paul.knight> shrinking the counter means it's hard to protect jumbograms
2047 <paul.knight> Since it's easy to add the security without incurring the computational tradeoff, we should probably consider this
2047 <paul.knight> Good list of questions in the presentation:
2048 <paul.knight> 85 or fewer bits of security acceptable?
2048 <paul.knight> inability to encrypt jumbograms acceptable?
2048 <paul.knight> implement and use AES-192?
2049 <paul.knight> Do we need an explicit IV? multiple receiver case vs. bandwidth is the tradeoff
2050 <paul.knight> For high bandwidth (10 Gbps) counter mode appears to be the only way to go; few IPR-free alternatives
2051 <paul.knight> crypto forum Research Group: www.irtf.org/cfrg
2052 <paul.knight> Q: Not sure of practicality of this attack..
2052 <paul.knight> A: Then are you saying 85 bits of security is enough?
2054 <paul.knight> Dave: want to get fast action on the list
2055 <paul.knight> Ted Ts'o - need to have good crypto review
2057 <paul.knight> Charlie Kaufman - Son of IKE Status
2057 <paul.knight> hanges
2058 <paul.knight> a la carte replaced by suites (controversial)
2058 <paul.knight> always 4 messages (controversial) etc etc.
2059 <paul.knight> NAT Traversal:
2100 <paul.knight> draft extending IKEv1 - does it apply to IKEv2? Should it be included in IKEv2?
2100 <paul.knight> Tunnel vs. Transport?
2101 <paul.knight> - not negotiated in IKEv2 .. is it needed? Interaction with NAT?
2102 <hartmans> What was always four messages?
2102 <paul.knight> MUST/MAY key sizes and algorithms .. no consensus clear
2103 <paul.knight> NUmber of messages: (IKE messages to create SA)
2104 warlord has arrived.
2105 <smb@research.att.com> (I'm writing up this whole talk, and will post when over.)
2105 <paul.knight> 4 messages unless: messages lost on network, initiator misguesses DH group, or initiator deciding he's under attack
2106 <hartmans> *sigh* I guess I need to pay attention to ikev2 with my Kerberos hat on
2106 <smb@research.att.com> I think that that's KINK anyway
2106 <warlord> Hmm, sounds like I need to get over there, eh?
2107 <smb@research.att.com> Not really -- not much discussion
2108 <paul.knight> Use legacy method before IKE? ... but recursion problems, especially with firewalls; may need PKI
2108 <mrose> just fyi: when the logger comes back up, i'll post the activity it missed when it was down.
2108 <smb@research.att.com> That's a strawman
2108 <paul.knight> For the true story, read Steve's write-up.
2110 <paul.knight> Did the volume of text kill the logger?
2113 <smb@research.att.com> it's a generic logger issue -- it vanished from many rooms.
2113 <mrose> paul.knight - no, the volume didn't kill it...the thing's some damn perl script...not what i'd call production code...
2113 pjnesser has left.
2114 <paul.knight> Suites, a la carte, or sweets a la carte?
2115 <smb@research.att.com> uite
2117 <smb@research.att.com> but that's my preference
2118 <warlord> I'm sort of mixed.
2118 <warlord> I like the ala carte ...
2118 <warlord> but there are certainly combinations that "dont work"
2118 <jis> which is why suites are good (as are sweets)
2120 <warlord> Yea, but you have to define n^2-epsilon suites as you add n different ciphers/hashes, etc.
2120 <jis> yep... but you don't *really* need to do that
2123 <warlord> No? Then what suites do I need to add when I want to add AES?
2123 <jis> You add an AES Suite with an appropriate Hash (SHA-256?)
2123 <smb@research.att.com> But new algorithms are added very rarely, and many combinations don't make sense
2123 <paul.knight> How many new ciphers are ikely in next 10 years? Hashes?
2124 <jis> Guess -> 5
2124 <jis> Or a working group (You have to be here)
2127 <smb@research.att.com> in the last 25 years, there have been exactly 3 *important* cipher choices -- des, 3des, aes (others are fads), and 2 or 3 hashes (md4 (maybe), md5, sha1). Double that for keyed hash vs. hmac
2127 <smb@research.att.com> ok, here come my notes on charlie's talk
2127 <smb@research.att.com> Changes in new draft:
suites (controversial)
JFK's 4 messages (always controversial)
JFK's traffic selector simplification
traffic selector narrowing clarification
crypto detail clarification
NAT traversal
use IKEv1 extensions with IKEv2?
Tunnel vs. transport negotiation
Not in v2
if inner==outer IP, MAY use transport instead of tunnel (some
say)
may interact with NAT
Key sizes and algorithms
1024 vs. 1023 vits? DSS support? MUST vs. MAY
consensus on change to certs
no consensus on suites vs. a la carte
Number of messages -- 4 unless
Messages lost on net (all)
Initiator misguesses DH group (JFK and old IKEv2)
Initiator decides being attacked (old IKEv2)
Cost of 4 mesgs
Complexity of statelessness
Partially-encrypted msg 3
Messages larger => UDP fragmentation
May impact legacy authentication
CRACK integrates better with oIKEv2
Legacy
Mostly road warrior
username/pw
securid
challenge/response card
OTP
Kerberos
others?
Past approaches to legacy auth
xauth
crack
ipsra/pic
Options
Ignore? Can't
Don't hold up IKEv2 while deciding (but 4 vs. 4/6 issue)
Use pw as shared key
dictionary attack
passwords only
design it in
sasl?
eap?
modify xauth/crack/pic?
start over?
Suites vs. a la carte
IKEv1 -- millions of possibilities/responder selects
oIKEv2 -- more efficient; same flexibility
JFK: responder selects one of (very) many possibilities (currently
small)
current IKEv2: propose subset of suites
Advantages of suites:
easier to specify and implement if number kept manageable
Advantage of a la card:
Easier if many
Easier to add new <xyz> and have it work, i.e., new elliptic
curve DH group wouldn't need all new suites
Options
Leave it as suites
change back to a la carte
cleverly-chosen multi-byte suite IDs
both? MUST suites, MAY a la carte?
Paul Hoffman's Revised Identity - several proposals wrapped:
certreq renamed TrustedRoot
dates back to isakmp
intended for bootstrapping directory access
used for listing trust anchors
current: DN of anchors
RI: SHA1(key of anchors)
charlie: copy TLS, whatever that does
allow URLs to certs
certs are large
UDP fragmentation
other end might already know
but -- can't always (no URL)
What's MUST, SHOULD, MAY for interoperability?
Negotiate authentication algorithms
new IDAccepted field
needed if multiple ways to authenticate and want to
autoselect
RSA cert, DSS cert, etc.
username/pw
other legacy
could be hidden in extended certreq
merge ID and CERT into FullID
today:
id required; cert optional
rules for matching id and cert unspecified
with legacy auth, things like CERTs (but not CERTs)
might be needed (i.e., Kerberos tickets)
proposal:
merge fields and allow more encodings
How do we reach RFC?
chose between multiple bales of hay
integrate nat traversal now or later?
integrate legacy auth now or later?
charlie's prefs:
crypto tweaks recommended by Hugo (and minor
tweaks from others)
chose the bales in the current spec (or decide
today)
work on nat and legacy in parallel with advancing
this spec
2129 <paul.knight> A point of extensibility has gotten lost in the suites vs. a la carte debate
2130 <paul.knight> Q: There is no use in publishing it if it does not support NAT. It's not the user's fault for being behind NAT.
2134 <paul.knight> Hillary Orman: issues not in key negotiation should be put into a different "policy" issue document (or WG?)
2136 <paul.knight> Problem with splitting things into other docs or WGs is that we lose momentum
2137 <paul.knight> Charlie: I didn't want to split things...
2139 <paul.knight> Jeff Schiller: rest of IETF wants to consume this technology. It's time.
2140 <paul.knight> We don't have to be perfect. If it doesn't finish soon, we will terminate it and the answer will be IKEv1.
2140 <paul.knight> I would like to see a timeline to get IKEv2 at IESG on Feb. 15 2003.
2141 <paul.knight> Go Jeff
2143 <paul.knight> Q: What does IKEv2 offer beyond IKEv1?
2144 <paul.knight> Jeff: Why are they waiting? To only implement it once.
2144 hartmans has left.
2144 <paul.knight> Jeff - let's resolve the 4 vs. 6 message question in the next 15 minutes. - A challenge!
2148 <jis> tick tick tick
2150 jis has left.
2153 <paul.knight> Can the chairs quickly put the proposals in writing on the screen before humming?
2154 <paul.knight> Humming supports 4/6 messages over 4.
2156 <paul.knight> Jeff: Next challenge: Suites vs. A la carte? 5 minutes!
2158 <paul.knight> Q: Make suites, but leave an extension mechanism
2201 <paul.knight> Jeff's question: Crypto suites or a la carte?
2201 <warlord> It;s a tie!
2204 <paul.knight> But when hands are counted, suites get about three times as many. I guess a la cartesians are louder.
2204 <warlord> I guess we are.
2204 smb@research.att.com has left.
2209 paul.knight has left.
2032 smb@research.att.com has changed the subject to: http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/ipsec/
2158 jis has left.
2201 <paul.knight> Can the chairs quickly put the proposals in writing on the screen before humming?
2202 <paul.knight> Humming supports 4/6 messages over 4.
2204 <paul.knight> Jeff: Next challenge: Suites vs. A la carte? 5 minutes!
2206 <paul.knight> Q: Make suites, but leave an extension mechanism
2209 <paul.knight> Jeff's question: Crypto suites or a la carte?
2209 <warlord> It;s a tie!
2211 <paul.knight> But when hands are counted, suites get about three times as many. I guess a la cartesians are louder.
2212 <warlord> I guess we are.
2212 smb@research.att.com has left.
2216 paul.knight has left.
2234 mrose has left.
2243 warlord has left.
[06:43] %% mrose has left.
[10:53] %% cdel has arrived.
[10:55] %% cdel has left.