Subject: Re: [stir] New Version Notification for draft-ietf-stir-enhance-rfc8226-01.txt

From: Russ Housley <[email-masked]>
Date: Wed, 24 Mar 2021 10:37:33 -0400

This revision addresses the WG Last Call comments from Ben Campbell.  It also adds a security consideration regarding the "rcdi" claim defined in draft-ietf-stir-passport-rcd.  In addition, I thought of an additional security consideration regarding certificate renewal.  Finally, the reference to RFC 5912 is now normative.

Russ

> A new version of I-D, draft-ietf-stir-enhance-rfc8226-01.txt
> has been successfully submitted by Russ Housley and posted to the
> IETF repository.
> 
> Name:		draft-ietf-stir-enhance-rfc8226
> Revision:	01
> Title:		Enhanced JWT Claim Constraints for STIR Certificates
> Document date:	2021-03-23
> Group:		stir
> Pages:		11
> URL:            https://www.ietf.org/archive/id/draft-ietf-stir-enhance-rfc8226-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-stir-enhance-rfc8226/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-stir-enhance-rfc8226
> Htmlized:       https://tools.ietf.org/html/draft-ietf-stir-enhance-rfc8226-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-enhance-rfc8226-01
> 
> Abstract:
>   RFC 8226 provides a certificate extension to constrain the JWT claims
>   that can be included in the PASSporT as defined in RFC 8225.  If the
>   signer includes a JWT claim outside the constraint boundaries, then
>   the recipient will reject the entire PASSporT.  This document defines
>   additional ways that the JWT claims can be constrained.
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Mar 2021 10:57:42 -0500

This version addresses all of my comments.

I wonder if the new security consideration for rcdi might be better placed in the RCD spec? (No strong feelings—I’m okay leaving it here.)

Thanks!

Ben.

> On Mar 24, 2021, at 9:37 AM, Russ Housley <[email-masked]> wrote:
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Russ Housley <[email-masked]>
Date: Wed, 24 Mar 2021 12:04:26 -0400

Ben:

I agree that something about the constraints belongs in the RCD document, but I do not think a heads up in this document is bad.

Russ

> On Mar 24, 2021, at 11:57 AM, Ben Campbell <[email-masked]> wrote:
>

---

From: Ben Campbell <[email-masked]>
Date: Sun, 28 Mar 2021 13:11:09 -0500

Another thought just occurred to me, related to the previous conversation about non-string JSON types, although it probably matters for strings as well.

Does the addition of “excludedValues” suggest a need for canonicalization of the values? If not, it seems like a bad actor could sneak things past the verifier by varying white space usage, element order, etc.

This might also be useful for “permittedValues”, but in that case it might be more to help prevent errors.

As I think about this, I wonder if we should have a security consideration pointing out that the excludeValues mechanism cannot defend against more sophisticated bad actions such as confusable unicode strings. Unless we want to suggest that the issuer include every conceivable variation of the prohibited values, which seems a bit extreme.

Thanks!

Ben.

> On Mar 24, 2021, at 11:04 AM, Russ Housley <[email-masked]> wrote:
> 
> Ben:
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 29 Mar 2021 11:46:45 -0400

Ben:

The JWT specification (RFC 7519) does not require canonicalization.

JSON allows these types:
 -   a string
 -   a number
 -   a JSON object
 -   an array
 -   a boolean
 -   null

Only the array and JSON object can be a concern.

For an array, the ordering could be important, so the only thing we can do is remove all of the whitespace between array elements.

For a JSON Object, again we can remove whitespace outside of quotes, but we could require a sort order the elements of the object.

Looking at the example in passport-rcd:

   {
     "orig": { "tn": "12025551000"},
     "dest": { "tn": ["12155551001"]},
     "iat": 1443208345,
     "rcd": {
       "nam": "Q Branch Spy Gadgets",
       "jcd": ["vcard",
       [ ["version",{},"text","4.0"],
         ["fn",{},"text","Q Branch"],
         ["org",{},"text","MI6;Q Branch Spy Gadgets"],
         ["photo",{},"uri","https://example.com/photos/q-256x256.png"],
         ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"],
         ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"]
       ] ]
     },
     "crn": "Rendezvous for Little Nellie",
     "rcdi": {
       "/nam": "sha256-918VNJD12938SNCJ",
       "/jcd": "sha256-VNJDSNCJ12938918",
       "/jcd/1/3/3": "sha256-12938918VNJDSNCJ",
       "/jcd/1/4/3": "sha256-VNJDSNCJ12938918",
       "/jcd/1/5/3": "sha256-4049852730SFLGHL"
     }
   }

Would a sort order be helpful?

Russ

> On Mar 28, 2021, at 2:11 PM, Ben Campbell <[email-masked]> wrote:
>

---

From: Richard Shockey <[email-masked]>
Date: Mon, 29 Mar 2021 12:31:56 -0400

But maybe it should.  One of the biggest interoperablity concerns with STIR/SHAKEN in general is the lack of, or improper canonicalization.

On 3/29/21, 11:46 AM, "stir on behalf of Russ Housley" <[email-masked] on behalf of [email-masked]> wrote:

    Ben:

    JSON allows these types:
     -   a string
     -   a number
     -   a JSON object
     -   an array
     -   a boolean
     -   null

       {

    Russ

---

From: Chris Wendt <[email-masked]>
Date: Mon, 29 Mar 2021 12:47:12 -0400

Relative to order what Jon and I did for integrity was to include the base /rcd as part of the required part of the “rcdi” integrity, so because the digest is based on the JSON in a particular order, also required to make sure the JSON pointer points to the correct URI, that takes care of the array order of the jCard in particular.

But I think to Ben’s original point, I’m confused how you could "sneak anything by" with white space, or unicode swaps.  excludedValues is at the claim level, so it seems to me to be either correct or not correct in terms of the entire “rcd” or “rcdi” claims.  It’s not that you are going in and interpreting values or anything.  But maybe i missed the point.

-Chris

> On Mar 29, 2021, at 12:31 PM, Richard Shockey <[email-masked]> wrote:
> 
>

---

From: Chris Wendt <[email-masked]>
Date: Mon, 29 Mar 2021 12:55:04 -0400

Maybe i’m seeing the point actually, are you saying we should be explicit that the permitted or excludedValues are canonicalized (i.e. white space removal) before being encoded into cert.  This was my assumption, but would need to look if we have anything to say that explicitly.  My assumption was that the values when compared between the signed PASSporT and the certificate permited/excludedValues would not require any canonicalization procedures.

-Chris

> On Mar 29, 2021, at 12:47 PM, Chris Wendt <[email-masked]> wrote:
>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 29 Mar 2021 12:12:06 -0500

My original point was that (maybe) the value should be canonicalized in the JWTContraints, and that the claim values should be canonicalized when comparing against the constraints. And I meant that more as a question than an assertion :-)

But on reflection, the issue may be that I don’t really understand how we plan to use excludedValues. (Apologies if this has already been discussed and I either missed it or just forgot)

For the case of includedValues, one assumes that whoever builds the PASSporT is aware of the JWTConstraints in their certificate, and will put rcd/rcdi values that match. Maybe some guidance on not screwing that up would be helpful, but implementors will (eventually) figure it out. It is in their interests to get it right, else their calls will fail verification.

But in the case of excludedValues,  IIUC we are saying “you can’t put in an rcd claim that looks _exactly_ like this.”  What behavior are we trying to prevent? Is it in some senders' interests to circumvent the protection? It seems trivial to construct an RCD claim that is not identical to the prohibited value but close enough to confuse a recipient. Canonicalization might help prevent errors but probably won’t prevent intentional attempts to bypass the protection.

Thanks!

Ben.

> On Mar 29, 2021, at 11:55 AM, Chris Wendt <[email-masked]> wrote:
>

---

From: Richard Shockey <[email-masked]>
Date: Mon, 29 Mar 2021 13:24:13 -0400

Yep. Also in the TO: FROM: fields which should be expressed as full E164 with the + which I presume are used to encode. This is especially a problem when the call comes from a enterprise and it need to be normalized by the originating carrier before the INVITE is sent to the terminating carrier.

For a project I'm working on I've had the joy of reading several BCP's that accompany the Voice peering agreements. 

TCP vs UDP, packet fragmentation, keep alive, Diversion all the usual suspects.

I also hear a great deal about "Roadmap Fatigue" among operators and vendors.

— 
Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

On 3/29/21, 12:55 PM, "Chris Wendt" <[email-masked]> wrote:

    -Chris

---

From: Chris Wendt <[email-masked]>
Date: Mon, 29 Mar 2021 15:21:04 -0400

Hi Ben,

I think excluding claims use-case is the primary case where you simply don’t want people adding, for example, rph to an rcd passport because they could and it would look legit without the exclusion capability.  I think we added excludeValue because we thought it made sense to have it, however, i maybe don’t see as much of a use-case for that at present, however doesn’t mean that a use-case doesn’t exist.  Perhaps what you are asking Ben, is excludeValue may not be worth including and may be a security risk.  I would need to noodle on that a bit more, but it might be worth considering before we finalize the enhance-8226 document.

-Chris

> On Mar 29, 2021, at 1:12 PM, Ben Campbell <[email-masked]> wrote:
>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 29 Mar 2021 16:44:27 -0500

Right—the value of excluding claims seems pretty clear.

I’m not sure I would go so far as to call excludeValues a security risk, but I think it might at least need a safety label :-) Since you mention RPH, I can see where excludeClaims might be useful in a use case like RPH where you tend to select claim values from enumerated lists.

Ben.

> On Mar 29, 2021, at 2:21 PM, Chris Wendt <[email-masked]> wrote:
> 
> Hi Ben,
>