Subject: [paws] PAWS security

From: <[email-masked]>
Date: Fri, 7 Sep 2012 21:01:09 +0000

At the Vancouver F2F we had extensive discussions on the security model for PAWS. Draft-das proposes to use shared secrets pre-provisioned in the master devices for authentication, while draft-lei proposes to mandate client certificates into master devices.

There seemed to be an understanding that the credential types in use for authentication are a matter of a business model chosen by the provider which deploys white space devices, rather than a protocol decision.

Brian mentioned that the iesg may not allow a document to be published which specifies how shared secrets are used, but does not have a provisioning mechanism for the shared secrets defined. In my opinion, a mechanism for distributing shared secrets does not necessarily have to be defined, as a shared secret can be established using current practices to set up shared secrets with financial institutions (using the browser).
Thus, my suggestion would be to describe in the document how a shared secret and how a client certificate is used to authenticate a master device. Then, if we run into issues with iesg, in worst case we could remove the shared secret part and keep the other one.

I'd like to get additional views on this topic.

-          Gabor

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 07 Sep 2012 23:16:44 +0100

On 09/07/2012 10:01 PM, [email-masked] wrote:> At the Vancouver
F2F we had extensive discussions on the security model for PAWS.
Draft-das proposes to use shared secrets pre-provisioned in the master
devices for authentication, while draft-lei proposes to mandate client
certificates into master devices.
>
> There seemed to be an understanding that the credential types in use
for authentication are a matter of a business model chosen by the
provider which deploys white space devices, rather than a protocol decision.
>
> Brian mentioned that the iesg may not allow a document to be published
which specifies how shared secrets are used, but does not have a
provisioning mechanism for the shared secrets defined. In my opinion, a
mechanism for distributing shared secrets does not necessarily have to
be defined, as a shared secret can be established using current
practices to set up shared secrets with financial institutions (using
the browser).
> Thus, my suggestion would be to describe in the document how a shared
secret and how a client certificate is used to authenticate a master
device. Then, if we run into issues with iesg, in worst case we could
remove the shared secret part and keep the other one.
> I'd like to get additional views on this topic.

I can help a little here (depending on your definition of help:-)

BCP 107 [1] is the one to look at when considering how to
approach automated key management requirements. That has an
IMO very good abstract:

   The question often arises of whether a given security system requires
   some form of automated key management, or whether manual keying is
   sufficient.  This memo provides guidelines for making such decisions.
   When symmetric cryptographic mechanisms are used in a protocol, the
   presumption is that automated key management is generally but not
   always needed.  If manual keying is proposed, the burden of proving
   that automated key management is not required falls to the proposer.

For those that might be less familiar with IETF processes, the
fact that that's a BCP means that its entirely valid for an AD
to strenuously push back against a WG that wants to ignore what
it says.

Cheers,
S.

PS: I've not read the drafts, and couldn't make the session in
Vancouver, so this might be entirely off topic, but in the case of
PAWS I'd also argue that the regulators' apparent desire to force
devices to authenticate is not necessarily the right one for the
IETF to force upon all users of the PAWS protocol. So there could
for example be a mode of operation where the DB signs stuff but
doesn't care who's asking and that'd be a far far easier scenario
in terms of automated key management.

[1] http://tools.ietf.org/html/bcp107

---

From: Peter McCann <[email-masked]>
Date: Mon, 10 Sep 2012 17:58:29 +0000

Personally, I think that manually provisioned symmetric keys will
severely limit the ability for users to flexibly move from one
database provider to another.  It will require some secure out-of-band
channel on which to transmit the secret key from one party to the
other, and a mechanism for the user to push the secret key down
into the master device.

Provisioning of certificates does not require the secret channel,
only one that is integrity protected.  I think this is much easier
to achieve in practice.

-Pete

Stephen Farrell wrote:
> _______________________________________________ paws mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/paws

---

From: Peter Stanforth <[email-masked]>
Date: Mon, 10 Sep 2012 14:15:08 -0400

Pete,
I am not sure I believe in a use case where "users" move from one DB to
another. The relationship is between the radio vendor and the DBA. The
radio vendor may have multiple relationships and allow an end user to
choose one, but it will be from the predefined list. As a DBA I don't
think I would want, and in the USA we are not permitted, to establish a
relationship with a user without a preexisting relationship with the radio
vendor. So security should be primarily a radio vendor-DBA issue.
Wearing my DBA hat I don't think I would want to service a radio that I do
not have a preexisting relationship with it's manufacturer.  I am not sure
that user relationships are even within the scope of what PAWS should be
defining.
Peter S.

On MonSep/10/12 Mon Sep 10, 1:58 PM, "Peter McCann"
<[email-masked]> wrote:

>[email-masked]
>https://www.ietf.org/mailman/listinfo/paws

---

From: Peter McCann <[email-masked]>
Date: Mon, 10 Sep 2012 18:18:17 +0000

This is a key question we need to answer.

I thought we were defining a protocol that would allow a radio from any
manufacturer to interoperate with a database of any database vendor.

-Pete

Peter Stanforth wrote:
> Pete,
> I am not sure I believe in a use case where "users" move from one DB
> to another. The relationship is between the radio vendor and the DBA.
> The radio vendor may have multiple relationships and allow an end user
> to choose one, but it will be from the predefined list. As a DBA I
> don't think I would want, and in the USA we are not permitted, to
> establish a relationship with a user without a preexisting
> relationship with the radio vendor. So security should be primarily a radio vendor-DBA issue.
> Wearing my DBA hat I don't think I would want to service a radio that
> I do not have a preexisting relationship with it's manufacturer.  I am
> not sure that user relationships are even within the scope of what
> PAWS should be defining.
> Peter S.
> 
>> severely limit the ability for users to flexibly move from one database
>> provider to another.  It will require some secure out-of-band channel
>> on which to transmit the secret key from one party to the other, and a
>> mechanism for the user to push the secret key down into the master
>> device.
>> 
>> only one that is integrity protected.  I think this is much easier to
>> achieve in practice.
>> 
>> -Pete
>> 
>> Stephen Farrell wrote:
>>> 
>>> 
>>>> Brian mentioned that the iesg may not allow a document to be
>>> published which specifies how shared secrets are used, but does not
>>> have a provisioning mechanism for the shared secrets defined. In my
>>> opinion, a mechanism for distributing shared secrets does not
>>> necessarily have to be defined, as a shared secret can be established
>>> using current practices to set up shared secrets with financial
>>> institutions (using the browser).
>>> BCP 107 [1] is the one to look at when considering how to approach
>>> automated key management requirements. That has an IMO very good
>>> abstract:
>>> 
>>>    The question often arises of whether a given security system
>>>    requires some form of automated key management, or whether manual
>>>    keying is sufficient.  This memo provides guidelines for making
>>>    such decisions. When symmetric cryptographic mechanisms are used in
>>>    a protocol, the presumption is that automated key management is
>>>    generally but not always needed.  If manual keying is proposed, the
>>>    burden of proving that automated key management is not required
>>>    falls to the
> proposer.
>>> For those that might be less familiar with IETF processes, the fact
>>> that that's a BCP means that its entirely valid for an AD to
>>> strenuously push back against a WG that wants to ignore what it says.
>>> 
>>> Cheers,
>>> S.
>>> 
>>> devices to authenticate is not necessarily the right one for the IETF
>>> to force upon all users of the PAWS protocol. So there could for
>>> example be a mode of operation where the DB signs stuff but doesn't
>>> care who's asking and that'd be a far far easier scenario in terms of
>>> automated key management.
>>>

---

From: <[email-masked]>
Date: Mon, 10 Sep 2012 18:38:47 +0000

- as individual-
In a deployment using shared secrets, changing the provider should not require the shared secret to be transferred between providers. The master device could set up a new shared secret with the new provider.
Using client certificates is not problem free either: if the master device's certificate is not signed by a CA whose root cert is trusted by the new provider, then trust has to be established or the master needs to enroll to get a new cert from that provider.
- Gabor

-----Original Message-----
From: ext Peter McCann [mailto:[email-masked]] 
Sent: Monday, September 10, 2012 10:58 AM
To: Stephen Farrell; Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]
Subject: RE: [paws] PAWS security

Personally, I think that manually provisioned symmetric keys will severely limit the ability for users to flexibly move from one database provider to another.  It will require some secure out-of-band channel on which to transmit the secret key from one party to the other, and a mechanism for the user to push the secret key down into the master device.

Provisioning of certificates does not require the secret channel, only one that is integrity protected.  I think this is much easier to achieve in practice.

-Pete

Stephen Farrell wrote:
> published
> provisioning mechanism for the shared secrets defined. In my opinion, 
> a mechanism for distributing shared secrets does not necessarily have 
> to be defined, as a shared secret can be established using current

---

From: Peter McCann <[email-masked]>
Date: Mon, 10 Sep 2012 18:40:48 +0000

Sure, a new shared secret can be assigned by the new provider.  However,
some sort of confidential channel must be provided to communicate the
shared secret from one side to the other.

In contrast, a certificate signing request does not need confidentiality,
only integrity protection.

-Pete

[email-masked] wrote:
> - as individual-
> In a deployment using shared secrets, changing the provider should not
> require the shared secret to be transferred between providers. The
> master device could set up a new shared secret with the new provider.
> Using client certificates is not problem free either: if the master
> device's certificate is not signed by a CA whose root cert is trusted
> by the new provider, then trust has to be established or the master
> needs to enroll to get a new cert from that provider.
> - Gabor
> 
> 
> other, and a mechanism for the user to push the secret key down into
> the master device.
> 
> Provisioning of certificates does not require the secret channel, only
> one that is integrity protected.  I think this is much easier to
> achieve in practice.
> 
> -Pete
> 
> Stephen Farrell wrote:
>> 
>> 
>> provisioning mechanism for the shared secrets defined. In my
>> necessarily have to be defined, as a shared secret can be
>> established using current practices to set up shared secrets with
>> financial institutions (using the browser).
>> device. Then, if we run into issues with iesg, in worst case we
>> could remove the shared secret part and keep the other one.
>>> 
>>    keying is sufficient.  This memo provides guidelines for making such
>>    decisions. When symmetric cryptographic mechanisms are used in a
>>    protocol, the presumption is that automated key management is
>> doesn't care who's asking and that'd be a far far easier scenario in
>> terms of automated key management.
>>

---

From: Paul Lambert <[email-masked]>
Date: Mon, 10 Sep 2012 11:39:56 -0700

> mechanism for the user to push the secret key down into the master

Yes!!!  Distributing symmetric keys is a really bad idea for PAWS.  
They scale poorly, are more difficult to manage, and are more 
readily subject to misuse.

Paul

> requires

---

From: Peter Stanforth <[email-masked]>
Date: Mon, 10 Sep 2012 14:44:38 -0400

I completely agree with your statement below. If we are good any radio
will have the "Technical" capability to work with any database.
BUT, and this is a big BUT, the regulation may not allow it - The FCC does
not today. And as a DBA I only want to work with devices where I have a
predefined relationship. Not least of which, because as I am authorized by
a Regulator I want to make sure I am doing everything I can to avoid their
wrath.
This has come up before. PAWS is defining an API/Protocol, not the
regulation nor the business cases at this time. So I still say that we can
comply with your statement without considering a "User".

---

From: Peter McCann <[email-masked]>
Date: Mon, 10 Sep 2012 18:48:13 +0000

This restriction may hold today for the FCC, but I have a hard time
believing that a pre-existing manufacturer-database relationship
will be mandatory in every regulatory domain for the forseeable
future.  I think we should design to minimize the friction in changing
database providers.

-Pete

Peter Stanforth wrote:
> BUT, and this is a big BUT, the regulation may not allow it - The FCC
> does not today. And as a DBA I only want to work with devices where I
> have a predefined relationship. Not least of which, because as I am
> authorized by a Regulator I want to make sure I am doing everything I
> can to avoid their wrath.
> regulation nor the business cases at this time. So I still say that we
> can comply with your statement without considering a "User".
> 
>>> Pete, I am not sure I believe in a use case where "users" move from
>>> one DB to another. The relationship is between the radio vendor and
>>> the DBA. The radio vendor may have multiple relationships and allow an
>>> end user  to choose one, but it will be from the predefined list. As a
>>> DBA I  don't think I would want, and in the USA we are not permitted,
>>> to establish a relationship with a user without a preexisting
>>> relationship with the radio vendor. So security should be primarily a
>>> radio vendor-DBA issue. Wearing my DBA hat I don't think I would want
>>> to service a radio that I do not have a preexisting relationship with
>>> it's manufacturer.  I am not sure that user relationships are even
>>> within the scope of what PAWS should be defining. Peter S.
>>> 
>>>> database provider to another.  It will require some secure
>>>> out-of-band channel on which to transmit the secret key from one
>>>> party to the other, and a mechanism for the user to push the
>>>> secret key down into the master device.
>>>> 
>>>>> On 09/07/2012 10:01 PM, [email-masked] wrote:> At the
>>>>> Vancouver F2F we had extensive discussions on the security model for
>>>>> PAWS. Draft-das proposes to use shared secrets pre-provisioned in
>>>>> the master devices for authentication, while draft-lei proposes to
>>>>> mandate client certificates into master devices.
>>>>>> 
>>>>> approach automated key management requirements. That has an IMO
>>>>> very good
>>>>> abstract:
>>>>> 
>>>>>    such decisions. When symmetric cryptographic mechanisms are used
>>>>>    in a protocol, the presumption is that automated key management
>>>>>    is generally but not always needed.  If manual keying is
>>>>> proposed,
> the
>>>>> Vancouver, so this might be entirely off topic, but in the case
>>>>> of PAWS I'd also argue that the regulators' apparent desire to
>>>>> force devices to authenticate is not necessarily the right one
>>>>> for the IETF to force upon all users of the PAWS protocol. So
>>>>> there could for example be a mode of operation where the DB signs
>>>>> stuff but doesn't care who's asking and that'd be a far far
>>>>> easier scenario in terms of automated key management.
>>>>>

---

From: Paul Lambert <[email-masked]>
Date: Mon, 10 Sep 2012 12:03:05 -0700

> believing that a pre-existing manufacturer-database relationship will
> be mandatory in every regulatory domain for the forseeable future.  I
> think we should design to minimize the friction in changing database
> providers.

The least friction would be to hardwire devices with a 
PK "root" for each regulatory domain that the device supports.

Valid DBs would have credentials signed by the key holder of
roots for each regulatory domain

Paul

> >> I thought we were defining a protocol that would allow a radio from
> >> any manufacturer to interoperate with a database of any database
> vendor.
> >>
> >> -Pete
> >>
> >> Peter Stanforth wrote:
> >>> the DBA. The radio vendor may have multiple relationships and allow
> >>> an end user  to choose one, but it will be from the predefined
> list.
> >>> As a DBA I  don't think I would want, and in the USA we are not
> >>> permitted, to establish a relationship with a user without a
> >>> preexisting relationship with the radio vendor. So security should
> >>> be primarily a radio vendor-DBA issue. Wearing my DBA hat I don't
> >>> think I would want to service a radio that I do not have a
> >>> preexisting relationship with it's manufacturer.  I am not sure
> that
> >>> user relationships are even within the scope of what PAWS should be
> defining. Peter S.
> >>>
> >>>>> Vancouver F2F we had extensive discussions on the security model
> >>>>> for PAWS. Draft-das proposes to use shared secrets pre-
> provisioned
> >>>>> in the master devices for authentication, while draft-lei
> proposes
> >>>>> to mandate client certificates into master devices.
> >>>>>>
> >>>>> provider which deploys white space devices, rather than a
> protocol
> >>>>> decision.
> >>>>>>
> >>>>> published which specifies how shared secrets are used, but does
> >>>>> not have a provisioning mechanism for the shared secrets defined.
> >>>>> In my opinion, a mechanism for distributing shared secrets does
> >>>>> not necessarily have to be defined, as a shared secret can be
> >>>>> secret and how a client certificate is used to authenticate a
> >>>>> master device. Then, if we run into issues with iesg, in worst
> >>>>> case we could remove the shared secret part and keep the other
> one.
> >>>>>>
> approach
> >>>>> fact that that's a BCP means that its entirely valid for an AD to
> of