AW: 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.


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
> Mipshopietf.org
> https:
//www1.ietf.org/mailman/listinfo/mipshop
> 

_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

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:hannes.tschofenigsiemens.com] 
> Sent: Thursday, June 22, 2006 6:37 AM
> To: Narayanan, Vidya; Dondeti, Lakshminath; mipshopietf.org
> 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.
> 
> 
> 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
> > Mipshopietf.org
> > https:
//www1.ietf.org/mailman/listinfo/mipshop
> > 
> 

_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

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/draf
t-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

_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

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

Soliman, Hesham wrote:
> 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/draf
t-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
> 
> _______________________________________________
> Mipshop mailing list
> Mipshopietf.org
> https:
//www1.ietf.org/mailman/listinfo/mipshop


_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

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

Hesham

 > -----Original Message-----
 > From: Vijay Devarapalli [mailto:vijay.devarapalliazairenet.com] 
 > Sent: Monday, June 26, 2006 3:47 AM
 > To: Soliman, Hesham
 > Cc: mipshopietf.org
 > Subject: Re: [Mipshop] RFC4140bis
 > 
 > 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
 > 
 > Soliman, Hesham wrote:
 > > 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-m
ipshop-414
0bis-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
 > > 
 > > _______________________________________________
 > > Mipshop mailing list
 > > Mipshopietf.org
 > > https:
//www1.ietf.org/mailman/listinfo/mipshop
 > 
 > 

_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop