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

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

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:[e-mail]] 
> Sent: 26 June 2010 17:26
> To: Elwell, John
> Cc: Hilarie Orman; [e-mail]; 
> [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> 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: [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
> 
> 

--- Begin Message ---

 

> -----Original Message-----
> From: Hilarie Orman [mailto:[e-mail]] 
> 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 <[e-mail]>
> To: Hilarie Orman <[e-mail]>, [e-mail]
> Cc: Bernard Aboba <[e-mail]>, 
> [e-mail], gonzalo camarillo 
> <[e-mail]>, [e-mail], 
> [e-mail]
> 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: [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
> > 
> _______________________________________________
> secdir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdir
> 

--- End Message ---