Re: [Insipid] I-D Action: draft-ietf-insipid-session-id-23.txt

"Ben Campbell" <ben@nostrum.com> Wed, 29 June 2016 20:12 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F229412D684 for <insipid@ietfa.amsl.com>; Wed, 29 Jun 2016 13:12:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b8HXbddHpOc for <insipid@ietfa.amsl.com>; Wed, 29 Jun 2016 13:12:18 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA4912D677 for <insipid@ietf.org>; Wed, 29 Jun 2016 13:12:18 -0700 (PDT)
Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5TKCFGv061511 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 29 Jun 2016 15:12:15 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4]
From: "Ben Campbell" <ben@nostrum.com>
To: "Paul Giralt" <pgiralt@cisco.com>
Date: Wed, 29 Jun 2016 15:12:14 -0500
Message-ID: <DC35EA50-1505-41D3-B949-00A5A231366E@nostrum.com>
In-Reply-To: <49633303-629D-4CE3-A691-72D4E886080F@cisco.com>
References: <20160624043751.12660.23306.idtracker@ietfa.amsl.com> <99E92338-11D2-404C-BEC7-EDEB9B0C2792@cisco.com> <48BA34F8-5D0A-4597-A3FA-D9E8392F4323@nostrum.com> <22D19CAA-9CF5-4666-8839-20568FE3B35B@cisco.com> <77585AF0-736F-4BE7-B7D8-E1979A962B58@nostrum.com> <49633303-629D-4CE3-A691-72D4E886080F@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/DFqkla4y4meDHsQP4tGCcWJ6N_g>
Cc: "insipid@ietf.org" <insipid@ietf.org>
Subject: Re: [Insipid] I-D Action: draft-ietf-insipid-session-id-23.txt
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jun 2016 20:12:20 -0000

On 29 Jun 2016, at 15:10, Paul Giralt (pgiralt) wrote:

>>
>> That text talks about when the UUID MUST NOT change. I'm looking for 
>> text that says a UUID value MUST NOT be reused across multiple 
>> "sessions" (as sessions are defined in this draft.) The point is to 
>> avoid an accidentally persistent identifier that could be used to 
>> track user/UA activity across multiple sessions.
>
> I see where you are coming from now. I hadn’t payed attention to the 
> fact that the text in 4.2 is not normative. Currently the section 
> reads:
>
> 	The SIP User Agent (UA) initiating a new session by transmitting a 
> SIP
>          request ("Alice"), i.e., a User Agent Client (UAC), will 
> create a new,
>          previously unused, UUID and transmit that to the ultimate 
> destination UA
>          ("Bob").  Likewise, the destination UA ("Bob"), i.e., a User 
> Agent Server (UAS),
>          will create a UUID and transmit that to the first UA 
> ("Alice").
>
> If I just change the “will” to MUST and expand on the UAS also 
> having to create a previously-unused UUID like below, does this 
> address the concern?
>
> 	The SIP User Agent (UA) initiating a new session by transmitting a 
> SIP
>          request ("Alice"), i.e., a User Agent Client (UAC), MUST 
> create a new,
>          previously unused, UUID and transmit that to the ultimate 
> destination UA
>          ("Bob").  Likewise, the destination UA ("Bob"), i.e., a User 
> Agent Server (UAS),
>          MUST create a new, previously unused, UUID and transmit that 
> to the
> 	first UA ("Alice").
>
> Alternatively, I could add some normative text in Section 6 for 
> endpoint behavior, but I think just modifying the above should address 
> the concern. Please let me know your thoughts.
>
> -Paul

That, plus a sentence or two in the security considerations section 
talking about how that helps avoid cross-session persistent identifiers, 
would work for me.

Thanks!

Ben.