Achim,
if I understand correctly you are describing a case where an attacker has guessed (or eavesdropped) a session ID that is in use and can send a ClientHello from his own (valid) IP address and port to terminate the existing connection, right?
Seems you're right, what do you think, Simon?
Kai
Hi,
I'm afraid, that a session resumption may introduce a DoS attack possibility,
when the session ID is used to "discard" something BEFORE it's ensured,
that the Client_Hello using the session ID is from a client, which has proofen
to be the "right" one (for that proof I think, the "cookie" mechanism is not
enough).
RFC 5246, 7.4.2.1 client Hello:
"Warning: Because the SessionID is transmitted without encryption or
immediate MAC protection, servers MUST NOT place confidential
information in session identifiers or let the contents of fake
session identifiers cause any breach of security. (Note that the
content of the handshake as a whole, including the SessionID, is
protected by the Finished messages exchanged at the end of the
handshake.)"
So we should only "discard" something, if we have successfully reached the "finish".
With that in mind, I think we will have temporary more than one connection
per session ID.
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch Software Innovations GmbH
Communications (INST/ESY1)
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: Mittwoch, 24. Februar 2016 17:12
An: Californium (Cf) developer discussions
Betreff: Re: [cf-dev] Scandium connection resumption vs. renegotiation
About connection store even if this could do the job to return only the first connection for a particular sessionID, this is not really relevant as API since we said that for a sessionID we can have several connection ... And this will not be so easy to implement the Alert stuff without this.
So in a general way, I agree we should do that if we want to respect the spec which say that a session could be shared between several connection.
But I'm not sure we have real use case for now. So I prefer we don't support session sharing than implement it partially.
We should probably wait to see if there is needs about that.
Le 24/02/2016 16:32, Hudalla Kai (INST/ESY1) a écrit :
Very good point, Simon.
However, I think InMemoryConnectionStore supports keeping multiple Connections having the same session ID. Also, if a client wants to use an existing connection's state to negotiate a new connection based on the session ID, then it is irrelevant which of the (potentially) multiple existing Connections sharing this same session ID is returned by ConnectionStore.find(sessionID). In particular, the first matching Connection is fine.
What we currently do not support though, is what you dug out from the sepc regarding Alert handling. That is something we would need to add.
But would you in general agree that we should change Scandium's behavior according to my previous mail, i.e. keep the existing connection intact and let it time out (or not if the client keeps using it)?
Kai
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon Bernard
Sent: Wednesday, February 24, 2016 4:19 PM
To: Californium (Cf) developer discussions
Subject: Re: [cf-dev] Scandium connection resumption vs. renegotiation
Makes sense to me.
But this will involve more modification than that. I think in the current implementation we don't share session through connection.
The current connection only returns 1 connection for a given sessionID.
We should also mange this kind of thing :
"Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier MUST be invalidated, preventing the failed session from being used to establish new connections."[1]
We must see if we want to support sharing session before to do that.
[1] https://tools.ietf.org/html/rfc5246#section-7.2
Le 24/02/2016 13:41, Hudalla Kai (INST/ESY1) a écrit :
Hi Achim,
You are right, the server cannot really "recognize" this. Scandium currently "implicitly deduces" that this is the case from the fact that the client indicates the session ID of the previously established connection. However, this also means that a client currently cannot create an additional connection to the server based on an existing connection. I think we should change this behavior so that the server simply negotiates the additional connection with the client based on the existing connection and let the client decide whether it wants to continue to use both connections (old and new) or just the newly created connection. In the latter case the existing connection will simply time out on the server side and be "garbage collected".
Does that make sense?
Regards,
Kai
-----Original Message-----
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On Behalf Of Kraus Achim (INST/ESY1)
Sent: Wednesday, February 24, 2016 1:10 PM
To: Californium (Cf) developer discussions
Subject: Re: [cf-dev] Scandium connection resumption vs. renegotiation
Hi,
the wiki page mentions:
"The DTLSConnector running on the server side will recognize that the client's IP address/port has changed and will silently discard the previously established connection after the handshake has completed."
How does the server identify the client (to discard the old connection), if it could not use the address/port because this changed?
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch Software Innovations GmbH
Communications (INST/ESY1)
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
-----Ursprüngliche Nachricht-----
Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] Im Auftrag von Hudalla Kai (INST/ESY1)
Gesendet: Mittwoch, 24. Februar 2016 11:47
An: Californium (Cf) developer discussions
Betreff: [cf-dev] Scandium connection resumption vs. renegotiation
Hi,
Simon and I have been discussing for some time now about when and how a client would want to reconnect to a server and how these use cases are to be implemented according to the DTLS spec.
I have created a Wiki page [1] identifying some relevant real world use cases we would like to cover with Scandium. I would now like to use this thread to discuss the use cases and then gradually add information to the Wiki page so that we get a consistent picture over time and do not lose information.
So if you have any opinion regarding this topic I would be glad if you joined this thread :-)
[1] https://github.com/eclipse/californium/wiki/DTLS-Connection-Renegotiation-vs.-Resumption
Regards,
Kai
_______________________________________________
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
_______________________________________________
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
