RE: Re[2]: PPP over IPSec (without L2TP)?

[Stephen Kent <[e-mail]>]

Pyda,

>Ah, I see where you are coming from. Sure, RFC 2401 does allow using
>user-IDs to describe SPD. That is necessary, but not a sufficient
>condition to support user-ID authentication. IKE is the one that
>does the acutal user-ID authentication and hence provides the
>sufficiency for user-ID support.

I don't think that we're signifgicantly disagreeing here. IPsec, as defined
by the architecture document (RFC 2401) clearly mandates support for user
level auth, because it makes no sense to base access control decisions on
user IDs unless one authenticates users.  The question, then, is how to
accomoplish that.  because IPsec does not mandate use of IKE, per se, 2401
can't go into more detail re how one accomplishes user level auth for IPsec.

>Further, We are not just talking about being able to use user-ID for
>authentication, but the actual method of authenticating the user-ID.
>I believe, the confusion about user-ID authentication arises not
>because IKE does not support user-ID auth, but because it does not
>support asymmetric and legacy authentication methods.

The method used is of importance, but it is not the defining facet of
whether IPsec suppoprt user auth. I certainly DISAGREE with your last
statement.  Plain old IKE DOES support user auth, e.g., by associating
private key material with a user.  What is does not support is lagacy user
auth mechanisms.

>>                            I do agree that protocols such as XAUTH
>> demonstrate a clear intent to authenticate users, not just machines, but
>> IKE and 2401 make definite statements to that effect already.
>>
>
>I believe,  XAUTH and HYBRID-AUTH drafts (a) demonstrate the need for
>asymmetric and legacy authentication methods, and (b) attempt to address
>these in different ways as extensions to IKE.

The XUATH and HYBRID-AUTH IDs demonstrate a clear desire by vendors to sell
into environments that are reluctant to deploy PKIs.  That is not quite the
same as your statement above.

Steve