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

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

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

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

>       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
Follow-Ups: References: