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

From: Bo Burman <[email-masked]>
Date: Mon, 1 Apr 2019 14:30:44 +0000

Authors,

Do you have any answers to Flemming’s questions below?

When those questions are answered, please submit a new version that addresses them and all other WGLC comments.

/Bo (as MMUSIC co-chair)

From: mmusic <[email-masked]> On Behalf Of Flemming Andreasen
Sent: den 7 mars 2019 22:06
To: Martin Thomson <[email-masked]>; mmusic <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03

On 3/5/19 10:10 PM, Martin Thomson wrote:

Hi Flemming,

"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 
extension.  Peers
need access to any identity assertions present in signaling in order to 
perform
the checks in {{external_id_hash}}.  To perform the checks in
{{external_session_id}}, a 3PCC system needs to ensure that guarantee 
that peers
use the same SDP `tls-id` attribute value."
 I'm still not clear on how this works. RFC 3725 defines four different 
flows - does the mechanism work with all four of them ? To some extent, 
this may be a question on SIP Authenticated Identity (RFC 8224) as it 
is not clear to me how that works with 3PCC. An actual (high-level) 
call flow illustratings this would be helpful. 

The problem here is that RFC 3725 doesn't really contemplate the sorts of changes that earlier commenters observed happen in practice.  All the flows and recommendations there limit the changes made by the controller to fixups that ensure that offers and answers from the endpoints work effectively.  On that basis, simply following the guidance in RFC 3725 would - absent some mistake - result in a working session.  Presumably, if the controller supports tls-id, then it copies the value faithfully and things work.  That is how I would interpret the guidance in 3725.
 
But some people observed that 3PCC covers more than the fixups that 3725 recommends, so this text hedges a little.  Would it help if it were expanded thus:
 
"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 extension.  Peers
need access to any identity assertions present in signaling in order to perform
the checks in {{external_id_hash}}.  For a connection to be successfully
established, a controller needs to forward all fields that contain identity
assertions, including any fields outside of SDP that are used, such as the SIP
Identity header field {{?SIP-ID}}.  A controller that follows the best practices
in RFC 3725 is expected to forward the necessary information contained in SDP,
such as the WebRTC `identity` attribute, thus ensuring the necessary information
is present.
 
"To perform the checks in {{external_session_id}}, a 3PCC system needs to ensure
that guarantee that peers use the same SDP `tls-id` attribute value.  A
controller that follows the best practices in RFC 3725 will produce SDP with
consistent `tls-id` values, but other forms of modification might not.
 
"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."

The text is clearer, but I still don't follow. If I understand RFC 8224 correctly, authenticated identity is only defined for SIP requests, however all four 3PCC flows in RFC 3725 have the controller generate the SIP INVITE, so how do the endpoints exchange authenticated identity information ? 

 The text reads well, but I'm still left with the same question:
 
 Section 3.1, second paragraph says there are two separate sessions (I 
take that to mean SIP sessions). It then goes on to say 
 
 "In the first session, Patsy is presented with the option to 
communicate with Norma "
 
 If I understand correctly, this means there is a SIP INVITE sent by 
Mallory to Patsy, however Mallory somehow asserts Norma's identity to 
Patsy. How is Mallory able to do that if we are using SIP Authenticated 
Identity ? I'm not sure if the above would be cleare if the flow was 
expanded to show INVITE and 200-OK. 

Yeah, I really want to avoid adding all the SIP stuff here.  There would be lots of irrelevant messages involved and it distracts from the message.
 
The key insight here is that SIP identity only certifies a small number of fields and that the rest of the session is open to be modified by the signaling server.  RFC 8225 only covers the identity (sip:norma@example or tel:+12345556789) and the a=fingerprint values, everything else is open to attack.  So if we allow Mallory the ability to modify signaling, there is a lot she can do.  In practice however, this doesn't require much of an attack on the session, other than (maybe) to substitute transport parameters.
 
>From the perspective of SIP and SIP identity, these are largely legitimate sessions.  The attack on signaling is necessary only to the extent that the attack also depends on 
 
I've added more text here, realizing that it was a little light.  This is the updated section in full:
 
"The attack requires that Mallory obtain an identity binding for her own identity
with the fingerprints presented by Patsy (P).  This false binding is then
presented to Norma (Signaling1 in the figure).

You mean Signaling2 in the figure (below), right ? 

     Norma                   Mallory                   Patsy
     (fp=N)                   -----                    (fp=P)
       |                        |                        |
       |                        |<---- Signaling1 ------>|
       |                        |   Norma=N Patsy=P      |
       |<---- Signaling2 ------>|                        |
       |   Norma=N Mallory=P    |                        |
       |                                                 |
       |<=================DTLS (fp=N,P)=================>|
       |                                                 |
     (peer = Mallory!)                         (peer = Norma)

               Figure 1: Example Attack on Identity Bindings

 
"Patsy could be similarly duped, but in this example, a correct binding between
Norma's identity and fingerprint (N) is faithfully presented by Mallory.  This
session (Signaling2 in the figure) can be entirely legitimate.

Signaling1 ? 

"A DTLS session is established directly between Norma and Patsy.  In order for
this to happen Mallory can substitute transport-level information in both
sessions to facilitate this, though this is not necessary if Mallory is on the
network path between Norma and Patsy.
 
"As a result, Patsy correctly believes that she is communicating with Norma.

I don't follow the above sentence (just like I don't follow the sentence I referenced originally, i.e. "In the first session, Patsy is presented with the option to communicate with Norma".

If we double-click on "Signaling1", then I believe we start with:

    INVITE(From: Mallory, To: Patsy, Fingerprint:Norma, Identity:{From:Mallory, Fingerprint:Norma})

Implicit in the sentence above is an assumption that *Mallory* is somehow able to generate an INVITE to Patsy with an Identity header that authenticates *Norma* as the originator, i.e.:

    INVITE(From: Norma, To: Patsy, Fingerprint:Norma, Identity:{From:Norma, Fingerprint:Norma})

How is that possible ? What am I missing here ? 

However, Norma incorrectly believes she is talking to Mallory."

This part I understand. 

There is one last thing that I realized while writing up those changes, and that is that the text was a little vague about the relationship between the attacks.  I'll send another email with a proposed clarification, because I think that's important enough not to hide.

Ok - thanks 

-- Flemming 

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

---

From: "Martin Thomson" <[email-masked]>
Date: Sun, 07 Apr 2019 22:18:00 -0400

> The text is clearer, but I still don't follow. If I understand RFC 8224 
> correctly, authenticated identity is only defined for SIP requests, 
> however all four 3PCC flows in RFC 3725 have the controller generate 
> the SIP INVITE, so how do the endpoints exchange authenticated identity 
> information ? 

Flows 2 and 3 show the Controller creating an offer, but in all cases it is an offer with no media.  The endpoints are still responsible for creating the offer that contains media.  Therefore I assume that they can create offers with identity assertions.

> >>  The text reads well, but I'm still left with the same question:  Section 3.1, second paragraph says there are two separate sessions (I take that to mean SIP sessions). It then goes on to say   "In the first session, Patsy is presented with the option to communicate with Norma "  If I understand correctly, this means there is a SIP INVITE sent by Mallory to Patsy, however Mallory somehow asserts Norma's identity to Patsy. How is Mallory able to do that if we are using SIP Authenticated Identity ? I'm not sure if the above would be cleare if the flow was expanded to show INVITE and 200-OK.  Yeah, I really want to avoid adding all the SIP stuff here.  There would be lots of irrelevant messages involved and it distracts from the message. The key insight here is that SIP identity only certifies a small number of fields and that the rest of the session is open to be modified by the signaling server.  RFC 8225 only covers the identity (sip:norma@example or tel:+12345556789) and the a=fingerprint values, everything else is open to attack.  So if we allow Mallory the ability to modify signaling, there is a lot she can do.  In practice however, this doesn't require much of an attack on the session, other than (maybe) to substitute transport parameters. >From the perspective of SIP and SIP identity, these are largely legitimate sessions.  The attack on signaling is necessary only to the extent that the attack also depends on  I've added more text here, realizing that it was a little light.  This is the updated section in full: "The attack requires that Mallory obtain an identity binding for her own identitywith the fingerprints presented by Patsy (P).  This false binding is thenpresented to Norma (Signaling1 in the figure).

I swapped the two flows in the figure so that it more closely matches the text.

> >   "Patsy could be similarly duped, but in this example, a correct binding betweenNorma's identity and fingerprint (N) is faithfully presented by Mallory.  Thissession (Signaling2 in the figure) can be entirely legitimate.
> Signaling1 ? 
> 
> 
> 
> >  "A DTLS session is established directly between Norma and Patsy.  In 
> order forthis to happen Mallory can substitute transport-level 
> information in bothsessions to facilitate this, though this is not 
> necessary if Mallory is on thenetwork path between Norma and Patsy. "As 
> a result, Patsy correctly believes that she is communicating with Norma.
>
> I don't follow the above sentence (just like I don't follow the 
> sentence I referenced originally, i.e. "In the first session, Patsy is 
> presented with the option to communicate with Norma".
> 
>  INVITE(From: Mallory, To: Patsy, Fingerprint:Norma, 
> Identity:{From:Mallory, Fingerprint:Norma})
> 
> Implicit in the sentence above is an assumption that *Mallory* is 
> somehow able to generate an INVITE to Patsy with an Identity header 
> that authenticates *Norma* as the originator, i.e.:
> 
>  INVITE(From: Norma, To: Patsy, Fingerprint:Norma, 
> Identity:{From:Norma, Fingerprint:Norma})
> 

The section starts with "it is assumed that the attacker also controls the signaling channel."  We allow this possibility because the use of an identity assertion assumes a more capable attacker.  More likely, this assumes that we are defending against the signaling service itself.

Once you get into that state, it's trivial for Mallory to construct the above messages.  Note that Norma will provide Mallory with an identity assertion that binds the identity "Norma" to Norma's fingerprints as part of the Norma<->Patsy session.  So all that Mallory needs to do is fit that into a plausible INVITE.

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 8 Apr 2019 16:48:14 -0400

> Flows 2 and 3 show the Controller creating an offer, but in all cases it is an offer with no media.  The endpoints are still responsible for creating the offer that contains media.  Therefore I ass…
Offers and SIP Requests are not the same. In RFC 3725 Flow 2 and 3, it 
is the controller that generates the SIP Requests and the endpoints that 
generate the SIP Responses and to quote RFC 8224, Section 3:

    Note that the scope of this document is limited to providing an
    identity assurance for SIP requests; solving this problem for SIP
    responses is outside the scope of this work (see [RFC4916]).

Thus, I still don't see how you get these endpoint Identity assertions 
sent across with 3PCC. Maybe we need somebody else to chime in at this 
point.

Jon/Cullen/Ekr: As authors of RFC 8224, can you help shed light on this 
part of the thread ?

> I swapped the two flows in the figure so that it more closely matches the text.
Ok.
> Once you get into that state, it's trivial for Mallory to construct the above messages.  Note that Norma will provide Mallory with an identity assertion that binds the identity "Norma" to Norma's f…
Ok - I think you are saying a bit more actually. Using the terminology 
of RFC 8224, I believe you are assuming that the attacker controls the 
Authentication Service (which I see as more than the signaling channel). 
If that is the case, then I would suggest clarifying that in the text.

Thanks

-- Flemming

> [email-masked]

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 08 Apr 2019 20:20:14 -0400

On Tue, Apr 9, 2019, at 06:48, Flemming Andreasen wrote:
> is the controller that generates the SIP Requests and the endpoints 
> that generate the SIP Responses and to quote RFC 8224, Section 3:
>

Right.  What is relevant here is the offers and answers, not the SIP requests.  RFC 3725 shows only inconsequential offers being generated by the controller.  In the RFC 8224 context, this remains true, but it is hard to see why (more on that below).

>  Jon/Cullen/Ekr: As authors of RFC 8224, can you help shed light on 
> this part of the thread ?

[...]

> Ok - I think you are saying a bit 
> more actually. Using the terminology of RFC 8224, I believe you are 
> assuming that the attacker controls the Authentication Service (which I 
> see as more than the signaling channel). If that is the case, then I 
> would suggest clarifying that in the text. 

I don't believe that is the case.  But I see now the angle you are concerned about.  Because RFC 8224 doesn't consider 3PCC, we might have a problem in the sense that 3PCC doesn't work at all with SIP Identity, but let's see if we can work out what it looks like.

Note that "signing" as imagined in RFC 8224 depends on there being SDP to sign.  If there is SDP and it is not bogus, then there is potentially a binding between the a=fingerprint attributes and some identity.  Whether that is in the SIP Identity header field (RFC 8224) or the SDP itself (WebRTC), the result is the same. 

For 3PCC with RFC 8224, either the controller is responsible for signing, the signing is performed by proxies near A and B (proxies that are not shown in the figure), or by A and B directly.  The point of the signature is to protect against attack between the point that the signature is added and where it is removed.  If the controller is both signing and consuming signatures, that would be pointless because they would be trusted by both A and B, so we'll ignore that case.   Therefore, we assume that signatures happen closer to A or B (or both) so that the signatures serve a purpose.

So we have:  A---AuthSvcA---...---AuthSvcB---B with a controller somewhere on the signaling path between the two ends.  Generally, RFC 8224 assumes that the path from A to its Authentication Service is "trusted", so the attack is on the path between the two Authentication Services.  The controller can be anywhere, because we're not assuming anything about that.

You might wonder whether the controller can generate bogus SDP that can be signed, but that is a constraint on deployment, not on security.  Bogus SDP generated by a controller that sits on the "untrusted" portion of the signaling path won't be signed and therefore might be rejected, but that just limits the choices the controller has.  If the controller is on a "trusted" segment, then it might generate SDP for the endpoint nearest to it and have a valid signature over that content.

The attack that we're contemplating acts on the "untrusted" segment of the signaling path.  It operates without collaboration with any of the "trusted" entities.  It relies on being able to intercept and modify signaling on that path segment.  That's all.  In all cases other than the nonsensical one where the controller acts as Authentication Service for both parties, the attack we're  considering doesn't depend on the Authentication Service being compromised.  

In the extreme case, say that  A and B sign their own SDP/signaling and assert their own identities.  If the controller is the attacker, they control when sessions are established and how.  They can copy-paste signatures between the different messages they receive.

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 21 Apr 2019 18:07:39 -0400

On 4/8/19 8:20 PM, Martin Thomson wrote:
> Right.  What is relevant here is the offers and answers, not the SIP requests.  RFC 3725 shows only inconsequential offers being generated by the controller.
This is where we differ. In the SIP case, the attack you describe is 
predicated on a mismatch between the Identity information provided in 
the SIP request and the (assumed) identity of the SDP in an offer, thus 
the SIP requests are indeed very relevant to the discussion.

> In the RFC 8224 context, this remains true, but it is hard to see why (more on that below).
>
Maybe so, but the flows and feasibility of the attacks are not, and that 
is an important distinction:
- 3PCC is defined for SIP, and SIP Identity is only defined for SIP Requests
- WebRTC Identity on the other hand is defined as an SDP attribute, and 
it is included in SDP offers (and optionally answers)

> So we have:  A---AuthSvcA---...---AuthSvcB---B with a controller somewhere on the signaling path between the two ends.  Generally, RFC 8224 assumes that the path from A to its Authentication Servic…
Agreed so far.
> You might wonder whether the controller can generate bogus SDP that can be signed, but that is a constraint on deployment, not on security.
I disagree - it is a constraint on the overall feasibility of the 
attack. If we can't construct a deployment scenario that enables the 
attack, then the attack is not practically feasible, and then why are we 
concerned with it ?

To be more specific, the signature covering the SDP is generated by the 
authentication service above, and you stated (and I agree) that the 
attack cannot happen between A and AuthSvcA. Given that, how can the 
controller generate bogus SDP that gets signed (with a signature 
covering the "From: A", "To: B", Date and SDP fingerprint ) ?

>    Bogus SDP generated by a controller that sits on the "untrusted" portion of the signaling path won't be signed and therefore might be rejected, but that just limits the choices the controller has.
I agree it won't be signed, but at that point I don't believe we are in 
the attack scenario the document describes (?)

>   If the controller is on a "trusted" segment, then it might generate SDP for the endpoint nearest to it and have a valid signature over that content.
Sure, but above, you just said that wasn't the attack scenario we were 
contemplating (presumably because it invalidates the premise of SIP 
Identity to begin with)
>
> The attack that we're contemplating acts on the "untrusted" segment of the signaling path.  It operates without collaboration with any of the "trusted" entities.  It relies on being able to intercept and modify signaling on that path segment.  That's all.
I hear you, but you have yet to show me how that is possible. Please 
provide an example SIP flow that demonstrates how this attack is 
realized, 'cause I still don't see it.

>   In all cases other than the nonsensical one where the controller acts as Authentication Service for both parties, the attack we're  considering doesn't depend on the Authentication Service being compromised.
I agree that should be the premise, but I don't see how it is achieved.
> In the extreme case, say that  A and B sign their own SDP/signaling and assert their own identities.  If the controller is the attacker, they control when sessions are established and how.  They ca…
Please provide an example flow that illustrates this in more detail.

Thanks

-- Flemming

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 23 Apr 2019 00:29:01 -0400

On Mon, Apr 22, 2019, at 08:07, Flemming Andreasen wrote:
> This is where we differ. In the SIP case, the attack you describe is predicated on a mismatch between the Identity information provided in the SIP request and the (assumed) identity of the SDP in an offer, thus the SIP requests are indeed very relevant to the discussion. 

I see your point below.  I missed the bit in RFC 8224 where it has to be a request. I was concentrating on the properties of the assertions, not the protocol integration.  I agree that it's important.

If 3PCC as described in RFC 3725 never produces a scenario where a request is bound to valid SDP, then 8224 + 3725 won't ever intersect.  Looking again with that constraint in mind (that it has to be a request), I see no scenario where 8224 and 3725 could be used together unless the controller is also the authorization service.  That arrangement would rule the controller out as an attacker we care about, because it has to be trusted by definition.   (More below.)

This doesn't invalidate the other aspects of the attack, just that this attack isn't valid when both 8224 and 3725 are used.  SIP identity can be used on calls without 3PCC and the text here applies to those uses.  Or 3PCC can be used without SIP identity (maybe the WebRTC identity is used) and the attack would be relevant.

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?

On the specific flows:

Flow I might work if the controller was the Authorization Service for A.  Or the controller was between A and its Authorization Service.
Flow II only works if the controller is the Authorization Service for both A and B.
Flows III and IV might work if the controller was the Authorization Service for B.  Or the controller was between B and its Authorization Service.

I base this on the fact that any non-trivial offers only appear in 200 responses.  So the first place that the message appears in a request is at the controller.  This puts the controller on a "trusted" segment of the signaling path.