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

From: [email-masked] (Dale R. Worley)
Date: Sun, 10 Jun 2018 17:18:03 -0400

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 Security Considerations section does not describe whether and
how the messages in the call flows need to be protected from
eavesdropping.

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

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

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

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

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

Dale

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 11 Jun 2018 16:41:21 -0400

Hi Dale,

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

Regards,
 Rifaat

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

> Yeah, I will add these details.

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

> I will fix that.

> I will fix that.

> I will clarify that

> There is a reference to "RFC474bis" which should be "RFC4474bis".
Thanks,
 Rifaat

> Dale
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 12 Jun 2018 22:21:41 -0400

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

> We had a long debate on the mailing list about this, so we left it for

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

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 13 Jun 2018 09:30:33 -0400

Inline...

> Server and should be accessed per the protocols in this document.

Will do.

> Sure.
I did assume that people are familiar with OAuth, which in hindsight it is
clear that was a mistake.

> 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