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

RE: Extended authentication with ISAKMP/Oakley draft

Roy,

When I said "adding new modes for ISAKMP/Oakley" I meant adding new
methods for carrying out phase 1 (on top of signature, encryption, etc).

My point was that there is no necessity in modifying anything to the
ISAKMP/Oakley exchange itself. You can do the extra authentication messages
after the exchange is done (and just drop the connection if things go wrong).
But I see that there is value in piggybacking the NOTIFY messages on the
phase 1 messages. So I do not object to that.

In any case, the current draft only describes how to do the piggibacking 
with the signature mode of phase 1. One should also specify how to do
the piggibacking with the other modes of phase 1 (encryption,
revised encryption, pre-shared key.) In fact, perhaps one can describe 
a general method of piggybacking and say that it applies to all modes.


Ran





> The main reason that this proposal is presented this way is because
> SecureID/RADIUS/TACACS+/AXENT are just methods of authentication and
> thus they should be placed where other methods of authentication are
> now.  Mainly in the authentication exchange of ISAKMP (phase I).
> 
> Your suggestion of performing the extra authentication after ISAKMP has
> created both a ISAKMP SA and an ESP SA, in my view, defeats the purpose
> of authentication.  In the proposal, if SecureID authentication fails,
> then no ISAKMP SA is created and we do not move on to phase II (to build
> an ESP SA).
> 
> >Reading the new extended authentication within ISAKMP/Oakley draft
> >(draft-ietf-ipsec-isakmp-xauth-00.txt), I have the following problem.
> >Why do the extra Secure-ID authentication as part of the ISAKMP/Oakley
> >key exchange? It seems easier to do the Secure-ID authentication
> >(that is, the NOTIFY messages) *after* the ISAKMP oakley exchange is
> >completed. The NOTIFY messages can be then transmitted securely using,
> >say, ESP. This is a more modular design. In particular:
> >
> >* You can use *any* ISAKMP/Oakley mode.
> >
> The only reason that MainMode was chosen was because it encrypts the
> authentication exchange.  If you don't mind sending user names and
> passcodes in the clear, then you may use Aggressive Mode.  But I don't
> think people should do that.
> >
> >* There is no need to modify/add new modes to ISAKMP/Oakley
> >
> No new modes are being added to ISAKMP.  This is an extention to Main
> Mode.
> >
> >* This way, the NOTIFY messages can be simplified considerably,
> >since now they get their authentication from ESP. But this is a concern
> >of the Secure_ID/RADIUS guys.
> >
> The notify messages in the proposal are already simplified and they use
> ISAKMP NOTIFY payloads.  Thus we do not have to build yet another
> protocol.  It is very clean.
> 
> >True, the cost of this modularity is another 1.5 round trips. But this may
> >be well worth it. (In ISAKMP we pay much more for modularity and good 
> >uniform design.)
> >
> >
> >Ran Canetti
> >
>
Follow-Ups: