[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Ordering of payloads
Hi Tero,
My understanding of Aggressive mode was that most of the problems you
describe are actually features of that particular mode. It becomes
useful in situations where there doesn't need to be any 'real'
negotiation of ISKAMP SAs. For example an IT person in a corporate
environment may find it desirable to have all the clients configured to
use one and only one ISAKMP SA type. If they are only going to
negotiate this one type (say DES/MD5/Shared Secret) use aggressive and
speed up the connect time.
On the original subject...
I agree with Tero, given the fact you have to flip through the packet
for a sanity check anyways, you have an opportunity to figure out where
everything is. Added on top of that the fact that the other payloads
can come in any order (but in a specific group sequence) there is no
added complexity in finding the SA payload and processing it in the
order you require. ISAKMP also states that some optional payloads must
be accepted at any point in the exchange (not that I would ever stick
anything before the SA).
But specifying it must be first doesn't really bother me either :)
Bye
----
Greg Carter, Entrust Technologies
greg.carter@entrust.com
Get FREE 128-bit FIPS-140-1 Validated Crypto for the desktop
http://www.entrust.com/solo.htm
>----------
>From: Tero Kivinen[SMTP:kivinen@ssh.fi]
>Sent: Thursday, September 11, 1997 10:24 PM
>To: ben@ascend.com
>Cc: ipsec@tis.com; isakmp-oakley@cisco.com
>Subject: Re: Ordering of payloads
>
>...
>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.
>--
>kivinen@iki.fi Work : +358-9-4354 3205
>Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573
>