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

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




> 
> Pyda,
> 
> >    1. The ID payload is not good enough for remote access user
> >       authentication. What we need is new type(s) of ISAKMP
> >       payload(s) - something like ID_EXCHANGE_INITIATE,
> >       ID_EXCHANGE_IN_PROGRESS and ID_EXCHANGE_COMPLETE.
> >       (There may be variations to the ID_EXCHANGE types,
> >        like challenge/response, token card, OTP etc..)
> 
> This assertion needs to be justified.  Perhaps the argument is support of
> legacy auth systems, but it certainly is not security.  We can do a better
> job of user auth with certs than any of these other approaches.  The certs
> (and associated crypto processing) could be in a personal token, not just
> in software, thus providing very high quality user auth.  Also, one might
> argue that IPsec provides an impetus to switch away from transient user
> auth, to continuous user auth, from passwords to keys, etc.  That's why I
> think this first premise needs to be much better justified than what I've
> seen so far.
> 

First, the authentication info in the main mode is encrypted. The actual 
authentication mechanism is not indicative of the type of security that
would be allowed for session SAs or the ISAKMP SA encryption. 
Note, pre-shared key is a valid auth. mechanism. It is up to the 
negotiating peers to determine the level of authentication they 
like to enforce. The drafts cannot mandate this, only offer viable
solution options.

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.

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.

> >    3. The authentication mechanisms suggested are asymmetrical between
> >       edge device and remote user. Edge device is authenticated with
> >       a public key, whereas remote user is authenticated with token card
> >       and CHAP(Challeng/Response) mechasims.
> 
> Why?  I'd much rather use a cert for user auth, as provided in SSL with
> client certs, than these other mechanisms.  Again, you need to justify this
> assertion.
> 

Please see my comments above. 

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

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

> >       Keeping an SA valid for the lifetime of network connection,
> >       makes the administratve overhead on remote user and edge device
> >       simpler. I can see this new metric being valuable even in
> >       GW-GW type VPN connections. (SA rekeying is a lot of overhead
> >       and has lots of scope for confusion and inconsistencies between
> >       vendors).
> 
> See questions above.
> 
> Steve
> 
> 

cheers,
suresh


Follow-Ups: References: