Re: [stir] Brief review of draft-ietf-stir-rfc4474bis-08

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

Thanks Alan, these are useful comments.

I can try to clarify the language a bit about the authentication service.
As RFC4474bis says (in language it inherits from RFC4474), we based the
authentication service on the abstract "location service" concept in
baseline RFC3261 which is similarly and intentionally vague in its
relationship to any given SIP component. I am aware that some
implementations of RFC4474bis are already decomposing the authentication
service into a stub in the proxy that contacts a RESTful web service which
in turn generates the PASSporT object and passes it back over HTTP to the
proxy. I do want to make sure any language we add doesn't rule out
implementations like that, which seem like useful ones.

I have been hearing that we need to put in some clearer language about 438
and other response codes that are grandfathered in from RFC4474, in
particular to explain how they might differ now. I think the semantics is
largely the same, but there are a few issues: e.g., we don't want a
response code status line for "Bad Identity-Info" when in fact the
Identity-Info header has been deprecated in favor of the "info="
parameter. The next revision will clean those things up a bit.

The issue of distributing private keys to virtual hosting systems and so
forth is a known hard problem, and scoping the credential solely to SIP
doesn't really give us much relief. I'm holding out for a general
solution, possibly as a result of the LURK BoF we saw in Buenos Aires.

Your smaller fixes I'll fix.

Jon Peterson
Neustar, Inc.

On 4/30/16, 1:35 PM, "stir on behalf of Alan Ford" <[e-mail]
on behalf of [e-mail]> wrote:

>Hi all,
>
>At IETF95, Robert suggested I should review draft-ietf-stir-rfc4474bis
>from an implementer's point-of-view... So I have :)  I was coming at this
>completely fresh - I had never read any of the document before and had
>very limited background on this topic... And I must first say it's a
>really accessible document, very easy to follow and understand. I have
>only a few very minor comments on clarity:
>
>- Section 4, it took me a while to realise that the authentication
>service typically sat as a component of Alice's home SIP proxy. Whilst
>obvious once a bit more context was available, I'd suggest adding a
>sentence at the end of paragraph 5 (The proxy, ...) that reads something
>like "The proxy then forwards the request under normal to Bob's domain".
>
>- Section 5.1, Step 4, paragraph 3... Similarly, just insert "at the
>receiver" after "In some cases, a request sent through an authentication
>service will be rejected by the verification service" - helps make the
>process a little clearer.
>
>- Section 5.2, it is not clear if there should be anything different in
>the 488 for no Identity header, and unsupported ppt?
>
>- Section 6.3, typo "bae64"
>
>- Section 6.3, "result of the JSON object construction process", would it
>not be clearer to say "the PASSporT object" or similar? There is a clear
>definition of "canon" in the last paragraph of Section 8 which could be
>used earlier too.
>
>- Section 6.4, "URL of the form" ? Is form the right word for
>content-type here?
>
>- Section 6.4 references "this registry" -> what registry? Maybe this
>should reference IANA section? Also the ref to RFC7519 to define "RS256"
>should probably occur here.
>
>- Section 7.2 - could the use of the key not in some way be restricted
>purely for use with SIP Identity? Therefore removing issues with giving
>it to a third-party service provider?
>
>- Section 12.1, paragraph 4: "The To helps" and "over the To" -> insert
>"header" after "To" for clarity since it scans really strangely otherwise!
>
>Cheers,
>Alan
>
>_______________________________________________
>stir mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/stir