Subject: [sipcore] I-D Action: draft-ietf-sipcore-rejected-01.txt

From: [email-masked]
Date: Sun, 25 Nov 2018 17:51:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core WG of the IETF.

        Title           : A Session Initiation Protocol (SIP) Response Code for Rejected Calls
        Author          : Eric W. Burger
	Filename        : draft-ietf-sipcore-rejected-01.txt
	Pages           : 19
	Date            : 2018-11-25

Abstract:
   This document defines the 608 (Rejected) SIP response code.  This
   response code enables calling parties to learn their call was
   rejected by an intermediary and will not be answered.  As a 6xx code,
   the caller will be aware that future attempts to contact the same UAS
   will be likely to fail.  The present use case driving the need for
   the 608 response code is when the intermediary is an analytics
   engine.  In this case, the rejection is by a machine or other
   process.  This contrasts with the 607 (Unwanted) SIP response code,
   which a human at the target UAS indicated the call was not wanted.
   In some jurisdictions this distinction is important.  This document
   defines the use of the Call-Info header in 608 responses to enable
   rejected callers to contact entities that blocked their calls in
   error.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-rejected-01
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rejected-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Eric Burger <[email-masked]>
Date: Sun, 25 Nov 2018 21:04:42 -0500

Do we need replay protection? The current draft allows a malicious actor to cut and paste a signed jCard JWS. The question is how realistic is an attack where someone is basically smurfing a legitimate resolution contact with someone else’s pseudo-spit calls?

I was hoping we could pre-compute the jCard signature. However, no big deal to have to computer per-call. In the real world, the intermediary is only generating a 608 with a Call-Info JWS if the original call is STIR-signed, SHAKEN-signed with an approved CA in North America, and verification passes.

You will note I went the jCard route instead of trying to figure out how to sign vCards. The TL;DR explanation is the marshaling required to sign a JSON object is a handful of page RFC; the extant draft to sign vCards was upwards of a hundred pages and has no expectation of ever getting finished.

> On Nov 25, 2018, at 8:51 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore