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

[Ben Campbell <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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 <[e-mail]> wrote:
>> 
>> 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 <[e-mail]> wrote:
>>> 
>>> 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 <[e-mail]> wrote:
>>>> 
>>>> 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 <[e-mail]> wrote:
>>>>> 
>>>>> 
>>>>> 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" <[e-mail] on behalf of [e-mail]> wrote:
>>>>> 
>>>>> 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 <[e-mail]> wrote:
>>>>>> 
>>>>>> 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 <[e-mail]> wrote:
>>>>>>> 
>>>>>>> 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 <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> 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 <[e-mail]> wrote:
>>>>>>>>> 
>>>>>>>>> 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.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> stir mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> stir mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>> 
>>>>>> _______________________________________________
>>>>>> stir mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>> 
>>>>> _______________________________________________
>>>>> stir mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> stir mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>> 
>>> 
>> 
>