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

Re: Why can't ESP authenticate IP header?




Steve --

I think we are much more in agreement than
disagreement. My main thrust of this admitted
ongoing hobby horse is that IPsec for better or
worse is the best we're likely to get for some
time for a whole range of protocols which either
do not have any native crypto support or have
modules which aren't widely implemented.

Unfortuntely, IPsec has had a very clear bias
toward security gateways because quite frankly
that's where the money is. I'm in agreement that
TLS is a misnomer which is why I want to make
certain that transport mode IPsec is a first class
citizen, and that it can be used as an alternative
when TLS is not possible or desirable. The fact
that nobody's built an API which allows transport
of credentials up to the application layer says to
me quite clearly that IPsec is not yet complete
for the role that I think we can all agree would
be highly advantageous: having strong crypto
deployed far and wide on as many hosts and routers
as possible, with the concomitant utility of being
able to provide strong authentication to various
applications which would otherwise have no other
recourse.

A few more inline:

Stephen Kent writes:
 > The terms quoted above are your words! But, my point is that the term 
 > "application later" is inappropriate, because the fields in question 
 > are from the IP and transport layer. Also, it is not always desirable 
 > to rely solely on applications to perform access control. For 
 > example, if we fail to match traffic against SA parameters within 
 > IPsec, we loose the ability to easily identify the sources of traffic 
 > with spoofed IP source addresses. 

Yes, but at the cost of transparency of IP
addresses to security associations. This affects
mobility, multihoming and renumbering; it's not a
zero cost tradeoff.

 > As noted above, if we are implementing IPsec at a security gateway, 
 > there is no standard means of relaying credentials between the SG and 
 > a host.

I only meant this in the context of transport
mode host to host.

 > Your last comment argues that this requirement of IPsec makes support 
 > for some communication scenarios harder.  I don't see this as true 
 > for renumbering, unless the renumbering takes place while the SA is 
 > in place.

   Well...? Is that not a valid concern?

 > Remember that one can populate SPD entries for source and 
 > destination addresses with symbolic values (e.g., DNS names or RFC822 
 > addresses), which insulates them from renumbering conducted on a 
 > longer time scale. The same is true for mobility.  

But that doesn't do much good if the kernel then
happily helps you by filtering out that obvious
spoofing attack for you...

 > I assume that what you meant to say above was that if I can choose to 
 > supply weak or strong credentials, then an attacker may exploit that 
 > design error.

I meant that if I have to supply strong
credentials at lower layer, but have to rely on
weak credentials at a higher layer, then the
system is only as strong as the weak credentials.
This in fact may be adequate for some use
scenarios; manifestly: this is what IPsec as
currently implemented provides. However, this is
not a panecea, and specifically does not help you
in situations where attackers might be able to
authenticate via IPsec/IKE but forge identities
with some application layer protocol like, say,
SIP.

 > We have enough trouble getting 
 > people to invest in security measures at any layer, so it behoves us 
 > to not make suggestions for security mechanisms that may have 
 > moderate or high costs and minimal benefits.

I meant "throughout" figuratively. 

	Mike


References: