[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using Legacy Authentication for IPSRA (was : xauth requirements: vulnerabilities)
Steve,
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.
Sara.
Follow-Ups:
References: