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

RE: Comments on draft-ietf-ipsec-ike-01.txt (long)



>>>>> "Mason," == Mason, David <David_Mason@NAI.com> writes:

 Mason,> I would like to see the following: For any symmetric ciphers
 Mason,> where there is negligible differences in memory consumption
 Mason,> and performance overhead between key lengths, the ID/RFC that
 Mason,> explains how the cipher is negotiated via IKE (transform ID,
 Mason,> etc) MUST state that only the maximum key length is used (no
 Mason,> key length attribute).

 Mason,> If this was the case, "negotiating up" for these ciphers
 Mason,> would no longer be an issue.

That seems reasonable.  One issue I can see is backwards
compatibility.  Currently such ciphers must have the keylength
attribute present; the change you're proposing means that it must be
absent.  A less disruptive way would be to require it to be present
but set to the max value.  Even then you may run into trouble if the
other end is an older implementation that supports several lengths but 
not the max length.  (Don't know if this is common but it is currently 
legal.)

 Mason,> For security attributes that have performance/security
 Mason,> tradeoffs, security gateway administrators will most likely
 Mason,> want the policy that they configure to be enforced
 Mason,> (hypothetically - they wouldn't want a policy that says PFS
 Mason,> off being "negotiated up" to 2048-bit DH for 1000
 Mason,> simultaneous SA negotiations). If an administrator wants to
 Mason,> allow "negotiation up" he would configure it that way and all
 Mason,> combinations for a security attribute of value X and greater
 Mason,> would be offered and allowed (but then that wouldn't be
 Mason,> "negotiate up").

Are you saying that you would simply generate N proposals with the N
possible values of the parameter?  That sounds problematic.  For
example, RC4 has a keysize 40 to 256 or so, which means N is 217...
Also, if you have a (hypothetical) variable length authentication
transform, you'd end up with N*M proposals.

I'd rather have an explicit "negotiate up" policy.

	paul


References: