5

I am trying to implement a DTLS server using OpenSSL. I can get app data through, but when the client and server have negotiated, I have noticed that the session_id is null on the server.

Checking the code, more specifically ssl_sess.c, session_id_length is explicitly set to zero, the comments refer to RFC4507.

My question is when the connection is negotiated, what ID can I use to uniquely identify a client?

I have noticed that on the client side, the session id seems to be calculated from the ticket, but this does not seem to happen on the server.

Jonas
  • 121,568
  • 97
  • 310
  • 388
Fredrik Jansson
  • 3,764
  • 3
  • 30
  • 33

1 Answers1

4

Same as you would with any datagram-based application. Per RFC 4347 (Datagram Transport Layer Security):

Note that unlike IPsec, DTLS records do not contain any association identifiers. Applications must arrange to multiplex between associations. With UDP, this is presumably done with host/port number.

(Emphasis mine)

From your comment, it looks like you're actually trying to maintain state across "sessions" (a vague but probably applicable descriptor). Maintaining state across "sessions" is an application-layer problem. (D)TLS is transport-layer (hence the name).

Strictly speaking, the application running over (D)TLS needs to have its own concept of a "client ID" which gets sent by the client to the server. There are innumerable ways to deal with that, depending on the nature of your application and your security requirements (username+password of course is the most common).

Another option is to use client-side certificates as a substitute for an independent application-layer ID, but that still requires the application layer to understand what is going on and associate the client's certificate with the permanent state information. Annoyingly, this requires the management of a separate certificate for every single client. This is sufficiently burdensome that most people don't take this route. It does have advantages, e.g. users can't exactly pick a bad password or write it on a sticky note on their monitor. On the other hand, if someone gets access to the file the certificate is stored in, it's game over anyway.

Of course, many books could be (and have been with great frequency) written on the subject of security and authentication...

Community
  • 1
  • 1
Nicholas Knight
  • 15,774
  • 5
  • 45
  • 57
  • Thanks for your answer! If a client changes IP address and/or source port, there is no way of telling that client has previously been connected? What I am looking for is to be able to have a state (outside DTLS) for each unique client, and when a client comes back, I would like to be able to look that state up. – Fredrik Jansson May 30 '11 at 11:26
  • @Fredrik: I think I see where you're getting hung up now. Check my updated answer. – Nicholas Knight May 30 '11 at 12:06
  • Thanks, I guess I have been a bit vague. Regardless of authentication, if I had had a session ID, I would have expected that session id to be the same after an abbreviated handshake. Now, as far as I can see, if a client does an abbreviated handshake, I have no way of looking up that old session data. With a session ID I could key application data on the session ID and look that up. If you can prove me wrong, you have saved my day! – Fredrik Jansson May 30 '11 at 15:04