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

Comments on "Hybrid Auth. mode for IKE"


Moshe,

Thanks for initiating the discussion on the subject. Your draft is
timely and goes right to the point of addressing remote user 
requirements. I have also been following the thread of comments from 
Tero, Bryan, Scott and others on the draft. Below is a summary of my 
thoughts on the draft.

    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 new exchange type of authentication begins when the user 
       sends in the ID_EXCHANGE_INITIATE with his/her username. The 
       exchange ends when the edge device grants authentication or 
       denies authentication with ID_EXCHANGE_COMPLETE payload.

    2. The authentication mechanism outlined in your draft is simpler
       and does away with the 2-level authentication approach (once
       with IKE negotiator device and once with the actual remote user)
       in the XAUTH draft.  However, I do think that NOTIFY is not the
       right type of payload to do that, because NOTIFY is a one-way 
       error notification type payload. 

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

    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. 

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

    5. Rekeying of ISAKMP SA:

       ISAKMP SAs (on client and server ends) neednt be kept forever 
       while the session SAs are alive. ISAKMP SAs can be short lived,
       unless either end wants to use the ISAKMP SA for periodic 
       authentication or session SA rekeying.

       In the case where an adge device or remote user has to use the
       ISAKMP SA to talk to the other end, and finds that the ISAKMP SA
       is missing (or lost in bit bucket), I think, it is reasonable 
       for the device to simply retire all the session SAs(created using 
       the lost ISAKMP SA), send an ICMP error message to the other end
       and drop the network connection. 
       
       At such a time, the remote user could reinitate the conection to
       edge device.

Thats all for now. Have a nice day.

cheers,
suresh
Follow-Ups: