[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: evaluation of draft-van-beijnum-multi6-odt-00.txt

On 9-jan-04, at 12:32, marcelo bagnulo wrote:

I have tried to spot the security measures used in the draft and i fond
that:


in section 6 you say that:
    The ODT authentication information consists of a secret or
    semi-secret key that each side announces to its correspondent.


How is this key obtained? is the key that it is sent in step 2 of the
procedure described in section 8 (as a challenge)
Or is it another key

Ok, simple scenario: an ODT-enabled host opens a TCP session towards a host it hasn't communicated with recently. The first TCP SYN packet then gets an ODT header that has two functions:

1. Signal to the other side that we support ODT
2. Set up a shared secret that can be used to authenticate subsequent packets

Now this happens in the clear so maybe "secret" is a bit too strong a word. Obviously it would be possible to add some crypto here, but I don't think this makes sense as we already have IPsec and TLS. I tried coming up with some non-public crypto authentication but I can't solve man in the middle without tight control over the timing, which makes the whole thing too complex to be worth the trouble.

If people want to use IPsec to protect ODT (but not the actual data) that would be possible by making the ODT layer send the initial setup packets as independent packets rather than tag along with upper layers, and then set up a policy that either allows or requires the ODT protocol to be encrypted.

Then you say that this key can be protected using IPsec, but in this case
how is the IPSec SA established between two generic nodes on the internet
(where no previous interaction can be assumed)

Add PKI and stir. :-)

I'm not really joking, though. If the communication is sensitive, some kind of encryption must be used, so on some level this problem must have been solved anyway. That's why I want to see if we can do some layer violating and use SSL/TLS (maybe even SSH?) state to get ODT keys across in a more secure manner.

If there is no encryption of the actual data over an insecure link, then I don't see how the data is sufficiently sensitive that the redirection attack that is possible with clear-text keys is a show stopper.