Subject: [saag] for your comments Internet draft

From: "DB" <[email-masked]>
Date: Thu, 22 Oct 2009 08:41:29 +1100

I dont know how this works, but could this be included in your next agenda?
I need your inputs and comments,

http://tools.ietf.org/html/draft-d-sec-udt-00

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, October 21, 2009 6:00 AM
Subject: saag Digest, Vol 16, Issue 4

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/saag
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send saag mailing list submissions to
> [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/saag
> or, via email, send a message with subject or body 'help' to
> [email-masked]
>
> You can reach the person managing the list at
> [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of saag digest..."
>
>
> Today's Topics:
>
>   1. Re: A question about AES properties... ([email-masked])
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 19 Oct 2009 13:49:37 -0700
> From: [email-masked]
> Subject: Re: [saag] A question about AES properties...
> To: Ken Raeburn <[email-masked]>
> Cc: John Border <[email-masked]>, "[email-masked]"
> <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Quoting Ken Raeburn <[email-masked]>:
>
>> On Oct 15, 2009, at 15:56, John Border wrote:
>> >     I have what I thought was a simple question about the properties
>> > of AES.  But, I have not been able to find an answer.  Possibly that
>> > means the question itself is flawed (but I haven?t been able to
>> > figure that out either)?
>> >
>> >    With AES, does the order of the functions matter, i.e. does
>> > EK(DK(P)) = DK(EK(P))?
>>
>
> As Ken responded, if the plaintext is a multiple of the block size, 
> because EK
> and DK are inverses, the result is the identity function, so the answer to 
> the
> above is that the order does not make a difference.
>
> BUT, I expect what you might have been trying to ask is whether 
> EK1(DK2(P)) =
> DK2(EK1(P)), i.e. your question above, but using two different keys.  In 
> this
> case, the analyses is not as simple, and I would guess that the answer is 
> that
> no they are not the same.  But I could be wrong.  You should be able to 
> verify
> the "NO" answer with a simple experiment.
>
> Clifford Neuman
>
>
> ------------------------------
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>
>
> End of saag Digest, Vol 16, Issue 4
> ***********************************
>
> _____________________________________________________
> This mail has been virus scanned by Australia On Line
> see http://www.australiaonline.net.au/mailscanning
>

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Oct 2009 16:45:06 -0500

> http://tools.ietf.org/html/draft-d-sec-udt-00

UDT itself belongs in the Transport Area, either in TSVWG or in a new WG
or as an individual submission.  UDT security docs probably belong there
as well, but should be reviewed by the security area.

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, but if you want you can ask for time to make a short
presentation on UDT at the Hiroshima meeting (in which case it's the
Security Area Directors who would be giving you a time slot).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 Oct 2009 16:09:50 -0500

On Wed, Oct 21, 2009 at 04:45:06PM -0500, Nicolas Williams wrote:
> 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
--