Subject: [Mipshop] RE: Replay protection (was RE: Review of draft-vidya-mipshop-handover-keys-aaa-02)

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 7 Jun 2006 16:31:57 -0700

> 
> Here is my take on this (your summary is accurate, but I want 
> to look at it in a slightly different way):
> 
> The threat is from an active adversary (passive adversary 
> might just monitor or read traffic and active adversary may 
> delete, replay, and/or modify packets), and so replay 
> protection is a requirement.  HKReq is being sent to the AAA 
> server, and the integrity and replay protection is between 
> those two parties.  Timestamp based replay protection reduces 
> the number of round trips and so it makes sense.  If the 
> server has state, the MN can also use sequence numbers (or 
> message IDs, as they are similar) to achieve the same thing.
> 

Agree with the above. 

> For reliable transport the MN would retransmit the same 
> message a pre-configured number of times.  The AR would be 
> dumb to all of this and forward everything to the AAA server.
> 
> The use of message IDs and sequence numbers gives the AR the 
> ability to reduce the load on the AAA servers from 
> adversaries that may replay messages, but cannot modify them. 
>  It appears that this capability comes with additional over 
> the air overhead, extra processing at the MNs (for reliable 
> transport, the MN recreates the message with a new sequence 
> number and calculates the MAC again), and state at the AR (to 
> store the latest sequence number corresponding to a given 
> message-id from an MN). I think this additional complexity is 
> not worth it, since an adversary that can replay a message 
> can just as easily modify the sequence number to launch a DoS 
> attack on the AAA.
> 

I think we agree on what the sequence number achieves - it comes down to
a question of whether or not the complexity in retransimission and the
extra bytes are worth it. We had concluded it is (actually, we had
concluded that the simplest replay attack would really just involve
blind replays) and you contend it isn't - it would be good to get some
more perspectives here. 

Also, from an implementation perspective, does retransmission become a
lot more complicated due to the need for packet modification? I do
understand that the packet needs to be recreated and the MAC
recalculated - how bad is that? 

Regards,
Vidya

> regards,
> Lakshminath
> 
> At 09:15 PM 6/6/2006, Narayanan, Vidya wrote:
> 
> >All,
> >Lakshminath, in his review of the draft, raised a question 
> on how replay
> >protection is handled in draft-vidya-mipshop-handover-keys-aaa-02. A
> >brief summary of the currently specified behavior:
> >
> >The HKReq/HKResp messages contain a message ID and a sequence number.
> >Both are randomly chosen by the MN in the HKReq. The message ID stays
> >the same in retransmissions, while the sequence number is incremented
> >for every retransmission. The HKReq message is integrity 
> protected using
> >a key that the MN shares with the AAA server. If an 
> adversary replayed
> >the HKReq as-is, the AR would be able to drop that packet, 
> since it must
> >never receive multiple HKReq messages with the same message ID and
> >sequence number from an MN. If the adversary changed the 
> sequence number
> >and transmitted the HKReq, this message will only be dropped 
> at the AAA
> >server (due to a failed integrity check). Basically, the 
> sequence number
> >was included to detect blind replays at the AR, so that such replayed
> >messages are not sent to the AAA server.
> >
> >The protocol, in addition, has timestamp-based replay protection
> >end-to-end (however, it is specified as optional). The timestamp
> >provides "absolute" end-to-end replay protection between the 
> MN and AAA
> >server.
> >
> >Lakshminath raised the point that differentiating between 
> such "blind"
> >replays where the adversary replays the packet with no 
> modifications and
> >replays where the adversary does modify the packet to pass 
> through the
> >AR is unnecessary. At the time of writing the draft, we debated the
> >inclusion of the sequence number in addition to the message 
> ID quite a
> >bit and felt that it does have some value.
> >
> >Does anyone have thoughts on whether such a distinction in message
> >replays is needed/useful?
> >
> >Thanks,
> >Vidya
> >
> >ps: Lakshminath, please correct me if I have misstated your comment
> >here.
> 
> 

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 22 Jun 2006 15:38:19 +0200

Hi Lakshminath, 

> Hi Vidya,
> 
> Here is my take on this (your summary is accurate, but I want to look 
> at it in a slightly different way):
> 
> The threat is from an active adversary (passive adversary might just 
> monitor or read traffic and active adversary may delete, replay, 
> and/or modify packets), and so replay protection is a 
> requirement.  HKReq is being sent to the AAA server, and the 
> integrity and replay protection is between those two 
> parties.  Timestamp based replay protection reduces the number of 
> round trips and so it makes sense.  If the server has state, the MN 
> can also use sequence numbers (or message IDs, as they are similar) 
> to achieve the same thing.

It is true that you can also design the protocol not to use timestamps
(and synchronized clocks) but nonces or sequence numbers. This would,
however, require treatment of the special case where one of the end
points looses its state. 

> 
> For reliable transport the MN would retransmit the same message a 
> pre-configured number of times.  The AR would be dumb to all of this 
> and forward everything to the AAA server.

I did not quite got this point. 

> 
> The use of message IDs and sequence numbers gives the AR the ability 
> to reduce the load on the AAA servers from adversaries that may 
> replay messages, but cannot modify them.

With today's network access authentication procedures you can always put
load on AAA servers by just starting EAP-based authentication.

  It appears that this 
> capability comes with additional over the air overhead, extra 
> processing at the MNs (for reliable transport, the MN recreates the 
> message with a new sequence number and calculates the MAC again),

Where does the "reliable transport" come from? 

This overhead is minimal but it does not add any value. 

 and 
> state at the AR (to store the latest sequence number corresponding to 
> a given message-id from an MN). I think this additional complexity is 
> not worth it, since an adversary that can replay a message can just 
> as easily modify the sequence number to launch a DoS attack 
> on the AAA.
I agree. 

Ciao
Hannes

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 22 Jun 2006 15:38:19 +0200

Hi Lakshminath, 

  It appears that this 

 and 
I agree. 

Ciao
Hannes