Re: [sipcore] AD Review: draft-ietf-sipcore-rejected

[Eric Burger <[e-mail]>]

Thanks for the review! I think the draft will read a lot easier. I’ve accepted all of your suggestions, with a sideways deflection of the first set of substantive issues. I’ll trim the rest of the comments as they are in the archive, and focus in-line on the first set of comments.

I just posted -07 and the announcement just flew by.
https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rejected-07


> On Apr 17, 2019, at 9:41 PM, Adam Roach <[e-mail]> wrote:
> 
> This is my AD review for draft-ietf-sipcore-rejected. There are a few places
> where I think the mechanism needs to be better defined -- or, at least, more
> clearly described -- before it goes into IETF review. I've grouped those issues
> together at the top of my comments that follow.
> 
> ---------------------------------------------------------------------------
> 
> §4.1:
> 
> This example is perplexing in a few dimensions that should be either
> changed or explained. These are confusing enough that I'd like to see a new
> version of the document before putting it into IETF last call.
> 
> The first is that its Call-Info header field indicates a URL of the form:
> 
>   https://block.example.net/complaint.json
> 
> ...which strongly implies that one might find a JSON object at that location. It
> then goes on to specify that the thing one would retrieve from this location is
> a JWS. While there's nothing that technically binds a URL's name to the content
> type found at that URL, this goes against fairly well-established conventions in
> a way that is likely to confuse implementors.
> 
> That would imply a change to:
> 
>   https://block.example.net/complaint.jws

I would offer that when you resolve the URI, you will get… a JSON object. That JSON object /happens/ to be a JWS. Note that *.jws is a thing: we at BEA Systems (now Oracle) use it to identify Java Web Server code.

As such, no change there.

> But this leads us to the second problem: the form of the URL -- a domain
> followed by a simple word -- implies that this same URL is used for all
> rejected calls (and... one would assume is generated on the fly with a fresh
> "iat" parameter?)  If that's the case, then this URL becomes an oracle that
> allows for the exact kind of replay attacks described in the introduction. To
> prevent this from being such an oracle, it's going to minimally need to vary
> by call, which would lead it to look more like:
> 
> https://block.example.net/79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI.jws
> 
> However, this takes us to yet a third problem, which is -- even with a
> JWS-per-rejected-call approach, nothing prevents an attacker from spoofing 608
> responses with this URL for as long as the "iat" is likely to be accepted by
> callers (probably on the order of minutes), which can still cause some pretty
> substantial damage.
> 
> I *think* this requires the ability to bind the jCard-containing JWS to the
> call. This would require additional claims to be added to the body. You could
> re-use the "orig" and "dest" claims created by PASSPORT (but be wary of
> retargeting), or come up with your own claims that bind the rejection to the
> call (although be careful of choosing fields that may be fragile in the
> presence of B2BUAs); but I think the whole signing mechanism just doesn't work
> unless it's bound to the call in some way. It might be enough just to bind it to
> the calling party, since that reduces the attack from a DDoS to a simple
> one-device DoS.
> 
> Note that this last problem doesn't really bear on the example itself; however,
> I wasn't completely convinced that it was an issue until I got to the example.

I do not think we need to bind the jCard to a specific call. I greatly expanded the language in the Security Considerations section to make it clear what threats we are mitigating by signing the jCard and including an iat claim. Specifically, it is not to prove that /this/ jCard belongs to /that/ call. It is to prove that /this/ signer signed /this/ jCard. And, in reality, most intermediaries will have a fixed jCard and will use the iat as a nonce. More verbosity in the Security Considerations. Let me know if it makes more sense.


> ---------------------------------------------------------------------------
> 
> §4.4, Figure 5:
> 
> This is an issue that I'd like to see fixed before IETF last call.
> 
> Please either show the use of PRACK with the 183 response, or indicate that the
> required PRACK messages have been elided from the diagram for clarity. In either
> case, this document must have RFC 3262 as a normative dependency, as it's
> impossible to satisfy its normatively-required behaviors without that
> mechanism.

Head smack given the major point of PRACK is to play announcements, says the guy who built announcement boxes <argh!>
Fixed.
Duh.
Thanks.


> ---------------------------------------------------------------------------
> 
> §6:
> 
> This is an issue that I'd like to see fixed before IETF last call.
> 
> The mechanism specifies that the JWS objects are required to contain an "iat"
> claim, but provides no guidance for how the recipient of such a JWS is supposed
> to use this information. Clearly, it's intended to be "fresh enough" to prevent
> replay attacks, but this is never stated.
> 
> You should be able to fix this (once the first issue above is addressed) by
> adding something to the "Security Considerations" section modeled after
> https://tools.ietf.org/html/rfc8225#section-10.1

Done.