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

Re: Hybrid Authentication and Remote Access



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.

One thing that xauth draft does incorrectly is that it again extends
the transaction exchange defined by the configuration mode from 2
packets to 3 or more packets. The configuration mode clearly defines
that transaction mode is always 2 packets, and I think that if xauth
mode is supposed to work over that it must not modify the exchange,
only the values inside the payloads.

This could be fixed in the xauth draft so that it uses one or more
transaction exchanges like this:

   IPSec Host                                             Edge Device
   --------------                                   -----------------
1.                        <-- REQUEST(SECURID NAME PASSWORD PASSCODE)
   REPLY(SECURID NAME PASSWORD PASSCODE) -->

2.                        <-- REQUEST(SECURID NAME PASSWORD PASSCODE)
   REPLY(SECURID NAME PASSWORD PASSCODE) -->


Where 1 and 2 are separate transaction exchanges requesting two
passcodes.

The only thing that is missing is the AUTH-OK or AUTH-FAILED
information, but I think that can be expressed as notification (it
really is notification). So if the authentication fails the server MAY
send a notify message to the other end specifying that the
AUTHENTICATION-FAILED error (or probably better have own
EXTENDED-AUTHENTICATION-FAILED error code).

The IPSec host can know that the authentication has succeeded if the
Edge Device lets it continue the process that triggered this extended
authentication. If we think about the whole picture it will probably
be something like this:


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

> In general I agree with you. The problem is that while the future of
> ISAKMP is the full public key modes, in the present there are large
> installation bases of challenge/response tokens. Thus waiting for the
> next phase of the ipsec to add more notification types to is missing
> the point of providing a solution in the near future.

It is ok to add new ERROR notification types, but I don't think it is
good to add new semantics to notify payload.

I really really don't like that we modify existing exchanges and
extend the number of packets used in them. If you need more packets
than in the main mode, then define new exchange method.

Also note, that there is no need to be concerned about breaking
existing implementations. If the other end does support this new
authentication method (it selects that authentication method), then
it will also support all new payloads etc you might invent for this.
If you use new exchange method and the other end doesn't support it,
then you have to revert back to main mode if you can, but if you
cannot, then there is nothing you can do. 

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. 

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.

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.

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.

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

I think that draft is going to need more thinking about. I now think
that you really need new exchange method for this. 
-- 
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: