[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Scandium connection resumption vs. renegotiation
|
Hi,
> If the session resumption is done from a different peer, we wait that handshake was finished before to drop the previous connection.
This sound good for me.
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 Simon Bernard
Gesendet: Freitag, 26. Februar 2016 10:55
An: Californium (Cf) developer discussions
Betreff: Re: [cf-dev] Scandium connection resumption vs. renegotiation
Hi,
The specification [1] say :
"In cases where a server believes it has an existing association on a
given host/port quartet and it receives an epoch=0 ClientHello, it
SHOULD proceed with a new handshake but MUST NOT destroy the existing
association until the client has demonstrated reachability either by
completing a cookie exchange or by completing a complete handshake
including delivering a verifiable Finished message."
So just doing the cookie exchange seems accepted. But I agree with you this is not the most secure way.
Currently in scandium[2], there is 2 cases:
if the session resumption is done from the same peer (IP/port), we drop the previous connection immediately after the cookie exchange. (This is the case where the attacker steal the sessionID and the peer address, this looks like at a Man in the middle attack, in this case, The attacker has many other way to destroy the session) If the session resumption is done from a different peer, we wait that handshake was finished before to drop the previous connection.
So what I said before was a be confusing about shared session was a bit confused.
To be more clear: Currently in scandium we can have several connection for one sessionID (0 or 1 established + 0 or n handshaking) , but we have only one established connection for one sessionID.
[1]https://tools.ietf.org/html/rfc6347#section-4.2.8
[2]https://github.com/eclipse/californium/blob/master/scandium-core/src/main/java/org/eclipse/californium/scandium/DTLSConnector.java#L964
Le 26/02/2016 09:42, Kraus Achim (INST/ESY1) a écrit :
> 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-Renegotiat
> ion-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
_______________________________________________
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
