-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: > At 6:00 PM -0600 2/21/06, Nicolas Williams wrote: > >>On Tue, Feb 21, 2006 at 06:24:05PM -0500, Stephen Kent wrote: >> >>> Nico, >>> >>> > > however, it is fair to say that I worry that the attempt to use layer >>> >> 7 authentication in conjunction with layer 3 confidentiality, >>> >> integrity and access control may a continuing source of problems for >>> >> us. >>> > >>> >Hmm, no, the problems we've been discussing in this thread do not arise >>> >from trying to mix authentication at higher layers with session >>> >protection at lower layers. In fact, channel binding is an answer to >>> >those problems :) >>> >>> Maybe for end systems, but probably not for intermediate systems. >> >>BTNS for SG use is out of scope, as I recall... > > > I really don't recall, and I'm too lazy to check the charter right > now :-). But IF one were to suggest changes to IPsec that are > designed to address problems other than those induced by BTNS > functionality, THEN such changes must be considered in the context of > all IPsec deployment options as defined in 4301, i.e., native host, > BITW, BITS, and SG. > > >>...but even if it is in scope, connection latching[*] (though there is >>no ULP connection to speak of) can still work, as can channel binding. >> >>[*] See draft-btns-connection-latching-00, when it appears in the I-D >> directory. >> >>Think of having a layer 7 protocol for authenticating to the SG and the >>SG enabling packet forwarding only once the client is authenticated; >>conversely the tunnel (and latch) are to be torn down only when the >>client agrees or a sufficiently long inactivity timer expires. The >>latch and inactivity timer prevent theft of a client's packet flows (the >>attack that Michael described a few days ago). > > > This almost sounds like a MIDCOM-style solution. I think this would > be a very big change to the current IPsec architecture, probably out > of scope for this WG. I agree, however I wonder if that sort of issue was already present in the BITW variants in 4301 anyway (to ensure, e.g., that packets arriving on different links with the same IP address didn't collide on SPI allocations). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD/OnoE5f5cImnZrsRApjsAJwOlQuFZZX4ss6JcIU/jlD9AHbhEgCfVvpW BpC2QkuJiWp4U2xUpANHJzU= =ZWJA -----END PGP SIGNATURE-----
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.