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

[Adam Roach <[e-mail]>]

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

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.

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§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

===========================================================================

My remaining comments are non-blocking, and can be handled at the same 
time as
other IETF last call comments.

---------------------------------------------------------------------------

Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

  - UAS - User Agent Server
  - JOSE - JSON Object Signing and Encryption
  - JWT - JSON Web Token
  - JWS - JSON Web Signature
  - UAC - User Agent Client
  - JWA - JSON Web Algorithms
  - SDP - Session Description Protocol

---------------------------------------------------------------------------

Abstract:

 >  The present use case driving the need
 >  for the 608 response code is when the intermediary is an analytics
 >  engine.

The use of "present" won't age well. Suggest changing to "initial."

---------------------------------------------------------------------------

§1:

 >  was unwanted.  As RFC8197 explains, not only does the called party

Nit: "[RFC8197]" or "RFC 8197"

 >  call analytics engine.  For various reasons described in RFC8197, if

Same as above.

 >  does not want the call.  However, RFC8197 specifies that one of the

Same as above.

---------------------------------------------------------------------------

§1:

 >  An algorithm can be vulnerable to the base rate
 >  fallacy base rate fallacy [BaseRate] algorithm rejecting the call.

This sentence is difficult to follow. Please re-write for clarity.

---------------------------------------------------------------------------

§1:

 >  One might ask why we cannot use the same mechanism an analytics
 >  service provider offers their customers that lets them correct a call
 >  blocked in error?

Nit: replace "?" with "."

---------------------------------------------------------------------------

1:

 >  The protocol described in this document uses existing IETF protocol
 >  mechanisms...

This reads a bit awkwardly. Consider "...existing SIP protocol 
mechanisms..."

---------------------------------------------------------------------------

§1:

 >  ...we have a standard marshaling mechanism for
 >  creating a canonical representation of a JSON [RFC8259] object...

I don't think this is true as stated, nor is it needed for this 
document. There
are ongoing discussions about defining a standardized canonical 
serialization of
JSON objects, but those discussions are still in their very earliest stages.

---------------------------------------------------------------------------

§1:

 >  Suppose, for
 >  example, that the redress address was simply passed as a header
 >  value.

Nit: "...header field value."

---------------------------------------------------------------------------

§1:

 >  The jCard encoding might seem unnecessary at first, but it is...

This paragraph is confusing, as there's nothing inherent in jCard that 
does any
of the things this paragraph claims. I think changing "jCard" to "Signed 
jCard"
probably fixes this.

---------------------------------------------------------------------------

§3.1:

 >  In this situation, the requirements stated in Section 16.7 of RFC3261
 >  [RFC3261] apply.

Nit: remove the initial "RFC3261".

---------------------------------------------------------------------------

§3.2:

 > 3.2.  jCard Construction
 >
 >    The intermediary constructs the JWS as follows.

This is a bit confusing: the section header indicates that this talks about
jCard construction, while the prose indicates that it talks about JWS
construction. I suggest adjusting the title.

---------------------------------------------------------------------------

§3.4:

 >  they will pass headers such as "Feature-Caps: *;+sip.608" unmodified.

Nit: "...pass header fields such as..."

---------------------------------------------------------------------------

§4.1:

 >  Contact: <sip:[phone]@2001:db8::12:50207;rinstance=9da3088f36cc>

Thanks for using IPv6 in your examples! Please reformat according to the 
rules
for IPv6 addresses in URIs (note the brackets):

    Contact: <sip:[phone]@[2001:db8::12]:50207;rinstance=9da3088f36cc>

 >  Via: SIP/2.0/UDP 2001:db8::177:60012;branch=z9hG4bK-524287-1

Similarly:

    Via: SIP/2.0/UDP [2001:db8::177]:60012;branch=z9hG4bK-524287-1

---------------------------------------------------------------------------

§4.1:

All of the JWS examples in this document use vanilla Base64 encoding, rather
than the "Base64url" encoding defined in section 2 of RFC 7515. None of them
are syntactically valid JWS. Please see RFC 7515 Appendix C for guidance.

---------------------------------------------------------------------------

§4.4:

 >  608.  Per RFC6809 [RFC6809], the SBC can insert "*;+sip.608" into the

Please remove the redundant "RFC6809".

---------------------------------------------------------------------------

§4.4, Figure 5:

It's a bit unconventional for a ladder diagram to have the initiating action
start from the right-hand-side of the diagram. Consider reversing the 
order of
elements left-to-right.

---------------------------------------------------------------------------

§6:

 >  Intermediary operators need to be mindful of whom they are sending
 >  the 608 response.

This is missing a preposition. I suggest adding a "to" either before 
"whom" or
after "response" (depending on how formally correct you wish to be).

---------------------------------------------------------------------------

§6:

    more significant risk, is that by providing a contact in the Call-
    Info field, the intermediary may be giving the malicious caller a

Nit: "...header field..."

---------------------------------------------------------------------------

§6:

 >  Because
 >  the mechanism described here can result in an audio file being sent
 >  to the target of the Contact header field,

This isn't right. The target of the attack would need to be indicated in 
the SDP
of the INVITE, not the Contact header field. Basically, this describes 
the exact
same attack that RFC 5245 section 18.5.1 does. I don't mention this for the
purpose of citing RFC 5245 (which has been superseded by RFC 8445, which 
lacks a
corresponding section), but to point out that the security considerations
section in this document should at least mention ICE as a mitigation 
technique
for this attack.