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

From: "martini issue tracker" <[email-masked]>
Date: Sun, 27 Jun 2010 18:40:21 -0000

#46: Security Directorate review of draft-ietf-martini-reqs-07.txt
-----------------------------------+----------------------------------------
 Reporter:  ho@…                   |       Owner:  john.elwell@…                     
     Type:  defect                 |      Status:  new                               
 Priority:  minor                  |   Milestone:  milestone1                        
Component:  reqs                   |     Version:  1.0                               
 Severity:  Submitted WG Document  |    Keywords:                                    
-----------------------------------+----------------------------------------
 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).

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

 Minor non-security things:

 Requirement 4 has a triple negative ("not" "prevent" "without"), and
 I'm not sure what the heck it means.

 Requirement 5 has a typo, probably "internally" for "internal".

 Hilarie

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

---

From: "martini issue tracker" <[email-masked]>
Date: Sun, 27 Jun 2010 18:43:30 -0000

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

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

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