[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention Security Transform to Proposed Standard
>> Thus, I conclude that the combined transform provides *weaker*
>> authentication than the standalone transforms. This surprises me, and
>> seems a mistake.
>In the case of IP in IP, the inner IP packet is the one protected by this
>transform. I will add a statement that IP in IP is what was ment...
Thinking about this a bit, It has become less clear to me that the
combined ESP/AH/Replay transfor is significantly less strong than an
AH that covers the IP header. My reasoning is that with yhe addition
of a replay counter, it becomes close to impossible to take an old
packet, change the IP header fields and have it accepted at the
destination - the replay field will always flag it as a duplicate.
>> Another important point:
>>
>> > 1. (Optional step) Decrypt the first bock of data using the
>> > appropriate DES_key_ and IV_key_ (or IV) and then do a quick "san-
>> > ity check" of the count. If the count has decreased below the win-
>> > dow or has increased by more than 65k, then it is safe to discard
>> > this packet as either a replay, non-authentic or too old. If the
>> > count is within 65K, then the probability that the packet is
>> > authentic is 65535/65536. (The following replay check and HMAC
>> > check are both still required).
>>
>> Maybe I'm missing something, but the above would appear to not handle
>> network partitions well. If a destination becomes unreachable (for
>> whatever reason), and the sender sends 65K packets during the outage,
>> packets sent after the destination becomes reachable again will
>> continue to be rejected. Thus, this "optimization" seems wrong.
>2 comments, First, my choice of 65000 was arbitrary. That number can be up
>to 16M with little change. That is, by making sure that the number was
>within 16M, then the probabilitiy of a bad packet being caught is 255/256,
>which makes this still reasonable.
It seems to me you don't want to have *any* limit. Replay protection
requires that you not accept any packets with sequence numbers lower
than the highest received so far (modulo the window). Under what
conditions would it be correct to reject a packet with a higher
sequence number than seen so far?
I agree that receiving a packet with a replay coutners whole lot
greater than expected should serve as a warning that something is not
right (e.g., there was a network partition). However, simply rejecting
such packets without taking further action (such as renegotiating
keys) can lead to connectivity failures that won't fix
themselves.
My recommendation would be to remove the text and the quick test
(since it may be incorrect) and add a paragraph suggesting that such a
test might be useful to detect problems that require further
investigation. E.g., it might be useful to renegotiate keys. Just
blindly rejecting packets that arrive with a greatly advanced replay
counter can lead to connectivity failures.
>> I assume the IV needs to be a multiple of 64-bits (to insure that the
>> Data starts on a 64-bit boundary for IPv6)? If so, the draft should
>> state this explicitely (it doesn't seem to).
>Interesting point. I assumed that the IV was a full DES block or 64
>bits.
Oh, right. The IPv6 alignment requirement falls out naturally, but
isn't the driving motivation. What is a "full DES block"? Wouldn't it
be 64 bits as well?
>> Also, I don't understand where the 65535/65536 probability comes from
>> or what it means.
>Assuming that the packet received count (x) and the highest received replay
What exactly is the "received count" x? The number of received packets
addressed to the same destination with the same SPI?
>count (r) are 32 bit unsigned number, if the packet is between r < x <
Do you mean if the "replay field of the packet is between.."?
>r+65K then this checks to see if x is within the 64k possible. If the field
>has been randomized through modification of the first block -or- the
If which field has been randomized? The replay counter field? (Sorry
if this seems really basic, but I'm missing something important obviously.)
>attacker does not know the key, then the value of x will be any random 32
>bit value or one of 4B numbers. The probability of 2 random 32 bit numbers
>being within 65K of each other is 4B/65K or 65K.
>> >Appendix A
>> >
>> > This is a routine that implements a 32 packet window. This is intend-
>> > ed on being an implementation sample.
>>
>> This code in fact assumes that the replay counter always starts at
>> 0. It should state this, since this assumption is not made elsewhere
>> in the draft.
>>
>> Also, if it is reasonable to always start the replay counter at zero,
>> why does the draft not simply require this? Right now, the initial
>> counter value is negotiated.
>Good point. I assumed that the caller would normalize this (by subtracting
>the starting value. Since this is an unsigned value, this works.) Again, I
>will add commments regarding this.
I'm still a bit unclear about whether the replay counter should/should
not start at 0. If it shouldn't (and it probably shouldn't, since the
first packet sent to a new SPI would then have a predictable replay
field value) I think the document should say so explicitely.
On another point that others have brought up, I don't see the value of
having a *negotiated* replay window. I think its reasonable for the
receiver to have one, but for the sender to know what its size is
implies that the sender would (for some reason) find it useful to send
(slightly) out of sequence packets and derive some sort of benefit. I
don't have a clear sense of why a sender would do that and what
benefit it would derive.
Thomas
References: