Subject: Re: [dispatch] https://www.ietf.org/id/draft-dawes-sipcore-mediasec-parameter-03.txt

From: "Ben Campbell" <[email-masked]>
Date: Tue, 22 Mar 2016 17:44:39 -0500

Hi,

The ADs and chairs discussed this offline, and we think that this might 
be a candidate for AD sponsorship. However, in my opinion as an ART AD, 
there are some issues that need to be discussed before going that route 
(and are probably relevant however this progresses:

2. The draft creates a "media security" sub-class of security mechanisms 
that are registered in a separate registry with a 
"specification-required" policy. The existing security mechanism 
registry has a policy of "RFC required". I think that's a reasonable 
policy, given the security implications of RFC 3329 extensions.  In my 
opinion, this draft should get rid of the separate registry, and put any 
media-specific mechanism into the existing one. But failing that, the 
policy on this new registry should be no weaker than that of the 
existing one. ( If people think "RFC Required" is not the right policy 
for either registry, we can discuss that.)

3. The draft assumes that the first hop SIP proxy is also the first hop 
media-plane device, a la a p-cscf. This may be a reasonable assumption 
for IMS and IMS-like architectures, but it's not an assumption we want 
to encourage in general. This could be mitigated by stronger language 
scoping the work to IMS, and discouraging its use elsewhere. (This is 
designed to enable the IMS end-to-edge-agent security model, and should 
probably say so.)

3. There's a fair amount of work left. The security considerations seem 
inadequate, and there are sections that still have xml2rfc sample text. 
If we progress this, we should get targeted reviews from Gonzalo and/or 
Jari, as well as secdir. So it's only worth trying to progress this if 
the authors are willing put non-trivial additional work in on it.

This is not an exhaustive list--I'm sure other issues will shake out if 
we move forward. But I think these are important for figuring out the 
strategy for progressing the work.

Thanks!

Ben.

On 10 Feb 2016, at 5:32, Dawes, Peter, Vodafone Group wrote:

> Hello All,
> I would like to ask dispatch to (re-)consider the proposals in 
> https://datatracker.ietf.org/doc/draft-dawes-sipcore-mediasec-parameter/ 
> and how it might be progressed. One of the sipcore chairs has 
> indicated that this draft probably does not belong in sipcore and 
> dispatch did not make a detailed evaluation the first time it was 
> brought to the group.
>
> The most recent comments on the sipcore mailing list are 
> https://mailarchive.ietf.org/arch/msg/sipcore/mD1Qedh93ep9oVOxttIxKN7lIcg 
> and it might help to repeat part of what I said there about the new 
> header field parameter that is the reason for the draft:
>
> "...the header field parameter introduced by this draft originates 
> from 3GPP specifications and related procedures and header field 
> values are also described in 3GPP specifications. The purpose of this 
> draft is to name the header field parameter, give several illustrative 
> examples to make it clear how it is used, and set up an IANA registry 
> for existing and future values. The draft does not propose that IETF 
> defines any new security setup procedures, ciphering, integrity 
> protection etc."
>
> Thanks and regards,
> Peter
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Thu, 24 Mar 2016 11:16:03 +0000

Hello Ben and dispatch chairs,

Thanks for taking the time to discuss this draft and give your views. I think it is important that this "media security" sub-class of security mechanisms has a registry (either new or existing) and I am certainly willing to discuss and follow up your comments below, and any others that may arise. If the draft can be revised in such a way that new "media security" mechanisms are described and scoped consistent with existing similar IETF standards and can therefore be IANA registered then it's worth doing. Since I started the draft the IMS has needed to add MSRP to the media protocols that require protection and MIKEY-TICKET (RFC 6043) as a key management option, so a registry is needed to keep track.

Regarding scope, I agree with your comment that the draft applies only to IMS and IMS-like architectures and I can think about ways to make the scope more explicit. Regarding security considerations, I can expand on those but it might help to have specific review comments to work from. Regarding "specification required" or "RFC required" it would help if someone could point me at any previous occasions where the decision between the two was made, or any RFCs that give guidelines, so that I can understand the criteria. 

Thanks again,
Peter

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: 22 March 2016 22:45
To: Dawes, Peter, Vodafone Group
Cc: [email-masked]; [email-masked]
Subject: Re: [dispatch] https://www.ietf.org/id/draft-dawes-sipcore-mediasec-parameter-03.txt

Hi,

The ADs and chairs discussed this offline, and we think that this might be a candidate for AD sponsorship. However, in my opinion as an ART AD, there are some issues that need to be discussed before going that route (and are probably relevant however this progresses:

2. The draft creates a "media security" sub-class of security mechanisms that are registered in a separate registry with a "specification-required" policy. The existing security mechanism registry has a policy of "RFC required". I think that's a reasonable policy, given the security implications of RFC 3329 extensions.  In my opinion, this draft should get rid of the separate registry, and put any media-specific mechanism into the existing one. But failing that, the policy on this new registry should be no weaker than that of the existing one. ( If people think "RFC Required" is not the right policy for either registry, we can discuss that.)

3. The draft assumes that the first hop SIP proxy is also the first hop media-plane device, a la a p-cscf. This may be a reasonable assumption for IMS and IMS-like architectures, but it's not an assumption we want to encourage in general. This could be mitigated by stronger language scoping the work to IMS, and discouraging its use elsewhere. (This is designed to enable the IMS end-to-edge-agent security model, and should probably say so.)

3. There's a fair amount of work left. The security considerations seem inadequate, and there are sections that still have xml2rfc sample text. 
If we progress this, we should get targeted reviews from Gonzalo and/or Jari, as well as secdir. So it's only worth trying to progress this if the authors are willing put non-trivial additional work in on it.

This is not an exhaustive list--I'm sure other issues will shake out if we move forward. But I think these are important for figuring out the strategy for progressing the work.

Thanks!

Ben.

On 10 Feb 2016, at 5:32, Dawes, Peter, Vodafone Group wrote:

> https://datatracker.ietf.org/doc/draft-dawes-sipcore-mediasec-paramete
> r/ and how it might be progressed. One of the sipcore chairs has 
> https://mailarchive.ietf.org/arch/msg/sipcore/mD1Qedh93ep9oVOxttIxKN7l
> Icg and it might help to repeat part of what I said there about the 
> new header field parameter that is the reason for the draft:
>

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 25 Mar 2016 16:42:11 -0500

Thanks for the response. Some more comments inline:

Thanks!

Ben.

On 24 Mar 2016, at 6:16, Dawes, Peter, Vodafone Group wrote:

> Thanks for taking the time to discuss this draft and give your views. 
> I think it is important that this "media security" sub-class of 
> security mechanisms has a registry (either new or existing) and I am 
> certainly willing to discuss and follow up your comments below, and 
> any others that may arise. If the draft can be revised in such a way 
> that new "media security" mechanisms are described and scoped 
> consistent with existing similar IETF standards and can therefore be 
> IANA registered then it's worth doing. Since I started the draft the 
> IMS has needed to add MSRP to the media protocols that require 
> protection and MIKEY-TICKET (RFC 6043) as a key management option, so 
> a registry is needed to keep track.

It's probably worth discussion the motivations behind why the draft 
proposes a separate registry for "media security" mechanisms, rather 
than just adding new mechanisms to the "Security Mechanism Names" 
registry from RFC 3329.

>
> Regarding scope, I agree with your comment that the draft applies only 
> to IMS and IMS-like architectures and I can think about ways to make 
> the scope more explicit.

That would be helpful.

> Regarding security considerations, I can expand on those but it might 
> help to have specific review comments to work from. Regarding 
> "specification required" or "RFC required" it would help if someone 
> could point me at any previous occasions where the decision between 
> the two was made, or any RFCs that give guidelines, so that I can 
> understand the criteria.

The registration policies are defined in RFC 5226, section 4.1. One 
previous occasion that is especially relevant is RFC 3329 :-) I have to 
assume the working group chose the "RFC Required policy" because they 
wanted to make sure that security mechanisms got sufficient review in 
the IETF, and that they wanted to make sure the specifications were 
sufficiently accessible and archived.

In any case, the proposed "Media security mechanism" registry is 
effectively an expansion of the "security mechanism" registry. Given 
that, if the authors think that the media security mechanism should have 
a weaker policy, the draft should explain why.

> Subject: Re: [dispatch] 
> https://www.ietf.org/id/draft-dawes-sipcore-mediasec-parameter-03.txt
>
> Hi,
>
> The ADs and chairs discussed this offline, and we think that this 
> might be a candidate for AD sponsorship. However, in my opinion as an 
> ART AD, there are some issues that need to be discussed before going 
> that route (and are probably relevant however this progresses:
>
>
> 2. The draft creates a "media security" sub-class of security 
> mechanisms that are registered in a separate registry with a 
> opinion, this draft should get rid of the separate registry, and put 
> any media-specific mechanism into the existing one. But failing that, 
> the policy on this new registry should be no weaker than that of the 
> 3. The draft assumes that the first hop SIP proxy is also the first 
> hop media-plane device, a la a p-cscf. This may be a reasonable 
> assumption for IMS and IMS-like architectures, but it's not an 
> assumption we want to encourage in general. This could be mitigated by 
> stronger language scoping the work to IMS, and discouraging its use 
> elsewhere. (This is designed to enable the IMS end-to-edge-agent 
> security model, and should probably say so.)
>
>
> 3. There's a fair amount of work left. The security considerations 
> seem inadequate, and there are sections that still have xml2rfc sample 
> text.
> If we progress this, we should get targeted reviews from Gonzalo 
> and/or Jari, as well as secdir. So it's only worth trying to progress 
> this if the authors are willing put non-trivial additional work in on 
> it.
>
> This is not an exhaustive list--I'm sure other issues will shake out 
> if we move forward. But I think these are important for figuring out 
> the strategy for progressing the work.
>
> Thanks!
>
> Ben.
>
>