[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ipsec-new-auth-00.txt
Rob,
I included HMAC with MD5 and SHA-1 in the I-D as a means of
expressing the default algorithm support requirements. Additional
algrotihms can be specified by separate RFCs; the difference is that these
RFCs need not include the rest of the AH (or ESP) spec. Instead, they will
just be algorithm defintions, perhaps with a few references to the relevent
RFCs. The additional algorithms will be registered with the IANA. We can
improve the I-Ds by emphasizing this means of adding other algorithms.
However, I don't think the current I-Ds are unduly algorithm dependent as a
result of the approach adopted here, but there is a clear intent to
establish default, required algorithms. I'm not sure that the indirection
through another RFC for specifying requirement algorithms is an
improvement. If we change the defaults, another RFC gets produced and the
indirection doesn't seem to buy us that much.
As for anti-replay and manual keys, I think other messages have
addressed that topic. Mostly, we need to refine the terminology, but I
think the intent is correct. If one uses a manually positioned key for AH,
then AR seems incompatible in that reliable state retention would be
required across crashes and some means would be needed to prevent cycling,
despite the lack of an automated ability to load new keys. Since we are
trying to minimize creating situations where procedural errors will result
in insecurities, I think it is appropropriate to rule out the use of AR
with static, manual authentication keys.
As for the optional nature of the AR counter, I'm quite happy to
make it permanent field if that's what the WG wants, but as the I-D points
out, this will result in an extra 4 bytes of overhead for IPv4. Given that
some folks have produced ESP drafts that employ implicit IVs specifically
to reduce per-packet transmission overhead in the 4-8 byte range, it seems
a bit inconsistent to mandate this 4 byte field.
I have also heard that there was some concern expressed over the
issue of making anti-replay optional, because of the overhead of
negotiating this security service, especially in terms of window size
negotiation. I've had some private communication with folks immediately
preceeding the meeting, and one suggestion that arose was making a window
size of 32 the default, if AR is negotiated. One might eliminate the need
to negotiate a window size at all if this default were considered adequate,
and the receiver were free to implement a larger window as a local option.
This would simplify the negotiation process, and allow it to be expressed
as just a compound "transform" along with the algorithm negotiation. That
would require no additional ISAKMP messages and thus should not raise
objections re added negotiation complexity.
Steve
References: