Re: [secdir] review of draft-ietf-martini-reqs-07.txt

"Elwell, John" <john.elwell@siemens-enterprise.com> Mon, 28 June 2010 07:27 UTC

Return-Path: <john.elwell@siemens-enterprise.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7CB3A6989 for <secdir@core3.amsl.com>; Mon, 28 Jun 2010 00:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.616
X-Spam-Level:
X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_50=0.001, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isWcsFijQ1YN for <secdir@core3.amsl.com>; Mon, 28 Jun 2010 00:27:27 -0700 (PDT)
Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 154803A6988 for <secdir@ietf.org>; Mon, 28 Jun 2010 00:27:26 -0700 (PDT)
Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-649358; Mon, 28 Jun 2010 09:27:35 +0200
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 1AE461EB82AB; Mon, 28 Jun 2010 09:27:35 +0200 (CEST)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 28 Jun 2010 09:27:35 +0200
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Date: Mon, 28 Jun 2010 09:27:33 +0200
Thread-Topic: review of draft-ietf-martini-reqs-07.txt
Thread-Index: AcsVTWlr+/jPrAVaT2686G+Xk89yOwBRWcGw
Message-ID: <A444A0F8084434499206E78C106220CAE7E7E61B@MCHP058A.global-ad.net>
References: <201006220148.o5M1mdgA006857@fermat.rhmr.com> <A444A0F8084434499206E78C106220CAE7C4CE35@MCHP058A.global-ad.net> <4C262A09.5070008@ericsson.com>
In-Reply-To: <4C262A09.5070008@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/mixed; boundary="_002_A444A0F8084434499206E78C106220CAE7E7E61BMCHP058Aglobala_"
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 28 Jun 2010 09:50:31 -0700
Cc: "secdir@ietf.org" <secdir@ietf.org>, "Bernard_Aboba@hotmail.com" <Bernard_Aboba@hotmail.com>, "hkaplan@acmepacket.com" <hkaplan@acmepacket.com>, "spencer@wonderhamster.org" <spencer@wonderhamster.org>, "rjsparks@nostrum.com" <rjsparks@nostrum.com>
Subject: Re: [secdir] review of draft-ietf-martini-reqs-07.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Jun 2010 07:27:29 -0000

I believe Hilary and I are in agreement - I received no further response (see my most recent mail attached). So I will go ahead and produce -08 right now.

John 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] 
> Sent: 26 June 2010 17:26
> To: Elwell, John
> Cc: Hilarie Orman; secdir@ietf.org; 
> Bernard_Aboba@hotmail.com; spencer@wonderhamster.org; 
> rjsparks@nostrum.com; hkaplan@acmepacket.com
> Subject: Re: review of draft-ietf-martini-reqs-07.txt
> 
> Hi John,
> 
> please, agree with Hilarie on how to address these comments 
> and submit a
> new revision of the draft. Please, also include any other IETF LC
> comments you have received.
> 
> I have updated the draft's state in the tracker to Revised ID Needed.
> 
> Thanks,
> 
> Gonzalo
> 
> 
> On 22/06/2010 9:43 AM, Elwell, John wrote:
> > Hilarie,
> > 
> > Thanks for your review. See responses below: 
> > 
> >> -----Original Message-----
> >> From: hilarie@purplestreak.com 
> >> [mailto:hilarie@purplestreak.com] On Behalf Of Hilarie Orman
> >> Sent: 22 June 2010 02:49
> >> To: secdir@ietf.org
> >> Cc: Bernard_Aboba@hotmail.com; spencer@wonderhamster.org; 
> >> gonzalo.camarillo@ericsson.com; rjsparks@nostrum.com; Elwell, 
> >> John; hkaplan@acmepacket.com
> >> Subject: review of draft-ietf-martini-reqs-07.txt
> >>
> >> Security review of draft-ietf-martini-reqs-07.txt,
> >> Multiple AOR reachability in SIP 
> >>
> >> Do not be alarmed.  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.
> >>
> >> The abstract:
> >>  This document states requirements for a standardized SIP 
> registration
> >>  mechanism for multiple addresses of record, the mechanism being
> >>  suitable for deployment by SIP service providers on a 
> large scale in
> >>  support of small to medium sized Private Branch Exchanges (PBXs).
> >>  The requirements are for a solution that can, as a 
> minimum, support
> >>  AORs based on E.164 numbers.
> >>
> >> There are 21 requirements, and two of them address security.
> >>
> >> I think requirement 14 leaves out a couple of things:
> >>   REQ14 - The mechanism MUST be able to operate over a 
> transport that
> >>   provides integrity protection and confidentiality.
> >> It should probably require "end-to-end" integrity protection and
> >> confidentiality between the two entities (SIP-PBX and the SSP).
> > [JRE] In the next version I will change it to:
> > "The mechanism MUST be able to operate over a transport 
> that provides end-to-end integrity protection and 
> confidentiality between the SIP-PBX and the SSP."
> > 
> >>
> >> And I think requirement 15 should say something about how the two
> >> entites are expected to agree on an authentication method, and that
> >> the authentication should apply to every registration message
> >> exchanged by the entities.  That is, once they have authenticated,
> >> then that information should be tied to requirement 14 and 
> ensure that
> >> the integrity and/or confidentiality is defined between the two
> >> entities (by use of, for example, an authenticated key exchange
> >> protocol) on all subsequent messages between the two.  
> > [JRE] I am reluctant to make any changes here. We don't 
> anticipate any new security mechanism, and indeed the 
> solution that is moving forward in the WG allows use of TLS, 
> which is already allowed for in SIP. For authentication it 
> allows both TLS mutual authentication or SIP digest 
> authentication + TLS server authentication, again, in line 
> with what is already allowed in SIP. SIP has a wealth of 
> material in this area, including aspects of RFC 3263 and RFC 
> 3329. I don't think it worthwhile adding a bunch of 
> requirements that in the end will not lead to any new 
> mechanisms or influence use of existing mechanisms. REQ14 and 
> REQ15 I think are sufficient pointers to needs in this area.
> > 
> >>    REQ15 - The mechanism MUST support authentication of 
> the SIP-PBX by
> >>    the SSP and vice versa.
> >> I'd also add that it MUST support termination of authenticaton and
> >> re-authentication.
> > [JRE] I am not sure exactly what you are looking for here. 
> Is this referring to what happens when a certificate expires, 
> say? Again, I would doubt we really need to add anything 
> here, since we don't anticipate new security mechanisms.
> > 
> >>
> >> Minor non-security things:
> >>
> >> Requirement 4 has a triple negative ("not" "prevent" 
> "without"), and
> >> I'm not sure what the heck it means.
> > [JRE] Yes, in the next version I will change it to:
> > "The mechanism MUST allow UAs attached to a SIP-PBX to 
> register with the SIP-PBX for AORs based on assigned 
> telephone numbers, in order to receive requests targeted at 
> those telephone numbers, without needing to involve the SSP 
> in the registration process."
> > 
> >>
> >> Requirement 5 has a typo, probably "internally" for "internal".
> > [JRE] It intentionally says "internally" at present - an 
> adverb modifying the verb "handle". I am not sure how to 
> reword it to prevent misinterpretation.
> > 
> > John
> > 
> > 
> >>
> >> Hilarie
> 
> 
--- Begin Message ---
 

> -----Original Message-----
> From: Hilarie Orman [mailto:hilarie@purplestreak.com] 
> Sent: 22 June 2010 18:48
> To: Elwell, John
> Subject: Re: [secdir] review of draft-ietf-martini-reqs-07.txt
> 
> OK, but maybe you reference existing security documents in 
> the security requirements?
[JRE] I could add to REQ14 "e.g., using TLS as specified in <xref target="RFC3261"/>" and to REQ15 "e.g., using SIP digest authentication plus TLS server authentication as specified in <xref target="RFC3261"/>". Personally I don't think it is needed, but if you think it would help I could do that.

> 
> Just delete the word "internally" -- it's not doing anything useful.
[JRE] Will do.

John


> 
> Hilarie
> 
> 
> ----- Original Message -----
> From: John Elwell <john.elwell@siemens-enterprise.com>;
> To: Hilarie Orman <ho@alum.mit.edu>;, secdir@ietf.org
> Cc: Bernard Aboba <Bernard_Aboba@hotmail.com>;, 
> hkaplan@acmepacket.com, gonzalo camarillo 
> <gonzalo.camarillo@ericsson.com>;, spencer@wonderhamster.org, 
> rjsparks@nostrum.com
> Sent: Tue, 22 Jun 2010 00:43:44 -0600 (MDT)
> Subject: Re: [secdir] review of draft-ietf-martini-reqs-07.txt
> Hilarie,
> Thanks for your review. See responses below: 
> > -----Original Message-----
> > From: hilarie@purplestreak.com 
> > [mailto:hilarie@purplestreak.com] On Behalf Of Hilarie Orman
> > Sent: 22 June 2010 02:49
> > To: secdir@ietf.org
> > Cc: Bernard_Aboba@hotmail.com; spencer@wonderhamster.org; 
> > gonzalo.camarillo@ericsson.com; rjsparks@nostrum.com; Elwell, 
> > John; hkaplan@acmepacket.com
> > Subject: review of draft-ietf-martini-reqs-07.txt
> > 
> > Security review of draft-ietf-martini-reqs-07.txt,
> > Multiple AOR reachability in SIP 
> > 
> > Do not be alarmed. 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.
> > 
> > The abstract:
> > This document states requirements for a standardized SIP 
> registration
> > mechanism for multiple addresses of record, the mechanism being
> > suitable for deployment by SIP service providers on a large scale in
> > support of small to medium sized Private Branch Exchanges (PBXs).
> > The requirements are for a solution that can, as a minimum, support
> > AORs based on E.164 numbers.
> > 
> > There are 21 requirements, and two of them address security.
> > 
> > I think requirement 14 leaves out a couple of things:
> > REQ14 - The mechanism MUST be able to operate over a transport that
> > provides integrity protection and confidentiality.
> > It should probably require "end-to-end" integrity protection and
> > confidentiality between the two entities (SIP-PBX and the SSP).
> [JRE] In the next version I will change it to:
> "The mechanism MUST be able to operate over a transport that 
> provides end-to-end integrity protection and confidentiality 
> between the SIP-PBX and the SSP."
> > 
> > And I think requirement 15 should say something about how the two
> > entites are expected to agree on an authentication method, and that
> > the authentication should apply to every registration message
> > exchanged by the entities. That is, once they have authenticated,
> > then that information should be tied to requirement 14 and 
> ensure that
> > the integrity and/or confidentiality is defined between the two
> > entities (by use of, for example, an authenticated key exchange
> > protocol) on all subsequent messages between the two. 
> [JRE] I am reluctant to make any changes here. We don't 
> anticipate any new security mechanism, and indeed the 
> solution that is moving forward in the WG allows use of TLS, 
> which is already allowed for in SIP. For authentication it 
> allows both TLS mutual authentication or SIP digest 
> authentication + TLS server authentication, again, in line 
> with what is already allowed in SIP. SIP has a wealth of 
> material in this area, including aspects of RFC 3263 and RFC 
> 3329. I don't think it worthwhile adding a bunch of 
> requirements that in the end will not lead to any new 
> mechanisms or influence use of existing mechanisms. REQ14 and 
> REQ15 I think are sufficient pointers to needs in this area.
> > REQ15 - The mechanism MUST support authentication of the SIP-PBX by
> > the SSP and vice versa.
> > I'd also add that it MUST support termination of authenticaton and
> > re-authentication.
> [JRE] I am not sure exactly what you are looking for here. Is 
> this referring to what happens when a certificate expires, 
> say? Again, I would doubt we really need to add anything 
> here, since we don't anticipate new security mechanisms.
> > 
> > Minor non-security things:
> > 
> > Requirement 4 has a triple negative ("not" "prevent" "without"), and
> > I'm not sure what the heck it means.
> [JRE] Yes, in the next version I will change it to:
> "The mechanism MUST allow UAs attached to a SIP-PBX to 
> register with the SIP-PBX for AORs based on assigned 
> telephone numbers, in order to receive requests targeted at 
> those telephone numbers, without needing to involve the SSP 
> in the registration process."
> > 
> > Requirement 5 has a typo, probably "internally" for "internal".
> [JRE] It intentionally says "internally" at present - an 
> adverb modifying the verb "handle". I am not sure how to 
> reword it to prevent misinterpretation.
> John
> > 
> > Hilarie
> > 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> 
--- End Message ---