Re: [saag] for your comments Internet draft

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Wed, Oct 21, 2009 at 04:45:06PM -0500, Nicolas Williams wrote:
> Now, from the looks of your document, it's early enough that you're
> really just asking for advice on how to add end-to-end security to UDT.
> SAAG is the right place to seek such advice.  This mailing list is good
> enough to start, ...

I see three options for authentication and end-to-end security:

a) GSS-API
b) DTLS
c) IPsec

d) SASL/GSS-API for authentication + channel binding to DTLS, DTLS for
   data integrity/confidentiality protection

e) SASL/GSS-API for authentication + channel binding to IPsec, IPsec for
   data integrity/confidentiality protection

(a) is probably the easiest to implement, followed closely by (b), for
the simple reason that these are easy to use and there exist multiple
implementations.  DTLS is newer, and TLS has lots of options, so it's
probably a bit harder to use than the GSS-API.

(The GSS-API is a rather large API, but for applications like this one,
one need only use a small subset of that API.  Don't let the size of the
API intimidate you.)

(c) is very hard to use.  Right now you can't really drive the use of
IPsec from applications, which means that you'd have to rely on the
sender and receiver to be configured properly.  That won't work for
Internet-scale deployments.  BTNS WG work on IPsec APIs would help, but
it will be a long time before those are widely available.  In other
words, (c) is not a very realistic option.

(OTOH, if you have a no-security option for UDT, then (c) can be done by
the sysadmin if they want, without even having to tell the UDT app.)

(d) is only useful if you're interested in the sum of user/host
authentication options available with SASL, GSS-API and DTLS.  It's
worth considering, though mostly because of the very unfortunate reality
that authentication mechanisms are not equally available in all these
authentication frameworks :(

(e) is like (d), but using IPsec; see (c) for why (e) not a realistic
option.

Of these I'd say the best choice is to do (a), (b) and leave room for
adding (d) later.

The protocol would look roughly like:

 - First authenticate (exchange opaque GSS context / DTLS handshake
   messages until authenticated) (for (d) you'd do both... we can
   discuss that later).

 - Then use per-message token functions (GSS-API) or DTLS record layer
   (DTLS) to protect UDT messages.

   Interleaving could be an issue.  You might need a separate security
   context per-channel.

Nico
--