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

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

Hi 

there has to be a way to restransmit a HKReq message by the MN if it does not receive a HKResp within a pre-configured time interval. This, however, does not require the usage of sequence numbers. You just create a new message ID and you will be fine. You have to attach a new lifetime field as well.

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: Narayanan, Vidya [mailto:[email-masked]] 
> Gesendet: Donnerstag, 8. Juni 2006 01:32
> An: Dondeti, Lakshminath; [email-masked]
> Betreff: [Mipshop] RE: Replay protection (was RE: Review 
> ofdraft-vidya-mipshop-handover-keys-aaa-02)
> 
> > 
> > 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
> 

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