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

Re: Why can't ESP authenticate IP header?

Title: Re: Why can't ESP authenticate IP header?
At 7:27 AM -0700 9/24/01, Michael Thomas wrote:
Stephen Kent writes:
 > >In fact, I'll bet what's really lurking here is
 > >the desire to have application layer cross
 > >checking since what you're effectively doing is
 > >providing a (weak) check to filter out
 > >authenticated but unauthorized traffic (ie,
 > >filtering crypto protected source spoofing).
 > >
 > Mike,
 >
 > I would not characterize this as "application layer cross
 > checking."

   Nor would I. At best, it's a substitute for
   application layer cross checking which does
   not exist.

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. We all realize that it's very difficult to manage the configuration of access controls on all hosts inside of an organization security perimeter, hence the popularity of firewalls. IPsec offers the same sort of perimeter access controls that we have come to rely on, but with cryptographic protection for traffic flows, which adds a considerable level of assurance to this mechanism.


 > Access control is the motivation for this check, and it is consistent
 > with the principle of least privilege. We have many examples of
 > systems that have been vulnerable because they made the assumption
 > that everyone peer is "trusted."

   Sure. That's why applications need the ability get
   access to credentials when available. Enforcing
   source address to SA foils exactly one attack but
   leaves you completely vulnerable to any number of
   attacks with the higher layer protocols which have
   no clue whether the credentials presented at the
   IP layer disagree with the identities presented at
   the application layer. Also: as I mentioned, binding
   to the source IP address makes multi-homing, mobility,
   and renumbering problematic.

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. Even in an end system IPsec implementation, use of the SPD allows one to specify and enforce access controls for applications without modifying those applications. Also, some vendors are planning to offer IPsec in a NIC, which would enforce these controls without having to rely on the host OS, an attractive option given the sorry state of OS security.

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.  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.  Anyway, the requirement to match traffic against the SPD corresponding SPD entries is not new; it has been a part of IPsec for a long time and I do not see it changing in the next rounds of revisions to 2401.

 > We often hear folks use this sort of
 > terminology in discussing IPsec SAs.  A compliant IPsec
 > implementation, using the SPD, expresses access control constraints
 > on all communication that passes through it. The check performed by a
 > receiver after IPsec processing ensures that no peer can violate the
 > access control parameters that characterize the SA carrying traffic
 > from that peer. This is just good security engineering. 

   Good security engineering needs to consider the
   whole system. If I can use strong credentials at
   one layer and weak credentials at another, the
   system is as strong as the weak credentials. For
   many protocols, IPsec is about the only answer if
   you want strong credentials any time soon (TLS isn't
   currently viable if you want to use UDP).

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. That's true, whether the error occurs due to mismatches arising at different layers or via other means, e.g., the ability to negotiate user authentication mechanisms "down." But, what we are talking about is provision of access controls (not quite the same as user or data origin authentication) in IPsec not in lieu of other controls, but in addition to other controls that might be employed. Also, TLS will NEVER support UDP, unless one redesigns the protocol and keeps the name constant, since TLS/SSL rely on sequenced delivery of the record protocol sublayer.

   What we have right now, however, is a return to the
   past for those applications where you can be pretty
   sure about their source IP address, but have to resort
   reverse DNS mappings (and their well known weaknesses)
   or worse to have any ability to cross check the
   asserted identity in, say, a SIP or SMTP message.

Your comments here are not very clear, but I'll take a guess at what you may be trying to express and respond accordingly. If one makes use of the symbolic IP address facility of IPsec, and uses appropriate credentials, then you can do better, but DNS security is a limiting factor in any case.


 > Yes, the
 > traffic has passed a cryptographic data origin authentication check,
 > but a failure to perform this check would undermine the access
 > control features. Relative to the stated goals, the check is not
 > "weak;" it is precise.

   Hamfisted is closer to the truth. ACL based security
   is better than nothing, but it is both crude and weak
   in comparison to a well integrated system with strong
   authentication throughout the layers.

I presume that you are referring to a rather narrow definition of "ACL" here, one that applies only to filter rules in a router, firewall, or IPsec device.  Stong authentication is not necessarily a great measure "throughout the layers." 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.

Your closing comment, interpreted literally, would call for crypto authentication at the MAC layer (we could use IEEE 802.11), IP layer (IPsec), transport layer (no current standards here), session layer (SSL/TLS), and application layer (application specific protocols or maybe GSSAPI-based measures). Is it really appropriate to invest in strong authentication at all layers for all traffic? Probably not. That, in part, is why we have no transport layer security protocols today (despite the TLS misnomer). That is why we have almost no deployed use of MAC layer security protocols today.  Application layer security requires retrofitting applications, which is costly, and it fails to provide protection for applications that offer backwards-compatible non-authenticated modes of operations. In part IPsec is offered as an alternative to this sort of retrofit, for applications that do not really need application-specific security.  It's not the only choice, e.g., TLS/SSL is also popular, but has limitations re transport protocols and the need to deploy it at the end system, not at an intermediate system.

Steve
Follow-Ups: References: