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

[[e-mail] (Dale R. Worley)]

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.

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"!

>> - 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.

Dale