Re: [pcp] Problem with nonce checking

Simon Perreault <simon.perreault@viagenie.ca> Wed, 05 June 2013 08:39 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC6421F9A48 for <pcp@ietfa.amsl.com>; Wed, 5 Jun 2013 01:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JGTYofeOSAg for <pcp@ietfa.amsl.com>; Wed, 5 Jun 2013 01:39:23 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1397C21F9A41 for <pcp@ietf.org>; Wed, 5 Jun 2013 01:39:23 -0700 (PDT)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:2905:fce2:6a47:af4e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6628440452 for <pcp@ietf.org>; Wed, 5 Jun 2013 04:39:22 -0400 (EDT)
Message-ID: <51AEF93A.9040300@viagenie.ca>
Date: Wed, 05 Jun 2013 10:39:22 +0200
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: pcp@ietf.org
References: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> <tslr4ghl5u7.fsf@mit.edu> <648DDFDF-7CBC-489E-8F95-DB7D8F74D986@cisco.com>
In-Reply-To: <648DDFDF-7CBC-489E-8F95-DB7D8F74D986@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [pcp] Problem with nonce checking
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jun 2013 08:39:23 -0000

Le 2013-06-05 04:29, Dan Wing a écrit :
>> 1) make it easier for the client to retrieve the existing mapping (but
>> not learn the nonce).
>> We'd need to do security analysis of that but I think it's OK.
>
> I like that approach to retrieve the existing mapping.  Seems that solves Stuart's case without adding new burden for storing state on the client.

What if, when the server receives a MAP request matching an 
already-mapped internal port but with the wrong nonce, instead of 
returning NOT_AUTHORIZED, it would send a success response containing 
the external address+port, remaining lifetime, and a dummy nonce? I 
can't see anything that would break.

Seems like we don't need a different opcode at all to make this use case 
work. And one round-trip saved.

(But seriously the client should just remember nonces across reboots.)

Simon