[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Using Legacy Authentication for IPSRA (was : xauth requirements: vulnerabilities)
Sara wrote, excerpting:
> The problem as I see it : provide IPSec with an
> authentication of a user
> with a non fixed or fixed IP address (i.e. the IP address he
> uses is irrelevant to
>
> the authentication process). Ofcourse security
> vulnerabilities are an important
> part of this problem, after all these are the issues we
> discuss in this area, but
> they exist
> in several levels.
> I think that the a possible architecture for a solution could
> be a modular
> architecture
> that consists of an authentication mechanism that provides
> user authentication and
> a protocol
> that conveys this information to either IPSec or IKE. This
> solution is different
> from the current IKE
> approach to authentication in which the authentication is an
> integral part of the
> IKE protocol.
It seems to me that two distinct problems arise for IPSRA: authentication of
an IPsec client (familiar from base IPsec) and authentication of an
associated human user (arising more specifically in the IPSRA context).
Both are relevant to IPSRA, carry different assumptions and constraints, and
may therefore suggest different mechanisms. People are poorly suited to
remembering and entering long secrets or performing exponentiation, but can
perform operations with hardware tokens that are disconnected from the IPsec
client system. Computers are good at remembering long secrets, but quite
variable in terms of how well those secrets are protected from unintended
disclosure. Whether IPsec client and human user authentication are
addressed within the same mechanism or separately from one another, it seems
important that both sets of concerns be satisfiable.
Several general choices could arise as to what's authenticated on behalf of
the remote accessor:
(1) the client IPsec entity only, independent of its user: here, no
user-level secrets would be involved in the IPsec-visible distributed
authentication protocol(s), though they might be used locally (perhaps
involving side-channel protocol transactions outside IPsec) to unlock
client-level secrets for use
(2) the user only, independent of the client: here, user-level secrets would
be involved in performing IPsec-visible distributed authentication
protocol(s), and it would not be assumed that any client-retained secrets
are sufficiently fine-grained to authenticate an individual client
(3) a compound principal, representing the bound combination between user
and client: here, separate secrets representing both user and client would
be applied within the IPsec-visible protocol(s), in such a way as to
demonstrate their conjunction
(4) the user and client, independently authenticated: here, independent
IPsec-visible authentication transactions would be performed for both user
and client, though the performance of one authentication might rely on a
secure channel provided by the other
Does this taxonomy help to clarify the possibilities?
--jl
Follow-Ups: