[I've taken the liberty of re-formatting the quoted text for line
wrapping and indentation.]
On Mon, Jan 07, 2008 at 03:18:09PM -0500, Stephen Kent wrote:
> - creating IPsec/IKE SAs w/o authentication, for use in
> contexts where an application will perform its own
> authentication, but wants the layer 3 confidentiality,
> integrity and continuity of authentication offered by ESP.
>
> Here a critical part of the argument is that these
> applications cannot use the authentication provided by IKE,
> but the explanation for this is poor.
I think one part of the answer to this is there, but the other part
appears to be missing.
> For example there is no
> recognition of the use of EAP authentication methods with
> IKE.
EAP is not applicable. The applicability statement for EAP rules out
use where end-to-end authentication is desired.
Beyond that, the authentication infrastructure may not be suitable for
use in IKE, even if that's merely an issue of lack of specifications or
implementations. (This is mentioned in the I-D.)
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.
> The text also does not address the possibility that a
> suitable API could allow an application to acquire and track
> the ID asserted during an IKE exchange, in lieu of the
> unauthenticated SA approach that is being motivated.
Given the answers above such an API would be insufficient, though still
quite welcome.
Note that applications would care about the IDs of the SAs that protect
their packets. But applications don't usually deal in packets.
Connection latching is a simple method for tracking the IDs of the SAs
that protect the apps' packets; the API that you suggest can be (and
will be) built on top of connection latching. A non-connection-oriented
version of connection latching is certainly feasible too.
> The security considerations section is too long, mostly because much
> of the material should be earlier, e.g., the CB discussion. One
> might also move the rekeying attack example (which I expanded to be
> more accurate) to the CB document, and just reference the notion here.
Given that this is a problem and applicability statement for a security
technology, the security considerations section might as well state that
security considerations are discussed throughout the document, thus
freeing the authors to structure the document like you suggest.
Nico
--
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf