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

RE: Legacy auth methods support

Hi Dan,

> Please don't reinvent terms. There's phase 1 which 
> establishes an authenticated
> IKE SA and phase 2 which establishes IPSec SAs. XAUTH doesn't 
> fit into this
> well. 

I didn't try to redefine "phase 1"; I used the definition from [IKE]. I
merely tried to come up with a fair definition of "phase 1.5" -- a seemingly
pejorative term which has been used on this list without clear definition.

Yes, I left out the section which states "Main Mode and Aggressive Mode each
accomplish a phase 1 exchange." 

Why? Because that quote was merely an explanation of the behaviour at the
time the RFC was written, not a command to the implementer. Yes, it is a
valid explanation when you only consider the authentication mechanisms that
were available at the time. (But it doesn't say "Main Mode and Aggressive
mode MUST accomplish a phase 1 exchange.")

Restricting new behaviour based on explanatory passages in the RFC seems
awfully pedantic to me.

> And the phrase "the channel is secure, but not yet 
> authenticated" is very 
> bizarre. An unauthenticated channel is not secure.

I don't want to argue over semantics. You know full well what I MEAN by
"secure". BTW, if "authenticated" is redundant given "secure", then why did
you write "secure, authenticated channel" in the RFC?

> If you look at the exchanges in RFC2409 you'll notice that they morph
> depending on the authentication method. The exchanges are different if
> you do pre-shared key authentication vs encrypted nonce 
> authentication.

They never morph by adding new packets, and with the exception of public key
encryption, payloads don't get moved around. They mainly morph by redefining
the SIG/HASH payload in some pseudo-random fashion. In that sense, the
authentication method can be changed in a fairly MODULAR fashion.

That's what we want to do with XAuth -- provide legacy authentication (and
only legacy authentication) in a modular fashion.

In addition to providing legacy authentication, Crack mandates various
properties of the exchange: Only digital signatures can be used, DoS
resistance is not provided, a certain type of extended digest is required,
and rekeying must be initiated by the client.

None of these requirements are part of XAuth. XAuth plugs into any existing
phase 1 mode with no change except for a single magic number in the

> And that's what gives people heartache. Some grafting has to 
> be done into
> your code to force an IKE SA which has completed phase 1 
> (either by Main
> Mode or by Aggressive Mode) to not immediately transition into doing a
> phase 2 exchange (Quick Mode). 

Yeah, I remember that code. It was maybe 10 lines. Something like this:

if (WeNeedToDoXAuth)
  if (WeAreXAuthInitiator)

> And if the peer initiates a 
> Quick Mode to
> not accept it, although the behavior is not well defined in 
> this case. Do
> you send back a notify message saying INVALID_EXCHANGE_TYPE? 
> Do you silently
> drop them while you do XAUTH? What if the peer retransmits 
> enough times
> causing him to give up? In either case the peer could 
> reasonably delete
> the IKE SA out from under the XAUTH exchange. These problems 
> don't exist
> with CRACK because once you transition out of phase 1 you're 
> immediately
> ready to do phase 2 just like normal IKE.

In this case the peer is clearly misbehaving.

What do you do if the peer sends you a Quick Mode before you have finished
doing Crack? 

It's the same situation if the peer initiates QM before XAuth is complete
WHEN YOU HAVE NEGOTIATED TO DO XAUTH. That's why we keep telling people that
they need to negotiate XAuth as part of the SA proposal. That's why the
magic numbers are in the draft.

 Beauty without truth is insubstantial.
 Truth without beauty is unbearable.