Re: [stir] Review of: draft-ietf-stir-passport-05

[Dave Crocker <[e-mail]>]

Chris,

Thanks for the followup.  Pruned responses to responses, below...

\
On 8/22/2016 10:58 AM, Chris Wendt wrote:
>> Detailed Comments -----------------
>>> STIR
>>> C. Wendt Internet-Draft
>>> Comcast Intended status: Standards Track
>>> J. Peterson Expires: January 23, 2017
>>> Neustar Inc. July 22, 2016
>>>
>>>
>>> Persona Assertion Token draft-ietf-stir-passport-05
>>>
>>> Abstract
...
>> Is the timestamp the basis of claiming non-repudiation?
>
> Partially, depending on your interpretation of how non-repudiation is
> achieved.  The digital signature based on a certificate is the
> non-repudiation of the original assertion and signing of the token.

That seems to equate authentication with non-reputation of originator. 
But they aren't the same.

 
http://security.stackexchange.com/questions/6730/what-is-the-difference-between-authenticity-and-non-repudiation

Worse, the opening sentence above, means that there is no way to know 
what the term applies to or how to validate its use.

At the least, a technical specification should use terms of art 
precisely and should provide enough detail so there is reliable, 
cross-reader understanding of its meaning and appropriateness in the 
document.

When the term refers to something that is foundational-but-partial, such 
as working 'in support of' something else that is detailed outside of 
the specification or hasn't even been detailed anywhere, then there 
needs to be text that explains the basis of that support.

For example, authentication of an identifier used in an email 'supports' 
the development of accurate and reliable reputation assessment for mail 
associated with the identifier.  A specification for authentication that 
makes this assertion but does not specify the detail for achieving that 
use needs to explain the claim, such as:  It does that by ensuring that 
the identifier's use is only by authorized entities, thereby eliminating 
the reputation analysis 'noise' from unauthorized use of the identifier 
in messages.

The current spec needs to similarly explain/justify a claim of use for 
non-reputation, but with something more substantive and reliable than 
"depending on your interpretation".  To the extent that it's useful in 
some cases of non-repudiation and not others, there should be an 
explanation of which cases it helps and how.


> The timestamp and including the destination identity adds the ability
> to further validate that there wasn’t someone illegitimate that
> simply replayed the sending of the token.

My understanding is that a replay attack is quite different from 
non-repudiation protection.  So the text should not conflate the two.


>>> repudiation the sender of and authorization to send information
>>> related to the originator of personal communications.  A
>>
>> 'info related to'... what does this mean?
>
> Yes this was a bit too broad and the abstract text wasn’t updated
> when the scope was reduced.
>
> replaced with: 'non-repudiation the author of the token, their
> authority to author the token and, minimally, the asserted
> originating identity or persona contained within the token
> corresponding specifically to the originator of personal
> communications'

My guess is that all of the above fall under authentication, not 
non-repuduation.  If my guess is wrong, it really would help to see a 
careful explanation of how it is non-repudiation rather than authentication.



>>> This document defines a common method for creating and validating
>>> a
>>
>> [common] delete
>
> fixed
>
>>
>>> token that cryptographically verifies an originating identity,
>>> or more generally a URI or application specific identity string
>>
>> 'identity string'?  what does this mean?
>>
>> 'app string id'? what does this mean?
>
> Removed and replaced with 'URI or telephone number'

So this seems like a good place to raise this basic question:  I thought 
all of the strings that were to be used at 'identity' strings started as 
URIs, albeit with some variations on the type of URI.

Also, there is the continuing point that has been repeatedly stressed 
that STIR's current goal is telephone numbers, not other forms of 
addressing.


>>> representing the originator of personal communications.  Through
>>> extended profiles other information relevant to the personal
>>> communications can also be attached to the token.  The primary
>>> goal of PASSporT is to provide a common framework for signing
>>> persona
>>
>> What is a 'persona'?  Where is this construct introduced or cited
>> and explained?
>
> ‘persona’ replaced with 'originating identity'
>
>>
>> 'profiles'?  Where is this construct introduced or cited and
>> explained?
>
> replaced with 'Through extensions defined in this document'

Normally, when extensibility is permitted, a base document like this 
defines the extensibility mechanism and might or might not /also/ give 
an initial set of extensions.

(In which case, these really are 'options' and not 'extensions', but 
yes, that's just quibbling...)

In any event, the reference should point to where the extensions or 
extensibility mechanism are specified.



>>> however this is intentionally out of scope for this document.
>>>
>>> Note: As of the authoring of this document,
>>> [I-D.ietf-stir-rfc4474bis] provides details of how to use
>>> PASSporT within SIP signaling for the signing and verification of
>>> telephone numbers.
>>
>> remove Note.  Or make it a note to RFC Editor to remove it, or
>> rephrase so it's useful 10 years from now.
>
> Would probably like a reference here, don’t want to just remove.

Why?  It's an uplink reference.  This is a component system used by 
rfc4474bism.  So the uplink confuses the relationship and messes with 
the clean, subsystem interface.



>>> 2.  Token Overview
>>>
>>> Tokens are a convenient way of encapsulating information with
>>
>> Why?  What are the alternatives?  Why is this the starting point?
>>
>>
>>> associated digital signatures.  They are used in many
>>> applications
>>
>> Such as?
>>
>> Anyhow, this section seems to take the construct of 'token' as
>> being an established term of art.  It isn't.  Or, at least, I've no
>> idea what is meant here that distinguishes a token from anything
>> else, such as other forms of encapsulation.  Say/cite what a token
>> is, if it is such a distinctive thing.  Say/cite how it differs
>> from alternatives, if its superiority is going to be touted.
>>
>>
>>> that require authentication, authorization, encryption, non-
>>> repudiation and other use cases.  JSON Web Token (JWT) [RFC7519]
>>> and JSON Web Signature (JWS) [RFC7515] are designed to provide a
>>> compact form for many of these purposes and define a specific
>>> method and syntax for signing a specific set of information or
>>> "claims" within the token and therefore providing an extensible
>>> set of claims. Additionally, JWS provides extensible mechanisms
>>> for specifying the method and cryptographic algorithms used for
>>> the associated digital signatures.
>>
>> Note that there is nothing in the above text that actually explains
>> what a token is or how it differs from things that aren't tokens.
>
> I would challenge the fact that ‘token’ is a term of art, but i
> suppose maybe it depends on what crowd you run with.  In either case,
> I defined it as a canonical string object at the beginning of the
> document.

If it is not a term of art, then what does it mean and why is it used? 
That is, it is used here as if it has distinctive meaning -- even at the 
level of being part of a section title! -- but the meaning isn't provided.


>>> 3.1.3.  "x5u" (X.509 URL) Header Parameter
>>>
>>> As defined in JWS, the "x5u" header parameter is used to provide
>>> a URI [RFC3986] referring to the resource for the X.509 public
>>> key certificate or certificate chain [RFC5280] corresponding to
>>> the key
>>
>> So this service uses a classic X.509 authentication hierarchy?
>> That's a key design point, only mentioned in a third-level
>> section.
>
> clarified this in overview
>
>>
>>
>>> used to digitally sign the JWS.  Note: The definition of what the
>>> URI represents in terms of the actor serving the X.509 public key
>>> is out
>>
>> 'actor serving the X.509 public key' ? what does that mean?
>
> removed
>
>>
>>> of scope of this document.  However, generally this would
>>> correspond to an HTTPS or DNSSEC resource with the guidance that
>>> it MUST be a
>>
>> [a] remove
>
> fixed
>
>>
>>> TLS protected, per JWS spec.
>>
>> This /object/ specification (that is transport independent)
>> dictates /transport/ security???  This is probably wrong, but at
>> least needs careful explanation.
>>
>
> This is mostly a comment towards security consideration
> recommendation.  I could remove the comment if it’s bothering folks.

For specification of a discrete component like this, which should be 
entirely independent of lower-level transport, etc. issues, I think the 
legitimate concern is noting that nature of sensitive information is 
carries and the need to protect that information 'appropriate', but to 
treat or state that the details of that protection are outside the scope 
of this specification.



>>> 3.2.1.  JWT defined claims
>>
>> When something like this is imported from another spec, there needs
>> to be a precise pointer to the specific part of the spec defining
>> it.
>
> This was the text provided by Ted based on discussion in Berlin, but
> beyond that i’m not seeing what isn’t specific enough.

iat - rfc7519, section 4.1.6, as I noted.

etc.

In other words, try to never require the reader to search around an 
entire document for the information being imported or referenced.



>>> 3.2.2.1.  Originating and Destination Identity Claims
>>>
>>> Baseline PASSporT defines claims that convey the identity of the
>>
>> "Baseline PASSporT defines claims" ?  First reference in a
>> 4th-level section???
>
> Removed baseline
>
>>
>>
>>> origination and destination of personal communications.  There
>>> are
>>
>> 'personal'?  so this can't be used by and between companies?
>> Really, there is nothing about any of this that pertains to the
>> type of users or even the content of the communication.
>
> defined ‘personal communications'
>
>>
>> What is the exact definition or origination and destination?  For
>> example, there is an important distinction between the person
>> making a call vs. the device they are using, versus the provider
>> they are going through.  Which is meant here and how is the reader
>> to know? (cf, call for a terminology section.)
>
> we don’t want to make the distinction here, it’s only about the
> identity, URI or TN.  whether device or network.  we don’t want to
> predetermine what the end to end architecture is, this is protocol
> only.

origination and destinction are extremely important terms of art for 
STIR and for this specification.  if they have no meaning, don't use 
them.  if they have to be used, they need to be carefully defined, 
either here or in a cited document.


>>> two claims that are required for PASSporT, the "orig" and "dest"
>>> claims.  Both "orig" and "dest" should have values that are JSON
>>> objects that include identities represented by key value pairs,
>>> where
>>
>> 'key value pairs' aren't 'claims'?
>>
>> should and not must? why?
>>
>
> changed to MUST and clarified
>
>>
>>> the key represents an identity type and the value is the
>>> identity string.  Currently, these identities can be represented
>>> as either
>>
>> So, there is expectation of other types?  There needs to be a
>> pointer to an IANA registry.
>
> we do have IANA request for these types, will add text once i figure
> out how to point to that
>
>>
>>
>>> telephone numbers or Uniform Resource Indicators (URIs).  The
>>> definition of how telephone numbers or URIs and examples are
>>> provided below.
>>>
>>> The "orig" JSON object MUST only have one key value pair
>>> representing the asserted identity of any type (currently either
>>> "tn" or "uri") of the originator of the personal communications
>>> signaling.
>>>
>>> The "dest" JSON object MUST have at least have one key value
>>> pair, but could have multiple identity types (i.e. "tn" and/or
>>> "uri") but only one of each.  Additionaly, in the case of "dest"
>>> only, the identity type key value MUST be an array signaled by
>>> standard JSON brackets, even when there is a single identity
>>> value in the identity type key value.
>>>
>>> 3.2.2.1.1.  "tn" - Telephone Number identity
>>
>> A document that uses five-levels of section numbering warrants
>> reconsideration of its structure.
>
> fair point, looking for suggestion

My personal style is to try to have at most 3 levels, with the table of 
contents showing only the first two.  OVerall it seems to be cleaner, 
but yeas, that's purely a matter of taste (although there are also some 
human factors cognitive loading issues when there are more than 3 levels 
in a structure...)

(Re-)organzing things to fit that model sometimes requires creativity.

But since you asked...


  1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  2.  PASSporT Token Overview . . . . . . . . . . . . . . . . . . .   3

  3.  PASSporT Header . . . . . . . . . . . . . . . . . . . . .   4
        3.1.1.  "typ" (Type) Header Parameter . . . . . . . . . . . .   4
        3.1.2.  "alg" (Algorithm) Header Parameter  . . . . . . . . .   4
        3.1.3.  "x5u" (X.509 URL) Header Parameter  . . . . . . . . .   4
  4  PASSporT Payload  . . . . . . . . . . . . . . . . . . . .   5
        3.2.1.  JWT defined claims  . . . . . . . . . . . . . . . . .   5
          3.2.1.1.  "iat" - Issued At claim . . . . . . . . . . . . .   5
        3.2.2.  PASSporT specific claims  . . . . . . . . . . . . . .   5
          3.2.2.1.  Originating and Destination Identity Claims . . .   5
          3.2.2.2.  "mky" - Media Key claim . . . . . . . . . . . . .   7
      3.3.  PASSporT Signature  . . . . . . . . . . . . . . . . . . .   8
  5.  Extending PASSporT  . . . . . . . . . . . . . . . . . . . . .   8
      4.1.  "ppt" (PASSporT) header parameter . . . . . . . . . . . .   8
      4.2.  Extended PASSporT Claims  . . . . . . . . . . . . . . . .   9
  6.  Deterministic JSON Serialization  . . . . . . . . . . . . . .   9
      5.1.  Example PASSport deterministic JSON form  . . . . . . . .  10
  7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
      6.1.  Avoidance of replay and cut and paste attacks . . . . . .  10
      6.2.  Solution Considerations . . . . . . . . . . . . . . . . .  10
      6.3.  Privacy Considerations  . . . . . . . . . . . . . . . . .  11


For deeper subsections, consider converting them to a labeled hanging 
indent.  This especially works when there's already a convenient label, 
like 'iat'.

Lots of small subsections tends to break up the reading.  Hanging 
indents don't.


>>>
>>> If the originating or destination identity is a telephone number,
>>> the key representing the identity should be "tn".
>>
>> should and not must???  why?
>
> fixed
>
>>
>>
>>> Telephone Number strings for "tn" MUST be canonicalized according
>>> to the procedures specified in [I-D.ietf-stir-rfc4474bis] Section
>>> 7.2.
>>
>> Actually, this dependency on 4474bis seems odd.
>>
>> Given that the phone number construct is at the core of the work
>> here and this is the essential data object, and this object is
>> presumably intended for use outside of 4474bis, I'd expect that
>> canonicalization algorithm to be here.
>>
>> If 4474 needs to cite/use the algorithm, it can cite here, which it
>> already will have to do.  There is no other normative use of 4474
>> in this document.
>>
>
> needs discussion

oh goodie.



>>> 3.2.2.1.2.  "uri" - URI identity
>>>
>>> If any of the originating or destination identities is of the
>>> form URI, as defined in [RFC3986], the key representing the
>>> identity should be "uri" URI form of the identity.
>>
>> should and not must?  why?
>
> fixed
>
>>
>>
>>> 3.2.2.1.3.  Future identity forms
>>>
>>> We recognize that in the future there may be other standard
>>> mechanisms for representing identities.  The "orig" and "dest"
>>> JSON
>>>
>>>
>>>
>>>
>>> Wendt & Peterson        Expires January 23, 2017
>>> [Page 6]
>>>
>>> Internet-Draft                  PASSporT
>>> July 2016
>>>
>>>
>>> objects with "tn" and "uri" allow for other identity types with
>>> unique keys to represent these forms.
>>
>> Recognition is dandy, but where is the specification detail to
>> support the extensibility?
>
> clarified text
>
>>
>>
>>> 3.2.2.1.4.  Examples
>>
>> *** Explain these examples, so they aren't merely syntax detail
>> ***
>>
>>
>>> Single Originator to Single Destination example:
>>>
>>> { "dest":{"uri":["sip:[e-mail]"]}, "iat":"1443208345",
>>> "orig":{"tn":"12155551212"} }
>>>
>>> Single Originator to Multiple Destination Identities example:
>>>
>>> { "dest":{ "tn":["12125551212"], "uri":["sip:[e-mail]",
>>> "sip:[e-mail]"] }, "iat":"1443208345",
>>> "orig":{"tn":"12155551212"} }
>>>
>>> 3.2.2.2.  "mky" - Media Key claim
>>>
>>> Some protocols that use PASSporT convey hashes for media
>>> security keys within their signaling in order to bind those keys
>>> to the identities established in the signaling layers.  One
>>> example would be the DTLS-SRTP key fingerprints carried in SDP
>>> via the "a=fingerprint" attribute; multiple instances of that
>>> fingerprint may appear in a single SDP body corresponding to
>>> difference media streams offered.
>>
>> difference -> different?
>>
>> The above text belongs elsewhere, explaining the overall set of
>> capabilities, use cases, and the like  In a definitions section
>> like this, focus on definitions, not discussions about use.
>>
>> First use of 'SDP', with no explanation of its meaning.
>
> Added citation
>
>>
>> 'DTLS-SRTP' citation?
>>
>> And again, how does this citation slip into a transport-independent
>> object signing spec?
>
> Meant to be a useful/likely used example.

Well, I fear it's a relatively esoteric reference, so that it probably 
needs to assume less familiarity by the reader, which is to say the 
example needs to explain itself more.



>>> 4.2.  Extended PASSporT Claims
>>>
>>> Future specifications that define such extensions to the
>>> PASSporT
>>
>> [Future] remove
>>
>> [such] remove.  there's no context for it.
>
> removed
>
>>
>>
>>> mechanism MUST explicitly designate what claims they include
>>> beyond
>>
>> designate -> specify  (it's defining, not appointing)
>
> fixed
>
>>
>>
>>> the base set of claims from this document, the order in which
>>> they will appear, and any further information necessary to
>>> implement the extension.  All extensions MUST incorporate the
>>> baseline JWT elements specified in Section 3; claims may only be
>>> appended to the claims
>>
>> If all extensions include the baseline, then 'must incorporate' is
>> an odd way to say that
>
> changed to include
>
>>
>> This seems best and first handled by earlier in the spec, by
>> providing a syntax (and text) that shows the base set and then an
>> optional extended set.  With that setup, it is clear that
>> extensions are always /in addition to/ the base.
>
> JSON sort of provides this capability inherently, so would prefer to
> keep it simple rather than adding more protocol.

The 'sort of' does not encourage confidence about the resolution of this 
point...




>> The JSON object MUST follow the rules for the construction of
>>> the thumbprint of a JSON Web Key (JWK) as defined in [RFC7638]
>>> Section 3. Each JSON object MUST contain no whitespace or line
>>> breaks before or after any syntactic elements and with the
>>> required members ordered lexicographically by the Unicode
>>> [UNICODE] code points of the member names.
>>
>> mumble.
>
> ?

I was reacting the to the redundant specification here, as well as to 
its being in prose that gets a bit complicated.  (Humans process 
negation and discussion worse than conjunction.)

Basically, this spec should not be repeated technical details that are 
being specified elsewhere and used here.  They should be be reference.



>>> 5.1.  Example PASSport deterministic JSON form
>>>
>>> For the example PASSporT Payload shown in Section 3.2.2.2, the
>>> following is the deterministic JSON object form.
>>>
>>> {"dest":{"uri":["sip:[e-mail]"],"iat": 1443208345,"mky"
>>> :[{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442
>>> CD54F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F8
>>> 2183B540212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}],
>>> "orig":{"tn":"12155551212"}}
>>
>> Perhaps explain the steps followed to produce this? Perhaps show
>> the intermediate forms?
>>
>
> will discuss the need for more explicit instructions, to me, it’s
> following the spec, but could improve if folks think it’s necessary.

I think the main concern I was expressing was that it should a result, 
without commentary, and without showing the intermediate steps.  As 
such, the reader learns relatively little from the example, IMO.



>>> 7.  Security Considerations
>>>
>>> 7.1.  Avoidance of replay and cut and paste attacks
>>>
>>> There are a number of security considerations for use of the
>>> token
>>
>> I suspect they are not 'security considerations' as much as
>> 'mechanisms' or 'provisions'
>>
>>
>>> for avoidance of replay and cut and paste attacks.  PASSporT
>>> tokens must be sent along with other application level protocol
>>> information
>>
>> Huh?  You are trying to dictate application-level transport
>> behavior?
>>
>> This smacks of layer/scoping violation.
>
> changed to should and removed along, but don’t want to remove this
> consideration.
>
>>
>>
>>> (e.g. for SIP an INVITE as defined in [RFC3261]).  There should
>>> be a link between various information provided in the token and
>>> information provided by the application level protocol
>>> information.
>>
>> Why?
>
> explained
>
>>
>>
>>> These would include:
>>>
>>> o  "iat" claim should closely correspond to a date/time the
>>> message
>>
>> The semantics of iat are defined earlier. Either there is
>> compliance or there isn't. The discussion here, therefore, should
>> probably say something like "a valid iat claim aids in detecting
>> re-use at a later time.”
>
> i am explaining the ‘why’ here, added a sentence about validation and
> correlation to network time variances.
>
>>
>>
>>> was originated.  It should also be within a relative delta time
>>
>> What is a delta time?  How is the reader to know?  Where is it
>> defined? I suspect what is meant is that it's deviation from time
>> of origination should be small.  If this has a more precise
>> technical definition, then cite it.
>
> removed delta
>
>>
>>
>>> that is reasonable for clock drift and transmission time
>>> characteristics associated with the application using the
>>> PASSporT token.
>>>
>>> o  "dest" claim is included to prevent the ability to use a
>>> previously originated message to send to another destination
>>> party
>>
>> the ability to -> using  (or use of)
>
> fixed with ‘valid re-use'
>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Wendt & Peterson        Expires January 23, 2017
>>> [Page 10]
>>>
>>> Internet-Draft                  PASSporT
>>> July 2016
>>>
>>>
>>> 7.2.  Solution Considerations
>>>
>>> It should be recognized that the use of this token should not,
>>> in it's own right, be considered a full solution for absolute
>>> non- repudiation of the persona being asserted.  This only
>>> provides non- repudiation of the signer of PASSporT.  If the
>>> signer and the persona
>>
>> huh?  So the originator isn't really being validated, as
>> claimed???
>
> This is only a statement to recognize that you are only trusting the
> signer and certificate owner to tell the truth about the originating
> identity.  If you are familiar with how certificates work, this is an
> obvious statement, but just a word of consideration.

Start by saying the affirmative, so that the negative has a foundation.

For the current topic, the usual caveat language is along the lines that 
"authentication validates authorization to use the identifier, but does 
not imply any assessment about the reputation or safety of the actor 
using the identifier"  or somesuch...

While authentication does involve a kind of trust, using that word here 
usually confuses readers that it it has something to do with 'usage 
reputation' that is the derivative function after authentication.


>>> are not one in the same, which can and often will be the case in
>>> telecommunications networks today, protecting the destination
>>> party from being spoofed may take some interpretation or
>>> additional verification of the link between the PASSporT
>>> signature and the persona being asserted.
>>>
>>> In addition, the telecommunications systems and specifications
>>> that use PASSporT should in practice provide mechanisms for:
>>>
>>> o  Managing X.509 certificates and X.509 certificate chains to
>>> an authorized trust anchor that can be a trusted entity to all
>>> participants in the telecommunications network
>>
>> Touching this sort of topic is, at the very best, redundant with
>> specifications devoted to X.509. Just cite them and don't attempt
>> to repeat them.
>
> I see this as helpful, we can discuss if it’s not needed, but I
> recall being asked by working group to include text to inform the
> reader.
>
>>
>>> o  Accounting for entities that may route calls from other peer
>>> or interconnected telecommunications networks that are not part
>>> of the "trusted" communications network or may not be following
>>> the usage of PASSporT or the profile of PASSporT appropriate to
>>> that network
>>
>> Passport doesn't do calls.  Dictating activity involving calls is
>> out of scope.

While some of my comments in this subsection can be class as matters of 
taste or an opinion about risks of redundant text, this here point is 
about language that is simply wrong.


>> On the other hand, perhaps this qualifies for a discussion about
>> transferring passport objects across administrative (trust) domain
>> boundaries?
>>
>> At best, this section seems to be trying to compensate for the lack
>> of a framework discussion about the problem domain and the
>> practical uses of the various specifications being produced.
>
> similar to above comment, this is meant to be a cautionary statement
> and something to consider if you are an implementer.  If you
> understand the limits of what X.509 based certificate signing and PKI
> can represent in terms of trust, these are obvious statements, but I
> think it’s good to include none-the-less.

In other words, you are trying to provide a tutorial about X.509 rather 
than discussion about Passport.




d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net