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

From: "Hilarie Orman" <[email-masked]>
Date: Mon, 21 Jun 2010 19:48:39 -0600

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

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

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 22 Jun 2010 08:43:44 +0200

Hilarie,

Thanks for your review. See responses below: 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hilarie Orman
> Sent: 22 June 2010 02:49
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; Elwell, 
> John; [email-masked]
> Subject: review of draft-ietf-martini-reqs-07.txt
> 
[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."

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

> I'd also add that it MUST support termination of authenticaton and
[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.

> 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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 26 Jun 2010 19:25:45 +0300

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

---

From: "Hilarie Orman" <[email-masked]>
Date: Mon, 28 Jun 2010 10:08:19 -0600

I did respond to you --- I asked that for the security issues that
I raised and you said were already addressed in other documents, that
you reference those documents in the sections were you require transport
security and mutual authentication.

Hilarie

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 28 Jun 2010 09:27:33 +0200

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 

> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: 26 June 2010 17:26
> To: Elwell, John
> Cc: Hilarie Orman; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: review of draft-ietf-martini-reqs-07.txt
> 
> Hi John,
> 
> > "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."
> > 
> >>
> > [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.
> > 
> > [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.
> > 
> >>
> > "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.
> > 
> > John
> > 
> > 
> >>
> >> Hilarie
> 
> 

Subject: RE: [secdir] review of draft-ietf-martini-reqs-07.txt
From: "Elwell, John" <[email-masked]>
To: Hilarie Orman <[email-masked]>
Date: Wed, 23 Jun 2010 08:24:30 +0200

> From: Hilarie Orman [mailto:[email-masked]] 
> 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 <[email-masked]>
> To: Hilarie Orman <[email-masked]>, [email-masked]
> Cc: Bernard Aboba <[email-masked]>, 
> [email-masked], gonzalo camarillo 
> <[email-masked]>, [email-masked], 
> [email-masked]
> Sent: Tue, 22 Jun 2010 00:43:44 -0600 (MDT)
> Subject: Re: [secdir] review of draft-ietf-martini-reqs-07.txt
> Hilarie,
> "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."
> > 
> [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.
> [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.
> > 
> "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.
> John
> > 
> > Hilarie
> > 
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 28 Jun 2010 18:23:29 +0200

Hilarie,

What I meant was that I did not get a further response, so I assumed you were happy with my later response sent on 2010-06-23.

Anyway, if you have any concerns with -08 as posted today, please let me know.

John 

> Sent: 28 June 2010 17:08
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: review of draft-ietf-martini-reqs-07.txt
>