Subject: Re: [paws] PAWS security

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Sep 2012 15:18:27 -0400

The easiest way to do this is to have the manufacturer put a cert in the device that it signs.  Then the only thing the database needs is the public key of the manufacturer,

Why do we want to make this harder?

Because some manufacturers think its too much work to do that?

Brian

 -----Original Message-----
From: 	Paul Lambert [mailto:[email-masked]]
Sent:	Monday, September 10, 2012 03:15 PM Eastern Standard Time
To:	Peter McCann; Peter Stanforth; Stephen Farrell; [email-masked]
Cc:	[email-masked]
Subject:	Re: [paws] PAWS security

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

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

> -Pete
> 
> Peter Stanforth wrote:
> > 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".
> >
> > On MonSep/10/12 Mon Sep 10, 2:18 PM, "Peter McCann"
> > <[email-masked]> wrote:
> >
> >> 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.
> >>>
> >>> On MonSep/10/12 Mon Sep 10, 1:58 PM, "Peter McCann"
> >>> <[email-masked]> wrote:
> >>>
> >>>> 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:
> >>>>>
> >>>>>
> >>>>> 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
> >>>>> _______________________________________________ paws mailing list
> >>>>> [email-masked] https://www.ietf.org/mailman/listinfo/paws
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> paws mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/paws
> >>
> >>
> >>
> 
> 
> 
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/paws

---

From: Paul Lambert <[email-masked]>
Date: Mon, 10 Sep 2012 13:02:24 -0700

> From: Rosen, Brian [mailto:[email-masked]]
...
> The easiest way to do this is to have the manufacturer put a cert in
> the device that it signs.  Then the only thing the database needs is
> the public key of the manufacturer,
You cannot prevent spoofing of a DB without having a root
of some sort that "certifies" real db providers.  This is a small
number of certificates installed in the servers.

Having a per-device cert signed by a manufacturer and installed
in the factory is harder.  It's more certificates and complicates
the manufacturing process.  The authentication to a manufacturer
is not necessarily useful. The authentication of the manufacturers
FCC ID and device Id might be of interest, but the regulations
do not mandate (AFAIK) this complexity of assignment of a
few bits of per device regulatory information.

> Why do we want to make this harder?
There are two requirements:
 - authentication of multiple DB providers within a regulatory domain
 - "secure" transmission of Regulatory ID and Device identification 
    to DB
Proposal below was primarily focused on the first requirement
above.  Your proposal for device certs is for the second.
Both might be required ... device certs have other options also
than manufacturer oriented certs and is a longer discussion.

Paul

> 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
> 
> 
> > -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.
> > >>> 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.
> > >>>> only one that is integrity protected.  I think this is much
> > >>>> easier to achieve in practice.
> > >>>>
> > >>>> -Pete
> > >>>>
> > >>>> Stephen Farrell wrote:
> > >>>>>
> > >>>>>
> > >>>>> for authentication are a matter of a business model chosen by
> > >>>>> the provider which deploys white space devices, rather than a
> > protocol
> > >>>>> decision.
> > >>>>>>
> > >>>>> established using current practices to set up shared secrets
> > >>>>> with financial institutions (using the browser).
> > >>>>> 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.
> > >>>>>
> > >>>>> 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.
> > >>>>>
> > >>>>> _______________________________________________ paws mailing
> > >>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/paws
> > >>>>
> > >>>>
> > >>>>

---

From: <[email-masked]>
Date: Fri, 14 Sep 2012 00:00:54 +0000

We in IETF cannot require a client cert to be installed in the device. Regulators may require it, and if they don't, the folks who deploy it may do so.
What we can do in IETF is to decide to only specify how a device with a client cert is authenticated, and not specify how a paws master device is authenticated with a shared secret. Is that what we want?
 
Having a client cert in the device would certainly not contradict with the current FCC requirement to have a prior relationship between the master and the db.

The drawback I can see with not specifying the shared secret case is that the lack of specifying the use of shared secrets will not prevent folks to deploy it using shared secrets; which may lead to deployments with not standard variations.

- Gabor

-----Original Message-----
From: ext Rosen, Brian [mailto:[email-masked]] 
Sent: Monday, September 10, 2012 12:18 PM
To: 'Paul Lambert'; 'Peter McCann'; 'Peter Stanforth'; 'Stephen Farrell'; Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]'
Subject: RE: [paws] PAWS security

Brian

 -----Original Message-----
From: 	Paul Lambert [mailto:[email-masked]]
Sent:	Monday, September 10, 2012 03:15 PM Eastern Standard Time
To:	Peter McCann; Peter Stanforth; Stephen Farrell; [email-masked]
Cc:	[email-masked]
Subject:	Re: [paws] PAWS security

> think we should design to minimize the friction in changing database 

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

> >>> relationships and allow an end user  to choose one, but it will be 
> >>> from the predefined
> list.

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 13 Sep 2012 20:07:03 -0400

<as individual>
We can say that the security model for paws is PKI when authentication of the device is needed, with a provisioned cert signed by an entity the DB trusts.  Whether it's preloaded by a manufacturer or provisioned by some other mechanism doesn't need to be specified.  This is my preference.

I would prefer not to have any mention of shared secrets.

There are no protocol police.  If deployments decide to use shared secrets, we can't stop them.

Brian

---

From: <[email-masked]>
Date: Wed, 19 Sep 2012 17:01:44 +0000

I can sense an agreement on this topic, that we are going to only describe the case when the master device has a cert issued by a trusted CA. 

I would summarize the objections against describing using shared secrets as we would also have to either define an automated key management mechanism for those keys  or explain why it is reasonable not to have such a mechanism. We likely would not be able to come up with an explanation (as required by BCP107) in a way that will stand up to scrutiny of IESG.

Therefore, I am inclined to instruct the editor to incorporate client cert part into the merged document.

- Gabor

-----Original Message-----
From: ext Rosen, Brian [mailto:[email-masked]] 
Sent: Thursday, September 13, 2012 5:07 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [paws] PAWS security

<as individual>

Brian

On Sep 13, 2012, at 8:00 PM, [email-masked] wrote:

> To: 'Paul Lambert'; 'Peter McCann'; 'Peter Stanforth'; 'Stephen 
> Farrell'; Bajko Gabor (Nokia-CIC/SiliconValley)
> Cc: [email-masked]'