Subject: Re: [paws] identity verification (was: Database Discovery Question)

From: <[email-masked]>
Date: Thu, 19 Apr 2012 19:54:36 +0000

Hi Pete,

Some comments inline:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Peter McCann
Sent: Wednesday, April 18, 2012 9:02 AM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: [paws] Database Discovery Question

Hi, Brian,

The problem is, the master device cannot be authoritative on whether the slave device is approved for use by the regulator.  It must rely on the WSDB it uses (has a relationship with) to tell it.

At the least, we need a format for device identifiers that can be understood by multiple independently operated databases.
<GB> yes, this should be part  of the data model.

Maybe the WSDB trusts the master device to collect this information securely from the slave devices using slave-to-master credentials.  
<GB> yes, this is what at least the 802.11af draft amendment is currently defining for the 802.11 air interface. The slave sends its identifier to the master, then waits for the enablement signal. The enablement signal comes after the master was able to successfully validate the identifier of the slave with the DB.

Normally, the allocation authority for the identifier space would be a trust anchor for the identifier-to-device binding.  I agree that the master-to-slave interface is out of scope, but there should be some mechanism in the marketplace for the master device operator to securely bind the identifier presented by the slave to the communication channel with the slave device, in the sense that the master device is able to know in a secure way that the device it is talking to actually does own the regulator-assigned device identifier.  It seems natural for the master device to rely on its relationship with a database to help with this binding.
<GB> I see two things here: binding between the communication channel and identity; and binding between the identity and the hardware to which it was assigned.
The binding between the communication channel and the identity as presented by slave is there inherently in the radio. 
The task to verify that the identity indeed belongs to the slave should not be the burden of the master device, rather the DB (if seen necessary). 
In order for the DB to verify that the presented identifier indeed belongs to that device, a client cert or sg similar would be needed. Afaik, regulators do not require for client certs binding the identifier to the hardware. Therefore, the verification of whether the identifier is the correct one or not seems to be outside the scope of paws. The master should rely on the lower layers and the DB for this verification.

- Gabor

-Pete

Rosen, Brian wrote:
> <As individual, and I should have said that on all of my messages on 
> this thread> The credentialling system used between the database 
> server and its client (the master) are those of its client.  The 
> database trusts its client.
> 
> The client (the master) may need its customer, the slave, to present 
> credentials for service.
> 
> This means we assume transitive trust on the ID information from the 
> client.  The master validates the slave, the database validates the 
> master.  I would not advocate trying to make anything more complex.
> 
> Brian
> 
> On Apr 18, 2012, at 11:16 AM, Peter McCann wrote:
> 
>> Right, the master queries the database on behalf of the slave, 
>> sending the slave's Device ID and location.  (See Don's message about 
>> validating the FCC ID).  My question is, what is the security model 
>> for validating the slave's ID?  Is there a secure credential 
>> associated with the ID, or is it an insecure check of a number 
>> against a whitelist?  If the former, we will need a credential 
>> management system that is able to cross between different databases.  
>> If the latter, I wonder if it opens up security problems.
>> 
>> -Pete
>> 
>> Rosen, Brian wrote:
>>> Perhaps I am confused, but I think in a master/slave environment, 
>>> the slave does not query the database, the master does.  The slave 
>>> gets its allowed spectrum data from the master.  There is always the 
>>> question of whether the master queries on its own behalf and the 
>>> slaves just get assignments within that database response, or 
>>> whether the master queries on behalf of the slaves.  Might have to 
>>> support both models. In many cases, I think it's the latter: the 
>>> master queries using the slaves location and parameters.
>>> 
>>> The most common master/slave setup is tower and clients, right? The 
>>> tower has an Internet connection and can query the database. The 
>>> clients of the tower are the slaves.  Does the database query use 
>>> the location and type data of the slave or the master?
>>> 
>>> Brian
>>> 
>>> On Apr 18, 2012, at 10:51 AM, Peter McCann wrote:
>>> 
>>>> I think it would be a mistake to assume that the slave & master 
>>>> devices both have pre-existing relationships with the same database.
>>>> In a commercial service, the slave devices would all come from 
>>>> different manufacturers and would certainly have different owners.
>>>> Wouldn't we want them to interoperate with any master device, 
>>>> assuming they are RF-compatible?
>>>> 
>>>> -Pete
>>>> 
>>>> Rosen, Brian wrote:
>>>>> Doesn't the slave get it's database access through the master?
>>>>> If that's true, the problem you are worried about doesn't exist.
>>>>> 
>>>>> Brian
>>>>> 
>>>>> On Apr 18, 2012, at 10:37 AM, Peter McCann wrote:
>>>>> 
>>>>>> I agree with Brian that LoST could be a good model for 
>>>>>> discovering the appropriate database for the region you're in.  A 
>>>>>> nation may decide to subdivide their territory into provinces or 
>>>>>> states, each of which maintains its own database.
>>>>>> 
>>>>>> I think it would be a mistake to assume that there is a single, 
>>>>>> pre-defined relationship for one device with just one database. 
>>>>>> In particular, I think there is a thorny issue that will arise 
>>>>>> with management of secure credentials on whitespace devices, 
>>>>>> illustrated by the first use case in Section 4.2.1 of 
>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03.  Step 9 of that 
>>>>>> use case says:
>>>>>> 
>>>>>> 9.   Once the master/AP has met all regulatory domain
> requirements
>>>>>>      (e.g. validating the Device ID with the trusted database, etc)
>>>>>>      the master provides the list of channels locally available to
>>>>>>      the slave/user device.
>>>>>> My question is, what if the master device has a relationship with 
>>>>>> one database, but the slave device has a relationship with another?
>>>>>> How is the master's database supposed to validate the credentials 
>>>>>> of the slave device, if we don't have some sort of common trust 
>>>>>> anchor? Or will this "validation" be simply an insecure check of 
>>>>>> an ID against a whitelist/blacklist?  Who will allocate Device IDs?
>>>>>> Will they be specific to a particular database operator, or do we 
>>>>>> need some common top-level allocation format?
>>>>>> 
>>>>>> -Pete
>>>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>>

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

---

From: Peter McCann <[email-masked]>
Date: Thu, 19 Apr 2012 21:42:17 +0000

Hi, Gabor,

[email-masked] wrote:
>> The problem is, the master device cannot be authoritative on whether
>> the slave device is approved for use by the regulator.  It must rely
>> on the WSDB it uses (has a relationship with) to tell it.
>> 
>> At the least, we need a format for device identifiers that can be
>> understood by multiple independently operated databases.
>>

Agreed.

>> Maybe the WSDB trusts the master device to collect this information
>> securely from the slave devices using slave-to-master credentials.
>>
> <GB> yes, this is what at least the 802.11af draft amendment is
> currently defining for the 802.11 air interface. The slave sends its
> identifier to the master, then waits for the enablement signal. The
> enablement signal comes after the master was able to successfully
> validate the identifier of the slave with the DB.

Is there any security or spoofing protection defined in 802.11af?

>> Normally, the allocation authority for the identifier space would be a
>> trust anchor for the identifier-to-device binding.  I agree that the
>> master-to-slave interface is out of scope, but there should be some
>> mechanism in the marketplace for the master device operator to securely
>> bind the identifier presented by the slave to the communication channel
>> with the slave device, in the sense that the master device is able to
>> know in a secure way that the device it is talking to actually does own
>> the regulator-assigned device identifier. It seems natural for the
>> master device to rely on its relationship with a database to help with
>> this binding.
>> 
> <GB> I see two things here: binding between the
> communication channel and identity; and binding between the identity and
> the hardware to which it was assigned. The binding between the
> communication channel and the identity as presented by slave is there
> inherently in the radio. 

I don't understand this last statement.  Do you mean a cryptographically
secure binding?  What if I spoof my MAC address?

> The task to verify that the identity indeed
> belongs to the slave should not be the burden of the master device,
> rather the DB (if seen necessary). In order for the DB to verify that
> the presented identifier indeed belongs to that device, a client cert or
> sg similar would be needed. 

That seems reasonable to me.  The slave device has a client cert and
somehow demonstrates knowledge of the private key that goes with the
cert to the database.  After this, the database can send "I approve"
to the master device.  Assuming that both communication channels (slave
to master and master to database) have been authenticated and secured,
the master can then tell the slave to go ahead.

However, we now require the database be able to validate the credentials
of any slave device that may be manufactured/owned by someone other than 
the manufacturer/owner of the master device.  It would seem we need a 
nationally-scoped trust anchor to achieve this.

> Afaik, regulators do not require for client
> certs binding the identifier to the hardware. Therefore, the
> verification of whether the identifier is the correct one or not seems
> to be outside the scope of paws. The master should rely on the lower
> layers and the DB for this verification.

This statement really confuses me.  To me, a binding of an identifier
to hardware means that there is some tamper and copy-proof storage for
a private key epoxied into the wireless hardware.  This private key would
be used to authenticate & distribute keying material for a secure channel
between the slave and the master.  That part is indeed out of scope of 
PAWS, but the master-to-database messages to validate the slave's credentials
are not.

-Pete

>>> Right, the master queries the database on behalf of the slave, sending
>>> the slave's Device ID and location.  (See Don's message about
>>> associated with the ID, or is it an insecure check of a number against
>>> a whitelist?  If the former, we will need a credential management
>>> system that is able to cross between different databases. If the
>>> latter, I wonder if it opens up security problems.
>>> 
>>> -Pete
>>> 
>>> Rosen, Brian wrote:
>>>> Perhaps I am confused, but I think in a master/slave environment, the
>>>> slave does not query the database, the master does.  The slave gets
>>>> its allowed spectrum data from the master.  There is always the
>>>> slaves just get assignments within that database response, or whether
>>>> the master queries on behalf of the slaves.  Might have to support
>>>> both models. In many cases, I think it's the latter: the master
>>>> queries using the slaves location and parameters.
>>>> 
>>>> The most common master/slave setup is tower and clients, right?
>>>> The tower has an Internet connection and can query the database.
>>>> The clients of the tower are the slaves.  Does the database query
>>>> use the location and type data of the slave or the master?
>>>> 
>>>> Brian
>>>> 
>>>>>>> I agree with Brian that LoST could be a good model for discovering
>>>>>>> the appropriate database for the region you're in. A nation may
>>>>>>> decide to subdivide their territory into provinces or states, each
>>>>>>> of which maintains its own database.
>>>>>>> 
>>>>>>>      (e.g. validating the Device ID with the trusted database,
>>>>>>>      etc) the master provides the list of channels locally
>>>>>>>      available to the slave/user device.
>>>>>>> one database, but the slave device has a relationship with
>>>>>>> another? How is the master's database supposed to validate the
>>>>>>> credentials of the slave device, if we don't have some sort of
>>>>>>> common trust anchor? Or will this "validation" be simply an
>>>>>>> insecure check of an ID against a whitelist/blacklist?  Who will
>>>>>>> allocate Device IDs? Will they be specific to a particular
>>>>>>> database operator, or do we need some common top-level allocation
>>>>>>> format?
>>>>>>> 
>>>>>>> -Pete
>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
>>> 
> 
> 
>

---

From: <[email-masked]>
Date: Thu, 19 Apr 2012 22:14:39 +0000

Hi Pete,
My responses inline:

-----Original Message-----
From: ext Peter McCann [mailto:[email-masked]] 
Sent: Thursday, April 19, 2012 2:42 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley); [email-masked]
Cc: [email-masked]
Subject: RE: identity verification (was: Database Discovery Question)

Hi, Gabor,

Agreed.

Is there any security or spoofing protection defined in 802.11af?
<GB> It inherits whatever is in the 802.11 base spec, ie .1x

>> Normally, the allocation authority for the identifier space would be 
>> a trust anchor for the identifier-to-device binding.  I agree that 
>> the master-to-slave interface is out of scope, but there should be 
>> some mechanism in the marketplace for the master device operator to 
>> securely bind the identifier presented by the slave to the 
>> communication channel with the slave device, in the sense that the 
>> master device is able to know in a secure way that the device it is 
>> talking to actually does own the regulator-assigned device 
>> identifier. It seems natural for the master device to rely on its 
>> relationship with a database to help with this binding.
>> 
> <GB> I see two things here: binding between the communication channel 
> and identity; and binding between the identity and the hardware to 
> which it was assigned. The binding between the communication channel 
> and the identity as presented by slave is there inherently in the 
> radio.

I don't understand this last statement.  Do you mean a cryptographically secure binding?  What if I spoof my MAC address?
<GB> Assuming an RSN network, after the .1x procedure, there is a key derived to encrypt the STA to AP communication.
802.11af does not assume that the credentials the slave has to get authenticated with the master can in any way be used to prove the ownership of the identity. There's a set of credentials for slave-master authentication, and there might be (currently there is no requirement for it) another mechanism for the slave to prove to the db that it owns the identity it sent to the master.

> The task to verify that the identity indeed belongs to the slave 
> should not be the burden of the master device, rather the DB (if seen 
> necessary). In order for the DB to verify that the presented 
> identifier indeed belongs to that device, a client cert or sg similar 
> would be needed.

That seems reasonable to me.  The slave device has a client cert and somehow demonstrates knowledge of the private key that goes with the cert to the database.  After this, the database can send "I approve"
to the master device.  Assuming that both communication channels (slave to master and master to database) have been authenticated and secured, the master can then tell the slave to go ahead.

However, we now require the database be able to validate the credentials of any slave device that may be manufactured/owned by someone other than the manufacturer/owner of the master device.  It would seem we need a nationally-scoped trust anchor to achieve this.

<GB> I think this is the part which is outside the scope of our charter, which says: " 4. Ensure that the discovery mechanism, database access method,
and query/response formats have appropriate security levels in place. ". There is no mention about the db making sure the slave devices did not spoof their identity. Especially as regulators do not require slave devices to have a mechanism to be able to prove ownership of the identity. If I remember correctly, this was considered in FCC, but then the requirement was dropped.

> Afaik, regulators do not require for client certs binding the 
> identifier to the hardware. Therefore, the verification of whether the 
> identifier is the correct one or not seems to be outside the scope of 
> paws. The master should rely on the lower layers and the DB for this 
> verification.

This statement really confuses me.  To me, a binding of an identifier to hardware means that there is some tamper and copy-proof storage for a private key epoxied into the wireless hardware.  This private key would be used to authenticate & distribute keying material for a secure channel between the slave and the master.  That part is indeed out of scope of PAWS, but the master-to-database messages to validate the slave's credentials are not.

<GB> I think the confusion might come that you assume the private key in the slave (if existed at all) would also be used to authenticate the slave to the master. In my understanding that would not necessarily be the case. Even if there was a private key in the slave, the slave would acquire another set of (eg username/password) credentials, independent of the private key,  to connect to the master device. 

- Gabor

-Pete

>>> sending the slave's Device ID and location.  (See Don's message 
>>> about validating the FCC ID).  My question is, what is the security 
>>> model for validating the slave's ID?  Is there a secure credential 
>>>> gets its allowed spectrum data from the master.  There is always 
>>>> the question of whether the master queries on its own behalf and 
>>>> the slaves just get assignments within that database response, or 
>>>>>>> My question is, what if the master device has a relationship 
>>>>>>> with one database, but the slave device has a relationship with 
>>>>>>> database operator, or do we need some common top-level 
>>>>>>> allocation format?
>>>>>>> 
>>>>>>> -Pete
>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
>>> 
> 
> 
>

---

From: Peter McCann <[email-masked]>
Date: Fri, 20 Apr 2012 13:59:17 +0000

Hi, Gabor,

[email-masked] wrote:
>>>> The problem is, the master device cannot be authoritative on
>>>> whether the slave device is approved for use by the regulator.  It
>>>> must rely on the WSDB it uses (has a relationship with) to tell it.
>>>> 

Ok, so there are two sets of credentials.  One is a Network Access 
Identifier used within EAP between the slave and the master.  The 
second is a regulator-assigned identifier (such as an FCCID).
Although the NAI can be authenticated using e.g., AAA back-end servers,
it is NOT the same identifier that is used by the master to validate
the slave for purposes of regulatory compliance.
 
>>>> Normally, the allocation authority for the identifier space would
>>>> be a trust anchor for the identifier-to-device binding.  I agree
>>>> that the master-to-slave interface is out of scope, but there
>>>> should be some mechanism in the marketplace for the master device
>>>> operator to securely bind the identifier presented by the slave to
>>>> the communication channel with the slave device, in the sense that
>>>> the master device is able to know in a secure way that the device
>>>> it is talking to actually does own the regulator-assigned device
>>> <GB> I see two things here: binding between the communication
>>> channel and identity; and binding between the identity and the
>>> hardware to which it was assigned. The binding between the
>>> communication channel and the identity as presented by slave is
>>> there inherently in the radio.
>> 
>> I don't understand this last statement.  Do you mean a
>> cryptographically secure binding?  What if I spoof my MAC address?
>>
> <GB> Assuming an RSN network, after the .1x procedure, there is a key
> derived to encrypt the STA to AP communication.
> 802.11af does not assume that the credentials the slave has to get
> authenticated with the master can in any way be used to prove the
> ownership of the identity. There's a set of credentials for slave-
> master authentication, and there might be (currently there is no
> requirement for it) another mechanism for the slave to prove to the db
> that it owns the identity it sent to the master.

This is the critical decision we have to make.  Note that the identity
the slave sends for access authentication is different from the one it
sends for validation with the database.  Is there any cryptographic
credential whatsoever associated with this second identifier?  Why are
we checking it against a whitelist at all, if it can be easily spoofed
and replaced with another?

>>> should not be the burden of the master device, rather the DB (if
>>> seen necessary). In order for the DB to verify that the presented
>>> identifier indeed belongs to that device, a client cert or sg
>>> similar would be needed.
>> 
>> to the master device.  Assuming that both communication channels
>> (slave to master and master to database) have been authenticated and
>> secured, the master can then tell the slave to go ahead.
>> 
>> However, we now require the database be able to validate the
>> credentials of any slave device that may be manufactured/owned by
>> someone other than the manufacturer/owner of the master device.  It
>> would seem we need a nationally-scoped trust anchor to achieve this.
>> 
> <GB> I think this is the part which is outside the scope of our
> charter, which says: " 4. Ensure that the discovery mechanism,
> database access method, and query/response formats have appropriate
> security levels in place. ". There is no mention about the db making
> sure the slave devices did not spoof their identity. Especially as
> regulators do not require slave devices to have a mechanism to be able
> to prove ownership of the identity. If I remember correctly, this was
> considered in FCC, but then the requirement was dropped.

Ok, so the check at the database is pretty meaningless, because the FCCID
can be replaced with someone else's with no accountability.  What's to
prevent an attacker from spoofing someone else's FCCID, then behaving badly 
on the wireless channel in such a way that the FCCID needs to be put on a
blacklist?  It would be impossible to prevent this kind of DoS attack.

>> a private key epoxied into the wireless hardware.  This private key
>> would be used to authenticate & distribute keying material for a
>> secure channel between the slave and the master.  That part is indeed
>> out of scope of PAWS, but the master-to-database messages to validate
>> the slave's credentials are not.
> 
> <GB> I think the confusion might come that you assume the private key
> in the slave (if existed at all) would also be used to authenticate
> the slave to the master. In my understanding that would not
> necessarily be the case. Even if there was a private key in the slave,
> the slave would acquire another set of (eg username/password)
> credentials, independent of the private key,  to connect to the master device.

Ok, I now understand there will be two identifiers and one or two sets of
cryptographic credentials.  If there is only one cryptographic credential,
it will be associated with the network access (slave-to-master) link, and
you think the second cryptographic credential is just not needed.

-Pete

---

From: <[email-masked]>
Date: Fri, 20 Apr 2012 20:44:16 +0000

Sure, and I don't think anyone said otherwise.
The point we were debating is how to make sure the slave (mode 1) devices did not spoof their identity. Since regulators do not require the slave devices to have a crypto binding between the identifier and the hardware, the master who authenticates the slave using some other existing credentials, has no choice but to trust the slave will not spoof its identity.

-          Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Dave Halasz
Sent: Friday, April 20, 2012 6:58 AM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [paws] identity verification (was: Database Discovery Question)

My reading of paragraph 98 of FCC-10-174A1 indicates that regulators do require verification of the FCC-ID of Mode 1 devices by the database(s).
http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-10-174A1.pdf

  Dave H.

On Thu, Apr 19, 2012 at 6:14 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pete,
My responses inline:

-----Original Message-----
From: ext Peter McCann [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, April 19, 2012 2:42 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley); [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: identity verification (was: Database Discovery Question)

Hi, Gabor,

[email-masked]<mailto:[email-masked]> wrote:
>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
>> Of ext Peter McCann
>> Cc: [email-masked]<mailto:[email-masked]>

Agreed.

- Gabor

-Pete

> [email-masked]<mailto:[email-masked]>

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

---

From: <[email-masked]>
Date: Fri, 20 Apr 2012 22:34:45 +0000

Hi Dave, I don't read it that way. What that paragraph tells me is that the FFC ID is sent to the db which checks it against a white list to determine if a device with the presented FCCID was certified for white spaces operation.
But maybe some other folks more intimately familiar with FCC intentions could clarify.

-          Gabor

Sent: Friday, April 20, 2012 2:23 PM

Hi Gabor,

I'm confused by your second sentence. My read of paragraph 98 indicates the regulators do require a crypto binding. Of course, my interpretation can be wrong. Pasting in the section that has me concerned.
"To achieve the necessary protection of databases and connections between
devices and databases regarding channel availability, we are requiring that TV bands devices and
database systems employ security measures as follows.  First, we are requiring that, for purposes
of obtaining a list of available channels and related matters, fixed and Mode II TVBDs only be
capable of contacting databases operated by administrators designated by the Commission.  This
will prevent TV bands devices from obtaining channel lists from unauthorized databases which
may be invalid or inaccurate  - we are particularly concerned about potential cases where a
database would indicate as available channels that are used by authorized services.  We also are
specifying that TV bands databases must not provide lists of available channels to uncertified TV
bands devices for purposes of operation (it is acceptable for a TV bands database to distribute
lists of available channels by means other than contact with TVBDs) in order to avoid facilitating
the operation of unapproved and non-compliant devices.  To facilitate these restrictions, we are
requiring that database(s) verify that the FCC identification number (FCC ID) supplied by a
fixed or personal/portable TV bands device is for a certified device.  To implement this
provision, we are also requiring that database administrators obtain a list of certified TVBDs
from our Equipment Authorization System."

In particular, the following sentence,
"To facilitate these restrictions, we are
requiring that database(s) verify that the FCC identification number (FCC ID) supplied by a
fixed or personal/portable TV bands device is for a certified device."

To me, it sounds like they do want a binding of the FCC ID to the hardware.

  Dave H.
On Fri, Apr 20, 2012 at 4:44 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Sure, and I don't think anyone said otherwise.
The point we were debating is how to make sure the slave (mode 1) devices did not spoof their identity. Since regulators do not require the slave devices to have a crypto binding between the identifier and the hardware, the master who authenticates the slave using some other existing credentials, has no choice but to trust the slave will not spoof its identity.

-          Gabor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Dave Halasz
Sent: Friday, April 20, 2012 6:58 AM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] identity verification (was: Database Discovery Question)

  Dave H.

-----Original Message-----
From: ext Peter McCann [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, April 19, 2012 2:42 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley); [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: identity verification (was: Database Discovery Question)

Hi, Gabor,

Agreed.

- Gabor

-Pete