[Sipbrandy] RFC4474bis impact on RFC4916 (Connected Identity)

[Adam Roach <[e-mail]>]

SIPBRANDY participants --

In Seoul, I took on an action item[1] to examine the interaction between 
RFC4474bis and the Connected Identity mechanism defined in RFC 4916. At 
a high level, the mechanism described in RFC 4916 withstands the changes 
detailed in RFC4474bis pretty well; however, I have identified two areas 
that will likely warrant an update to RFC 4916.

The examples in 4916 are rendered inaccurate by the 
non-backwards-compatible changes made to the Identity header field 
syntax as well as the deprecation of the Identity-Info header field. It 
is notable that 4916 took the extremely helpful step of including a 
private key as well as actually valid Identity header fields. If we 
believe these examples had value -- and I think that they did -- then we 
probably want to spin a minimally changed 4916 with updated example for 
this reason alone.

The other (more substantial) issue that I identified is, I think, a flaw 
in 4474bis itself, the correction of which may require a small but 
normative update in RFC4916.

In section 6.1.1 of draft-ietf-stir-rfc4474bis-15, there is a "SHOULD" 
strength normative requirement on identity services: if they send a 
non-full-form PASSporT object and consequently receive a 438 response, 
they "SHOULD retry the request with the full form."  Given that the 
nominal instance of an identity service is a SIP proxy, this is very 
much under-specified, and is likely to be interpreted by implementations 
in at least three different ways:

1. Re-send the exact same message with unchanged to-tag, from-tag,
    Call-ID, CSeq, and via branch parameter but a different Identity
    header field. This will cause properly implemented downstream nodes
    to detect the request as a retransmission, which means they'll
    resend the 438 even if the expanded Identity header field is
    sufficient to satisfy the verifier.
2. Re-send the same message with the same to-tag, from-tag, and
    Call-ID, but an updated CSeq. This will work at the receiving end,
    but the UAC that originated the request will be unable to match the
    resulting response to its corresponding request unless the proxy
    turns into a B2BUA and segregates the CSeq space.
3. Send the retried request as  "serial fork" by having an unchanged
    to-tag, from-tag, Call-ID, CSeq but different via branch parameter.
    If the verification service is acting as a B2BUA or is co-located
    with the receiving UAS, then (according to the procedure in RFC3261,
    section 8.2.2.2), the UAS MUST send a 482 response to the request.

Interpretations 1 and 2 aren't actually allowed behaviors for proxy 
servers (and don't work anyway), and interpretation 3 fails under many 
useful circumstances. It's also a bit non-obvious and more than a little 
inelegant.

The only solutions that I think have any real hope of working here 
require the originating UAC re-sending the request so that the identity 
service will be able to put a full PASSporT on it the second time. We 
can talk through how to make that work separately (on the STIR list), 
but any such solution will contravene normative language in RFC 4916:

    The mid-dialog request can be rejected in accordance with RFC 4474
    [3] if the UAS does not accept the connected identity.  If the UAC
    receives a 428, 436, 437, or 438 response to a mid-dialog request it
    SHOULD regard the dialog as terminated in the case of a dialog-
    terminating request and SHOULD take no action in the case of any
    other request.

So I think we want to fix 4474bis with regards to this "re-sending" 
mechanism, and then -- assuming the selected fix requires it -- update 
4916 to accommodate whatever 438 handing we select.

/a

____
[1] I also want to give credit to Gonzalo Camarillo for following 
through with the "bothering the crap out of Adam" action item detailed 
in the minutes, which he took quite seriously. :)