[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ESP and AH combinations



David,

        In general, I'm not sure that two layers of integrity checks (they
are not really signatures!) on the same data would be useful. IP-AH-AH-ULP
seems more than a bit odd to me.  This is not application layer data, but
rather network or transport layer data.

In contrast, your exmaple of IP-AH-IP-AH-ULP makes more sense in that it
could be the result of an end-system applying AH to the packets it emits,
then an encrypting router encapsulating those packets and adding an outer
later of protection.


Your point about what data origin authentication is provided by AH (or ESP)
is an important one, that I would phrase differently.  When we establish an
SA, we should be determining what range of source addresses can be asserted
by the entity at the other end, if we are going to persist in using IP
addresses as inputs to access control decisions.  If the other end is an
end system, this is fairly simple.  The address  might come from a
certificate exchanged during SA establishment or it might be hard
configured into an ACL along with the public key for the other end.
However, if the other end is a router, the problem is much more complex!
One needs to have some way of constraining the range of addresses that the
other site is authorized to emit, either via some for of authorization
certificate, a set of certificates held for each indivdiaul end system
served by the router, or some manual configuration procedure.

I agree with your fundamental argument, i.e., source authentication is more
subtle here than one might first think, especially in the case of IPSEC
implemented in routers.  It is fundamentally a case of what granularity of
access control is appropriate and what form of identities are best suited
for ACLs and the people who will manage them.  Using DNS IDs and matching
certificates from the DNS security work might be appropriate in some
instances, but will that translate well for the hosts behind an encrypting
router?

Ultimately, access control decisions are likely to be based on some form of
identity and thinking about a key as an identity is not very intuitive for
security administration purposes.  Also, having one form of identity
verified at an encrypting router, but having another form acted upon by
hosts behind the router (which don't get to see explicit results of the
access control check at the router)  is probably a bad idea.  For most
purposes, it may be appropriate to be very explicit about how the mapping
between a key and a set of addresses is constrained, especially when
dealing with routers.

Steve