Subject: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 05 Aug 2019 19:28:42 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-mmusic-ice-sip-sdp-37: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) Section 8.1. Per “These require techniques for message integrity and
encryption for offers and answers, which are satisfied by the TLS mechanism
[RFC3261] when SIP is used”, the guidance is right (use TLS), but this
reference is outdated.  Section 26.2.1 of RFC3261 provides rather old guidance
on the ciphersuite.  Is there a reason why not to use BCP195 for guidance on
versions/ciphersuites?

(2) Section 8.2.1, The “voice hammer attack” appears to be an artifact of SDP. 
The text explicitly notes that this attack is not “specific to ICE but that ICE
can help provide a remediation” (aside, should “remediation” be “mitigation”). 
However, the preceding introductory section (8.2) explicitly says “there are
several attacks possible with ICE”.  These two statements aren’t consistent.

(3) Section 8.2.2.  This section reads like an operational consideration.  The
setup scoped in the parent Section 8.2, “there are several attacks possible
with ICE when the attacker is an authenticated and valid participant in the ICE
exchange”, isn’t discussed here (i.e., how is the presence or absence of an ALG
germane to an attacker who is a participant in the ICE exchange)

(4) Section 8.  Is there a reason why the security considerations from RFC8445
are not noted as also applying (e.g., Section 19.1 - .4.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(5) Section 3.2.6.  The example in this section is appreciated.  Additional
text to explain what this example is showing would be helpful.

(6) Section 3.4.1.2.1. Per “the offer MUST include the same set of ICE-related
information that the offerer included in the previous offer or answer”, what
happens if the ICE information is different?

(7) Section 3.4.1.2.2. Per “In addition, if the agent is controlling, it MUST
include the ‘a=remote-candidates’ attribute for each data stream whose check
list is in the completed state”, what is a ‘check list’ in this context?

(8) Section 4.4. Per “If two data streams have identical ice-ufrag's, they MUST
have identical ice-pwd's”, what happens if there are not identical?

(9) Section 4.4. Per “Its large upper limit allows for increased amounts of
randomness to be added over time”, what is the time horizon being mentioned? 
Is this saying that in the future, longer password and users could be adopted?

(10) Section 4.5.  Unlike the other sections in 4.*, this one doesn’t have an
example.

(11) Section 8.2.  The title “Insider Attack” seems like a forced fit – perhaps
“Malicious Peer” (although Section 19.5 of RFC8445 seems to use that language)

(12) Section 8.2.2.  Per “Unfortunately, many ALGs are known to work poorly in
these corner cases”, it is worth reiterating here what that corner case is –
I’m inferring it is what the ALF does when m= or c= has an internal address,
right?

(13) Appendix A.  (Just as Ben pointed out in his DISCUSS for the example in
Section 4.6) Shouldn’t the examples in this appendix include a
“a=ice-options:ice2” per the guidance in Section 3.2.1.5?

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Aug 2019 13:02:33 +0000

Hi Roman,

Thank You for the review! I will let someone that has more security expertise then I  have address your comments on section 8. For your other comments, please see inline.

> (5) Section 3.2.6.  The example in this section is appreciated.  Additional text to explain what this example is showing would be helpful.

We will add text.

---

> (6) Section 3.4.1.2.1. Per “the offer MUST include the same set of ICE-related information that the offerer included in 
> the previous offer or answer”, what happens if the ICE information is different?

Depending on what is different the peer will either consider it a protocol error, or an ICE restart.

---

> (7) Section 3.4.1.2.2. Per “In addition, if the agent is controlling, it MUST include the ‘a=remote-candidates’ attribute for each data stream
> whose check list is in the completed state”, what is a ‘check list’ in this context?

There is a check list associated with each data stream (m= line). So, if the check list associated with a given data stream is in the completed state, the agent will include an a=remote-candidates attribute in the m= line associated with that check list/data stream.

The check list concept is described more in detail in RFC 8445 (it is not SDP specific).

---

>(8) Section 4.4. Per “If two data streams have identical ice-ufrag's, they MUST have identical ice-pwd's”, what happens if there are not identical?

It is a protocol error.

---

>(9) Section 4.4. Per “Its large upper limit allows for increased amounts of randomness to be added over time”, what is the time horizon being mentioned? 

Yes.

>(10) Section 4.5.  Unlike the other sections in 4.*, this one doesn’t have an example.

Don't know what happened - it was supposed to have one 😊 I will add an example.

--

>(13) Appendix A.  (Just as Ben pointed out in his DISCUSS for the example in Section 4.6) Shouldn’t the examples in 
>this appendix include a “a=ice-options:ice2” per the guidance in Section 3.2.1.5?

Yes. We will add the attribute.

---

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Wed, 7 Aug 2019 14:27:23 -0500

I'm not generally around this week, but had a few moments and wanted to 
weigh in on these discuss points, as they don't appear to have responses 
yet. :)

> on the ciphersuite.  Is there a reason why not to use BCP195 for guidance on

As much as SIP has a convoluted layering story, the separation between 
SIP and SDP remains pretty clean (both from a protocol perspective and 
organizationally within the IETF). While it's likely the case that RFC 
3261 could use some updating to its security story [1], I don't think it 
makes sense to hold up this document on that work. It's really rather 
far outside the purview of this document to make changes to the 
underlying cipher suite; in fact, I would argue that doing so would be 
disallowed in MMUSIC, since it is part of the core protocol work that 
clearly falls in SIPCORE's charter.

> several attacks possible with ICE”.  These two statements aren’t consistent.

It seems that the solution for this would be to promote section 8.2.1 to 
its own top-level section inside the security considerations section. 
Would that work for you?

> germane to an attacker who is a participant in the ICE exchange)

It seems that the solution for this would be to promote 8.2.2 to its own 
top-level section within the document, preceding the Security 
Considerations section, possibly with a renaming along the lines of 
"Operational Considerations: Interactions with Application Layer 
Gateways and SIP". Does that work for you?

I note that making both of these changes leaves section 8.2 empty save 
for the introductory text; I propose that we simply remove the section.

> are not noted as also applying (e.g., Section 19.1 - .4.

Would the addition of text at the top of section 8 that says "Please 
note that the security considerations from sections 19.1 through 19.4 of 
[RFC8445] also apply to this document." address your concern?

/a

____
[1] And there is some work happening in this area, albeit not with TLS; 
see https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/ 
for example.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Aug 2019 15:50:41 +0000

Hi Adam,

Thanks for Your input! A few comments from me inline.
    
    > clearly falls in SIPCORE's charter.

    I agree. If we need to update the security properties of SIP, let's do it properly in SIPCORE.
    
    ---    

    > its own top-level section inside the security considerations section. 
    
   I would be ok with that.

   However, I think it would be good to add text to 8.2.1 saying that a "Voice hammer attack" attack can take place even when the 
   attacker is an authenticated user, and then go on describing how ICE can be used to prevent the attack. 

   ---
    
    > Gateways and SIP". Does that work for you?
    
    I am fine making it its own top-level section. But, do you think it should be a normative section, or an Appendix?

    > for the introductory text; I propose that we simply remove the section.
    
    I am fine with that.
    
    ---

    > [RFC8445] also apply to this document." address your concern?
    
    Others have commented on this, and there is a pull request addressing it:

    https://github.com/suhasHere/ice-sip-sdp/pull/18/files

    Please see the last change in the pull request.

    Regards,

    Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Aug 2019 18:03:39 +0000

Hi,

I have now updated the pull request based on the discussion below. Again, the changes related to the Security Considerations are at the end of the pull request:

Regards,

Christer

On 08/08/2019, 18.50, "Christer Holmberg" <[email-masked]> wrote:

    Hi Adam,

    
        
        ---    

       I would be ok with that.

       ---

    
        
        I am fine with that.
        
        ---

    
        https://protect2.fireeye.com/url?k=fc78358d-a0f2175b-fc787516-0cc47ad93dcc-f3a799884e91abda&q=1&u=https%3A%2F%2Fgithub.com%2FsuhasHere%2Fice-sip-sdp%2Fpull%2F18%2Ffiles

        Regards,
    
        Christer

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 9 Aug 2019 01:19:38 +0000

Hi!

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Thursday, August 8, 2019 11:51 AM
> To: Adam Roach <[email-masked]>; Roman Danyliw <[email-masked]>;
> The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; draft-
> [email-masked]
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37:
> (with DISCUSS and COMMENT)
> 
> Hi Adam,
> 

Ok.  That makes sense.  Thanks for this explanation.

>     > its own top-level section inside the security considerations section.

This editorial approach would clean it up for me.  I wasn't sure whether something was missing.

>    However, I think it would be good to add text to 8.2.1 saying that a "Voice
> hammer attack" attack can take place even when the

Makes sense.

> a normative section, or an Appendix?

I'd think normative.

>     > for the introductory text; I propose that we simply remove the section.

Makes sense to me.
 
>     Please see the last change in the pull request.

Generically referring to RFC8445 as done in this pull request works too.

Regards,
Roman

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 9 Aug 2019 01:23:06 +0000

Hi Christer!

Thanks for the quick follow-up.  There is one detail below to consider, but I've covered otherwise.

> Sent: Tuesday, August 6, 2019 9:03 AM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: VS: Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37:
> Thank You for the review! I will let someone that has more security expertise
> then I  have address your comments on section 8. For your other comments,
> please see inline.
> 
> > (6) Section 3.4.1.2.1. Per “the offer MUST include the same set of
> > ICE-related information that the offerer included in the previous offer or
> answer”, what happens if the ICE information is different?
> 

Understood.  Thanks or the clarification.

> ---
> 
> > (7) Section 3.4.1.2.2. Per “In addition, if the agent is controlling,
> > it MUST include the ‘a=remote-candidates’ attribute for each data stream
> There is a check list associated with each data stream (m= line). So, if the
> check list associated with a given data stream is in the completed state, the
> agent will include an a=remote-candidates attribute in the m= line
> associated with that check list/data stream.
> 

Got it.  That's context I didn't have.  Thanks.

> ---
> 
> >(8) Section 4.4. Per “If two data streams have identical ice-ufrag's, they
> MUST have identical ice-pwd's”, what happens if there are not identical?
> 
> It is a protocol error.

Is there generic guidance that would make that obvious in other SIP/SDP error handling, or should that be said explicitly?

> >Is this saying that in the future, longer password and users could be

Got it. 

> Don't know what happened - it was supposed to have one 😊 I will add an

Thanks.

> --
> 
> >(13) Appendix A.  (Just as Ben pointed out in his DISCUSS for the
> >example in Section 4.6) Shouldn’t the examples in this appendix include a

Thanks.

Regards,
Roman

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 9 Aug 2019 01:26:35 +0000

Hi Christer!

Adam and you clarifications; and this pull request addresses my discuss points.  Please go ahead and publish.  

I appreciate it the quick iteration.

Thanks,
Roman

> Sent: Thursday, August 8, 2019 2:04 PM
> I have now updated the pull request based on the discussion below. Again,
> the changes related to the Security Considerations are at the end of the pull
> request:
> 
>        However, I think it would be good to add text to 8.2.1 saying that a
> "Voice hammer attack" attack can take place even when the
>         https://protect2.fireeye.com/url?k=fc78358d-a0f2175b-fc787516-
> 0cc47ad93dcc-
> f3a799884e91abda&q=1&u=https%3A%2F%2Fgithub.com%2FsuhasHere%2F
> ice-sip-sdp%2Fpull%2F18%2Ffiles
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 8 Aug 2019 20:48:02 -0700

Hello All

  Version 38 was just submitted. please let us know your thoughts

Cheers
Suhas

On Thu, Aug 8, 2019 at 6:27 PM Roman Danyliw <[email-masked]> wrote:

> >         >> (1) Section 8.1. Per “These require techniques for message
> integrity
> > and
> >         >> encryption for offers and answers, which are satisfied by the
> TLS
> > mechanism
> >         >> reference is outdated.  Section 26.2.1 of RFC3261 provides
> rather old
> > guidance
> >         >> on the ciphersuite.  Is there a reason why not to use BCP195
> for
> > guidance on
> >         >> versions/ciphersuites?
> >         >
> >         > SIP and SDP remains pretty clean (both from a protocol
> perspective
> > and
> >         I agree. If we need to update the security properties of SIP,
> let's do it
> > properly in SIPCORE.
> >
> >         ---
> >
> >         >> (2) Section 8.2.1, The “voice hammer attack” appears to be an
> artifact
> > of SDP.
> >         >> The text explicitly notes that this attack is not “specific
> to ICE but that
> > ICE
> >         >> can help provide a remediation” (aside, should “remediation”
> be
> > “mitigation”).
> >         >> However, the preceding introductory section (8.2) explicitly
> says
> > “there are
> >         >> several attacks possible with ICE”.  These two statements
> aren’t
> > consistent.
> >         >
> >        attacker is an authenticated user, and then go on describing how
> ICE can
> > be used to prevent the attack.
> >
> >
> >        ---
> >
> >         >> setup scoped in the parent Section 8.2, “there are several
> attacks
> > possible
> >         >> with ICE when the attacker is an authenticated and valid
> participant
> > in the ICE
> >         >> exchange”, isn’t discussed here (i.e., how is the presence or
> absence
> > of an ALG
> >         I am fine making it its own top-level section. But, do you think
> it should
> > be a normative section, or an Appendix?
> >
> >         >> (4) Section 8.  Is there a reason why the security
> considerations from
> > RFC8445
> >         > note that the security considerations from sections 19.1
> through 19.4
> > of
> >         Others have commented on this, and there is a pull request
> addressing
> > it:
> >
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 12 Aug 2019 23:14:37 +0000

Hi Christer!
(pruning the thread ...)

-38 addresses my discussion #1 - 3, thank you.  However, something got lost for item #4 -- see below ... 

> > through 19.4 of

This pull request:

appears to have the following addition to address this issue but it didn't make it to -38:

<snip>
      <t>
        The generic ICE security considierations are defined in <xref target="RFC8445"/>, and the 
        generic SDP offer/answer security considerations are defined in <xref target="RFC3264"/>. The 
        security considerations also apply to implementations of this document.
      </t>
</snip>

Also, s/considierations/considerations/

Can you please add in this text.

Thanks,
Roman

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Aug 2019 04:19:05 +0000

Hi Roman,

>>> (4) Section 8.  Is there a reason why the security considerations from
>>> RFC8445 are not noted as also applying (e.g., Section 19.1 - .4.
>>>
...
>
> This pull request:
>
> https://protect2.fireeye.com/url?k=493cd979-15b60db8-493c99e2-863d9bcb726f-ec503dd28b20c537&q=1&u=https%3A%2F%2Fgithub.com%2FsuhasHere%2Fice-sip-sdp%2Fpull%2F18%2Ffiles
>

Correct. Suhas had to do some "manual" work when merging the pull requests, and the changes to the Security Considerations got lost for some reason.

There is now a new pull request, more or less a copy of the previous one, but also with some privacy text (requested by Benjamin), that will be used for the next version:

https://github.com/suhasHere/ice-sip-sdp/pull/21

Sorry for the confusion.

Regards,

Christer

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 13 Aug 2019 14:25:52 +0000

Hi Christer!

> Sent: Tuesday, August 13, 2019 12:19 AM
> To: Roman Danyliw <[email-masked]>; Adam Roach <[email-masked]>;
> The IESG <[email-masked]>
> >>> note that the security considerations from sections 19.1 through
> >>> 19.4 of [RFC8445] also apply to this document." address your concern?
> >>>
> ...
> >
> > This pull request:
> >
> > https://protect2.fireeye.com/url?k=493cd979-15b60db8-493c99e2-
> 863d9bcb
> > 726f-
> ec503dd28b20c537&q=1&u=https%3A%2F%2Fgithub.com%2FsuhasHere%2F
> ice
> Correct. Suhas had to do some "manual" work when merging the pull
> requests, and the changes to the Security Considerations got lost for some
> reason.
> 
> There is now a new pull request, more or less a copy of the previous one, but
> also with some privacy text (requested by Benjamin), that will be used for
> the next version:
> 

That works for me!  Thank you.

Roman

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 13 Aug 2019 18:28:42 -0700

Hi Roman

 We just submitted version 39 addressing the remaining feedback

Please let us know your thoughts

Thanks
Suhas

On Tue, Aug 13, 2019 at 7:26 AM Roman Danyliw <[email-masked]> wrote:

> > > appears to have the following addition to address this issue but it
> didn't
> > make it to -38:
> > >
> > > <snip>
> > >      <t>
> > >        generic SDP offer/answer security considerations are defined in
> <xref
> > target="RFC3264"/>. The

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 14 Aug 2019 01:35:48 +0000

Hi Suhas!

-39 addresses my remaining discuss item.  I just updated my ballot.  Thank you for this quick update.

Roman

From: Suhas Nandakumar [mailto:[email-masked]]
Sent: Tuesday, August 13, 2019 9:29 PM
To: Roman Danyliw <[email-masked]>
Cc: Adam Roach <[email-masked]>; Christer Holmberg <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)

Hi Roman

Thanks
Suhas

On Tue, Aug 13, 2019 at 7:26 AM Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:
Hi Christer!

> From: Christer Holmberg [mailto:[email-masked]<mailto:[email-masked]>]
> To: Roman Danyliw <[email-masked]<mailto:[email-masked]>>; Adam Roach <[email-masked]<mailto:[email-masked]>>;
> The IESG <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; draft-
> [email-masked]<mailto:[email-masked]>

Roman
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic