Re: [sipcore] Comments on draft-ietf-sipcore-sip-authn-02

Hi Dale,

Thanks for your review and comments.
Please, see my replies inline.

Regards,
 Rifaat

On Sun, Jun 10, 2018 at 5:18 PM Dale R. Worley <worley@ariadne.com> wrote:

> This is an interesting and important piece of work.  I've attempted to
> read earlier versions once or twice and never successfully understood
> it.  This version of the draft is more comprehensible than previous
> versions and seems to be on the right track, but there are a number of
> important issues that need to be addressed.  Trying to list them in
> order of importance:
>
> - All of the interactions with the "authorization server" are
> described as out of scope.  This is rather a problem, since all of the
> call flows that the document describes require the authorization
> server as an integral part of the flow.  If interacting with the
> authorization server is not standardized, then no interoperability has
> been defined in practice -- both the UA and the proxy must have
> special knowledge of the authorization server.  In practice, that
> means that all components of the system will have to be purchased from
> one vendor.
>
(As a consequence, the meaning of the Location header in the 401
> response (section 2.1.1) is not fixed -- the UA is expected to do
> something with the value of the header, but there is no specification
> of what that is.)
>
> The missing parts are the ones that use the existing OAuth 2.0 mechanism
defined in RFC6749.
I will try to add more details to make it clearer.

- The Security Considerations section does not describe whether and
> how the messages in the call flows need to be protected from
> eavesdropping.
>
> Yeah, I will add these details.

> - The document doesn't give a clear statement of which requests are
> authenticated, what guarantees the authentication provides, or how the
> call flows might be used in authorizing requests.  The only use of the
> authentication/authorization information specified in the document is
> SIP registration, but I suspect the intention is that SIP requests
> carrying authentication/authorization can be forwarded to other server
> entities, which can validate the AA information to determine whether
> to service the request.
>
> This part is out of scope for this document.
We had a long debate on the mailing list about this, so we left it for
future documents.

> - The terminology is not consistent throughout the document.  It's
> really important to use only one phrase to name each thing in a
> system, and to put the definition in the glossary.  E.g.,
> "Authorization Server" and "AuthZ" server are used interchangeably,
> and I suspect that "the server" and "IdP entity" also mean the same
> thing.  Of course, SIP and OAuth may use different terms for the same
> entity, which makes things harder, but the glossary can show the
> correspondence between the two sets of terms.
>
> I will fix that.

> - The meaning, use, and format of the various data items is not clear.
> E.g., what is the format and significance of an "authorization code"?
> In particular, HMAC is used without specifying how its output (which
> is a sequence of binary octets) is encoded when it is included in SIP
> messages.
>
> I will fix that.

> - The example call flow diagrams do not include enough detail, which
> means I can't study them to get into my memory a good idea of what the
> flow diagram illustrates.  Also, though the description gives an
> overview, but there's considerable information about the dataflow of
> authorization values that is under-described.  E.g., at the end of the
> section 2.1 flow, it *seems* that the proxy will retain "tokens"
> associated with the registration, but that's not stated, nor is it
> stated how the tokens might be used.  Is the proxy expected to attach
> them to later requests by the UA so that other servers can determine
> that the request is authorized?
>
> I will clarify that

> - Various nits, including:
>
> The document uses RFC 2119 rather than RFC 8174, which updates 2119.
>
> There is a reference to "RFC474bis" which should be "RFC4474bis".
>
>
Thanks,
 Rifaat

> Dale
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>