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

[Rifaat Shekh-Yusef <[e-mail]>]

Inline...


On Tue, Jun 12, 2018 at 10:21 PM Dale R. Worley <[e-mail]> wrote:

> Rifaat Shekh-Yusef <[e-mail]> writes:
> > (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.
>
> One suggestion is that the Location header in the F2 401 response should
> have a field parameter to indicate to the Agent the intended
> meaning of the Location URI, i.e., its the URL of an OAuth Authorization
> Server and should be accessed per the protocols in this document.
>

Will do.



>
> More importantly, a quick look suggests that where section 2.1 shows
> this
>
>      |           F2 401 Unauthorized |                               |
>      |              Location: AuthZ Server                           |
>      |<------------------------------|                               |
>      |                               |                               |
>      |                               |                               |
> >  The UA prompts the user to provide his/her credentials.           |
> >  The UA then, as per OAuth 2.0 protocol, authenticates the user to |
> >  the AuthZ server, and obtains an authorization code, which the UA |
> >  will later hand to the Proxy.                                     |
>      |<------------------------------------------------------------->|
>      |                               |                               |
>      |                               |                               |
>      | F3 REGISTER [authz code]      |                               |
>      |------------------------------>|                               |
>
> there is intended to be a reference to 4.1.1 and 4.1.2 of RFC 6749.
> 4.1.1 tells how the Agent is to construct an HTTP GET request, which
> starts the interaction between the user and the Authorization Server.
> Eventually, per 4.1.2, the Authorization Server sends the web client a
> redirection to a URL based on the redirect_uri parameter in the initial
> GET request.  The Agent recognizes that URL and extracts from it the
> authorization code, which it includes in the body of the F3 REGISTER per
> 2.1.1 in this draft.
>
> Generally speaking, I estimate that nobody reading this document will
> have prior knowledge of OAuth, so it would help greatly if you could
> provide the cross-references between the parts of the protocol described
> here with the sections of RFC 6749 that are incorporated into it.
> Currently, the document only says "The method used by the UA to obtain
> the code is out of scope for this document." which is generally used to
> mean "that part is not defined", not "that part is specified in RFC
> XXXX, so we won't repeat it here"!
>
> Sure.
I did assume that people are familiar with OAuth, which in hindsight it is
clear that was a mistake.


>> - 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 problem is that if there's no specification of how this would be
> used to actually do something, you haven't answered the question "Why
> bother?".


> If I guess correctly, once the registration is set up (F3 in 2.1), then
> the proxy is expected to apply the "tokens" to any request that the
> Agent sends to it, before the proxy forwards the request to its
> destination.  If you would specify how that is done, I would see how
> this could be used in a practical system.
>
>
The main problem that this document is trying to address is the *Single-Sign
On*.
We would like to allow the SIP UA to use one set of credentials to
authenticate
and get access to SIP and non-SIP services.

With regards to the authorization part, take a look at the following thread:
https://www.ietf.org/mail-archive/web/sipcore/current/msg07223.html

Because we could not get to an agreement at that time, we decided to work
on the parts that there is agreement on, and that is the reason for this
document and its limited scope.

Regards,
 Rifaat



> Dale
>