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

Re: proposed changes to ISAKMP/Oakley



  Tero,

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

New Groups are negotiated using New Group Mode and that has to be after
the ISAKMP SA has been established and authenticated. You can still define
a group in phase 1 by using, for example, the type and prime (for a MODP 
group) but I'd wonder why you'd just accept a prime like that and not do 
some sort of checking.

What this prevents is someone passing additional group attributes along with
an established, defined, group. If the group description is 2 and I pass
you a prime as well you should refuse this (even if the prime I send you
is the same as the one defined for group 2). Allowing such a capability
will force implementations to do rediculous checking for absolutely no reason.
If a group can be defined in shorthand (with only the description) it
makes no sense to allow additional attributes even if they merely enforce
the attributes already associated with the group.

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

For Informational exchanges that happen before the ISAKMP SA has been
established this is correct. The draft states that if the ISAKMP SA hasn't
yet been established that the Informational Exchange is passed in the clear.
In that case it wouldn't really matter what the M-ID was. 

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

Thank you! I forgot to mention that. It says:
	"The entire ID payload (including ID type, port, and protocol 
	 but excluding the generic header) is hashed into both HASH_I 
	 and HASH_R."

I also forgot to mention that I added text that allows conformant implement-
ations to limit the number of SAs it will inspect for negotiation since there
is no limit on the number of offers I can send you in the SA payload. The
following text was added to section "5. Exchanges":

	"Main Mode, Aggressive Mode, and Quick Mode do security 
	 association negotiation. There is no limit on the number of 
	 offers the initiator may send to the responder but conformant 
	 implementations MAY choose to limit the number of offers it 
	 will inspect for performance reasons."

> [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 understand what you mean by having the lengths included. Do you want
the ISKAMP generic header of the D-H public values and the IDs to be included? 
I don't see a point but I'm not a cryptographer. Can you explain this attack? 

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

The base ISAKMP draft defines this. There would be no padding added unless
this was the last payload in a Quick Mode exchange and it was necessary
for encryption.

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

I'll state the limitations on Aggressive Mode. It's not just in authentication
with public key encryption. There's no negotiation of the group either.
I don't think it's a matter of allowing or disallowing this. Aggressive
Mode is just that. It assumes quite a bit. I'll but the following text
in section "5. Exchanges" after the paragraph that describes Aggressive Mode:

	"Security Association negotiation is limited with Aggressive Mode.
	 Due to message construction requirements the group in which the
	 Diffie-Hellman exchange is performed cannot be negotiated. In
	 addition, different authentication methods may further constrain
	 attribute negotiation. For example, authentication with public
	 key encryption cannot be negotiated and when using the revised
	 method of public key encryption for authentication the cipher
	 cannot be negotiated. For situations where the rich attribute
	 negotiation capabilities of ISAKMP/Oakley are required Main Mode
	 may be required."

Let me know how that sounds. Suggested text is greatly appreciated if this
is not adequate.

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

Can you tell me where you think this should go? Along with the description
of IV generation for phase 1 (in Appendix B)?

  Dan.



Follow-Ups: References: