Date   
Re: Intel EPID For Device Onboarding

Drasko DRASKOVIC
 

On Tue, Oct 31, 2017 at 2:16 PM, Gardner, Doug <Doug.Gardner@...> wrote:
Hello Drasko,

We have looked into EPID also. It is interesting if the customer is concerned about privacy (consumer). The issues with the system is you must get all your keys from Intel as they are the only EPID key provider today.
I actually understood that they pushed this as a open ISO standard, so
that everybody would be capable to implement both server side (key
production and storage) and device side SW.

They say in the paper:
"To help take Intel EPID adoption to the next level, Intel has
contributed Intel EPID technology to leading industry organizations
for certification. As a result, Intel EPID is now:
- An International Standards Organization standard for identity and
privacy (ISO/IEC 20008, 20009)
- A Trusted Computing Group (TCG) standard for attestation.
Intel has also made Intel EPID technology available to processor,
microcontroller, and device manufacturers as open source under the
Apache 2 license."

These are the standards they are mentioning:
https://www.iso.org/standard/57018.html and
https://www.iso.org/standard/50341.html.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: Intel EPID For Device Onboarding

Drasko DRASKOVIC
 

On Tue, Oct 31, 2017 at 2:18 PM, Zolfonoon, Riaz <riaz.zolfonoon@...> wrote:
At RSA, we have also looked into Intel SDO both jointly with Dell and separately before our merging. We came to the same conclusion as Jason mentioned. The solution solves a real need, but due to impact on the entire chain, from manufacturing to deployment, it will take time to gain traction in the market.

FYI, another option that RSA has looked into is FIDO and its attestation technique. Recently, FIDO formed a study group to explore the applicability and use cases for FIDO in IoT space. The objective was to explore if there are opportunities for FIDO to consider making the necessary changes to its specs to make them applicable to authentication of devices (in addition to today's focus which is user authentication). RSA was involved in this exercise. Among areas that the study group identified, one was FIDO attestation for IoT device onboarding. In this case, similar to EPID, silicon manufacturers need to engage as well, but the rest of the process is simpler than SDO. This work is still in progress and FIDO board is considering the recommendations from the study group.

I've also heard of some other proprietary methods discussed by vendors, but I'm not aware of any other standards. Does anyone know if OMA's LWM2M or other standards offer any secure onboarding solution that may already be implemented/deployed?
LwM2M has a very nice and simple onboarding method via separated
"Bootstrap" server. You can see explanation here:
https://medium.com/@vrmvrm/device-key-distribution-with-lightweight-m2m-36cdc12e5711
or in a few slides here:
https://www.slideshare.net/OpenMobileAlliance/oma-lwm2m-tutorial-by-arm-to-ietf-ace

It is described in details in the standard (i.e. boostraping procedure
is built into the standard).

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Questions on open source licenses

Zolfonoon, Riaz
 

Hi all,

 

Per our discussion in yesterday security working group meeting, here are few questions we identified to ask Linux Foundation regarding the licensing restrictions. Please let me know by COB tomorrow (Friday Nov 3rd) if there are additional questions to be included in this list. I will then send the combined list to Philip who offered to get us the answers.

 

1)      Are there general guidelines regarding license restrictions as we explore the use of open source packages in Edgex for services such as key management, secure proxy, etc?

2)      More specifically, could we use packages with MPL 2.0 or MIT license in EdgeX? If yes, what restrictions, if any, do we impose on the resulting work?

3)      As a concrete example, if we adopt HashiCop Vault package (MPL 2.0) for key management in EdgeX, it states the sources for any changes to the code need to be disclosed. Are the following considered changes to the code and hence trigger the said disclosure clause?

a.       Adding new extensions (plug-in) to Vault, using existing Vault extensibility APIs.

b.       Keeping the Vault API and replacing the entire implementation of the API.

Thanks,

Riaz

 

Riaz Zolfonoon | Distinguished Engineer | RSA | www.rsa.com | o: +1 781-515-7168 | c: +1 617-283-4822

 

EdgeX Security?

James Kempf <kempf42@...>
 

Hi,

I'm looking into using EdgeX for an application but there does not seem to be any code there for security, just a whitepaper. Even the architecture seems to treat security as a kind of "nice idea but optional" as a kind of sidecar add-on rather than integrated into the basic operation. In contrast to, for example, Azure Hub, which has security build into the basic operation, requiring either X.509 certs or lightweight tokens to register a device and for a device to connect. And not allowing incoming requests unless they are authorized.

Is there any code currently in process to fix this?

                 jak

Re: EdgeX Security?

White2, James
 

Hi James,

To date, we have not implemented security features.  We are currently working on some of the first security service implementations and it is our intention that security will be a major part of our California release.  You can checkout the Security Working Group meetings to see and hear (they are recorded) some of the work going on currently.



Jim White
Distinguished Engineer, Software Architect
Dell Technologies | End User Computing, Chief Technology Office (EUC CTO)
Office +1 512-723-6139, mobile/text +1 612-916-6693
james_white2@...


From: edgex-tsc-security-bounces@... <edgex-tsc-security-bounces@...> on behalf of James Kempf <kempf42@...>
Sent: Tuesday, December 19, 2017 10:21 PM
To: edgex-tsc-security@...
Subject: [Edgex-tsc-security] EdgeX Security?
 
Hi,

I'm looking into using EdgeX for an application but there does not seem to be any code there for security, just a whitepaper. Even the architecture seems to treat security as a kind of "nice idea but optional" as a kind of sidecar add-on rather than integrated into the basic operation. In contrast to, for example, Azure Hub, which has security build into the basic operation, requiring either X.509 certs or lightweight tokens to register a device and for a device to connect. And not allowing incoming requests unless they are authorized.

Is there any code currently in process to fix this?

                 jak

Auth Service

Drasko DRASKOVIC
 

Hi all,
I started writing a small Auth service that would live behind the
proxy and have 3 goals:
1) To create (register) a user (i.e. create a user account in MongoDB)
2) Login user (i.e. issue JWT token upon correct username + password)
3) Expose /auth API call so that all other API calls to other services
can be first redirected first to this service for Auth check

Basically - whole API of the service is here:
https://github.com/drasko/edgex-auth/blob/master/auth/server.go#L21-L27

This service would solve gateway protection on production level
(encrypted user credentials are kept in MongoDB, can be also written
in Vault in later versions), and I guess that first version can be
finished in a couple of days.

Would something like this be of interest?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: [Edgex-tsc] Auth Service

White2, James
 

Drasko,
Per our meeting yesterday, I think the answer is yes this would be of interest. We wholeheartedly accept such contributions for consideration into the upcoming release cycle. If you (Mainflux) or others are willing to build these that would be great.

As a community, we need to make sure any contribution, to include this proposed one, meet the architectural guideposts we have in place (and from our conversation yesterday, I think this one does but defer to the security experts for more affirmative reaction). And we, as a community as of yesterday, haven't set this out as something we need as MVP for California release, but would love to see it if you can make it happen.

As I understand it, I think this would be a good addition to what we talked about for AAA with regard to support of the Basic Auth option. I would encourage you to continue to share through the Security WG via Doug, David and Riaz and others your thoughts, progress and any requests to deviate from our resolutions about California that we made yesterday.

Jim
________________________________________
From: edgex-tsc-bounces@... <edgex-tsc-bounces@...> on behalf of Drasko DRASKOVIC <drasko@...>
Sent: Tuesday, January 16, 2018 11:53 PM
To: edgex-golang@...; edgex-devel@...; edgex-tsc@...; edgex-tsc-security@...; edgex-tsc-core@...; Dejan Mijic; Janko Isidorovic; darko@...; manuel@...; Nikola Marcetic
Subject: [Edgex-tsc] Auth Service

Hi all,
I started writing a small Auth service that would live behind the
proxy and have 3 goals:
1) To create (register) a user (i.e. create a user account in MongoDB)
2) Login user (i.e. issue JWT token upon correct username + password)
3) Expose /auth API call so that all other API calls to other services
can be first redirected first to this service for Auth check

Basically - whole API of the service is here:
https://github.com/drasko/edgex-auth/blob/master/auth/server.go#L21-L27

This service would solve gateway protection on production level
(encrypted user credentials are kept in MongoDB, can be also written
in Vault in later versions), and I guess that first version can be
finished in a couple of days.

Would something like this be of interest?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-TSC mailing list
EdgeX-TSC@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc

Re: [Edgex-tsc] Auth Service

Gardner, Doug
 

Drasko,
Absolutely, this is a great addition and will greatly help the developer environment. This dual approach that supports a simple username/password in addition to supporting the more secure OAuth2 will benefit our security position and allow us to better understand the tradeoffs

Thanks for your contribution!




Thanks
Doug Gardner
doug.gardner@...
Office: 813.559.6617

-------- Original message --------
From: James.White2@...
Date: 1/17/18 8:18 AM (GMT-05:00)
To: drasko@..., edgex-golang@..., edgex-devel@..., edgex-tsc@..., edgex-tsc-security@..., edgex-tsc-core@..., dejan.mijic@..., janko@..., darko@..., manuel@..., nikola@...
Subject: Re: [Edgex-tsc] Auth Service

Drasko,
Per our meeting yesterday, I think the answer is yes this would be of interest. We wholeheartedly accept such contributions for consideration into the upcoming release cycle. If you (Mainflux) or others are willing to build these that would be great.

As a community, we need to make sure any contribution, to include this proposed one, meet the architectural guideposts we have in place (and from our conversation yesterday, I think this one does but defer to the security experts for more affirmative reaction). And we, as a community as of yesterday, haven't set this out as something we need as MVP for California release, but would love to see it if you can make it happen.

As I understand it, I think this would be a good addition to what we talked about for AAA with regard to support of the Basic Auth option. I would encourage you to continue to share through the Security WG via Doug, David and Riaz and others your thoughts, progress and any requests to deviate from our resolutions about California that we made yesterday.

Jim
________________________________________
From: edgex-tsc-bounces@... <edgex-tsc-bounces@...> on behalf of Drasko DRASKOVIC <drasko@...>
Sent: Tuesday, January 16, 2018 11:53 PM
To: edgex-golang@...; edgex-devel@...; edgex-tsc@...; edgex-tsc-security@...; edgex-tsc-core@...; Dejan Mijic; Janko Isidorovic; darko@...; manuel@...; Nikola Marcetic
Subject: [Edgex-tsc] Auth Service

Hi all,
I started writing a small Auth service that would live behind the
proxy and have 3 goals:
1) To create (register) a user (i.e. create a user account in MongoDB)
2) Login user (i.e. issue JWT token upon correct username + password)
3) Expose /auth API call so that all other API calls to other services
can be first redirected first to this service for Auth check

Basically - whole API of the service is here:
https://github.com/drasko/edgex-auth/blob/master/auth/server.go#L21-L27

This service would solve gateway protection on production level
(encrypted user credentials are kept in MongoDB, can be also written
in Vault in later versions), and I guess that first version can be
finished in a couple of days.

Would something like this be of interest?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com<http://www.mainflux.com> | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-TSC mailing list
EdgeX-TSC@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc
_______________________________________________
EdgeX-TSC mailing list
EdgeX-TSC@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc

Re: [Edgex-tsc] Auth Service

Drasko DRASKOVIC
 

Hello,
great, thanks.

Idea is to provide simple and lightweight service that is between
simple NginX config file and full-blown OAuth2.0 provider. In contrast
to simple pre-configured config file it will be production-grade and
will offer dynamic operation (addition/removing of users/tokens).

Note that this microservice can be used for securing southbound also,
i.e. obtaining simple JWT tokens for devices (sensors).

Jim,
I agree that we should not necessarily put this for California MVP,
but service will be there for the people who want to experiment and do
lightweight integrations. This service will work without problems on
RPi. When we consider service tested we can promote it further.

I will prepare a few slides to explain the service, but it is very
simple and generic (actually so generic that it can be reused for any
project). So, if somebody wants to help, PRs gladly accepted here:
https://github.com/drasko/edgex-auth, I'll maintain the repo until it
is ready to be uploaded to official EdgeX GitHub.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

On Wed, Jan 17, 2018 at 2:39 PM, Gardner, Doug <Doug.Gardner@...> wrote:
Drasko,
Absolutely, this is a great addition and will greatly help the developer environment. This dual approach that supports a simple username/password in addition to supporting the more secure OAuth2 will benefit our security position and allow us to better understand the tradeoffs

Thanks for your contribution!




Thanks
Doug Gardner
doug.gardner@...
Office: 813.559.6617





-------- Original message --------
From: James.White2@...
Date: 1/17/18 8:18 AM (GMT-05:00)
To: drasko@..., edgex-golang@..., edgex-devel@..., edgex-tsc@..., edgex-tsc-security@..., edgex-tsc-core@..., dejan.mijic@..., janko@..., darko@..., manuel@..., nikola@...
Subject: Re: [Edgex-tsc] Auth Service

Drasko,
Per our meeting yesterday, I think the answer is yes this would be of interest. We wholeheartedly accept such contributions for consideration into the upcoming release cycle. If you (Mainflux) or others are willing to build these that would be great.

As a community, we need to make sure any contribution, to include this proposed one, meet the architectural guideposts we have in place (and from our conversation yesterday, I think this one does but defer to the security experts for more affirmative reaction). And we, as a community as of yesterday, haven't set this out as something we need as MVP for California release, but would love to see it if you can make it happen.

As I understand it, I think this would be a good addition to what we talked about for AAA with regard to support of the Basic Auth option. I would encourage you to continue to share through the Security WG via Doug, David and Riaz and others your thoughts, progress and any requests to deviate from our resolutions about California that we made yesterday.

Jim
________________________________________
From: edgex-tsc-bounces@... <edgex-tsc-bounces@...> on behalf of Drasko DRASKOVIC <drasko@...>
Sent: Tuesday, January 16, 2018 11:53 PM
To: edgex-golang@...; edgex-devel@...; edgex-tsc@...; edgex-tsc-security@...; edgex-tsc-core@...; Dejan Mijic; Janko Isidorovic; darko@...; manuel@...; Nikola Marcetic
Subject: [Edgex-tsc] Auth Service

Hi all,
I started writing a small Auth service that would live behind the
proxy and have 3 goals:
1) To create (register) a user (i.e. create a user account in MongoDB)
2) Login user (i.e. issue JWT token upon correct username + password)
3) Expose /auth API call so that all other API calls to other services
can be first redirected first to this service for Auth check

Basically - whole API of the service is here:
https://github.com/drasko/edgex-auth/blob/master/auth/server.go#L21-L27

This service would solve gateway protection on production level
(encrypted user credentials are kept in MongoDB, can be also written
in Vault in later versions), and I guess that first version can be
finished in a couple of days.

Would something like this be of interest?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com<http://www.mainflux.com> | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-TSC mailing list
EdgeX-TSC@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc
_______________________________________________
EdgeX-TSC mailing list
EdgeX-TSC@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc

Re: Auth Service

David Ferriera
 

Hi Drasko,

   This is a great start, thanks for the effort.  I will take a look at it.

   There are a couple of additional items that would be required to be complete:
  • Full CRUD operations on the user/identity including password change (password change by the user or admin only)
  • Root/Admin identity required including secure administration of the root/admin identity - only this identity can perform C and D ops above
  • Token validation endpoint  for the proxy to call - this would include token expiry validation
  • Code changes to the proxies to call the above endpoint with the token, handle responses and potentially translate for response to client
  • Work through the preferred auth flow (redirects are not preferred for a service to service flow)
  • For a complete solution, we will need some sort of ACLs/authorization rule capability - E.G., this identity can stop/start edgex services
  • Security validation of the solution for example:
    • Are the tokens signed and encrypted? If yes, where/how do you store the key(s), what algorithm?
    • How are the passwords stored (hashed not encrypted?), what algorithm?
    • Are the passwords readable (even hashed) by all other microservices?
    • How is key rotation handled?
   Some food for thought going forward about what we would need for something that is fully functional.  There are probably a few more. It would be great if you are willing to contribute all of the above.  If so, I think it would be a good choice to replace the heavier solution.  Let's discuss.

Thanks,
-David

On Wed, Jan 17, 2018 at 12:53 AM, Drasko DRASKOVIC <drasko@...> wrote:
Hi all,
I started writing a small Auth service that would live behind the
proxy and have 3 goals:
1) To create (register) a user (i.e. create a user account in MongoDB)
2) Login user (i.e. issue JWT token upon correct username + password)
3) Expose /auth API call so that all other API calls to other services
can be first redirected first to this service for Auth check

Basically - whole API of the service is here:
https://github.com/drasko/edgex-auth/blob/master/auth/server.go#L21-L27

This service would solve gateway protection on production level
(encrypted user credentials are kept in MongoDB, can be also written
in Vault in later versions), and I guess that first version can be
finished in a couple of days.

Would something like this be of interest?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com   |  Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division |   Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-TSC-Security mailing list
EdgeX-TSC-Security@lists.edgexfoundry.org
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-security



--
David Ferriera | Forgerock
Senior Director, Cloud Technology | Office of the CTO

Re: Auth Service

Domenico Rotondi <domenico.rotondi@...>
 

On 17 Jan 2018 at 6:53, Drasko DRASKOVIC wrote:
Hi all,
if of interest, in FINCONS SpA, we have developed, in the context of EU R&D
projects, a set of libraries (JavaScript and Java) and backend to manage login and
AuthZ using JWT tokens and other security features to increase the overall system
reliability. Everything is provided with the Apache V2 license.

From an architectural point of view our scenario envisages clients, an Authorization
Service and one or more "operational services" (in our case for example a document
store and a policy store).
As in token based systems, any request to any service has to include an explicit
authorization token that must be requested to the Authorization Service before
submitting the service request (this is managed internally by our libraries). Therefore,
on the service side there is no need to check user ID, access rights, etc.; the only
check is related to the correctness of the presented token.

Of course, the client needs initially to authenticate itself, but, in order to avoid having
to manage sensitive info like password on the backend, we actually use a
proof-of-ownership of the presented identity.
If the proof is successful then the client and the Authorization Service create a shared
secret which is used afterwards to manage token's requests from the client to the
Authorization Service.

If of interest we'll be happy to provide the SW. Of course no problem in providing
further details.
Ciao
Domenico

Hi all,
I started writing a small Auth service that would live behind the
proxy and have 3 goals:
1) To create (register) a user (i.e. create a user account in MongoDB)
2) Login user (i.e. issue JWT token upon correct username + password)
3) Expose /auth API call so that all other API calls to other services
can be first redirected first to this service for Auth check

Basically - whole API of the service is here:
https://github.com/drasko/edgex-auth/blob/master/auth/server.go#L21-L27

This service would solve gateway protection on production level
(encrypted user credentials are kept in MongoDB, can be also written
in Vault in later versions), and I guess that first version can be
finished in a couple of days.

Would something like this be of interest?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-TSC-Security mailing list
EdgeX-TSC-Security@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-security
----------------------------------------------------------------------
PERSONALE E CONFIDENZIALE
Questa mail potrebbe includere materiale confidenziale, proprietario o
altrimenti privato per l'uso esclusivo del destinatario.
Se l'avete ricevuto per errore, siete pregati di contattare chi ha inviato il
messaggio e di cancellarne tutte le copie.
Ogni altro uso da parte vostra del messaggio è proibito.
Se non ti è necessario, non stampare questo documento. Grazie

PERSONAL AND CONFIDENTIAL
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in error,
please notify the sender immediately and delete all the copies.
Any other use of the email by you is prohibited.
Please consider the environment before printing this email


---
This email has been checked for viruses by AVG.
http://www.avg.com

(Fwd) Re: Auth Service

Domenico Rotondi
 

Sorry for posting again, but my previous email was rejected having used my
company address.
Ciao
Domenico
------- Forwarded message follows -------
From: Domenico Rotondi <domenico.rotondi@...>
To: Drasko DRASKOVIC <drasko@...>
Subject: Re: [Edgex-tsc-security] Auth Service
Cc: edgex-golang@..., edgex-devel@...,
edgex-tsc@..., edgex-tsc-security@...,
edgex-tsc-core@..., Dejan Mijic <dejan.mijic@...>,
Janko Isidorovic <janko@...>, darko@...,
manuel@..., Nikola Marcetic <nikola@...>,
Diego Pedone <diego.pedone@...>, Leonardo Straniero <leonardo.straniero@...>
Date: Wed, 17 Jan 2018 15:52:36 +0100

On 17 Jan 2018 at 6:53, Drasko DRASKOVIC wrote:
Hi all,
if of interest, in FINCONS SpA, we have developed, in the context of EU R&D
projects, a set of libraries (JavaScript and Java) and backend to manage login and
AuthZ using JWT tokens and other security features to increase the overall system
reliability. Everything is provided with the Apache V2 license.

From an architectural point of view our scenario envisages clients, an Authorization
Service and one or more "operational services" (in our case for example a document
store and a policy store).
As in token based systems, any request to any service has to include an explicit
authorization token that must be requested to the Authorization Service before
submitting the service request (this is managed internally by our libraries). Therefore,
on the service side there is no need to check user ID, access rights, etc.; the only
check is related to the correctness of the presented token.

Of course, the client needs initially to authenticate itself, but, in order to avoid having
to manage sensitive info like password on the backend, we actually use a
proof-of-ownership of the presented identity.
If the proof is successful then the client and the Authorization Service create a shared
secret which is used afterwards to manage token's requests from the client to the
Authorization Service.

If of interest we'll be happy to provide the SW. Of course no problem in providing
further details.
Ciao
Domenico

Hi all,
I started writing a small Auth service that would live behind the
proxy and have 3 goals:
1) To create (register) a user (i.e. create a user account in MongoDB)
2) Login user (i.e. issue JWT token upon correct username + password)
3) Expose /auth API call so that all other API calls to other services
can be first redirected first to this service for Auth check

Basically - whole API of the service is here:
https://github.com/drasko/edgex-auth/blob/master/auth/server.go#L21-L27

This service would solve gateway protection on production level
(encrypted user credentials are kept in MongoDB, can be also written
in Vault in later versions), and I guess that first version can be
finished in a couple of days.

Would something like this be of interest?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-TSC-Security mailing list
EdgeX-TSC-Security@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-security
------- End of forwarded message -------



---
This email has been checked for viruses by AVG.
http://www.avg.com

Re: [Edgex-tsc] Auth Service

Vlado Handziski <handziski@...>
 

Hi all,

I also think that this approach of using JWT as short-term, single-use authorization tokens has benefits vs. using JWT as a pseudo session mechanism. I am not a security expert, but there seems to be a lot of general debate in the community over the usability of JWT in this context, i.e.:


I definitely see value in having a lightweight AAA, as proposed by Drasko, so one option to reduce the attack / error surface would be to use something like PAST instead: https://github.com/ericchiang/go-past

--Vlado



On Wed, 17 Jan 2018 at 16:02 Domenico Rotondi <domenico.rotondi@...> wrote:
On 17 Jan 2018 at 6:53, Drasko DRASKOVIC wrote:
Hi all,
if of interest, in FINCONS SpA, we have developed, in the context of EU R&D
projects, a set of libraries (JavaScript and Java) and backend to manage login and
AuthZ using JWT tokens and other security features to increase the overall system
reliability. Everything is provided with the Apache V2 license.

From an architectural point of view our scenario envisages clients, an Authorization
Service and one or more "operational services" (in our case for example a document
store and a policy store).
As in token based systems, any request to any service has to include an explicit
authorization token that must be requested to the Authorization Service before
submitting the service request (this is managed internally by our libraries). Therefore,
on the service side there is no need to check user ID, access rights, etc.; the only
check is related to the correctness of the presented token.

Of course, the client needs initially to authenticate itself, but, in order to avoid having
to manage sensitive info like password on the backend, we actually use a
proof-of-ownership of the presented identity.
If the proof is successful then the client and the Authorization Service create a shared
secret which is used afterwards to manage token's requests from the client to the
Authorization Service.

If of interest we'll be happy to provide the SW. Of course no problem in providing
further details.
Ciao
   Domenico

Hi all,
I started writing a small Auth service that would live behind the
proxy and have 3 goals:
1) To create (register) a user (i.e. create a user account in MongoDB)
2) Login user (i.e. issue JWT token upon correct username + password)
3) Expose /auth API call so that all other API calls to other services
can be first redirected first to this service for Auth check

Basically - whole API of the service is here:
https://github.com/drasko/edgex-auth/blob/master/auth/server.go#L21-L27

This service would solve gateway protection on production level
(encrypted user credentials are kept in MongoDB, can be also written
in Vault in later versions), and I guess that first version can be
finished in a couple of days.

Would something like this be of interest?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com   |  Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division |   Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-TSC-Security mailing list
EdgeX-TSC-Security@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-security
----------------------------------------------------------------------
PERSONALE E CONFIDENZIALE
Questa mail potrebbe includere materiale confidenziale, proprietario o
altrimenti privato per l'uso esclusivo del destinatario.
Se l'avete ricevuto per errore, siete pregati di contattare chi ha inviato il
messaggio e di cancellarne tutte le copie.
Ogni altro uso da parte vostra del messaggio è proibito.
Se non ti è necessario, non stampare questo documento. Grazie

PERSONAL AND CONFIDENTIAL
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in error,
please notify the sender immediately and delete all the copies.
Any other use of the email by you is prohibited.
Please consider the environment before printing this email


---
This email has been checked for viruses by AVG.
http://www.avg.com

_______________________________________________
EdgeX-TSC mailing list
EdgeX-TSC@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc

RPi -> 64-bit OS

Drasko DRASKOVIC
 

Hi all,
one thing to keep in mind is that official flavor od Debain that runs
on RPi, called Raspbian, is 32 bit. This might be problematic for some
apps, and in particular Docker (although this should be enabled via
Hypriot project:
https://www.raspberrypi.org/blog/docker-comes-to-raspberry-pi/).

This is something to keep in mind.

Tony,
does Ubuntu Core support RPi in 64-bit mode
(https://developer.ubuntu.com/core/get-started)?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: [Edgex-tsc-core] RPi -> 64-bit OS

Brad Kemp
 

If 32 bit is a problem, gentoo has a 64 bit distribution. You also can build a 64 bit from yocto.
Brad

Brad Kemp
brad@...
123 North Washington St, 3rd Floor, Boston. MA 02114
(o) 617-963-8104
(c) 617-291-9233
(f) 617-742-0242

On Jan 17, 2018, at 8:46 AM, Drasko DRASKOVIC <drasko@...> wrote:

Hi all,
one thing to keep in mind is that official flavor od Debain that runs
on RPi, called Raspbian, is 32 bit. This might be problematic for some
apps, and in particular Docker (although this should be enabled via
Hypriot project:
https://www.raspberrypi.org/blog/docker-comes-to-raspberry-pi/).

This is something to keep in mind.

Tony,
does Ubuntu Core support RPi in 64-bit mode
(https://developer.ubuntu.com/core/get-started)?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-TSC-Core mailing list
EdgeX-TSC-Core@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-core

Re: RPi -> 64-bit OS

espy
 

On 01/17/2018 11:46 AM, Drasko DRASKOVIC wrote:
Hi all,
one thing to keep in mind is that official flavor od Debain that runs
on RPi, called Raspbian, is 32 bit. This might be problematic for some
apps, and in particular Docker (although this should be enabled via
Hypriot project:
https://www.raspberrypi.org/blog/docker-comes-to-raspberry-pi/).
This is something to keep in mind.
Tony,
does Ubuntu Core support RPi in 64-bit mode
(https://developer.ubuntu.com/core/get-started)?
Yes, we have std Ubuntu Core images for rpi3. There are no std classic Ubuntu Server images for rpi3. We only have 32-bit server images for rpi2.

/t


Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor
www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France
LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: [Edgex-tsc-core] RPi -> 64-bit OS

espy
 

On 01/17/2018 11:53 AM, Brad Kemp wrote:
If 32 bit is a problem, gentoo has a 64 bit distribution. You also can build a 64 bit from yocto.
FYI, according to Jim, there is a 64-bit version of Raspbian, however one of my co-workers has mentioned that the Pi foundation doesn't recommend running 64-bit on the Pis, due to memory starvation and the fact that you'll quickly run into OOM problems. From what I've been told, running 64-bit on anything with less than 4GB of RAM isn't advised.

Regards,
/tony

Brad
Brad Kemp
brad@...
123 North Washington St, 3rd Floor, Boston. MA 02114
(o) 617-963-8104
(c) 617-291-9233
(f) 617-742-0242

On Jan 17, 2018, at 8:46 AM, Drasko DRASKOVIC <drasko@...> wrote:

Hi all,
one thing to keep in mind is that official flavor od Debain that runs
on RPi, called Raspbian, is 32 bit. This might be problematic for some
apps, and in particular Docker (although this should be enabled via
Hypriot project:
https://www.raspberrypi.org/blog/docker-comes-to-raspberry-pi/).

This is something to keep in mind.

Tony,
does Ubuntu Core support RPi in 64-bit mode
(https://developer.ubuntu.com/core/get-started)?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-TSC-Core mailing list
EdgeX-TSC-Core@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-core

Re: [Edgex-tsc-core] RPi -> 64-bit OS

Bryan Gartner
 

FYI,

SUSE has an aarch64 image for RPi3 -
https://www.suse.com/products/arm/raspberry-pi/ (I've been running one
of mine this way for more than a year now).

Llikewise you can find openSUSE 64bit variants as well -
https://en.opensuse.org/HCL:Raspberry_Pi3

On Wed, Jan 17, 2018 at 9:46 AM, Drasko DRASKOVIC <drasko@...> wrote:
Hi all,
one thing to keep in mind is that official flavor od Debain that runs
on RPi, called Raspbian, is 32 bit. This might be problematic for some
apps, and in particular Docker (although this should be enabled via
Hypriot project:
https://www.raspberrypi.org/blog/docker-comes-to-raspberry-pi/).

This is something to keep in mind.

Tony,
does Ubuntu Core support RPi in 64-bit mode
(https://developer.ubuntu.com/core/get-started)?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-TSC-Core mailing list
EdgeX-TSC-Core@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-core

Re: [Edgex-golang] [Edgex-tsc] Auth Service

Smith, Nick A <nick.a.smith@...>
 

Hi,

 

My 2 cents. Whilst in totality specifications like OAuth2 are complex it is perfectly possible and sensible from a security perspective to use subsets of their functionality. To that end whilst JWTs are far from perfect they have at least been studied to ascertain their attack surface and they have widespread support. Securing JWTs can be achieved by reducing the scope of their configuration i.e. disallowing insecure algorithms (RSA PKCS1.5, None) and making some of the optional headers mandatory (key ID etc).

 

I’d encourage the use of something like OpenID Connect Code Flow for authenticating humans whilst going for something simple for services like an OAuth2 Client Credentials Grant. Both result in the authenticating entity receiving a token that can be used in authorization later on, both have widespread adoption, both have had at least some security analysis and are relatively simple to integrate. Additionally the use of existing protocols enables existing identity federation services to be re-used. Creating more identity and credential repositories is more likely to reduce security than to help it.

 

None of this takes away from Drasko’s work as it’s possible to use his API in both an OAuth2 and OpenID Connect context (as identity verification is open to implementation; it could be via a shared key, username/password or some sort of 2FA) but those standards do enable better integration into existing infrastructures.

 

Nick

 

From: edgex-golang-bounces@... [mailto:edgex-golang-bounces@...] On Behalf Of Vlado Handziski
Sent: 17 January 2018 15:26
To: Domenico Rotondi
Cc: Drasko DRASKOVIC; edgex-tsc-core@...; edgex-golang@...; manuel@...; edgex-tsc-security@...; edgex-tsc@...; Nikola Marcetic; Dejan Mijic; edgex-devel@...; Leonardo Straniero; Diego Pedone
Subject: Re: [Edgex-golang] [Edgex-tsc] [Edgex-tsc-security] Auth Service

 

Hi all,

 

I also think that this approach of using JWT as short-term, single-use authorization tokens has benefits vs. using JWT as a pseudo session mechanism. I am not a security expert, but there seems to be a lot of general debate in the community over the usability of JWT in this context, i.e.:

 

 

I definitely see value in having a lightweight AAA, as proposed by Drasko, so one option to reduce the attack / error surface would be to use something like PAST instead: https://github.com/ericchiang/go-past

 

--Vlado

 

 

 

On Wed, 17 Jan 2018 at 16:02 Domenico Rotondi <domenico.rotondi@...> wrote:

On 17 Jan 2018 at 6:53, Drasko DRASKOVIC wrote:
Hi all,
if of interest, in FINCONS SpA, we have developed, in the context of EU R&D
projects, a set of libraries (JavaScript and Java) and backend to manage login and
AuthZ using JWT tokens and other security features to increase the overall system
reliability. Everything is provided with the Apache V2 license.

From an architectural point of view our scenario envisages clients, an Authorization
Service and one or more "operational services" (in our case for example a document
store and a policy store).
As in token based systems, any request to any service has to include an explicit
authorization token that must be requested to the Authorization Service before
submitting the service request (this is managed internally by our libraries). Therefore,
on the service side there is no need to check user ID, access rights, etc.; the only
check is related to the correctness of the presented token.

Of course, the client needs initially to authenticate itself, but, in order to avoid having
to manage sensitive info like password on the backend, we actually use a
proof-of-ownership of the presented identity.
If the proof is successful then the client and the Authorization Service create a shared
secret which is used afterwards to manage token's requests from the client to the
Authorization Service.

If of interest we'll be happy to provide the SW. Of course no problem in providing
further details.
Ciao
   Domenico

Hi all,
I started writing a small Auth service that would live behind the
proxy and have 3 goals:
1) To create (register) a user (i.e. create a user account in MongoDB)
2) Login user (i.e. issue JWT token upon correct username + password)
3) Expose /auth API call so that all other API calls to other services
can be first redirected first to this service for Auth check

Basically - whole API of the service is here:
https://github.com/drasko/edgex-auth/blob/master/auth/server.go#L21-L27

This service would solve gateway protection on production level
(encrypted user credentials are kept in MongoDB, can be also written
in Vault in later versions), and I guess that first version can be
finished in a couple of days.

Would something like this be of interest?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com   |  Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division |   Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-TSC-Security mailing list
EdgeX-TSC-Security@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-security
----------------------------------------------------------------------
PERSONALE E CONFIDENZIALE
Questa mail potrebbe includere materiale confidenziale, proprietario o
altrimenti privato per l'uso esclusivo del destinatario.
Se l'avete ricevuto per errore, siete pregati di contattare chi ha inviato il
messaggio e di cancellarne tutte le copie.
Ogni altro uso da parte vostra del messaggio è proibito.
Se non ti è necessario, non stampare questo documento. Grazie

PERSONAL AND CONFIDENTIAL
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in error,
please notify the sender immediately and delete all the copies.
Any other use of the email by you is prohibited.
Please consider the environment before printing this email


---
This email has been checked for viruses by AVG.
http://www.avg.com

_______________________________________________
EdgeX-TSC mailing list
EdgeX-TSC@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc

Reverse proxy footprint

Dellabianca, Alberto
 

Hi all,

 

I would like to share some comments related to the ongoing discussion about the footprint of some proposed Reverse Proxy. I saw on slide #9 form the last meeting that “Size of proposed containers are large”.

Please look at the below.

 

 

EdgeX Mongo is 20x times bigger than nginx.

The container size of both options does not look bad unless for some reason we cannot use the alpine version.

 

I’d like to know your thoughts about this.

 

Thanks

Alberto