[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hybrid Authentication and Remote Access
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?
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.
> 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.
> > 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. 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)).
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
Follow-Ups:
References: