[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: L2TP+IPsec and IKE authentication
Comments interspersed below.
> Stephen,
>
> >My take on this is that secondary authentication is needed, be
> it at the PPP
> >level, XAUTH or other (e.g. CRACK proposal) to allow for a 'challenge'.
> >
> >If we relied solely on a device-loaded certificate or pre-shared
> secret to
> >authenticate the user, that is not a 'secure' situation in the
> event of the
> >device being 'borrowed'.
> >
> >In time, when certificate smartcards and native laptop smartcard
> readers are
> >readily available (smartcards that request a user challenge -
> >pin/signature/biometrics), then we may be able to dispense with
> >'device+user' authentication.
>
> As you note here, if one uses a smart card with a PIN or a biometric
> to activate it, then it is arguably as secure as using a SecurID
> card.
At least.
> From an interoperability perspective, how the private key is
> made available for use in IKE the two are indistinguishable, i.e.,
> the means by which the private key (not the certificate, as suggested
> above) is protected is purely a local matter.
Yes.
> So, what is disturbing
> about this argument is that we're making architectural accommodations
> for what would normally not be subject to an IETF standard. This is
> even more surprising because in most (if not all) of the other
> security standards I can think of, we are amazingly silent about
> these sorts of assurance issues. Thus I am forced to conclude that
> the departure from this precedent is driven more by market(ing)
> forces than by technology or security concerns.
God forbid we would allow reality to impinge upon the standardization
process.
>
> Steve
>
>
>
Follow-Ups:
References: