I think this document is mostly quite fine and almost ready.
Besides some minor editing I think that some text on authentication
assymetry in CBB could be removed.
Comments below.
Abstract
The Internet network security protocol suite, IPsec, consisting of
IKE, ESP, and AH, currently requires authentication via IKE of
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Does it?
network layer entities to bootstrap security. This authentication can
be based on mechanisms such as pre-shared symmetric keys,
certificates and associated asymmetric keys, or the use of Kerberos.
The need for authentication information and its associated identities
between network layer entities can be a significant obstacle to
deploying network security. This document explains the rationale for
extending the Internet network security suite to enable use of IPsec
security mechanisms without full IKE authentication. These
^^^^^^^^^^^^^^^^^^^^^^^
Can we find a better way to say this?
"without actually authenticating IKE peers"?
extensions are intended to protect communication "better than
^
with
nothing" (BTNS) on their own (Stand Alone BTNS, or SAB), and may be
^
security
useful in providing network layer security that can be authenticated
by higher layers in the protocol stack, called Channel Bound BTNS
(CBB). This document also explains situations in which use of SAB and
CBB extensions are appropriate and can achieve their intended
benefit.
Also, s/on their own//.
Consider the case of transport protocols. Increases in network
performance and the use of long-lived connections have resulted in
increased vulnerability of connection-oriented transport protocols to
attacks. Such attacks can be resisted to some extent within the
transport layer by performing additional validity checks, requiring
additional mechanisms added to each transport protocol. More direct
^ ^ ^^^^^^
that be
s/direct/comprehensive/
security can be provided, either at the transport or network layer.
This security currently requires a predetermined way to authenticate
s/This security/Obtaining comprehensive security/
the endpoints with a pre-shared secret, a public key infrastructure
(PKI) with shared trusted anchors, or an external key coordination
^^^^^^^^^^^
s/an external/other/
system such as Kerberos. In all cases, secure communication can be
established only after endpoints mutually assert authenticated
s/assert authenticated/authenticate each other's/
identities as specified in their access control policies.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
and pass their access control policies
There is weaker notion of identity, one which is bootstrapped from
the session association itself. The identity doesn't mean "Bill
Smith" or "owner of shared secret X2YQ", but means something more
like "the entity with whom I have been communicating on connection
#23". Such identity is not invariant across associations, but because
it is invariant within an association it can still be used to provide
protection for that association.
- I would add that it is possible, in some schemes (specifically the
scheme in draft-btns-core), to refer to such an identity by a
repeatable, non-spoofable handle. In draft-btns-core this would be a
public key, and it is non-spoofable because it is bound into the
"connection" by IKE.
This is useful because it allows one to ask "is my peer on connection
#32 the same as I had on connection #23 three days ago?"
I believe this is mentioned later in the I-D, but it could stand
being mentioned here where the topic of identity is broached.
- Section 2.2 mentions the need, in CBB, for defining IPsec channels,
but section 2.1 does not mention the need, in SAB, for either defining
IPsec channels or LoF binding of BTNS peers to their addresses. A
minor inconsistentcy since the topic is handled subsequently.
- Section 2.2, s/where similar relates to/where similarity relates to/.
- Section 2.4,
BTNS is not intended to protect the key exchange itself, so this
presents an opportunity for a man-in-the-middle attack or a well-
timed attack from other sources. Stand-alone BTNS is further not
intended to protect the endpoint from nodes masquerading as
legitimate clients but rather to raise the level of effort of an
attack to that of emulating a client. BTNS together with
authentication from higher layers in the stack can protect from such
masquerading, depending on how the authentication is coupled with the
BTNS associations, and at a later point in the protocol exchange.
- Note that in CBB the key exchange is protected a posteriori, thus
_detecting_ MITMs. This is quite similar to what happens in IKEv2.
- Section 3.1: I would prefer most references to authentication
a/symmetry in the application layer, in the CBB cases, be removed.
Such as in the table that follows the first paragraph and the
5. Asymmetric CBB (A-CBB): one side lacks network layer
authentication information and possesses authentication at a
higher layer in the protocol stack; there are two variants,
^
stop here and delete the
remainder.
Asymmetric IKE CBB(AI-CBB) where the other side possesses
conventional IKE-supported authentication, and asymmetric stand-
alone CBB (AS-CBB), where the other side lacks network layer
authentication information and lacks authentication at higher
layers
S-CCB could utilize application layer authentication, including
^^^
CBB
challenge/response PINs, such as used by S/Key in software or copy
protection dongles, or login passwords.
I'm not sure where this came from, but it's neither quite right nor
does it belong in this document.
- Section 3.1.4. I'm rather confused by this one and I think that by
and larger we can completely get rid of the distinction between S-CBB
and A-CBB.
What the application does for authentication and whether that is
symmetric or not is really none of BTNS' business. We're trying to
enable channel binding to BTNS -- that is, we're trying to say that
BTNS is applicable to channel binding applications.
Beyond that this I-D is simply not the right place to discuss the
particulars of what happens at the application layer beyond saying
that authentication at the app layer is to be bound to a BTNS
channel.
Nor is this I-D the right place to discuss the applicability of
channel binding generally.
So I think this section should be removed and the distinction of
S-CBB vs. A-CBB should be removed as well.
SAB CBB
-------------------------------------------------------------
Uses Open services Password/PIN services
Peer-to-peer
Zero-config. infrastructure
Where did "Password/PIN services" come from? What does that mean?
Nico
--