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

Re: Using Legacy Authentication for IPSRA (was : xauth requirements: vulnerabilities)


Stephen Kent wrote:

> John,
> Your taxonomy is a nice one, but I think another way to view this issue is
> to remember that the primary reason for authentication in IPsec is as input
> to an iddentity-based access control decision that is enforced by the IPsec
> receiver.  RFC 2401 defines a set of ID forms for use in the SPD, and they
> define the types of principles to which access is granted.  This includes
> both devices (based on IP address or DNS name or DN) and people (based on
> RFC822 name or DN).  [Often there is an assumption that if one
> authenticates an end system, and it is a single user end system, then there
> is a one-to-one mapping to a specific user, even if that mapping is not
> expressed in the SPD by the choice of name form.]

When an IPSec implementation is examining an IP packet against the SPD it has
no clue which
DNS name or DN name matches the IP addresses in the header.
I think that the purpose of the authentication process is to bind a DN or DNS
name to an
IP address so that matching of a packet against the SPD is possible.

> IPsec does not support
> authentication of a compound principle, or of a user and a system
> independently.  It would not sense to do so unless there was a
> corresponding SPD entry type for compound principles.

I don't think IPSec needs to support compound principles.
I do think that we need to define requirements from the authentication
process that binds between the DN and the IP address. I think this should
be an IPSec extension, and part of the IPSRA work.
In this context I think this taxonomy is helpful.

> Steve
> P.S.  I avoid using the term "client" with IPsec as the protocols do not
> have clients and servers.  We have end systems and security gateways.