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

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

Hi Vidya, 

the HKReq message is authenticated by the AAA server via the usage of
the timestamp carried in the Timestamp Mobility Option (defined in
Section 5.2.3) [in combination with the shared secret shared between the
two parties...]. 

The message ID allows the response message being mapped to a previous
request message and provides the end host with a guarantee of freshness.

I don't see a value in providing sequence numbers.

Ciao
Hannes

> 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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 22 Jun 2006 11:46:21 -0700

Hi Hannes,
I recall we had a long discussion on this during the early versions of
the draft and decided we'll include the sequence numbers. Some of it was
also due to the fact that the timestamp was included only in the later
versions of the draft - 00 only had sequence numbers. 

But, I'm okay with getting rid of this - it sounds like there is
agreement that the complexity is not worth the additional protection. We
can revise the draft to this effect. 

Thanks,
Vidya

> -----Original Message-----
> From: Tschofenig, Hannes [mailto:[email-masked]] 
> Sent: Thursday, June 22, 2006 6:37 AM
> To: Narayanan, Vidya; Dondeti, Lakshminath; [email-masked]
> Subject: AW: [Mipshop] Replay protection (was RE: Review 
> ofdraft-vidya-mipshop-handover-keys-aaa-02)
> 
> Hi Vidya, 
> 
> the HKReq message is authenticated by the AAA server via the 
> usage of the timestamp carried in the Timestamp Mobility 
> Option (defined in Section 5.2.3) [in combination with the 
> shared secret shared between the two parties...]. 
> 
> The message ID allows the response message being mapped to a 
> previous request message and provides the end host with a 
> guarantee of freshness.
> 
> 
> > 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:
> > 
> > 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.
> > 
> > provides "absolute" end-to-end replay protection between the MN and 
> > AAA server.
> > 
> 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.
> >

---

From: "Soliman, Hesham" <[email-masked]>
Date: Sat, 24 Jun 2006 10:14:16 -0700

Folks, 

I submitted an RFC 4140bis to start the work towards a PS RFC for
HMIPv6.
The draft can be found at:

http://www.ietf.org/internet-drafts/draft-soliman-mipshop-4140bis-00.txt

There are no changes from the RFC but I do have a list of TODOs that I
hope to get a slot for in Montreal. 

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 25 Jun 2006 10:46:34 -0700

hi Hesham,

there is one issue I would like to raise.

on the NETLMM mailing list, I was arguing for not tying
HMIPv6 or FMIPv6 with the use of Mobile IPv6. FMIPv6
already does that. it can be used independent of MIPv6.
for example, it can provide fast handoffs for a
MOBIKE enabled IPsec tunnel.

HMIPv6 OTOH has text thats says after sending a BU to
the MAP, there MUST be a BU sent to the HA. basically
it assumes MIPv6 is being used at the same time. I
think it would be a good idea to clean up the text so
that HMIPv6 can be used independent of any "global"
mobility management protocol.

Vijay

---

From: "Soliman, Hesham" <[email-masked]>
Date: Sun, 25 Jun 2006 21:39:00 -0700

Sure, this will be be cleaned up. There is no reason for tying HMIP
to the use of a permanent HA aka MIPv6. 

Hesham

 > From: Vijay Devarapalli [mailto:[email-masked]] 
 > Sent: Monday, June 26, 2006 3:47 AM
 > To: Soliman, Hesham
 > Cc: [email-masked]
 > Subject: Re: [Mipshop] RFC4140bis
 > 
 > hi Hesham,
 >