Subject: Re: [stir] Shepherd comments: draft-ietf-stir-passport-shaken-03

From: Mary Barnes <[email-masked]>
Date: Fri, 12 Oct 2018 10:07:03 -0500

Hi STIR WG,

We've had some off list discussion between the authors and Robert.

Chris and I had proposed text something like the following for the security
section:

This document defines a new PASSporT [RFC 8225] extension.  In general the
considerations related to the security of the PASSporT are the same as
those described in RFC 8225.   Along with the “dest”, “orig” and “iat”
claims, this document includes defines two new claims in the SHAKEN
PASSport: ‘attest’ and ‘origid’.  These are informational elements that are
not dependent on or impact the original security properties of the core
PASSporT claims therefore no new security considerations are introduced.

Robert has proposed text something like the following:

This document defines a new PASSporT [RFC 8225] extension.  The

considerations related to the security of the PASSporT object itself

are the same as those described in RFC 8225.

RFC 8224 defines how to compare the values of the "dest", "orig" and

"iat" claims against fields in a SIP containing a PASSporT as part of

validating that request. The values of the new "attest" and "origid"

claims added by this extension are not used in such a validation

step. They are not compared to fields in the SIP message. Instead,

they simply carry additional information from the signer to the

consumer of the PASSport. This new information shares the same

integrity protection and non-repudiation properties as the base

claims in the PASSporT.

Note, however, that this additional information affects the semantics

of the PASSporT itself. In particular the "attest" claim provides

additional information about the quality of the assertion the signer

makes about the requester's authorization to use a particular calling

identity. The consumer of the PASSporT object can factor that quality

into its processing decisions as long as it understands the

extensions defined in this document. Should a PASSporT using this

extension arrive at an implementation unaware of the extension, the

additional claims will be ignored. Thus it is important that signers

only provide PASSporTs using this extension when semantics of the

assertions made by the base PASSporT hold true.

My view is that the "attest" and "origid" are purely informational claims
from a protocol perspective and don't have security implications - i.e.,
they're independent of any other fields in the SIP message.   The "attest"
claim can be used by an application at the calling party device to display
something reflecting an originating service provider's knowledge about (and
thus level of trust in) the identity of  the calling party  - e.g., a
calling party when a call comes through a gateway ("attest" = c) is likely
to be less trusted than one coming from a calling party known to the
originating service provider (e.g., one of their customers with an
"attest"=A ), so what gets displayed might be different - e.g., green check
mark versus warning.  And, the "origid" claim could be used for traceback.
 We don't have any text about potential uses for the information in this
STIR document, but it is described in ATIS-1000074 (and we will be adding a
link to that document in the references).   But, we say absolutely nothing
about the semantics with regards to the consumer of the PASSporT.   The
claims don't define anything prescriptive about how a call is handled in
the network or by the consumer.

We need WG feedback on this in order to progress the draft.  I'm okay with
Robert's suggested first 2 paragraphs, but I don't think the 3rd is
directly related to security considerations.

Regards,
Mary.

On Mon, Sep 24, 2018 at 1:51 PM Robert Sparks <[email-masked]> wrote:

> While performing the shepherd writeup, I notice the following things:
>
> 1) The document has no security considerations section. The document is
> so straightforward, I can understand (but shake my head at) the group
> missing that so far. The document really needs to say something here.
> While I don't expect it to be long, "introduces no new considerations"
> is clearly not right.
>
> 2) In section 9.2, say "Personal Assertion Token (PASSporT) Extensions
> registry" instead of "PASSporT Types registry" (to match what's at
> https://www.iana.org/assignments/passport/passport.xhtml .
>
> 3) Can (should?) we provide a stable link in the reference for
> ATIS-1000074?
>
> RjS
>
>

---

From: Chris Wendt <[email-masked]>
Date: Fri, 12 Oct 2018 11:21:33 -0400

I guess put another way, the addition of the new claims doesn’t alter the security properties of the verification of the claims and mechanisms defined in 8224/8225, which i think is what Robert’s second paragraph is saying.  

The new claims provide additional contextual information to the verifier, and we indeed want to make sure the claims are not altered in transit or replayed, etc, etc. but none of those security properties are changed based on the definition of the passport extension, so i would also agree the third paragraph is not necessary.  We are only stating what the extension mechanism is defined to do, if you don’t know how to handle the new claims in a passport extension, then you shouldn’t be looking at that identity header in the first place.  This is common to all extensions.

> On Oct 12, 2018, at 11:07 AM, Mary Barnes <[email-masked]> wrote:
> 
> Hi STIR WG,
> 
> Chris and I had proposed text something like the following for the security section:
>>> This document defines a new PASSporT [RFC 8225] extension.  In general the considerations related to the security of the PASSporT are the same as those described in RFC 8225.   Along with the “dest”, “orig” and “iat” claims, this document includes defines two new claims in the SHAKEN PASSport: ‘attest’ and ‘origid’.  These are informational elements that are not dependent on or impact the original security properties of the core PASSporT claims therefore no new security considerations are introduced.
> 
> My view is that the "attest" and "origid" are purely informational claims from a protocol perspective and don't have security implications - i.e., they're independent of any other fields in the SIP message.   The "attest" claim can be used by an application at the calling party device to display something reflecting an originating service provider's knowledge about (and thus level of trust in) the identity of  the calling party  - e.g., a calling party when a call comes through a gateway ("attest" = c) is likely to be less trusted than one coming from a calling party known to the originating service provider (e.g., one of their customers with an "attest"=A ), so what gets displayed might be different - e.g., green check mark versus warning.  And, the "origid" claim could be used for traceback.   We don't have any text about potential uses for the information in this STIR document, but it is described in ATIS-1000074 (and we will be adding a link to that document in the references).   But, we say absolutely nothing about the semantics with regards to the consumer of the PASSporT.   The claims don't define anything prescriptive about how a call is handled in the network or by the consumer.  
> 
> We need WG feedback on this in order to progress the draft.  I'm okay with Robert's suggested first 2 paragraphs, but I don't think the 3rd is directly related to security considerations. 
> 
> Regards,
> Mary. 
> 
> On Mon, Sep 24, 2018 at 1:51 PM Robert Sparks <[email-masked] <mailto:[email-masked]>> wrote:
> https://www.iana.org/assignments/passport/passport.xhtml <https://www.iana.org/assignments/passport/passport.xhtml> .
> 
> 3) Can (should?) we provide a stable link in the reference for ATIS-1000074?
> 
> RjS
>

---

From: Robert Sparks <[email-masked]>
Date: Fri, 12 Oct 2018 11:21:08 -0500

On 10/12/18 10:21 AM, Chris Wendt wrote:
> I guess put another way, the addition of the new claims doesn’t alter 
> the security properties of the verification of the claims and 
> mechanisms defined in 8224/8225, which i think is what Robert’s second 
> paragraph is saying.
>
> The new claims provide additional contextual information to the 
> verifier, and we indeed want to make sure the claims are not altered 
> in transit or replayed, etc, etc. but none of those security 
> properties are changed based on the definition of the passport 
> extension, so i would also agree the third paragraph is not necessary. 
>  We are only stating what the extension mechanism is defined to do, if 
> you don’t know how to handle the new claims in a passport extension, 
> then you shouldn’t be looking at that identity header in the first 
> place.  This is common to all extensions.
I'm not sure the last two sentences are correct. Can you point at text 
in 8224 or 8225 that supports "shouldn't be looking at that identity 
header in the first place"? If so, I think _this_ security 
considerations section should point to that. But I'm not finding any 
such text on a quick skim.

So unless I'm mis-remembering something, I believe I see things that say 
the opposite. Look at section 8.3 in RFC8225 and the end of section 9 of 
RFC8224. Specifically "Understanding an extension or new claims defined 
by the extension on the destination verification of the PASSporT is 
optional."

Thus I think this sentence in the third paragraph is factually correct: 
"Should a PASSporT using this extension arrive at an implementation 
unaware of the extension, the additional claims will be ignored. " And 
the ramifications of that should be highlighted. What I tried to 
reinforce with the rest of that paragraph is that the additional claims 
are not allowed to change (specifically, weaken) the semantic of the 
base claims. Reminding future signers of that seems prudent.

>
>
>> On Oct 12, 2018, at 11:07 AM, Mary Barnes <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi STIR WG,
>>
>>>>     This document defines a new PASSporT [RFC 8225] extension.In
>>>>     general the considerations related to the security of the
>>>>     PASSporT are the same as those described in RFC 8225. Along
>>>>     with the “dest”, “orig” and “iat” claims, this document
>>>>     includes defines two new claims in the SHAKEN PASSport:
>>>>     ‘attest’ and ‘origid’.These are informational elements that are
>>>>     not dependent on or impact the original security properties of
>>>>     the core PASSporT claims therefore no new security
>>>>     considerations are introduced.
>>>>
>> My view is that the "attest" and "origid" are purely informational 
>> claims from a protocol perspective and don't have security 
>> implications - i.e., they're independent of any other fields in the 
>> SIP message.   The "attest" claim can be used by an application at 
>> the calling party device to display something reflecting an 
>> originating service provider's knowledge about (and thus level of 
>> trust in) the identity of  the calling party  - e.g., a calling party 
>> when a call comes through a gateway ("attest" = c) is likely to be 
>> less trusted than one coming from a calling party known to the 
>> "attest"=A ), so what gets displayed might be different - e.g., green 
>> check mark versus warning.  And, the "origid" claim could be used for 
>> traceback.   We don't have any text about potential uses for the 
>> information in this STIR document, but it is described in 
>> ATIS-1000074 (and we will be adding a link to that document in the 
>> references).   But, we say absolutely nothing about the semantics 
>> with regards to the consumer of the PASSporT.   The claims don't 
>> define anything prescriptive about how a call is handled in the 
>> network or by the consumer.
>>
>> We need WG feedback on this in order to progress the draft.  I'm okay 
>> with Robert's suggested first 2 paragraphs, but I don't think the 3rd 
>> is directly related to security considerations.
>>
>> Regards,
>> Mary.
>>
>>     https://www.iana.org/assignments/passport/passport.xhtml ..
>>
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Chris Wendt <[email-masked]>
Date: Fri, 12 Oct 2018 15:00:46 -0400

This is described in Section 8.3 of RFC8225.

The thing i don’t agree with is the idea that you should pay attention to the base PASSporT claims and ignore the extension claims.  The base PASSporT claims are for supporting the security of the PASSporT object and claims to be associated with a particular call (replay attack, etc) and the extension is the real meaning of what information you are trying to portray in an extended PASSporT.  If you only intend the receiver to validate the calling identity, you should only send a base PASSporT, a PASSporT with only base claims.  It’s all or nothing, you either know how to interpret the PASSporT extension or not was the original intent.

> On Oct 12, 2018, at 12:21 PM, Robert Sparks <[email-masked]> wrote:
> 
> 
> 
> I'm not sure the last two sentences are correct. Can you point at text in 8224 or 8225 that supports "shouldn't be looking at that identity header in the first place"? If so, I think _this_ security considerations section should point to that. But I'm not finding any such text on a quick skim.
> 
> So unless I'm mis-remembering something, I believe I see things that say the opposite. Look at section 8.3 in RFC8225 and the end of section 9 of RFC8224. Specifically "Understanding an extension or new claims defined by the extension on the destination verification of the PASSporT is optional."
> 
> Thus I think this sentence in the third paragraph is factually correct: "Should a PASSporT using this extension arrive at an implementation unaware of the extension, the additional claims will be ignored. " And the ramifications of that should be highlighted. What I tried to reinforce with the rest of that paragraph is that the additional claims are not allowed to change (specifically, weaken) the semantic of the base claims. Reminding future signers of that seems prudent.
> 
>> 
>> 
>>> On Oct 12, 2018, at 11:07 AM, Mary Barnes <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi STIR WG,
>>> 
>>> https://www.iana.org/assignments/passport/passport.xhtml <https://www.iana.org/assignments/passport/passport.xhtml> ..
>>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: Robert Sparks <[email-masked]>
Date: Fri, 12 Oct 2018 14:35:16 -0500

Actually, I think the thing where I may be off-base is discussed in 
section 8.1, where it says

"Relying parties MUST fail to validate PASSporT objects containing an 
unsupported "ppt"."

Having found that again, I'm ok dropping the 3rd paragraph.

RjS

On 10/12/18 2:00 PM, Chris Wendt wrote:
> The thing i don’t agree with is the idea that you should pay attention 
> to the base PASSporT claims and ignore the extension claims.  The base 
> PASSporT claims are for supporting the security of the PASSporT object 
> and claims to be associated with a particular call (replay attack, 
> etc) and the extension is the real meaning of what information you are 
> trying to portray in an extended PASSporT.  If you only intend the 
> receiver to validate the calling identity, you should only send a base 
> PASSporT, a PASSporT with only base claims.  It’s all or nothing, you 
> either know how to interpret the PASSporT extension or not was the 
> original intent.
>
>> On Oct 12, 2018, at 12:21 PM, Robert Sparks <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>>> I guess put another way, the addition of the new claims doesn’t 
>>> alter the security properties of the verification of the claims and 
>>> mechanisms defined in 8224/8225, which i think is what Robert’s 
>>> second paragraph is saying.
>>>
>>> extension, so i would also agree the third paragraph is not 
>>> necessary.  We are only stating what the extension mechanism is 
>>> defined to do, if you don’t know how to handle the new claims in a 
>>> passport extension, then you shouldn’t be looking at that identity 
>>> header in the first place.  This is common to all extensions.
>> I'm not sure the last two sentences are correct. Can you point at 
>> text in 8224 or 8225 that supports "shouldn't be looking at that 
>> identity header in the first place"? If so, I think _this_ security 
>> So unless I'm mis-remembering something, I believe I see things that 
>> say the opposite. Look at section 8.3 in RFC8225 and the end of 
>> section 9 of RFC8224. Specifically "Understanding an extension or new 
>> claims defined by the extension on the destination verification of 
>> the PASSporT is optional."
>>
>> Thus I think this sentence in the third paragraph is factually 
>> correct: "Should a PASSporT using this extension arrive at an 
>> implementation unaware of the extension, the additional claims will 
>> be ignored. " And the ramifications of that should be highlighted. 
>> What I tried to reinforce with the rest of that paragraph is that the 
>> additional claims are not allowed to change (specifically, weaken) 
>> the semantic of the base claims. Reminding future signers of that 
>> seems prudent.
>>
>>>
>>>
>>>> On Oct 12, 2018, at 11:07 AM, Mary Barnes 
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>> Hi STIR WG,
>>>>
>>>>>>     ‘attest’ and ‘origid’.These are informational elements that
>>>>>>     are not dependent on or impact the original security
>>>>>>     properties of the core PASSporT claims therefore no new
>>>>>>     security considerations are introduced.
>>>>>>
>>>> trust in) the identity of  the calling party  - e.g., a calling 
>>>> party when a call comes through a gateway ("attest" = c) is likely 
>>>> to be less trusted than one coming from a calling party known to 
>>>> the originating service provider (e.g., one of their customers with 
>>>> an "attest"=A ), so what gets displayed might be different - e.g., 
>>>> green check mark versus warning. And, the "origid" claim could be 
>>>> used for traceback.   We don't have any text about potential uses 
>>>> for the information in this STIR document, but it is described in 
>>>> We need WG feedback on this in order to progress the draft.  I'm 
>>>> okay with Robert's suggested first 2 paragraphs, but I don't think 
>>>> the 3rd is directly related to security considerations.
>>>>
>>>> Regards,
>>>> Mary.
>>>>
>>>>     https://www.iana.org/assignments/passport/passport.xhtml..
>>>>