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

RE: [Design] Re: Wes Hardaker: opportunistic encryption deploymen t problems

At 9:02 AM -0700 8/16/01, Michael Thomas wrote:
>Stephen Kent writes:
>  > At 10:32 AM -0700 8/15/01, Michael Thomas wrote:
>  > Mike,
>  >
>  > Your understanding is not quite right.  First, tunnel mode, while
>  > required for an SG, is also applicable to two hosts communicating.
>  > Second, IPsec supports authentication of symbolic names, not just IP
>  > addresses, which are dynamically bound to IP addresses for the
>  > duration of an SA. 
>
>    My understanding is that the reality is somewhat
>    different. For example, I don't believe that I
>    can have a credential which is bound to a SPI
>    which spans multiple IP addresses concurrently. As
>    such it would only provide a single layer of
>    indirection. Maybe the DNS modes provide some of
>    this functionality, but I have doubts as to how
>    well supported or secure it is.
>
>  > This is how we support connections from mobile
>  > users, for example.
>
>    Mobile nodes use their home address, right? So
>    it's not an issue.

some vendors have adopted that approach, but it is not a requirement 
and IPsec is prepared to deal with the more general case.

>
>  > The access control model that underlies IPsec is that one uses some
>  > means of authenticating a peer, e.g., via binding a signature key to
>  > an ID, traceable to a trust anchor, and that the traffic sent from
>  > and sent to the authenticated peer is subject to access controls
>  > expressed in the SPD. These controls apply not only to allowed IP
>  > addresses to/from which traffic may flow, but also protocols and port
>  > fields. The motivation for these other selectors is the same as in
>  > firewalls, i.e., we can control access to services based on access to
>  > well know ports.
>
>    Right... an authenticated firewall. That's pretty much
>    my understanding. This seems, well, of limited utility
>    for transport mode unless it can be tied to applications
>    (ie, in the same way that login names produce a mapping
>    to a GID/UID for file systems after login). Maybe I'm
>    just generally skeptical of integrated host firewalls
>    as being misguided, but that's probably just me.
>

In the context of a host it would be nice to have a standard API for 
applications to request IPsec services, this requires changes to the 
apps. the alternative is to configure the SPD to automatically 
provide the services, which is attractive as a centrally managed 
approach to security as well. there is no transport vs. tunnel mode 
distinction here, unless you're making the assumption that a host 
would only use transport mode. (this would be OK for host/host SAs, 
but it's not necessary and it doesn't work for host/SG SAs.)

Steve
References: