Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Jun 2016 09:09:59 +0000

Hi,

If I understand the proposal correctly, the reason we may not want to send
the JWT claims is because you’ll find the same information in SIP header
fields, and we will use the SIP header field information when calculating
(sender) and verifying (receiver) the JWT signature.

Now, keep in mind that, when you calculate the JWT signature using the JWT
claims, each claim value is considered a string, which means every
character (including space characters) count when calculating the
signature.

For example, if one claim represents the SIP Cseq value:

{
	“CSeq": “1234<SP>INVITE”
}

…will not (afaik) produce the same signature value as:

{
        “CSeq": “1234<SP><SP><SP>INVITE”
}

In SIP headers, you can not guarantee that what is sent is what will be
received. There may be additional space characters, there may be linear
whitespaces etc. So, when the receiver tries to verify the signature, it
may fail.

For example, if the sender sends:

CSeq: 1234<SP>INVITE

…it may receive:

CSeq: 1234<LWS>INVITE

…in which case the signature calculated by the receiver will not match
value signature calculated by the sender (assuming space characters etc
are also used when calculating the signature).

So, IF we want to calculate the signature based on SIP header filed
values, I think we need to define a way of canonicalising them.

Or, have I misunderstood something? :)

Regards,

Christer

On 01/06/16 03:25, "stir on behalf of Peterson, Jon"
<[email-masked] on behalf of [email-masked]> wrote:

>
>This is a point that Chris and I have discussed a bit before, and is one
>of those issues that is hard to resolve because the differences between
>the two choices are so small.
>
>>From my perspective, making implementations send "canon" by default,
>>while
>leaving the option to exclude it, requires the same two code paths to
>exist as we do when we don't send "canon" by default, and leave the option
>to include it. And yes, the argument not to send it be default is simply
>to reduce message size, given the fields in canon are necessarily
>redundant with various hearer field values and parameters in SIP. In some
>environments, I still hear that message size is a concern. That's why
>we've set it this way now. It might turn out in deployment that we need
>"canon" more often that we'd think, because of things like Date header
>changes, say. I'd be willing to revisit this when we have a bit more
>experience under our collective belts.
>
>Ultimately, as Chris says, a verification service will need to basically
>reconstruct the header and claims itself anyway from the SIP request - or
>at least that the differences between reconstructing them on the one hand
>and extracting each individual field to compare them to the corresponding
>headers and claims of the canonical JWT object on the other hand seem
>unlikely to genuinely impact either the difficulty of implementation or
>the compute cycles required.
>
>But like Chris, I'm interested to hear people's thoughts on this, and I'm
>not deeply committed to either approach.
>
>Jon Peterson
>Neustar, Inc.
>
>On 5/31/16, 6:06 AM, "stir on behalf of Chris Wendt"
><[email-masked] on behalf of [email-masked]> wrote:
>
>>Hi All,
>>
>>There was a discussion on the STIR interim call about whether there is
>>any strong reasons to consider using the full PASSporT
>>(header.claims.signature) as the default for the identity header in
>>4474bis.
>>
>>The primary argument for the full token being default would be, it may be
>>more efficient from an implementation point of view to have the
>>constructed token available to the verification service to directly
>>validate signature.  With the caveat that in either case you either need
>>to re-construct the header.claims or you need to decode the Base64 to get
>>the JSON header and claims to verify that the values correspond to values
>>in the SIP header.
>>
>>The primary argument for the current default of only including the
>>signature, is to save the 80-100 bytes of ³duplicate² information in the
>>SIP payload.
>>
>>Feel free to reword if i didn¹t capture the main arguments correctly.
>>
>>Would like to get other opinions or other arguments for or against
>>keeping things the way they are or considering just using the full
>>PASSporT token in the identity header.
>>
>>Thanks.
>>
>>-Chris
>>_______________________________________________
>>stir mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/stir
>
>_______________________________________________
>stir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/stir

---

From: Eric Burger <[email-masked]>
Date: Wed, 1 Jun 2016 08:35:01 -0400

Is the munging of SP to LWS real or theoretical? If real, no wonder end-to-end signed signaling NEVER worked. If theoretical, we can safely ignore it.

> On Jun 1, 2016, at 5:09 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>

---

From: Richard Shockey <[email-masked]>
Date: Wed, 01 Jun 2016 08:56:37 -0400

Well if the size of the INVITE is the concern, I would argue that we have crossed that Rubicon years ago or as Caesar said, ālea iacta est ("the die has been cast").  My concern, as Chris points out, are implementation issues and that seems to argue that the full token should be the default.

Speaking of implementation, my concern with these documents are that there are insufficient examples to guide implementers on what to expect or at the very least what a STIR enabled INVITE would look like as it reaches the Validation service and eventually as it reaches the UA.  We don’t need a full 5359 but something more than what we have now.   Based on what I see now I wouldn’t know how to code a product to make this work.

On 5/31/16, 8:25 PM, "stir on behalf of Peterson, Jon" <[email-masked] on behalf of [email-masked]> wrote:

>>From my perspective, making implementations send "canon" by default, while

---

From: Richard Shockey <[email-masked]>
Date: Wed, 01 Jun 2016 08:58:09 -0400

Thank you Eric .. I was thinking the same thing.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Jun 2016 14:16:31 +0000

Hi,

SP/LWS was just one example. Another example is when you have case-insensitive header field values. The case can be changed by intermediates.

This is what you get with the liberal encoding rules of SIP - which back in the days was one of the reasons why SIP was so much better than H.323... :)

Also, if we would only use the signature, what's then left of JWT?

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Richard Shockey<mailto:[email-masked]>
Sent: ‎01/‎06/‎2016 15:58
To: Eric Burger<mailto:[email-masked]>; Christer Holmberg<mailto:[email-masked]>
Cc: IETF STIR Mail List<mailto:[email-masked]>
Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon

---

From: Russ Housley <[email-masked]>
Date: Wed, 1 Jun 2016 11:39:13 -0400

>        “CSeq": “1234<SP><SP><SP>INVITE”

Correct.

We find this all the time in security protocols.  You need to be strict in what you send, otherwise the receiver will not be able to verify it.

If there is any ambiguity in the strings that can be produced, then the canon procedure should eliminate the ambiguity.  In the above, replace multiple occurrence of <SP> with a single <SP>.

Russ

---

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Jun 2016 11:59:46 -0400

This would require a reasonable amount of work to document correctly.

If we really want to do this, I might be willing to create a straw man of what was needed.

I am mostly responsible for the (crummy) ABNF in 3261 so I feel obligated to volunteer :(

Brian
> On Jun 1, 2016, at 11:39 AM, Russ Housley <[email-masked]> wrote:
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Jun 2016 16:05:02 +0000

Hi,

We obviously need to check whether the issues apply to the STIR usage of JWT - my comments were general, and we need to keep them in mind.

If we e.g. are going to calculate the signature based on a phone number, there will be no space characters etc between the digits.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Brian Rosen<mailto:[email-masked]>
Sent: ‎01/‎06/‎2016 18:59
To: Russ Housley<mailto:[email-masked]>
Cc: Christer Holmberg<mailto:[email-masked]>; IETF STIR Mail List<mailto:[email-masked]>
Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon

Brian

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 1 Jun 2016 16:48:18 +0000

This addresses a very different question than what Chris was asking when he kicked off this thread, but to this point: the header and claim values in baseline PASSporT do not take the entire content of any header field value from SIP in such a way that whitespace concerns will arise. The claims all take some single syntactical element: extracting the addr-spec, say, or the contents of the "info" parameter of Identity, or what have you. Since "iat" is used instead of the Date header field value, even that has no whitespace concerns.

That much said, it's probably worth noting in PASSporT that future extension headers and claims should avoid this. Display name, for example, has different properties, and we'd need to put up some warning tape around that.

Jon Peterson
Neustar, Inc,

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 1, 2016 at 9:05 AM
To: Brian Rosen <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>
Cc: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon

Hi,

Regards,

Christer

Sent: 01/06/2016 18:59

Brian
> On Jun 1, 2016, at 11:39 AM, Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:
>
>
> [email-masked]<mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Jun 2016 17:23:05 +0000

Hi,

>This addresses a very different question than what Chris was asking when he kicked off this thread, but to this point: the header
>and claim values in baseline PASSporT do not take the entire content of any header field value from SIP in such a way that whitespace
>concerns will arise. The claims all take some single syntactical element: extracting the addr-spec, say,

The SIP(S)-URI is an instance of addr-spec, and it contains parts that can be separated by whitespaces. In addition, some parts are also case-insensitive, some parts can be escaped, and I assume the order of URI parameters can also change.

See section 19.1.4 of RFC3261 for examples of URIs with different encodings but equivalent values.

>or the contents of the "info" parameter of Identity, or what have you. Since "iat" is used instead of the Date header field value, even that has no whitespace concerns.

True. And, as "iat" is carried as a JWT claim, it can't be "legally" modified using the SIP encoding rules.

Regards,

Christer

Hi,

Regards,

Christer

Brian
>>       "CSeq": "1234<SP>INVITE"
>> ...will not (afaik) produce the same signature value as:
>>
>> {
>>       "CSeq": "1234<SP><SP><SP>INVITE"
>> }
>
> Correct.
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 1 Jun 2016 18:19:38 +0000

This may then be a confusion that has crept in over the many steps we've taken in transition to PASSporT, but the original intention was for the ouri/duri not to contain parameters or other component of the SIP URI apart from the scheme, the user part, the @ sign, and the host part. Indeed, a call recently came from Cullen to consider just using an 822 email-style identifier without the scheme for better compatibility with WebRTC and through gateways. Whatever we end up using for ouri/duri, it should handle case sensitivity and so on.

But again - this is a separate issue from the one Chris was trying to raise.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 1, 2016 at 10:23 AM
To: Jon Peterson <[email-masked]<mailto:[email-masked]>>, Brian Rosen <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>
Cc: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: RE: [stir] 4474bis identity header - full JWT by default vs canon

Hi,

>or the contents of the "info" parameter of Identity, or what have you. Since "iat" is used instead of the Date header field value, even that has no whitespace concerns.

True. And, as “iat” is carried as a JWT claim, it can’t be “legally” modified using the SIP encoding rules.

Regards,

Christer

Hi,

Regards,

Christer

Brian

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Jun 2016 07:12:23 +0000

Hi,

I think the encoding issue IS related to Chris’s question – assuming the question was whether to include the JWT claims :)

Including the claims in the JWT will show exactly what was used to calculate the signature . Then, when comparing the claims to the associated SIP header field values, endpoints can check whether any deviations is because of encoding differences, or whether the compared values are actually different.

Otherwise, we need to make sure that the sender and the receiver will use exactly the same values for calculating the signature. For SIP-URIs we can probably use the RFC 3261 canonicalisation rules for doing that.

Just one question: are there other JWT use-cases where the claims aren’t included? Is it a valid JWT? Will off-the-shelf decoders be able to handle such JWTs?

Regards,

Christer

From: Jon Peterson <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 1 June 2016 at 21:19
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, Brian Rosen <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>
Cc: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon

Jon Peterson
Neustar, Inc.

Hi,

Regards,

Christer

Hi,

Regards,

Christer

Brian

---

From: Chris Wendt <[email-masked]>
Date: Thu, 2 Jun 2016 07:40:10 -0400

Hi Christer,

Canonicalization rules in rfc4474bis are defined to either reconstruct or verify values in the claim based on whether you use canon in identity header or not.  This was the intent of the original question and coming up with more consensus on what folks think should be default.

To address your specific concerns, 
otn and ouri are intended to be about identity assertion, not SIP header syntax validation.

For telephone identities, it should be clear that otn/dtn should be used, this is what rfc4474bis defines. 

Beyond rfc4474bis, I would ask if folks think the reference to RFC3986 in PASSporT draft is enough to avoid confusion for ouri and duri general URI scheme/user/domain as Jon describes.  I think so, but willing to reconsider more text to clarify further.

Additionally going forward, I would suspect there will likely be other higher level documents that may describe specific URI usage either in webrtc or non-telephone identity SIP deployments or XMPP or other domains, so i think we are ok personally.

-Chris

> On Jun 2, 2016, at 3:12 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> From: Jon Peterson <[email-masked] <mailto:[email-masked]>>
> To: Christer Holmberg <[email-masked] <mailto:[email-masked]>>, Brian Rosen <[email-masked] <mailto:[email-masked]>>, Russ Housley <[email-masked] <mailto:[email-masked]>>
> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> From: Christer Holmberg <[email-masked] <mailto:[email-masked]>>
> To: Jon Peterson <[email-masked] <mailto:[email-masked]>>, Brian Rosen <[email-masked] <mailto:[email-masked]>>, Russ Housley <[email-masked] <mailto:[email-masked]>>
> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
>> From: stir <[email-masked] <mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked] <mailto:[email-masked]>>
>> To: Brian Rosen <[email-masked] <mailto:[email-masked]>>, Russ Housley <[email-masked] <mailto:[email-masked]>>
>> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
>>> From: Brian Rosen <mailto:[email-masked]>
>>> Sent: 01/06/2016 18:59
>>> To: Russ Housley <mailto:[email-masked]>
>>> Cc: Christer Holmberg <mailto:[email-masked]>; IETF STIR Mail List <mailto:[email-masked]>
>>> > On Jun 1, 2016, at 11:39 AM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
>>> > 
>>> > 
>>> > [email-masked] <mailto:[email-masked]>
>>> > https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>_______________________________________________
> stir mailing list
> [email-masked]

---

From: Russ Housley <[email-masked]>
Date: Thu, 23 Jun 2016 17:12:17 -0400

I think that the stir-passport document meets all of the needs for
STIR.  However, I do not think that the stir-passport document has
enough information in it to help a developer use the PASSporT
framework with other applications.  I hope the addition of a bit
more information can resolve this issue.

Since the stir-passport document meets all of the needs for
STIR, I do not think this should delay the start of Working
Group Last Call on this document.

In Section 4.3, the stir-passport document says:

> Some applications may want to use the mechanism of the PASSporT
> digital signature that is not a superset of the base set of claims of
> the PASSporT token as defined in Section 3.

I do not understand this sentence.  Please explain it.

I can imagine that other applications may want to generate PASSporT
objects that are not a strict superset of the base set of headers and
claims defined in Section 3.  What does such an application need to
specify?  We get a hint in the next couple of sentences.

> Rather, a specification
> may use PASSporT with its own defined set of claims.

> In this case, the specification SHOULD define its own MIME media type
> [RFC2046] in the "Media Types” registry [IANA.MediaTypes].

I think that this means:

"Such applications of PASSporT may want to operate from
an entirely different set of claims.  Those PASSporT-using
applications may define their own set of claims by registering
a new MIME media type in the "Media Types" registry.”

I do not think that we can use normative language here.

This section goes on to say:

> The MIME
> subtype SHOULD start with the string "passport-" to signify that it
> is related to the PASSporT token.  For example, for the "foo"
> application the MIME type/sub-type could be defined as "application/
> passport-foo".

I think tho part needs to be cast as advice to the developers on
future PASSporT-using applications.

Can we offer any advice to the developer to help them decide when it is
necessary to use an alternate set of claims?  Also, can we offer any
advice regarding the properties that are needed to determine if an
alternate claim set meets the security requirements?  For example,
during the development of STIR we wanted to prevent cut-and-paste
attacks.

Are there any implications on interoperability for adopting a different
set of claims?

Can we offer any guidance that tells the developer when it would
be better to start fresh with JOSE JWS instead of trying to adjust
PASSporT?  In other words, where should one try to apply the
PASSporT framework, and where should one not bother.

Russ

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 26 Jun 2016 14:57:08 +0000

I agree that illustrating other applications, such as GETS, is needed

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Thursday, June 23, 2016 5:12 PM
To: IETF STIR Mail List <[email-masked]>
Subject: [stir] Using PASSporT with things other than STIR

I think that the stir-passport document meets all of the needs for STIR.  However, I do not think that the stir-passport document has enough information in it to help a developer use the PASSporT framework with other applications.  I hope the addition of a bit more information can resolve this issue.

Since the stir-passport document meets all of the needs for STIR, I do not think this should delay the start of Working Group Last Call on this document.

I can imagine that other applications may want to generate PASSporT objects that are not a strict superset of the base set of headers and claims defined in Section 3.  What does such an application need to specify?  We get a hint in the next couple of sentences.

> [RFC2046] in the "Media Types" registry [IANA.MediaTypes].

I think that this means:

"Such applications of PASSporT may want to operate from an entirely different set of claims.  Those PASSporT-using applications may define their own set of claims by registering a new MIME media type in the "Media Types" registry."

This section goes on to say:

> The MIME
> subtype SHOULD start with the string "passport-" to signify that it is 
> related to the PASSporT token.  For example, for the "foo"

I think tho part needs to be cast as advice to the developers on future PASSporT-using applications.

Can we offer any advice to the developer to help them decide when it is necessary to use an alternate set of claims?  Also, can we offer any advice regarding the properties that are needed to determine if an alternate claim set meets the security requirements?  For example, during the development of STIR we wanted to prevent cut-and-paste attacks.

Are there any implications on interoperability for adopting a different set of claims?

Can we offer any guidance that tells the developer when it would be better to start fresh with JOSE JWS instead of trying to adjust PASSporT?  In other words, where should one try to apply the PASSporT framework, and where should one not bother.

Russ

---

From: Richard Shockey <[email-masked]>
Date: Sun, 26 Jun 2016 11:35:50 -0400

+1 to both Russ and Martin.

Its vitally important to have clear examples in the text to guide the vendor community on what to expect.  

I’m personally getting several questions on production and implementation roadmap issues and some of us will have to begin briefing the NRA’s. 

I have no doubt there will be a need for some form of STIR-PASSporT profile once we can begin testing and deployment, but that is best handled in other forums.

— 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

On 6/26/16, 10:57 AM, "stir on behalf of DOLLY, MARTIN C" <[email-masked] on behalf of [email-masked]> wrote:

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Thursday, June 23, 2016 5:12 PM
To: IETF STIR Mail List <[email-masked]>
Subject: [stir] Using PASSporT with things other than STIR

I think that this means:

Russ