Simon,
yes you are right, we need to get a consistent Californium milestone out of the garage first …
We already discuss this on the Cf mailing list. I hope we will be able to do that soon.
From: leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx]
On Behalf Of Simon Bernard
Sent: Thursday, June 18, 2015 3:10 PM
To: leshan developer discussions
Subject: Re: [leshan-dev] Time for a milestone release
I missed there is not californium.core release with the new request.getSenderIdentity(); API.
Kai,
If we do a release with scandium 1.0.0-M4, we will not integrate the main changes arround "Principal" modification.
Does it still make sense to release a version of leshan based on scandium 1.0.0-M4 ?
If yes, we need to release a version which depends of californium.core 1.0.0-M3, scandium 1.0.0-M4 and element-connector 1.0.0-M4, that's right ?
If it's planned to release a new version of californium.core soon, we should maybe wait for this one ?
Simon
Le 16/06/2015 18:12, Simon Bernard a écrit :
I made some tests with scandium 1.0.0-M4, it seems ok.
We can make a release at the end of the week based on this version of scandium.
I also tested the master of scandium, it seems ok too. We could release a new leshan version later, based on scandium 1.0.0-M5, probably with X.509 certificate support. (still in development on our side), maybe with the client Registry issue too [1].
(For the Principal.getName(), I will reconsider the question again ^^)
[1] https://github.com/eclipse/leshan/pull/16
Le 12/06/2015 15:58, J.F. Schloman a écrit :
On Fri, Jun 12, 2015 at 3:02 AM, Hudalla Kai (INST/ESY) <Kai.Hudalla@xxxxxxxxxxxx> wrote:
Hi leshan committers,
just wanted to come back to this because I have created M4 of Scandium in the meantime
which contains all of the changes we discussed and also provides for automatic session expiration my means of parameters to InMemorySessionStore’s constructor (max number of sessions, expiration time).
Regarding the issues you raised:
You will still be able to define which kind of authentication the client must use because
the Principal.getName() method returns
-
The pre-shared key for clients who authenticated using PSK
-
The Subject DN of the client’s X.509 certificate if the client authenticated using X.509
-
The named identity (URI) containing the hash of the client’s raw public key if the client authenticated using RPK
This means that you can easily constrain the way a client must authenticate by simply
putting the desired type of name (as returned by Principal.getName()) to your SecurityInfo.
I do not see why this would make it harder to initialize the PSK store, simply because
you put the same information into it as before …
I would actually like to push forward on a new leshan milestone based on at least Scandium
M4 because so much has changed because M3 and M4 and I would prefer not to answer any more questions regarding leshan DTLS problems based on Scandium M3 …
Matthias (Kovatsch) wants to synchronize all Californium modules to the same milestone
version (M5 that would be). I would then suggest to adopt that version in leshan quickly and do a new leshan milestone based on Californium M5. Does that feel right for you guys?
Kai
(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
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
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
_______________________________________________
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
_______________________________________________
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
|
