Re: [SWMP] My understanding so far

[Roland Weber <[e-mail]>]

Hi Jay,

sorry for the late reply, I had little time to spare.

Jay C. Weber wrote:
> Roland Weber wrote:
>> Tickets are used similar to session cookies. When a network
>> element X opens the initial channel to Y, it sends a message
>> "HELLO, I am X and here is your ticket YtoX for contacting me".
> Yes and tickets usually have an expiration time/date (a date is part of the 
> ticket and the whole thing is digitally-signed to prevent tampering) in order to 
> address the man-in-the-middle attacks to which you alluded before.

In the web world, there is a distinction between session cookies
(like jsessionid) with an inactivity timeout, and authentication
cookies (like the LTPA cookie in WebSphere Application Server),
which have an expiration time.
The LTPA cookie fits your description: it is encrypted and has
an expiration time, in addition to user credentials. It is used
for Single Sign-On: one server issues the ticket, others receive
and verify it. However, the session is tracked by the standard
jsessionid.
In SWMP, as discussed so far, the ticket is only sent back to
the server where it came from. That server will probably not
bother to decrypt it, since it can just as well compare the
encrypted data bit by bit. I don't really see the purpose of
the encryption here. Since a timestamp is encrypted, it will not
be possible to guess from one ticket what the next will be. But
that would also be achieved by any cryptographically strong
pseudo random number generator. On the other hand, expiration
of the ticket requires re-issuing tickets during a session.

A ticket that is simply copied into a message will not protect
against man-in-the-middle attacks. The MITM can take it from
the intercepted message and pass it on in a modified message.
As discussed so far, an attacker doesn't even need to be in the
middle. It is sufficient to spy on one UDP packet to hijack the
respective channel in the direction of the sent packet. Just
fire a few messages with the ticket, and increment the message
IDs by 5 instead of 1 each time. The receiver will accept the
forged messages because they have the correct ticket, and
ignore all messages from the genuine sender because their ID
is too low.
Switching to a hashing technique has some advantages over
this, though at the price of hash computation. Firstly, the
ticket is only sent in plain during the initial handshake on
the main TCP channel. The hash in the UDP packets will not
allow an eavesdropper to guess the ticket and forge messages.
If the hash is computed over the message header only, MITM
attacks are still possible. If the hash is computed over the
full message, message integrity can be verified. A MITM could
still selectively drop messages, but not forge them. If so
desired, the ticket exchange on the main channel can be
protected by standard mechanisms like TLS or SASL.
Secondly, the paper says that ticket size is not fixed. So
a server might have some clients that use a 32 bit random
number as the ticket, and others that use 3 kbyte BLOBs as
tickets. If updates are to be sent to all clients, those
with a large ticket would need different and more messages
than those with the small tickets.

We can discuss that stuff in detail when we tackle authentication.
As long as anyone can connect to anyone else and get a ticket,
MITM attacks are pretty pointless ;-) Does your implementation
have authentication mechanisms in place?

cheers,
  Roland

_______________________________________________
SWMP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/swmp