Today's Topics: 1. Re: for your comments Internet draft (Nicolas Williams) ---------------------------------------------------------------------- Message: 1 Date: Thu, 22 Oct 2009 16:09:50 -0500 From: Nicolas Williams <Nicolas.Williams at sun.com> Subject: Re: [saag] for your comments Internet draft To: DB <dbernard at ozonline.com.au> Cc: saag at ietf.org Message-ID: <20091022210949.GE892 at Sun.COM> Content-Type: text/plain; charset=us-ascii 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.)
what are the existing implementations?
(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.)
This is another option, minimizing overhead,
(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 :(
This is something I will take into consideration. The draft is intended to cover a wide area of security options in considering security UDT.
(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).
Additional references to RFC 5554 and 5238 will be incorporated to this ID.
The protocol suggested above requires amplification.
- 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.
Additional references to RFC 5554 and 5238 will be incorporated to this ID.
The protocol suggested above requires amplification. Thanks for your inputs!
Nico -- ------------------------------ _______________________________________________ saag mailing list saag at ietf.org https://www.ietf.org/mailman/listinfo/saag End of saag Digest, Vol 16, Issue 6 *********************************** _____________________________________________________ This mail has been virus scanned by Australia On Line see http://www.australiaonline.net.au/mailscanning
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.