[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using Legacy Authentication for IPSRA (was : xauth requirements: vulnerabilities)
Hi John,
"Linn, John" wrote:
<substantially trimmed...>
> 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?
Yes, I think so. I was headed in this direction with the vulnerabilities
thread, but I had not reached this level of resolution yet. I think this
very succinctly summarizes the available authentication subjects. The
only thing missing seems to be the remote security gateway (the
server?). In some cases the user may want to insist that the sgw be
strongly authenticated, and in others, they may not care (or have the
ability).
Scott
References: