Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [leshan-dev] Time for a milestone release
(sry for the late response)
If I understand well, you propose to change the way to register SecurityInfo for a client. You propose to remove presharedKey/rawPublicKey info and replace that by a single String.
I see 2 disadvantages :
  - we don't know anymore which kind of authentication the client must use. (maybe this is not a problem)
  - This will be harder to initialize the pskStore.
We could keep this idea in mind and rethink about that when we will have an other implementation of leshan based on another transport/security layer to see which kind of abstraction is easier to use.


Le 30/04/2015 08:37, Hudalla Kai (INST/ESY) a écrit :

Of course you are right that for the current implementation of leshan – (pre-)registering a (binary) PublicKey – this would not be a great improvement J However, given that there are multiple ways of authenticating a client (Certificate, RawPublicKey and PSK) we could instead (pre-)register the string representation of the expected clients’ identities along with their valid endpoint addresses/IDs. It then doesn’t make any difference if the client provided a RawPublicKey, a Certificate or a PSK identity, they will all be mapped to a string representation (by the Principal.getName()) method and you can then use that name and the endpoint provided by the LWM2M client in its registration request to authorize the client. Does that make sense to you?

 

Kai

 

From: leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon Bernard
Sent: Wednesday, April 29, 2015 5:30 PM
To: leshan developer discussions
Subject: Re: [leshan-dev] Time for a milestone release

 

You're assuming right :)
But I don't see why the name information URI format is simpler?
In fact the leshan API propose a way to (pre-)register the public key. I think this make sense to use the PublicKey abstraction for that.
(Leshan does not presume how the user will create the keys)

So we will have PublicKey as input, we can change it to a name information URI to be able to compare it to Principale.getName(), but It seems a bit strange to do that as the RawPublicKeyIdentity will also do the same thing. (taking the publicKey as input and change it to niURI)
I think having a getKey on RawPublicKeyIdentity make sense. Am I wrong ?

Le 29/04/2015 16:11, Hudalla Kai (INST/ESY) a écrit :

Simon,

 

regarding your usage of the PublicKey:

 

Am I right in assuming that you keep a Map<InetSocketAddress, PublicKey> which you use to verify that a LWM2M client’s endpoint address matches the (pre-)registered PublicKey?

If this is the case, couldn’t you simply use a Map<InetSocketAddress, String> where you use the Principal.getName() as the value? At least this is how the CoAP spec envisions the usage of RawPublicKeys, using a hash of the SubjectInfo structure as defined by RFC 6920 [1]. This is exactly what RawPublicKeyIdentity.getName() returns …

 

Or are you doing any cryptographic verification based on the PublicKey?

 

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

 

Regards,

Kai

 

From: leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon Bernard
Sent: Wednesday, April 29, 2015 11:49 AM
To: leshan developer discussions
Subject: Re: [leshan-dev] Time for a milestone release

 

Ok I did the modification. It's ok now.
Thx a lot Kai !
(About the use of the PublicKey we just need it to verify if the couple client endpoint/publickey is valid. To avoid that a client which has a good public/private key at dtls level can usurp the identity of another client. We use the class PublicKey as it seems a good java abstraction for public key, we could also use a byte[] but is not so clear cause of the different key encoding formats)


 




_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/leshan-dev

 



_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/leshan-dev

Back to the top