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

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



Title: RE: Comments on "Hybrid Auth. mode for IKE"

FYI: A general common authentication protocol BOF is being planned for the Chicago IETF.  The agenda is to discuss combining among others, the PPP EAP protocol and IPSec's XAUTH protocol, and producing an authentication mechanism that can be migrated to any environment. 

I would worry that we are trying to on-the-fly build a protocol thru email that would be better designed by teams dedicated to solving this problem.  Besides most of these issues were already brought up on this mailing list previously when XAUTH was released and again when PPP EAP was introduced to the IPSec mailing list.

> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: Tuesday, July 21, 1998 10:26 PM
> To: suresh@livingston.com
> Cc: moshe@checkpoint.com; ipsec@tis.com; suresh@livingston.com
> Subject: 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: