Re: [stir] Roman Danyliw's Discuss on draft-ietf-stir-passport-divert-08: (with DISCUSS and COMMENT)

["Peterson, Jon" <[e-mail]>]

Hi Roman,

Thanks for the notes on this; sorry for taking a while to get around to them.

    Roman Danyliw has entered the following ballot position for
    draft-ietf-stir-passport-divert-08: Discuss
    
    ----------------------------------------------------------------------
    DISCUSS:
    ----------------------------------------------------------------------
    
    Section 5.  The text notes that procedures for the authentication and
    verification service for the “div-o” claim will be “left to future work”.  Can
    the rational for this deferral be explained.  Creating an interoperable
    solution without this guidance seem challenging as it would be crucial guidance
    on processing this newly introduced claim.

This -08 text mostly resulted from a process matter. To get into the document history a bit, when we moved stir-oob off the Standards Track to an Informational in the late stages of its development, we still wanted "div" to be future-proof when/if standards-track work based on the OOB framework rolled around (like for example the new OOB servprovider draft in STIR). Our solution was to uplevel: to specify "div-o" as something not specifically coupled to OOB, but instead as a general mechanism that could be used by OOB or other protocols that might prefer to use nested "div-o" style PASSporTs. That isn't an entirely cynical move, as we anticipate that protocols other than SIP will use the PASSporT mechanism, and might want to use the nested approach of "div-o".

I think within those constraints, I can thread the needle with some useful text about the non-SIP AS/VS behavior associated with the creation of "div-o" PASSporTs in a way that makes no explicit reference to OOB as such, but would apply equally if say XMPP or RTCWeb or some similar mechanism wanted to make use of PASSporT and nested "div". I've added some text to this effect, which I hope is sufficient - let me know if it isn't.
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    Please respond to Phillip Hallam-Baker SECDIR review (thanks Phillip!)

Done.
    
    ** Section 4.1.  Per “Provided that these PASSporTs share the same "orig" and
    "dest" values, the retargeting entity's authentication service SHOULD generate
    only one "div" PASSporT”, why not  MUST here?  What’s the corner case?

One corner case I can imagine is where diverts from special-use PASSporTs need to be signed with a certificate issued by a one-off trust anchor. Say, due to the government policy constraints of the "rph" header or something similar, you need to sign a "div" for its PASSporT with a different credential than you would use to sign a "div" for ordinary carrier calls. Not a common case, but, I don't want to close the door on it.
    
    ** Section 4.2.  Per “However, note that in some use cases, including  certain
    ways that blind transfer is implemented, it is possible that an established
    call will be retargeted long after it has originally been placed, and
    verification services may want to allow a longer window for the freshness of
    the innermost PASSporT if the call is transferred from a trusted party.”, are
    there any recommendations or bounds that can be placed on the duration of this
    “longer window of freshness”?

Unfortunately, not ones that are immensely useful - maybe like 3 hours? Attended transfer services can be triggered any time into a call - if you've ever gone through escalation with a bank company customer service line, you've probably experienced multiple such transfers during a single call which begins with you being on hold for 45 minutes, and you can easily spend ten minutes talking to one agent before you end up on the line with another. I think the "trusted party" portion here is the significant bit - that relying parties should only accept these kinds of stale PASSporTs within a closed circle of trust. Still, calls don't last for like a week, so there must be some upper bound here. I can put in 3 hours as a soft recommendation, I guess, if it helps...
    
    ** Editorial Nit:
    
    -- Section 3. Typo. s/identifiier/identifier/
    
Fixed. Thanks!

Jon Peterson
Neustar, Inc.