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

Re: proposed changes to ISAKMP/Oakley

  John,

> If you allow people to define a new group during Phase I setup, then you
> have the Group Description and other attributes (Prime, Type, etc.) in the
> SA.  Now, if it is possible for parties to retain a Group definition over
> Phase I re-establishment, then you the Responder would not know whether the
> Initiator is starting from boot; if it is, then it is going to repeat Group
> Description, Prime, Type, etc., and you would have to accept it or this
> wouldn't work.  (We have not yet said that everyone who starts up has to
> send the Restart Notification which was being discussed.)

I'm lost here. You define new groups-- with the Group Description-- in New
Group Mode. That is not a phase 1 mode. But nothing in the spec says that
you can't define a group by its component parts-- like Group Type and 
Group Prime-- if you so desire. In fact, it expressly allows you to do so. 
I personally won't accept them because I don't have the resources to throw 
at checking on the fly whether the group is strong enough. You might.

> Or is it considered that Phase I wipes the slate clean and all non-standard
> groups have to be renegotiated?  In that case the restriction makes sense;
> but the spec doesn't say such slate-cleaning is required.

I'm not sure which slate you're referring to. A phase 1 exchange establishes
the ISAKMP SA. Another phase 1 exchange would do the same. Nobody is wiping 
any slates.

> Re checking when you get a Group definition: any system which accepts a
> group definition from another has to either a) trust that party
> specifically to define a good group, or b) check the group.  For Phase I
> clearly it's b.  Checking: if the Group Description is one I've seen
> before, then I can check if the attributes duplicate what I have (zilch
> cost), and a match would save me any costly math checks.

If it's a defined Group Description (either through the ones defined in the
draft or via ones that you've accepted in New Group Mode) then why pass
more attributes? It's not zilch cost. I don't see the benefit in allowing
someone to say that the Diffie-Hellman group to choose is "Group Description
One" with "Group Type MODP" and Group Prime "<large number>" but I do see
a cost. It's the cost of checking and verifying that what you're sending
me is the same as what I already know.

Why do you want to be able to do this?

> Summary: I don't see why group parameter attributes should be forbidden.
> Maybe some discussion of how a system should protect itself should be
> there?  But the spec doesn't presently attempt that level of instruction to
> the reader.

They're forbidden because they burden the receiver and provide no benefit.
They're also a receipe for error.

> I would agree that group-parameter attributes should be forbidden for the
> standard groups.

That is exactly it! If the group is known by a Group Descriptor (whether 
because it's one defined in the draft-- there are now 4 groups-- or whether
it's one you have via New Group Mode-- then that's all you use to identify it. 
If it's not then you can define it by it's component parts.

Perhaps if I quote the draft you can tell me if it's unclear. In the section
that describes the attributes that must be negotiated in phase 1 it says:

	"The Diffie-Hellman group MUST be either specified using a defined 
	 group description (section 6) or by defining all attributes of a 
	 group (section 5.7). Group attributes (such as group type or 
	 prime-- see Appendix A) MUST NOT be offered in conjunction with a 
	 previously defined group."

and section 5.7 says:

	"Groups may be directly negotiated in the SA proposal with Main Mode.
	 To do this the component parts-- for a MODP group, the type, prime 
	 and generator; for a EC2N group the type, the Irreducible Polynomial, 
	 Group Generator One, Group Generator Two, Group Curve A and Group 
	 Curve B-- are passed as SA attributes (see Appendix A). Alternately, 
	 the nature of the group can be hidden using New Group Mode and only 
	 the group identifier is passed in the clear during phase 1 
	 negotiation."

Both these parts have been in the draft for a while. I added the last sentence
to the 1st part (which prompted this discussion) and wordsmithed the 2nd to
include EC2N groups since the original text was MODP-specific.

  Dan.
Follow-Ups: References: