[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
proposed changes to ISAKMP/Oakley
Daniel Harkins writes:
> * clarification on group offers. If a group is specified using its
> description (Group Description attribute) then other group attributes
> like Group Prime or Group Type are not allowed.
So you cannot give a "name" to private group when doing phase I
negotiation with group information? I think it would be nice to be
able to send new group in the phase I negotiation and use that also in
phase II without negotiating the group again in phase II new group
mode negotiation. (== allow group description, but say it MUST be on
private range if other the group is described in place).
> * added clarification on the M-ID used in Informational Exchanges. The
> M-ID of this exchange is unique and MUST NOT be the same as that
> used by a phase 2 exchange which prompted the Informational Exchange.
Some of the vendors in interop used Message ID 0 in informal exchanges
when something happens goes wrong with the exchange quite early (say
the first packet is invalid etc). I assume the M-ID of informal
exchange MUST be unique also in phase I?
Did you add any clarification of the calculation of authentication
hash? Most of the vendors in interop used only IP address instead of
full ID payload (without generic headers, but with protocol and port
number). I had to add compat option for that in interop...
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAp | IDii)
^^^^
HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDir)
^^^^
[I also would like to have lengths of the data added to authentication
hash, so it would clearly remove all kind of attacks where man in the
middle tries to move data from one payload to another (there was
similar case in early draft of ssh 2 protocol where you really could
even use it to do successfull attack. I haven't found a any way to use
it in isakmp/oakley, but it gives me bad feelings that some might find
out attack using that).]
> I don't think this will break too much since I know of only two
> implementations of authentication with public key encryption (one
> is mine) and in spite of the offers for testing there was no
> demonstrated interoperability of this at the last IPSec bakeoff at
> TimeStep.
Our implemntation also supports authentication with public key
encryption, but I don't think that will be big change.
There are also some other things that should have some text in the
draft:
1) The oakley draft specifies the format of variable lenght
integers, but that format is NOT used by isakmp/oakley. The
isakmp/oakley draft should say how variable length integers
are send in KE payloads (length in payload length, data
directly in payload, no extra padding), and how they should
be added to HASH (are leading zeros allowed in g^x)
2) Clarify the text in authentication with public key
encryption about the negotiated hash / encryption algorighm
when using aggressive mode (no negotiation of SA done yet).
3) Now it is allowed from initiator to send SA proposal that
will have several authentication methods offered to
responder. This is fine in main mode, but in aggressive
mode the initial packets sent by initiator differs when
authenticating with public key encryption or when
authentication with other authentication methods. I don't
know if this should be allowed or disallowed by draft, but
I would like to see something about it in the draft.
4) Draft should state clearly that there is only one cipher
context/IV shared in both directions. At least I
automatically assumed there is one cipher context/IV
for encryption and one for decryption (ie separate contexts
for each direction).
--
kivinen@iki.fi Work : +358-9-4354 3205
Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573
Follow-Ups:
References: