Subject: [sipcore] Draft new: draft-holmberg-sipcore-auth-id-00

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Oct 2014 10:34:18 +0000

Hi,

I've submitted a new draft, draft-holmberg-sipcore-auth-id-00.

The draft defines a new Authorization header field parameter, which can carry a string value identifying an authorization server, based on a requirement from 3GPP (the mechanism is general, though).

The mechanism can be used together with the mechanism defined in draft-yusef-sipcore-sip-oauth-01.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 27 Oct 2014 17:15:31 -0400

> From: Christer Holmberg <[email-masked]>
> 

It would help if the Abstract was rewritten so that one did not need
to know the meanings of "eP-CSCF", "WAF", and "S-CSCF" to understand
what the mechanism can do.

> The draft defines a new Authorization header field parameter, which
> can carry a string value identifying an authorization server, based
> on a requirement from 3GPP (the mechanism is general, though).

The text says that the "authorization-entity" parameter carries "a
string value which represents the identity of an authorization
server".  You might want to expand on that.  I'm guessing it means
that any entity that wants to verify the authorization of the REGISTER
request should present the request contents to the specified
authorization server.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Oct 2014 08:28:39 +0000

Hi,

> It would help if the Abstract was rewritten so that one did not need to know the meanings of "eP-CSCF", "WAF", and "S-CSCF" to understand what the mechanism can do.

I had very limited time to write the draft, so that's the reason it ended up in this way. But, I DO agree with you, and that will be fixed in the next version :)

>> can carry a string value identifying an authorization server, based on 
>> a requirement from 3GPP (the mechanism is general, though).
>
> The text says that the "authorization-entity" parameter carries "a string value which represents the identity of an authorization server".  You might want to expand
> on that.  I'm guessing it means that any entity that wants to verify the authorization of the REGISTER request should present the request contents to the specified 
> authorization server.

I am not sure I understand what you mean by "present the request contents to the specified authorization server". The identity is obtained from the authorization server (or, the eP-CSCF knows it by configuration). The identity is then provided to the S-CSCF (SIP registrar), which can use the information for policy decisions.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 28 Oct 2014 11:20:02 -0400

> > that any entity that wants to verify the authorization of the
> > REGISTER request should present the request contents to the
> > specified authorization server.
> 
> I am not sure I understand what you mean by "present the request
> contents to the specified authorization server". The identity is
> obtained from the authorization server (or, the eP-CSCF knows it by
> configuration). The identity is then provided to the S-CSCF (SIP
> registrar), which can use the information for policy decisions.

The general idea is this:  Suppose the reader has no idea how IMS does
things.  Within the SIP authorization model(s) presented in the RFCs,
what is the function of "authorization-entity"?  I assume that you
intend to extend the set of SIP authorization models; it's necessary
to describe, at least in outline, what the new authorization model is
and how "authorization-entity" is used in it so people can tell
whether they want to use it in their SIP implementations and how they
would do so.

As this draft is currently written, it seems to be "IMS needs this, so
we'll write that down and call it an RFC".  It needs considerable
clarification.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Oct 2014 15:57:49 +0000

Hi,

> The general idea is this:  Suppose the reader has no idea how IMS does things.  Within the SIP authorization 
> model(s) presented in the RFCs, what is the function of "authorization-entity"? 

The function is to provide the authorization server identity to the S-CSCF (registrar). The S-CSCF MAY use that information when authorizing a user. For example, it can check whether the authorization server is authorized to provide IMS credentials to the user.

3GPP does not mandate the usage of the information, and does not specify the policy procedures how it's used. 3GPP only requires the information to be conveyed to the S-CSCF.

> I assume that you intend to extend the set of SIP authorization models; it's necessary to describe, at least in outline, what the new authorization model is and how 
> "authorization-entity" is used in it so people can tell whether they want to use it in their SIP implementations and how they would do so.

The way the IMS core authorizes users as such is not changed. 

The information is there so that IMS can use the information to check whether the authorization server is used, but that authorization server may serve multiple users. 

> As this draft is currently written, it seems to be "IMS needs this, so we'll write that down and call it an RFC".  It needs considerable clarification.

As always, we need to decide whether there is any interest for this outside 3GPP. But, I am happy to provide more information/clarification.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 29 Oct 2014 17:35:48 -0400

> The function is to provide the authorization server identity to the
> S-CSCF (registrar). The S-CSCF MAY use that information when
> authorizing a user. For example, it can check whether the
> authorization server is authorized to provide IMS credentials to the
> user.

When you say "provide the authorization server identity", so you mean
"provide the identity of the authorization server"?  And does that
mean that registrar/S-CSCF will use that as an input to its
authorization check (as basically a string, much like the username and
realm) or is it the DNS name of an authorization server that the
registrar is supposed to query to check the validity of the
credentials?

I think that you mean the former rather than the latter.

In that case, in what way does authorization-entity differ from the
username and realm?

> > I assume that you intend to extend the set of SIP authorization
> > models; it's necessary to describe, at least in outline, what the
> > new authorization model is and how "authorization-entity" is used
> > in it so people can tell whether they want to use it in their SIP
> > implementations and how they would do so.
> 

OK, but is the way that IMS core authorizes users different from the
usual SIP digest model?  If so, documenting that authorization method
could be useful for broader SIP usage.

> As always, we need to decide whether there is any interest for this
> outside 3GPP. But, I am happy to provide more
> information/clarification.

Granted.  But to determine that, people outside of 3GPP need to know
what the mechanism does, and that's not very clear yet.

Dale