[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.
> 

There may be a mis-understanding here. What I was saying was not what 
you were alluding to. Re-authentication may be done any number of times, 
if so desired, independent of what the authetication type is. CHAP allows
re-authentication. But, Re-authentication arguments you allude to apply 
to existing authentication schemes as well as the exchange-type 
authentication scheme being proposed.

I am drawing a distinction between an authentication mechanism that is 
exchange oriented (starting with a ID_EXCH_START type payload, and 
ending with a ID_EXCH_DONE payload) as opposed to a single-payload-type 
authentication (ex: signature authentication).

Within an exchange-type authentication, you could authenticate a 
client in more than one-way. For example: Challenge/response
authentication, followed by smart token card authentication.
In general, the exchange type authentication could combine multiple
authentications and hence is a stronger mechanism for auth than a
single-payload-type authentcation. 

Why do you call the current auth. mechanism continuous auth? They 
authenticate each side just once using a single ID payload from either
side. 

I dont quite parse you last sentence right. I am arguing for using smart 
token cards for IKE authentication. 

> >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.
> 

You may be right in that there are CA deployments, based on name/password
baselines. But, CA deployment is still very small compared to RADIUS based 
deployments for CHAP and token card authentications.

> >> >       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.
> 

Hmm... Seems to me, you have the logic the other way around. Certificate 
based authentication is lot more complex to design, implement and manage 
than CHAP type authentication. Certificate based CAs are yet another 
infrastructure and auth database to deloy and manage. So are secure-DNS,
Kerberos and so forth. 

Customers want fewer databases. But, only time will tell which database 
they would want to keep. In the mean time, it is important to support the 
existing databases while trying to leap frog into other databases.

> >>
> >> >    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.
> 

Let us say, there is a way to determine the connect time of a remote 
user into enterprise network. I am refering to such a network-connected-time 
as the metric. I was suggesting to keep the negotiated SAs alive for the
whole of network-connected-time, as opposed to an arbitrary time-bound
or data-bounbd lifetime. Of course, Network-connected-time could in 
itself be combined with time-bound and/or data-bound lifetimes.

> Steve
> 

cheers,
suresh
Follow-Ups: References: