[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on "Hybrid Auth. mode for IKE"

Suresh,

>Secondly, I would think, exchange mode of authentication is generally
>speaking more robust than a one-time ID authentication. Exchange mode
>allows either party to probe beyond a single notification. For example,
>it allows multiple forms of authentication (i.e., increasingly strong
>levels of authentication, if you desire). Above all, exchange mode
>of authentication does meet the legacy auth. requirements.

I don't agree.  Once an IKE exhange has been performed using certs, all
subsequent client traffic is cryptographically protected using keying
material that has been bound to the user in question (if we are providing
user-granularity keying) and authenticated by the cert processing. The
suggestion is often made that a protocol that allows for subsequent re-auth
is "more secure," but that is true only under certain curstances.  If the
communication path were not continuousluy authenticated, this argument has
some merit, but that's not the case for IPsec.  If the re-auth requires
additional user involvement, all of my marketing folks tell me it's
unacceptable, and, as a user, I agree with them!  This is the era of single
sign on, not extra sign on.  Finally, if the re-auth is automatic, then I'd
argue that it is no better than the continuous auth being probvided by
IPsec.  We also must compare apples and organges.  Using hardware for key
management with IKE should be better than using a software-based OTP
system, or even a token like SecurID.  Arguments about using a hardware
token for user auth but not for IKE are mushier.

>Lastly, certificate based authentication you suggests requires a vast
>deployment of CA infrastructure, which is not in place yet. Many of the
>ISP consortiums have to go with what is commonly available as opposed to
>what a single enterprise or a limited no. of ISPs have. Would you rather
>that remote access applications not utilize the benefits of IPsec until
>the certificate deployment is common place? I would think not.

Not true.  I have personal experience establ;ishing PKIs that were derrived
from name/password baselines.  It can be done easily, especially for
intranets and for closed user communities. Since I'm in the PKI business I
may me accused of being biased ;-), but I also have some ammount of
experience proving assertions of this sort to be false.

>> >       However, it doesnt have to be that way. If desired, the remote
>> >       user could run the same token card/CHAP mechanisms to authenticate
>> >       the edge device.
>>
>> That's definately a step down in security!  Why even suggest this?
>
>Well, not really. It is just an extension of the authentication
>mechanism to both parties.

If we have authenticated end points using good keys associayted with certs,
it's not at all clear that use of additional, weaker mechanisms adds to the
strength of the system, while it certainly adds to the complexity of design
and management!  My clients want fewer user auth databases to manage, not
more, and moving these databases to certs is the best approach from a
security perspective, in most cases.

>>
>> >    4. SA lifetime:
>> >
>> >       The current  metrics of "time-bound" and "Data-bound" for an
>> >       SA lifetime do not seem adequate for remote access users.
>> >       I would like to see a new metric like "network-connected-time"
>> >       for SA lifetime. This new metric may be used in conjunction with
>> >       other metrics (if the crypto algorithms mandate such a limiting
>> >       criteria) or by itself.
>>
>> Why is not SA lifetime close enough to net sonnect time?  Why is the latter
>> metric preferable?
>>
>
>How would you pick a close enough metric? Could be quite arbitrary.
>A user may have no way to know ahead of time, how long his/her sessions
>are going to have to be kept alive or how much data he/she is going
>to be exchanging.  If these metrics are to be set infinitely large,
>then that defeats the purpose to start with.
>
>Most often than not, a user is likely to want to keep the negotiated
>security parameters unchanged throughout the connected time.

i don't understand your response.  You origjnally suggested that net
connect time was preferable to SA lifetime.  For an individual user SA,
these seem to be almost the same to me, so I asked how they bwere
significantly different.  Your response does not address that question.

Steve
Follow-Ups: References: