[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hybrid Authentication and Remote Access
Tero Kivinen wrote:
>
> Moshe Litvin writes:
> > > Read the other drafts.
> > I read them. From where do you think that I got the idea of using the
> > notify payload for challenge response? (read for example
> > ISAKMP/XAUTH).
>
> The draft-ietf-ipsec-isakmp-xauth-02 draft uses configuration mode
> instead of notify payloads. The configuration mode
> draft-ietf-ipsec-isakmp-mode-cfg-04 draft defines new exchange method
> called transaction exchanges, and uses special attribute payload
> inside them. It doesn't use notify payloads anymore.
You are right, I wasn't aware of the changes in that draft, the ATTR
payload is more appropriate.
[critisim of XAUTH deleted]
>
> IPSec Host Edge Device
> ---------------- -------------------
> Starts Main mode
> HDR, SA ->
> <- HDR, SA
> HDR, KE, Ni ->
> <- HDR, KE, Nr
> HDR*, IDii, SIG_I ->
> <- HDR*, IDir, SIG_R
> Starts quick mode
> HDR*, HASH, SA, Ni, KE, IDci, IDcr ->
> Edge device realizes
> that it needs extended
> authentication before
> quick mode can be
> allowed, it starts
> extended authentication
>
> <- REQ(NAME, PASSWORD)
> Asks password from user (note that
> quick mode negotiation may expire
> during this, because it may take quite
> long time from the user to answer the
> password query)
> REPLY(NAME, PASSWORD) ->
> If client notices that is quick mode
> has already expired (timed out)
> it should start new one here.
> Verifies the password.
> If correct, replies to
> the quick mode.
> <- HDR*, HASH, SA, Nr,
> KE, IDci, IDcr
> HDR*, HASH ->
>
> And then we have authenticated connection. If the password
> verification fails the negotiation might continue like this:
>
> IPSec Host Edge Device
> ---------------- -------------------
> Verifies the password.
> Notices that password
> is bad, sends notify
> back
> <- HDR*, HASH, N
> If the client receives notification
> it can show it to user.
> In any way it is going to resent
> its quick mode packet later, because
> server hasn't yet answered that
> HDR*, HASH, SA, Ni, KE, IDci, IDcr ->
> Edge device realizes
> that it needs extended
> authentication before
> quick mode can be
> allowed, and it doesn't
> have extended
> authentication in
> progress, so it starts
> a new extended
> authentication
> <- REQ(NAME, PASSWORD)
> Asks password from user
> REPLY(NAME, PASSWORD) ->
> Lets assume here that the previous
> packet to the quick mode was the final
> retransmit and now the negotiation is
> expired, so the client must start new
> quick mode negotiation here.
> HDR*, HASH, SA, Ni, KE, IDci, IDcr ->
> Verifies the password
> if correct replies to
> the quick mode.
> <- HDR*, HASH, SA, Nr,
> KE, IDci, IDcr
> HDR*, HASH ->
1. If you already did ISAKMP with signatures why do you need XAUTH?
signatures seems to be a stronger method.
2. How does the edge device knows the client support XAUTH? is it
negotiated or just assumed?
3. I thought that the main purpose of main mode is to provide
authentication for the following negotiations, in your example it didn't
(otherwise you wouldn't need XAUTH). You created an ISAKMP SA, what
security does it hold?
[deleted argument that I already agreed to]
> Also extending the main mode after the 6 packet (+ possible commit bit
> notifications) is explicitly forbidden in the isakmp-oakley-08 draft
> when doing certificate request payload processing, so I think most of
> the implementations take that so that it will always take 6 packets,
> no more, no less (+ plus the (two) final connected notifications if
> commit bit was on).
>
> If you are going to extend it, that might require quite a large
> modifications to the existing code.
None of the implementation support hybrid mode, I think that most of
them don't even support the revised encryption mode, so I am sure that
it will require quite a large modifications to the existing code. I
don't see why the larger number of packet is so much harder than other
changes.
>
> So I suggest following. Use ATTR payload (from configuration mode) to
> store authentication information. You can also use the same numbers
> etc than the extended authentication mode is already using. If the
> server selects the hybrid authentication mode from the SA then it also
> supports those new payloads, if it doesn't select it then it selects
> something else (if another choice is provided) and the other end does
> not send ATTR payloads.
I agree.
>
> You might also want to think about creating completely new exchange
> method that would allow this, gss api authentication, and possible
> other authentication methods that require multiple packets back and
> fort.
There are three options:
1. Create a new exchange type which means that the hybrid mode cannot be
negotiated.
2. Criple the mode to allow only a single "challenge/response" (like in
the GSS-API draft).
3. Allow more than 6 packets in main mode.
Two of those option heart the usability of the authentication mode, one
of them breaks a detail wich is not even specified as a rule. I really
don't see why there is a question which is the best option.
> Also I really don't like the idea that the server cannot start
> re-keying, because IT MAKES things really hard. If you think about the
> situation where we have 10 MB byte life time for the SA and the server
> is sending some large file to the client. Now the client must count
> incoming bytes in addition to its own outgoing bytes, so it can know
> when the server is going to expire the SA because of the byte limit,
> and it must start re-keying before that (provided that the ISAKMP SA
> is already expired too). That is really BAD.
It less bad in reality than it is in theory. All the client has to do is
to keep the ISAKMP SA alive. (BTW the client has to count the incoming
bytes anyway, to make sure that complies with the security policy)
> Also note, that the client might not know that the server has already
> deleted the ISAKMP SA when it is going to start re-keying of the ipsec
> SA. The server might have deleted the ISAKMP SA because it run out of
> memory or so and the delete notify might have been lost (if the server
> even ever sent one). In that case the server has no other choice than
> just start dropping all packets going to the client. It cannot restart
> main mode, because it needs client to do that. It might not even have
> enough information about the previous ISAKMP SA, so it could resent
> its delete notification to client. The only thing it can do is to send
> completely UNPROTECTED notification to the client asking him to start
> ISAKMP SA (denial of service attackers really like that, they just
> send one faked isakmp notify to client and that will consume lots of
> processing power from the server (Diffie-Hellman, Private key decrypt
> etc).
When dealing with remote users (with no fixed IP) the server has to
remember some dynamic data to be able to do isakmp (it at least has to
know that there is a remote user at that IP, it will probably want to
know who is the user (perhaps that user is not permited to work at those
hours so there is no need to waste effort on negotiation). In some case
it will do some sort of NAT, so it will have to remember also this.
So, to be able to recover, the server may generate a protected delete
payload when it delete the SA and remember it. Then if and when the
server will won't to recover the tunnle he can retransmit that payload.
>
> I think that draft is going to need more thinking about. I now think
> that you really need new exchange method for this.
I really don't see what is so wrong with having more than 6 packets in
main mode. For me the structure of main mode is: two packets for SA
attributes negotiation, two packet for exchangin key material, and
authentication packets. Until now the authentication mode required
exactly two packets, so main mode needed exactily 6 packets. But if an
authentication mode require a different number of packet main mode can
be made to have a different number of packets.
Regards,
Moshe
--
-----------------------------------------------------------------------
Moshe Litvin Check Point Software Technologies Ltd.
moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555)
Fax: +972-3-575-9256
-----------------------------------------------------------------------
Follow-Ups:
References: