Subject: [MMUSIC] Resolving IESG issues with RFC4566bis-35: k= security considerations

From: Paul Kyzivat <[email-masked]>
Date: Thu, 6 Jun 2019 12:15:29 -0400

I've been working to resolve the IESG issues with RFC4566bis-35.
I think I have resolved most of them, but I have a couple where I feel I 
need input from the wg. This is one of those:

"k=" Security Considerations:

I had multiple comments on the last paragraph of Section 7 (Security 
Considerations) that discusses "k=". Here is that paragraph:

    Use of the "k=" line poses a significant security risk, since it
    conveys session encryption keys in the clear.  SDP MUST NOT be used
    to convey keying material, unless it can be guaranteed that the
    channel over which the SDP is delivered is both private and
    authenticated.  Moreover, the "k=" line provides no way to indicate
    or negotiate cryptographic key algorithms.  As it provides for only a
    single symmetric key, rather than separate keys for confidentiality
    and integrity, its utility is severely limited.  The "k=" line MUST
    NOT be used, as discussed in Section 5.12.

As I recall there was a lot of wg discussion on this as well as input 
from a security review, so I hesitate to change without wg input.

Comments I received:

Alissa Cooper:

> It's odd to me that this text was retained from RFC 4566 as-is, 
> except for the last sentence. I would have expected this to lead 
> with something like 'Use of the "k=" line is obsolete due to 
> security risk.' And then perhaps some of the rest of the text 
> could remain by way of explanation why it was obsoleted. 

Roman Danyliw:

> I’d like to escalate Alissa’s point about the k= language in 
> Section 7 (Security Considerations).  It looks like the new 
> Section 5.12 removes all of the historical language beyond saying 
> it MUST NOT be used.  This approach makes sense to me.  However, 
> the language in Section 7 could be read as conflicting with that.  Specifically:
> 
>    Use of the "k=" line poses a significant security risk, since it
>    conveys session encryption keys in the clear.  SDP MUST NOT be used
>    to convey keying material, unless it can be guaranteed that the
>    channel over which the SDP is delivered is both private and
>    authenticated.  ...  The "k=" line MUST
>    NOT be used, as discussed in Section 5.12.
> 
> The first sentence makes a strong statement.  The first clause of 
> the second sentence makes a more generic MUST NOT statement but the 
> second clause seems to say that is acceptable under certain 
> circumstances.  The third sentence reiterates that k= MUST NOT be used.  
> 
> How should this be reconciled?  Is the text suggesting that conveying 
> keying materials outside of k= is acceptable over the right kind of 
> channel? 

Colin Perkins responded with:

> I’d be happy for "SDP MUST NOT be used to convey keying material, 
> unless it can be guaranteed that the channel over which the SDP is 
> delivered is both private and authenticated” to change to “SDP 
> MUST NOT be used to convey keying material”.

Is that ok??? This seems consistent with what we agreed on for section 5.12.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 6 Jun 2019 12:34:30 -0400

> Is that ok??? This seems consistent with what we agreed on for section

I think the last paragraph in section 7 was also intended to describe
SDES-SRTP (RFC 4568) or any other protocols that distribute keying material
in clear text in SDP . Not allowing to use SDP to distribute keying
material would likely be excessive and would make anything implementing
SDES-SRTP non-compliant, despite the fact that SIPS+SDES-SRTP is perfectly
secure. I do agree that discussing k= line in this paragraph is strange
since it is deprecated, but discussing keying material in SDP should remain.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 7 Jun 2019 10:06:59 -0400

Roman,

On 6/6/19 12:34 PM, Roman Shpount wrote:
> On Thu, Jun 6, 2019 at 12:16 PM Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> SDES-SRTP (RFC 4568) or any other protocols that distribute keying 
> material in clear text in SDP . Not allowing to use SDP to distribute 
> keying material would likely be excessive and would make anything 
> implementing SDES-SRTP non-compliant, despite the fact that 
> SIPS+SDES-SRTP is perfectly secure. I do agree that discussing k= line 
> in this paragraph is strange since it is deprecated, but discussing 
> keying material in SDP should remain.

IIUC you are suggesting reducing the last paragraph to the single sentence:

    SDP MUST NOT be used to convey keying material (e.g., using
    "a=crypto" [RFC4568]) unless it can be guaranteed that the channel
    over which the SDP is delivered is both private and authenticated.

Is there a possibility that this might be construed to apply to 
"a=fingerprint"? That is "keying material" in a sense, even though it is 
incomplete.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Fri, 7 Jun 2019 11:27:17 -0400

Paul,

>     over which the SDP is delivered is both private and authenticated.

 Yes, this would work for me.

> "a=fingerprint"? That is "keying material" in a sense, even though it is

I do not think this will apply to "a=fingerprint", since technically
"a=fingerprint" is more like authentication not keying material. When SDP
is used to deliver "a=fingerprint" its content should be authenticated
(signed) but does not have to be private. If you think clarification is
required, it can be added, but I think it is better handled in security
considerations for things that described using DTLS with SDP.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 7 Jun 2019 18:09:54 -0400

OK. I'm going to go with this unless I hear something more in the next 
couple of days. But I would prefer to hear from more people.

	Thanks,
	Paul

On 6/7/19 10:06 AM, Paul Kyzivat wrote:
>>      > I’d be happy for "SDP MUST NOT be used to convey keying material,
>>      > unless it can be guaranteed that the channel over which the SDP is
>>      > delivered is both private and authenticated” to change to “SDP
>>      > MUST NOT be used to convey keying material”.
>>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic