Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03

I took another look at the "chair review update" version at 
https://martinthomson.github.io/sdp-uks/chair-review/draft-ietf-mmusic-sdp-uks.html 
(I see you just posted an -04 as well - not sure if there are any 
differences between those two).

The "chair-review" version generally looks good to me, except in Section 
3.2, I think we need to say something about how to handle the situation 
where you send and/or receive both SIP Identity and SDP identity (we can 
have one take precedence or try both).

Also, two suggested editorial updates:

Section 3.1, first sentence after Figure 1
OLD: "The attack requires that Mallory obtain an identity binding for 
her own identity with the fingerprints presented by Patsy (P)."
NEW: "The attack requires that Mallory obtain an identity binding for 
her own identity with the fingerprints presented by Patsy (P), which 
Mallory may have obtained previously.".

Section 3.2, First paragraph after "Note" section:
s/Identity/"SIP Identity"

Other than that it looks good.

Thanks for the patience in all the discussion on this.

-- Flemming

On 5/7/19 5:29 PM, Flemming Andreasen wrote:
>
>
> On 5/6/19 12:53 AM, Martin Thomson wrote:
>> (I apologize for errors in adjusting quoting, our MTAs seem incompatible somehow.)
>>
>> On Sat, May 4, 2019, at 07:28, Flemming Andreasen wrote:
>>>>    Or 3PCC can be used without SIP identity (maybe the WebRTC identity
>>>> is used) and the attack would be relevant.
>>> Can WebRTC identity be used with regular SIP ?
>>>
>>> That's not the impression I got from
>>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-18  (where
>>> WebRTC identity is defined), nor do I think it should be since that
>>> would:
>>>   a) Be redundant with the SIP Identiy information defined in RFC 8224
>>> and hence require further treatment in terms of how you deal with
>>> discrepancies between the two.
>>>   b) Conflate session signaling (SIP) with media signaling (SDP).
>> These are reasons for not using WebRTC Identity in regular SIP, but I don't believe the two to be *fundamentally* incompatible.  The latter is perhaps a good argument against the use of WebRTC Identity at all, but the split between media and session signaling and the relationship of each with the security properties of the system is probably a topic of discussion for another draft.  We're just trying to work out how to proceed with this little piece.
>>
>>>   In any case, this is probably something that should be clarified in
>>> draft-ietf-rtcweb-security-arch-18 (might as well do that now, since
>>> you will ultimately get an SDP designated expert review from me on that
>>> one that will ask the same).
>> I'm sure that there's something worth saying there.  Not sure what other think, but I wouldn't expressly prohibit the use of the two in combination.  I would reduce this to pointing out that there is a potential for disagreement between the two that would be bad.
>>
>>>> It might be good to categorically say that 3PCC - as described in RFC 3725 - is incompatible with RFC 8224.  Would that help clarify this bit?
>>>   I believe so.
>> I've updated the PR with the following text (being the entire section on 3PCC):
>>
>> ---8<---
>> Third-party call control (3PCC) {{?RFC3725}} is a technique where a signaling
>> peer establishes a call that is terminated by a different entity.  This attack
>> is very similar to the 3PCC technique, except where the TLS peers are aware of
>> the use of 3PCC.
>>
>> 3PCC as described in RFC 3725 is incompatible with SIP identity {{?SIP-ID}} as
>> SIP Identity relies on creating a binding between SIP requests and SDP.  The
>> controller is the only entity that generates SIP requests in RFC 3725.
>> Therefore, in a 3PCC context, only the use of the `fingerprint` attribute
>> without additional bindings or WebRTC identity {{?WEBRTC-SEC}} is possible.
>>
>> For 3PCC to work with the proposed mechanisms, TLS peers need to be aware of the
>> signaling so that they can correctly generate and check the TLS extensions.  For
>> a connection to be successfully established, a 3PCC controller needs to either
>> forward SDP without modification, or to avoid modifications to `fingerprint`,
>> `tls-id`, and `identity` attributes.  A controller that follows the best
>> practices in RFC 3725 is expected to forward SDP without modification, thus
>> ensuring the integrity of these attributes.
>>
>> It is understood that this technique will prevent the use of 3PCC if peers have
>> different views of the involved identities, or the value of SDP `tls-id`
>> attributes.
>> ---8<---
>>
>> How does that work for you?
> That looks good to me - thx Martin
>
> -- Flemming
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>> ..
>>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic