Subject: [Rum] Username/password vs cert/OAUTH token

From: Brian Rosen <[email-masked]>
Date: Fri, 20 Nov 2020 10:10:40 -0500

In the RUM meeting, Olle suggested we leave username/password as authentication mechanism for SIP (and, he proposes, for the code authentication issue) behind, and use OAUTH tokens or certs.

In thinking about this, it occurs to me that the way you authenticate to the OAUTH IDP is, wait for it, username and password, and the way you access a private key if it’s human based access, is a pass phrase.  So, we might be improving the crypto a bit, but not the authentication strength.  So, why do it?

Most IDPs these days offer, and sometimes require MFA.  That’s an improvement.  Although it could be considered a SIP extension, something simple like appending a code to the password or hashing the password with a code would get us that if we wanted it.  I’d actually prefer OAUTH, but I could see doing that for REGISTER, or for that matter HTTPS.  I also note that the transaction to present the API Key doesn’t need user credentials, but if we didn’t use them, then we would need a token returned from the HTTPS API Key transaction to be included in the REGISTER to make sure that it came from the approved app.  

The RUE could reasonably construct a CRL, pass it to a provider, get a cert back and use ACME to refresh it, all without any human interaction.  So I can see how to do certs.  OAUTH is also obvious.  

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Nov 2020 13:00:49 -0500

> The RUE could reasonably construct a CRL, pass it to a provider, get a cert back and use ACME to refresh it, all without any human interaction.  So I can see how to do certs.  OAUTH is also obvious.

ISTM that the way we are arranging things there is a non-sip step in 
authentication that always involves a human in real-time. Using OAUTH 
there seems good because it can push the logic off to some other entity 
whose choice is between the provider and the user.

That is presumably to get to the configuration server. Then the 
configuration server hands back credentials for use in SIP. Currently we 
are handing back userid/pw there. But it could just as well be a token. 
Or we could allow that to be a choice made by the provider.

There is also the issue of refreshing the configuration if something in 
it has changed. (E.g. a credential revocation.) That should be able to 
happen without the human. I guess that may be a reason to use OAUTH so 
that there can be a refresh token.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Tue, 24 Nov 2020 11:10:41 -0500

I think the problem is who runs the configuration server and who runs the OAUTH IDP?

The fundamental thing we are trying to do here is support multiple accounts at different providers.  We’re all agreeing that needs to be secure, and in one way or another, the human user has to authenticate,

Maybe we should start at requirements:
1. Configuration is per provider
2. Multiple accounts at different providers must be supported
3. All information needed to connect to a provider must be in the configuration
4. Some form of (human) user authentication is required (but the question is when, see 5)
5. The mechanisms has to work over a power failure: after power is restored, incoming calls have to be received
6. The mechanism must be secure (for example, stored password must be encrypted in storage and transit)
7. As much as possible, the user should not have to enter configuration data such as proxy server URIs, TURN server URIs, etc.

?More?
Brian

> On Nov 23, 2020, at 1:00 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> ISTM that the way we are arranging things there is a non-sip step in authentication that always involves a human in real-time. Using OAUTH there seems good because it can push the logic off to some other entity whose choice is between the provider and the user.
> 
> That is presumably to get to the configuration server. Then the configuration server hands back credentials for use in SIP. Currently we are handing back userid/pw there. But it could just as well be a token. Or we could allow that to be a choice made by the provider.
> 
> There is also the issue of refreshing the configuration if something in it has changed. (E.g. a credential revocation.) That should be able to happen without the human. I guess that may be a reason to use OAUTH so that there can be a refresh token.
> 
> 	Thanks,
> 	Paul
> 
> -- 
> Rum mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Nov 2020 11:42:58 -0500

Brian,

On 11/24/20 11:10 AM, Brian Rosen wrote:
> The fundamental thing we are trying to do here is support multiple 
> accounts at different providers.  We’re all agreeing that needs to be 
> secure, and in one way or another, the human user has to authenticate,
> 
> 5. The mechanisms has to work over a power failure: after power is 
> restored, incoming calls have to be received
> 7. As much as possible, the user should not have to enter configuration 
> data such as proxy server URIs, TURN server URIs, etc.

Good start.

In addition to 7, I think there is an issue around credential 
revocation/reissue. If there is a need to issue new credentials (e.g., 
due to compromise of a cert or pw vault or just timeout of the 
credential), if user input is required then it needs to be arranged to 
be done when a human is available. (This needs more consideration.)

	Thanks,
	Paul

> ?More?
> Brian
> 
>> On Nov 23, 2020, at 1:00 PM, Paul Kyzivat <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> In the RUM meeting, Olle suggested we leave username/password as 
>>> authentication mechanism for SIP (and, he proposes, for the code 
>>> authentication issue) behind, and use OAUTH tokens or certs.
>>> In thinking about this, it occurs to me that the way you authenticate 
>>> to the OAUTH IDP is, wait for it, username and password, and the way 
>>> you access a private key if it’s human based access, is a pass 
>>> phrase.  So, we might be improving the crypto a bit, but not the 
>>> authentication strength.  So, why do it?
>>> Most IDPs these days offer, and sometimes require MFA.  That’s an 
>>> improvement. Although it could be considered a SIP extension, 
>>> something simple like appending a code to the password or hashing the 
>>> password with a code would get us that if we wanted it.  I’d actually 
>>> prefer OAUTH, but I could see doing that for REGISTER, or for that 
>>> matter HTTPS.  I also note that the transaction to present the API 
>>> Key doesn’t need user credentials, but if we didn’t use them, then we 
>>> would need a token returned from the HTTPS API Key transaction to be 
>>> included in the REGISTER to make sure that it came from the approved app.
>>> The RUE could reasonably construct a CRL, pass it to a provider, get 
>>> a cert back and use ACME to refresh it, all without any human 
>>> interaction.  So I can see how to do certs. OAUTH is also obvious.
>>
>> there seems good because it can push the logic off to some other 
>> entity whose choice is between the provider and the user.
>>
>> configuration server hands back credentials for use in SIP. Currently 
>> we are handing back userid/pw there. But it could just as well be a 
>> token. Or we could allow that to be a choice made by the provider.
>>
>> There is also the issue of refreshing the configuration if something 
>> in it has changed. (E.g. a credential revocation.) That should be able 
>> to happen without the human. I guess that may be a reason to use OAUTH 
>> so that there can be a refresh token.
>>
>> Thanks,
>> Paul
>>
>> --
>> Rum mailing list
>> https://www.ietf.org/mailman/listinfo/rum 
>> <https://www.ietf.org/mailman/listinfo/rum>
> 
>

---

From: Jim Malloy <[email-masked]>
Date: Tue, 24 Nov 2020 17:22:34 +0000

Comments below in {}

--Jim

{
Yes – and configurations should be pulled from each provider independently. There is no reason for any provider to have visibility into another provider’s information
}
3. All information needed to connect to a provider must be in the configuration
4. Some form of (human) user authentication is required (but the question is when, see 5)

{
Since the “pull” is on a per-provider basis, the authentication is also on a per-provider basis.  Hew (and when) do providers require authentication on mobile devices or dedicated hardware today? I suspect the answers differ between providers and across device types.

While I agree with Olle’s sentiment that the RFC should not limit authentication to the “as-is” mechanisms in use today, it is important to provide a migration path from existing mechanisms to currently acceptable (and, where possible, future) mechanisms.  Most, if not all, current US VRS providers rely on username/password pairs for user authentication.
}

{
How do providers accomplish this today?  How do other, comparable, services handle this today?  Section 9 states “A RUE device may retrieve a configuration from a provisioned URL using HTTPs”. Every browser I use seems to be able to remember that I have credentials for multiple sites (but not my bank or insurance provider) without any difficulty.  Can we specify whatever mechanisms are commonly in use today?
}

{
The two-tiered configuration retrieval outlined in the document should eliminate the need for any of the information you listed to be manually entered.

Section 9.1,  RUE Provider Selection, outlines a Provider list which would be maintained by a single authoritative source (perhaps the FCC or their designee for the United States).  This list provides a minimal set of information per provider to supply the RUE with a list of Providers that can be contacted.

Section 9.2, RUE Configuration Service, _should_ contain and required configuration information for the user to access a specific provider’s service.  If there is something missing, we should add it.
}

?More?
Brian

On Nov 23, 2020, at 1:00 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

               Thanks,
               Paul

--
Rum mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rum

---

From: Brian Rosen <[email-masked]>
Date: Tue, 24 Nov 2020 12:43:22 -0500

One easy mechanism for the per provider config information is that the HTTPS service we’ve talked about for the API key could return the config for that provider.  If we included the userid in the query, that could be user-specific.  That would NOT include any authentication information, just the server URIs and other config data that wasn’t private (but doesn’t need to be spread to the world.

Jim, nearly every VoIP phone has a piece of local storage that holds all the config information.  It’s usually manually entered, sometimes laboriously (using the 10 key pad), more often these days with a built in web server and a browser.  Most handle multiple lines.  The data includes username/password.  It’s non-volatile storage.  If power fails, the phone boots, accesses this storage, and configures itself, REGISTERs and is then ready to accept calls.  No human interaction.  You can often put a username/password on the phone configuration interface.  I think we are replicating that, hopefully with a bit more automation.

Brian

> On Nov 24, 2020, at 12:22 PM, Jim Malloy <[email-masked]> wrote:
> 
> Comments below in {}
>  
> --Jim
>  
> On Nov 23, 2020, at 1:00 PM, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Nov 2020 14:32:35 -0500

On 11/24/20 12:43 PM, Brian Rosen wrote:
> One easy mechanism for the per provider config information is that the 
> HTTPS service we’ve talked about for the API key could return the config 
> for that provider.  If we included the userid in the query, that could 
> be user-specific.  That would NOT include any authentication 
> information, just the server URIs and other config data that wasn’t 
> private (but doesn’t need to be spread to the world.

I think we need to distinguish *enrolling* the device/app with the 
provider from the device fetching the provider-specific configuration of 
the device/app.

The enrollment would be a more or less one-time thing per device per 
provider, and would require the user to be present and to authenticate 
himself to the provider.

The configuration may need to fetched every time the device starts up, 
or it may only need to be refreshed from time to time. (This requires 
discussion.) But it too needs to work without anyone present. Then it 
provides the credentials needed for sip - registration, subscription, etc.

My thought has been that when the provider decides the device needs to 
be re-provisioned it can invalidate the sip credentials and unregister 
the device. That will trigger the device to attempt to reload its 
configuration, along the way receiving new sip credentials that will work.

If the provider feels a need to force re-authentication by the human 
(re-enrollment), it should when possible defer that until it sees some 
action that indicates a human is present. For instance, when an outgoing 
call is initiated. (For politeness it might want until the bye of the 
outgoing call.)

I'm not necessarily proposing that all of this mechanism be required. 
But rather that things be designed to accommodate this sort of behavior 
if the provider chooses to implement it.

	Thanks,
	Paul

> Jim, nearly every VoIP phone has a piece of local storage that holds all 
> the config information.  It’s usually manually entered, sometimes 
> laboriously (using the 10 key pad), more often these days with a built 
> in web server and a browser.  Most handle multiple lines.  The data 
> includes username/password.  It’s non-volatile storage.  If power fails, 
> the phone boots, accesses this storage, and configures itself, REGISTERs 
> and is then ready to accept calls.  No human interaction.  You can often 
> put a username/password on the phone configuration interface.  I think 
> we are replicating that, hopefully with a bit more automation.
> 
> Brian
> 
>> On Nov 24, 2020, at 12:22 PM, Jim Malloy <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Comments below in {}
>> --Jim
>> Yes – and configurations should be pulled from each provider 
>> independently. There is no reason for any provider to have visibility 
>> into another provider’s information
>> }
>> Since the “pull” is on a per-provider basis, the authentication is 
>> also on a per-provider basis.  Hew (and when) do providers require 
>> authentication on mobile devices or dedicated hardware today? I 
>> suspect the answers differ between providers and across device types.
>> While I agree with Olle’s sentiment that the RFC should not limit 
>> authentication to the “as-is” mechanisms in use today, it is important 
>> to provide a migration path from existing mechanisms to currently 
>> acceptable (and, where possible, future) mechanisms.  Most, if not 
>> all, current US VRS providers rely on username/password pairs for user 
>> authentication.
>> }
>> How do providers accomplish this today?  How do other, comparable, 
>> services handle this today?  Section 9 states “A RUE device may 
>> retrieve a configuration from a provisioned URL using HTTPs”. Every 
>> browser I use seems to be able to remember that I have credentials for 
>> multiple sites (but not my bank or insurance provider) without any 
>> difficulty.  Can we specify whatever mechanisms are commonly in use today?
>> }
>> 7. As much as possible, the user should not have to enter 
>> configuration data such as proxy server URIs, TURN server URIs, etc.
>> {
>> The two-tiered configuration retrieval outlined in the document should 
>> eliminate the need for any of the information you listed to be 
>> manually entered.
>> Section 9.1,  RUE Provider Selection, outlines a Provider list which 
>> would be maintained by a single authoritative source (perhaps the FCC 
>> or their designee for the United States).  This list provides a 
>> minimal set of information per provider to supply the RUE with a list 
>> of Providers that can be contacted.
>> Section 9.2, RUE Configuration Service, _/should/_ contain and 
>> required configuration information for the user to access a specific 
>> provider’s service.  If there is something missing, we should add it.
>> }
>> ?More?
>> Brian
>>
>>
>>         In the RUM meeting, Olle suggested we leave username/password
>>         as authentication mechanism for SIP (and, he proposes, for the
>>         code authentication issue) behind, and use OAUTH tokens or certs.
>>         In thinking about this, it occurs to me that the way you
>>         authenticate to the OAUTH IDP is, wait for it, username and
>>         password, and the way you access a private key if it’s human
>>         based access, is a pass phrase.  So, we might be improving the
>>         crypto a bit, but not the authentication strength.  So, why do it?
>>         Most IDPs these days offer, and sometimes require MFA.  That’s
>>         an improvement. Although it could be considered a SIP
>>         extension, something simple like appending a code to the
>>         password or hashing the password with a code would get us that
>>         if we wanted it.  I’d actually prefer OAUTH, but I could see
>>         doing that for REGISTER, or for that matter HTTPS.  I also
>>         note that the transaction to present the API Key doesn’t need
>>         user credentials, but if we didn’t use them, then we would
>>         need a token returned from the HTTPS API Key transaction to be
>>         The RUE could reasonably construct a CRL, pass it to a
>>         provider, get a cert back and use ACME to refresh it, all
>>         without any human interaction.  So I can see how to do certs.
>>         OAUTH is also obvious.
>>
>>
>>     ISTM that the way we are arranging things there is a non-sip step
>>     in authentication that always involves a human in real-time. Using
>>     OAUTH there seems good because it can push the logic off to some
>>     other entity whose choice is between the provider and the user.
>>
>>     configuration server hands back credentials for use in SIP.
>>     Currently we are handing back userid/pw there. But it could just
>>     as well be a token. Or we could allow that to be a choice made by
>>     the provider.
>>
>>     There is also the issue of refreshing the configuration if
>>     something in it has changed. (E.g. a credential revocation.) That
>>     should be able to happen without the human. I guess that may be a
>>     reason to use OAUTH so that there can be a refresh token.
>>
>>     Thanks,
>>     Paul
>>
>>     --
>>     Rum mailing list