[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
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
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.
Ietf mailing list