[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hybrid Authentication and Remote Access
Tero Kivinen wrote:
>
> Moshe Litvin writes:
> > 1. If you already did ISAKMP with signatures why do you need XAUTH?
> > signatures seems to be a stronger method.
>
> Because the signatures only authenticate the machine, not the user.
> For example we might have several general use machines around, with
> each one having separate private key, and when someone logs in from
> that, it only says that ok, this is this pc-55.xxx.com, but it doesn't
> say anything about who he is and does he have permission to create
> ipsec SA.
>
> > 2. How does the edge device knows the client support XAUTH? is it
> > negotiated or just assumed?
>
> If the server requires XAUTH, it assumes the clinet does it. If the
> client doesn't answer to XAUTH or answers with error notification then
> it doesn't support it, and then the edge device will propably just
> drop the connection, because the user could not be authenticated.
>
> > 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?
If I understand you correctly XAUTH is used when you want to separately
authenticate the machine and then the user. Usually in remote access
scenario you don't really care about the machine and you are only
interested in the user.
>
> Main mode is used to authenticate the MACHINE in the other end. For
> example the machine might be the other networks security gateway.
> After that we do know that ok, the connection is coming from the other
> network, but we do not know who is in the other end. XAUTH will give
> us that information after that we might decide wheter we allow user to
> do something or not.
>
> > 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.
>
> Larger number of packets isn't harder if it is separate exchange.
> Combining everything together makes the protocol complicated and we
> have lots of different special cases.
>
> > 1. Create a new exchange type which means that the hybrid mode cannot be
> > negotiated.
>
> I think it has so much special cases and differences compared to main
> mode that it is no use to try to combine it to main mode. Quite often
> the client will know before hand whether to use hybrid mode or not,
> and in the server it doesn't matter. So if client does have key for
> other authentications (rsa/dsa private key or preshared key) then use
> normal main mode first and do XAUTH after that. If the client doesn't
> have any key to the server, the only choice it has is to use hybrid
> mode anyways. So I don't think that is a real problem.
Hybrid mode is not so different, in fact it is more similar to revised
encryption than revised is to pre-shared secret.
>
> > 2. Criple the mode to allow only a single "challenge/response" (like in
> > the GSS-API draft).
>
> I don't think that is a good idea, because after that you create new
> complicated system and still you don't allow taking advantage of the
> benefits after the basic system.
>
> > 3. Allow more than 6 packets in main mode.
>
> I don't like that option, because it will make integrating lots of
> special code inside main mode code. If we use separate exchange the
> code can also easily be separated. In any way I really dont like about
> exchanges that can go forever...
>
> > 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.
>
> I want the isakmp to as simple as possible. I do not want to combine
> everything together as one huge negotiation having lots of different
> options that will change the negotiation slightly. Using modular
> structure makes implemantation quite a lot of easier. There are
> already some special cases in the isakmp protocol that makes its
> implementation unnecessaryly harder, and I don't want to get more of
> them in it.
It is modular. All the difference are after both sides agreed about a
certain path. If you like, after this point you can treat it as a
separate exchange.
>
> > > 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.
>
> How? The server can always delete the ISAKMP SA, and if the one packet
> containing the delete notification is lost the client HAS no way to
> know if the ISAKMP SA is still valid or not. Also if server has a
> resource shortage, it might be that it doesn't have enough resources
> to send that notification at all.
>
> > > 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.
>
> That information is usually stored in the ipsec SA and the ISAKMP SA
> doesn't need to store that information.
This a strange implementation choice, you may have a lot of IPSEC SA's
Simultaneously, and they will change all the time. Why do you want to
copy all that information to every separate IPSEC SA (especially since
you are so concerned about resource shortage).
> If the ISAKMP SA is deleted
> when the ipsec SA is about to expire we just create new ISAKMP SA with
> that IP address that is the other end of the ipsec SA. There is no
> need to store anything about the other end in the ISAKMP, only in the
> ipsec.
>
> > 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.
>
> And what happens if it runs out of memory to store those protected
> delete payloads? It has no way to know if the client has received it
> or not, and in your example it cannot delete it.
>
> > 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.
>
> I think the rekeying stuff is much more serious than having 6 packets
> in the main mode. Having more than 6 packets in the main mode will
> just make it harder to implement and proably generate some more bugs
> there, but it can be don. I just dont like it.
>
> Makeing the rekeying stuff only work for one direction is much worse,
> and can create very nasty situations where the server has no way to
> fix the broken connection with client (for example after server reboot
> the client cannot detect this before it sends first packet after that
> (or not even then, if the server just throws unknown ipsec packet away
> without any notification)).
The problem of rekeying is a direct consequences of the asymmetrical
nature of the hybrid mode. The asymmetrical nature gives the ability to
harness the powers of public key cryptography without using a full blown
PKI, but there is such thing as free lunch. However implementations that
are aware of that problem can solve it quite easily.
Remembering the encrypted delete payload will require less than 1K per
user, which means 1 MB per 1000 users, every machine that can handle
1000 concurent users can easily handle it (the same for higher or
smaller number).
Once you do this, all you need is for the client to keep the ISAKMP SA
alive. If there is on going traffic on the line someone has to keep it
alive and might as well be the client. If there is no traffic this can
be used as a keep-alive signal, so that the server will not think that
the client hanged-up (and in case of NAT will give the IP address to
someone else).
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: