Hi,
About the PSK issue, If the server try to talk to a client, there should know that client and so it know which Identity is must used.
(In Scandium, there is a String getIdentity(InetSocketAddress inetAddress) on PSKStore to help to do that)
About the Exchanging role, if you use DTLS to secure a pur CoAP connection in a more peer to peer way,
you are in the case there is not really an Applicative Server and an Application Client. "Client" just means "initiate the connection".
The "IP to identity" mapping may be unreliable for dynamic IP addresses.
In my opinion, having "roles" therefore helps to make the PSK handshake reliable.
So we will see, how robust "PSK without roles" will work in the "real live".
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch Software Innovations GmbH
Communications (INST/ESY4)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com
achim.kraus@xxxxxxxxxxxx
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] Im Auftrag von Simon Bernard
Gesendet: Freitag, 2. Oktober 2015 12:54
An: cf-dev@xxxxxxxxxxx
Betreff: Re: [cf-dev] Californium/Scandium; Server side sending "ClientHello"
Sorry Achim, I don't give you the right commit link :/, this is fixed in this commit 55d9d668e99789f7864a0379f821f1c42734055c which will be integrated in master as soon as we get a new californium release.
About the HelloRequest and renegociation, Maybe I missunderstand the spec but :
https://tools.ietf.org/html/rfc5246#section-7.4.1.1 :
"HelloRequest is a simple notification that the client should begin the negotiation process anew."
https://tools.ietf.org/html/rfc5246#section-7.4.1.2 :
" When a client first connects to a server, it is required to send the ClientHello as its first message. The client can also send a ClientHello in response to a HelloRequest or on its own initiative in order to renegotiate the security parameters in an existing connection."
About the PSK issue, If the server try to talk to a client, there should know that client and so it know which Identity is must used. (In Scandium, there is a String getIdentity(InetSocketAddress inetAddress) on PSKStore to help to do that)
About the Exchanging role, if you use DTLS to secure a pur CoAP connection in a more peer to peer way, you are in the case there is not really an Applicative Server and an Application Client. "Client" just means "initiate the connection".
Le 02/10/2015 09:39, Kraus Achim (INST/ESY4) a écrit :
Hi,
Since commit 7a1473683d544c41b7ab2374b21e9748c8d7d49f, Leshan should not send CLOSE_NOTIFY on deregistration.
Mystic to me. As far as I know, "deregister" is not handled in the "handlePOST", which was changed by that commit,
it's handled in " handleDELETE" where the close() is still called.
So, how did you test your statement above, that Leshan doesn't send CLOSE_NOTIFY on deregister?
But by the way "close()" is discussed in bug #478535, may be the information should be better reported there.
In this case the Leshan Server will be the Client at DTLS meaning and so send a ClientHello. (This is not a renegotiation)
Exchanging the roles in the handshake is on my opinion still wrong (and dangerous), at least for PSK (see arguments below in my first message).
I could not find any evidence, that exchange the handshake role is intended and reliable behavior. So, if you have some information how DTLS
handshake would work reliable with exchanged roles, it would be great, if you can share this.
According TLS, RFC 5246
"7.4.1.1. Hello Request
When this message will be sent:
The HelloRequest message MAY be sent by the server at any time."
a "Hello Request" could be used "at any time", so I don't see that it must be a "renegotiation" (if you ment that).
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch Software Innovations GmbH
Communications (INST/ESY4)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com
achim.kraus@xxxxxxxxxxxx
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] Im Auftrag von Simon Bernard
Gesendet: Donnerstag, 1. Oktober 2015 18:39
An: Californium (Cf) developer discussions
Betreff: Re: [cf-dev] Californium/Scandium; Server side sending "ClientHello"
Hi,
Since commit 7a1473683d544c41b7ab2374b21e9748c8d7d49f, Leshan should not send CLOSE_NOTIFY on deregistration.
About the "HelloRequest", as I understand the spec this should be used by the server to ask for a new renegotiation(also called "rehandshake") in an existing connection.
(see https://tools.ietf.org/html/rfc5246#section-7.4.1.1 and https://tools.ietf.org/html/rfc5246#section-7.4.1.2)
In your case, the CLOSE_NOTIFY close the DTLS connection, then the Leshan server want to respond to the Leshan client, but as there is no connection, the Leshan Server will initiate a new handshake for a new connection. In this case the Leshan Server will be the Client at DTLS meaning and so send a ClientHello. (This is not a renegotiation)
Simon
Le 25/09/2015 17:12, Kraus Achim (INST/ESY4) a écrit :
Hi All,
I'm not sure, if my observation is a "feature" or "bug", so I just report it (and didn't use the "bug-report"):
Setup:
Leshan Client using DTLS/PSK
Leshan Server
Both using Californium/Scandium.
When the lwm2m-client deregisters (lwm2m operation), the lwm2m-server response with a message and then closes the dtls session.
Sometimes this is executed by scandium in reverse order, because the message is sent "async via a queue" but the close is executed "sync".
If the execution is reversed, the server tries to send the response message without a DTLSSession and therefore starts a new handshake
with a "ClientHello" (see log below). But in my opinion, this is wrong. The server should send a "HelloRequest".
RFC 6347, page 23, says
"When the server desires a rehandshake, it transitions from the
FINISHED state to the PREPARING state to transmit the HelloRequest.
When the client receives a HelloRequest, it transitions from FINISHED
to PREPARING to transmit the ClientHello."
May be this doesn't clearly cover the situation above, but when the server sends a "ClientHello", the roles in the PSK
Handshake are exchanged. Therefore the server (now the handshake client) have to guess the "PSK identity" using the ip-address.
Using the "HelloRequest" will preserve the roles and therefore the handshake would run as "usual".
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch Software Innovations GmbH
Communications (INST/ESY4)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com
achim.kraus@xxxxxxxxxxxx
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
######################################## wireshark log ###############################################################
(client sends deregister)
No. Time Source Destination Protocol Length Info
88 13.647679000 192.168.10.111 192.168.10.103 DTLSv1.2 93 Application Data
(server close)
No. Time Source Destination Protocol Length Info
89 13.692304000 192.168.10.103 192.168.10.111 DTLSv1.2 73 Encrypted Alert
(server send "Client Hello", PSK handshake roles exchanged!)
No. Time Source Destination Protocol Length Info
90 13.747024000 192.168.10.103 192.168.10.111 DTLSv1.2 147 Client Hello
No. Time Source Destination Protocol Length Info
91 13.758528000 192.168.10.111 192.168.10.103 DTLSv1.2 102 Hello Verify Request
_______________________________________________
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
_______________________________________________
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
