Re: [martini] #46: Security Directorate review of draft-ietf-martini-reqs-07.txt

"martini issue tracker" <trac@tools.ietf.org> Sun, 27 June 2010 18:43 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: martini issue tracker <trac@tools.ietf.org>
Precedence: bulk
Auto-Submitted: auto-generated
To: john.elwell@siemens-enterprise.com, bernard_aboba@hotmail.com
Date: Sun, 27 Jun 2010 18:43:30 -0000
Message-ID: <066.59dbf53932a2640ef2457faff8b1e98f@tools.ietf.org>
References: <057.f6f86a244cf71c330f658826f6f7debc@tools.ietf.org>
In-Reply-To: <057.f6f86a244cf71c330f658826f6f7debc@tools.ietf.org>
Cc: martini@ietf.org
Subject: Re: [martini] #46: Security Directorate review of draft-ietf-martini-reqs-07.txt

#46: Security Directorate review of draft-ietf-martini-reqs-07.txt
-----------------------------------+----------------------------------------
 Reporter:  ho@…                   |        Owner:  john.elwell@…                     
     Type:  defect                 |       Status:  closed                            
 Priority:  minor                  |    Milestone:  milestone1                        
Component:  reqs                   |      Version:  1.0                               
 Severity:  Submitted WG Document  |   Resolution:  fixed                             
 Keywords:                         |  
-----------------------------------+----------------------------------------
Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 I think requirement 15 should say something about how the two
 entites are expected to agree on an authentication method....

 [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.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/46#comment:1>
martini <http://tools.ietf.org/martini/>

[martini] #46: Security Directorate review of dra… martini issue tracker
Re: [martini] #46: Security Directorate review of… martini issue tracker