On Mon, Jan 14, 2008 at 02:25:53PM -0500, Stephen Kent wrote:
> At 6:00 PM -0600 1/11/08, Nicolas Williams wrote:
> >...
> >
> >Finally, multi-user systems may need to authenticate individual users to
> >other entities, in which case IPsec is inapplicable[*]. (I cannot find
> >a mention of this in the I-D, not after a quick skim.)
> >
> >[*] At least to my reading of RFC4301, though I see no reason why a
> > system couldn't negotiate narrow SAs, each with different local IDs
> > and credentials, with other peers. But that wouldn't help
> > applications that multiplex messages for many users' onto one TCP
> > connection (e.g., NFS), in which case even if my readinf of RFC4301
> > is wrong IPsec is still not applicable for authentication.
>
> IPsec has always allowed two peers to negotiate multiple SAs between
> them, e.g., on a per-TCP connection basis.
Right.
> Ipsec does support
^^^^^
You're slipping :) :)
> per-user authentication if protocol ID and port pairs can be used to
> distinguish the sessions for different users.
I thought this was feasible (see above) but I thought the RFC4301 model
didn't quite deal with this (or at least Sam once convinced me that the
name selector of the SPD didn't quite work the way I would think it
should). I am glad to be wrong on this.
(So then, the name selector in the SPD can be used to select the local
ID and credentials?)
> So, if you want to
> restrict the cited motivation to applications that multiplex
> different users onto a single TCP/UDP session, that would be accurate.
I don't want to restrict it only to such applications, _no_.
The set of applications I can see as standing to benefit from BTNS:
- iSCSI -- because once revised to support use of connection latching,
IPsec APIs and channel binding then configuring iSCSI to use IPsec
will be a lot easier than it is today.
- NFSv4 -- because of the multi-user multiplexing issue, and because
reducing the number of distinct cryptographic keys and key states
will improve performance, particularly for large timesharing servers
(think SunRay servers).
- Eventually, if BTNS takes off, we might find that using BTNS in LoF
or CBB modes will be useful in apps that today do/would/should use
any of SASL, GSS, TLS and/or SSHv2. This is definitely speculative,
though it's certainly possible; I've no idea if it's probable.
How likely this is will depend on lots of things that I cannot
predict. E.g., if NICs w/ ESP/AH offload spread, then I think that
will greatly help make BTNS enticing. OTOH, NICs with TCP&TLS
offload will help not. CPUs like my employer's latest, with speedy
on-board crypto accelerators will be neutral (which, effectively,
means they will not help make BTNS popular where easier to adopt
alternatives exist).
- Of course, BTNS could be applicable to many new application
protocols, such as new protocols that are remotely similar to iSCSI
or NFS.
Keep in mind that iSCSI is not all that special compared to apps that
today use SASL or TLS (or both). The main difference is that iSCSI's
designers felt that for a bulk data protocol it would be best
(performance-wise, oer perhaps design effort-wise) to push
crypto down to the lowest possible layer.
So, if iSCSI can benefit from BTNS and/or related specs (connection
latching, IPsec APIs), then it's not farfetched to believe that more
apps will come along that can also benefit from our work.
I think the examples that you object to can remain in the I-D, but it
should be clear that BTNS is not 'RECOMMENDED' (nor 'NOT RECOMMENDED')
for those -- that those examples are speculative. Provided that such
examples are feasible.
Nico
--
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf