Re: Ordering of payloads

[Tero Kivinen <[e-mail]>]

Ben Rogers writes:
> Daniel Harkins writes:
> > > Any reason we don't mandate that the SA be the first payload for
> > > aggressive mode exchanges?  Until we parse the SA payload, we have no
> > > idea what to do with any of the others in that packet.  It seems that we
> > > are making the packet needlessly difficult to parse if the SA payload
> > > can be anywhere in the packet.
> >   I can't think of a reason. Is this a suggestion? You might want to run
> > this by the ipsec list as well if it is. Basically I don't see a problem
> > mandating that the 1st payload of the 1st message of a phase 1 exchange
> > be a SA payload.
> Yes, it was intended as a suggestion.  Anyone have any problems with
> making the mandate which Dan states above?

I don't think it will make much difference if the SA payload first or
not. If one argues that it would be easier, then one might just say
that every packet must be exactly the order given in draft, because
that would make things even more easy...

The only difference in the first packet in the aggressive mode is that
the public key encryption authentication have extra optional HASH(1)
payload and the ID and Ni payloads are encrypted with public key
encryption. At least my implementation always divides the packet
completely to separate payloads before doing anything else, so finding
the SA payload anywhere from the packet is just as easy as it would be
to find it from the beginning of packet. 

BTW there are some problems with the public key encryption
authentication in aggressive mode. Firstly there cannot be any other
authentication methods in sa proposals when using public key
encryption authentication method, because otherwise the responder
doesn't know if the ID and Ni payloads are encrypted or not.

Because the initial packets of signature and pre-shared keys have
identical information, you could have initiators proposal that offers
both signature and pre-shared keys authentication and then let the
responder select the authentication method.

The another problem is that there is no negotiated hash algorithm,
before the responder sends his SA payload back and negotiates one.
Unfortunately the draft says the HASH(1) payload that identifies the
public key used, uses the negotiated hash algorithm.

This means that the initiator have to guess a hash algorithm the
responder support and use that when sending hash of the certificate
used in the public key encryption authentication. If the responder
doesn't support it, it just drops your negotiation and hopefully sends
you ATTRIBUTES-NOT-SUPPORTED notification back, so you can retry with
other hash function. 

If initiator adds more than one hash algorithm in its SA proposal then
the responder doesn't know which of them was used to calculate the
hash (the first hash algorithm from the SA proposal?).

In the revised encryption method the problem is even harder, because
there we need common symmetric cipher before it is negotiated. If the
initiator doesn't know anything about the responder he have to try
to loop all cipher and hash algorithms one by one and try each
combination until the negotiation succeeds. 

It can only try one cipher algorithm and hash algorithm at time,
because othervise it has no knowledge which one of the algorithms
(cipher or hash) was unsuppored by responder. 
-- 
[e-mail]		              	     Work : [phone]
Magnus Enckellin kuja 9 K 19, 02610, Espoo   Home : [phone]