Subject: Re: draft-ietf-ccamp-rsvp-restart-ext-06

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 13 Jan 2007 11:39:21 -0000

Hi Derek,

I think this is a good question so I am bringing it to the CCAMP list.

The bottom line would appear to be:
- The exchange between neighbors before restart was
   secured by normal RSVP-TE means
- The exchange after restart is secured by the same means.
- This provides a degree of protection that the restarting
   node is receiving information that it originally sent to
   its neighbor.

The obvious question is, should the restarting node have some (private) way 
of authenticating that the information received on restart originated with 
it? This would presumably be some sort of cookie manufactured from a mock-up 
of the restart message that the restarting node expects to receive and 
handed to the neighbor for use in the event of a restart.

Seems like overkill to me, but I'd appreciate views from the WG.

Adrian

----- Original Message ----- 
From: "Derek Atkins" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Friday, January 12, 2007 10:59 PM
Subject: draft-ietf-ccamp-rsvp-restart-ext-06

>I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> I don't see any issues in this document beyond those already stated
> in the Security Considerations.
>
> My only question to the authors would be how does a recovering node
> verify that the data it gets from a peer node really came from the
> recovering node?  Right now it just seems to have to trust that the
> peer returns valid data.
>
> -derek
> -- 
>       Derek Atkins                 617-623-3745
>       [email-masked]             www.ihtfp.com
>       Computer and Internet Security Consultant
>
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Jan 2007 14:03:23 -0000

Hi Derek,

Yes you have captured the exposure correctly.

The question is: what is he trust model between neighbors? If the model is 
high enough then the only way for a!=b is a mistake. If the trust model is 
not high enough then a!=b could be malicious. If there is a security hole 
*between* neighbors, b may be modified in transit such that a!=b.

I think that in a cooperative singaling protocol we have to assume that 
there is trust between neighbors once identities have been established. 
RSVP-TE provides such identity confirmation and also secures the traffic 
between neighbors.

This leaves us with only the mistake, and generally we don't make extensive 
protocol changes to handle the potential for broken implementations.

Thanks,
Adrian

----- Original Message ----- 
From: "Derek Atkins" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Monday, January 15, 2007 2:56 PM
Subject: Re: draft-ietf-ccamp-rsvp-restart-ext-06

> Adrian,
>
> The fact that the exchange is secured only means that you've
> verified the endpoint, not the data.  For example, let's say
> that you and I are endpoints.  I send you "a" and then I restart.
> I ask for for my data, we secure the exchange (so I know that
> it's you I'm talking to), and then you send me "b".
>
> The RSVP-TE assures me that YOU sent me "b", but it doesn't
> assure me that "b" == "a", what I sent originally.
>
> Now, one way to solve this problem would be for the originating node
> to put their own MAC on their data with a private key known only to
> the originating node.  This way when you send me "b" it wouldn't
> have my own MAC on it (or the MAC would be invalid, or a timestamp
> would be too old).
>
> Maybe overkill, but if I'm trying to abuse resources I could use
> the restart method to backfill my requests.
>
> Thanks,
>
> -derek
>
> "Adrian Farrel" <[email-masked]> writes:
>
>> Hi Derek,
>>
>       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>       Member, MIT Student Information Processing Board  (SIPB)
>       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>       [email-masked]                        PGP key available
>
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Jan 2007 19:36:34 -0000

OK

We can write that sentence or three and close the issue.

Thanks for engaging.

Adrian
----- Original Message ----- 
From: "Derek Atkins" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
Sent: Tuesday, January 16, 2007 6:49 PM

> True, an attacker that sits between the peers shouldn't be able to
> inject messages because the endpoints are authenticated (and I
> presume that the transaction itself has integrity protection).
> You're correct that it is a question of the threat model, and that
> if you DO have a fully trusted set of peers then you don't have to
> worry about this attack.  But if that's the case I'd like to see
> a sentence or three in the Security Considerations section that
> explicitly states this threat model.  Then at least this attack
> would be clearly out of scope.  :)
>
> Thanks!
>
> -derek
>