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

["Elwell, John" <[e-mail]>]

> -----Original Message-----
> From: Elwell, John 
> Sent: 22 June 2010 07:44
> To: 'Hilarie Orman'; [e-mail]
> Cc: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; 
> [e-mail]
> Subject: RE: review of draft-ietf-martini-reqs-07.txt
> 
> Hilarie,
> 
> Thanks for your review. See responses below: 
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Hilarie Orman
> > Sent: 22 June 2010 02:49
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail]; 
> > [e-mail]; [e-mail]; Elwell, 
> > John; [e-mail]
> > 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
> >