Subject: Re: [saag] Contents of saag digest..."> 1. Re: for your comments Internet draft

From: "DB" <[email-masked]>
Date: Sat, 24 Oct 2009 17:45:56 +1100

> 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 <[email-masked]>
> Subject: Re: [saag] for your comments Internet draft
> To: DB <[email-masked]>
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> 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
> [email-masked]
> 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
>