[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Non-member submission from [firstname.lastname@example.org (Derek Atkins)]
----- Original Message -----
From: "Derek Atkins" <email@example.com>
To: "Sandy Murphy" <firstname.lastname@example.org>
Cc: <email@example.com>; <firstname.lastname@example.org>; <email@example.com>;
Sent: Tuesday, January 30, 2007 3:40 PM
Subject: Re: Security considerations with
Let me give an example. An ftp implementation is per spec in all respects
except that whenever you send "get foo" it returns the contents of the
bar. It seems to me that there is nothing that the peer ftp
can do within the scope of ftp to rectify or even detect this. Only the
application of other features (such as file encryption and file tagging)
help and this is outside the scope of ftp.
So with RSVP-TE. An application can do lots of things to verify that its
is correctly connected and passing the right data unmollested, but that
the job of the application not of the protocol.
Ahh, but in the RSVP restart case, it's more like an FTP
implementation does a "put foo" and then later a "get foo" and expects
the remote implementation to return the same "foo" that it put there
originally. You're trusting the remote implementation to give you the
same file that you uploaded earlier but you're not doing any kind of
verification that that's indeed the case.
All I'm suggesting is that the originator of the data have some way to
self-verify that the foo it got is the same foo it put. This could be
done by a simple "self-signature" or MAC, something where I have some
long term secret key (e.g. an AES key) and then upload the MAC with
the original data; then when I get it I can re-verify the MAC and see
that yes, this IS the data I uploaded.
Derek Atkins 617-623-3745
Computer and Internet Security Consultant