[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Request for feedback on mixing different DTLS modes
|
Hi Ludwig,
so try the approach using the senders identity to decide on the permissions.
Mit freundlichen Grüßen / Best regards
Achim Kraus
(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
-----Original Message-----
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ludwig Seitz
Sent: Donnerstag, 31. August 2017 14:38
To: cf-dev@xxxxxxxxxxx
Subject: Re: [cf-dev] Request for feedback on mixing different DTLS modes
On 2017-08-31 12:23, Kraus Achim (INST/ECS4) wrote:
> Hello Ludwig,
>
> I'm not sure, If I understand, what you want exactly to achieve.
>
Sorry I've not been clear enough.
I'll try to elaborate on the scenario:
I have a client and a server that are supposed to use DTLS-PSK to secure communications.
The client has the PSK but the server has not. Thus the client first needs to send something (the access token) to the server that contains the PSK.
(Background: A trusted third party (the Authorization Server) encrypts the PSK for the server inside that access token).
Thus I'd need the server to provide a resource that does not require DTLS-PSK (for example one that uses plain CoAP or DTLS-RPK without client authentication) to which the client can POST said access token.
/Ludwig
> Using branch 2.0, the CoapResource has:
>
> public void handleRequest(final Exchange exchange)
>
> overriding that you may access
>
> exchange.getCurrentRequest().getSenderIdentity()
>
> the senders identity and then check the instanceOf of that identity (e.g. PreSharedKeyIdentity or RawPublicKeyIdentity).
>
> So you could decide based on that identity to either call the "super.handleRequest()" or to response with an error.
>
>
> Mit freundlichen Grüßen / Best regards
>
> Achim Kraus
>
> (INST/ECS4)
> Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332
> Waiblingen | GERMANY | www.bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411
> B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
> Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
> -----Original Message-----
> From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Ludwig Seitz
> Sent: Dienstag, 29. August 2017 11:01
> To: cf-dev@xxxxxxxxxxx
> Subject: [cf-dev] Request for feedback on mixing different DTLS modes
>
> Hello,
>
> I'm trying to achieve a specific functionality which doesn't seem to be supported at the moment, and I'd like some input how to solve this (or why you think it's a bad idea):
>
> I'd like a server where all resources except one are protected with DTLS-PSK, the exception resource could e.g. use DTLS-RPK or plain CoAP.
>
> The reason for this is the work done at IETF in the ACE working group (https://datatracker.ietf.org/group/ace/). In short I need a way for a client that has no prior relationship to a server to submit some data (an access token) that establishes the DTLS-PSK they are going to use (among other things).
>
> Regards,
>
> Ludwig
> --
> Ludwig Seitz, PhD
> Security Lab, RISE SICS
> Phone +46(0)70-349 92 51
> _______________________________________________
> cf-dev mailing list
> cf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cf-dev
> _______________________________________________
> cf-dev mailing list
> cf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cf-dev
>
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cf-dev
