headers
Pasi.Eronen | 1 Oct 2009 17:33
Picon

Pasi's AD Notes for September 2009

Here's again a short status update about what things are going on from
my point-of-view. If you notice anything that doesn't look right, let
me know -- miscommunication and mix-ups do happen.

Best regards,
Pasi

MISC NOTES

- Sent a liaison statement reply to ITU-T regarding identity 
  management.
- Informed NomCom that I'm not running for a second term (see
  http://www.ietf.org/mail-archive/web/secdir/current/msg00994.html)
- Reviewed ROHCoIPsec drafts again for IETF last call.
- (not wearing AD hat): Errata #1628 (for RFC 4742): IANA has now  
  fixed the registry and Dan verified the errata. 
- Tools work: test suite improvements, Django 1.x transition,
  tools authentication model, IESG agenda-related tools, etc.
- Requested room/slot for SAAG and SecDir lunch at IETF76.
- Some discussions about SIDR algorithm agility.

WORKING GROUPS

DKIM
- Waiting for Stephen and Barry for new charter text (noting that 
  current work items are completed and adding 4871bis)
- I still need to review what to do about errata 1385, 1532, and 1596
- Talked about the mailing list with Tim/chairs/Dave; decided to keep
  the current list (and not move it to ietf.org) for the time being,
  since it's DKIM-signing the emails (and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pasi.Eronen | 6 Oct 2009 08:50
Picon

Request for SAAG agenda items

Folks,

Tim and I are working on the agenda for SAAG at IETF76.  
We would appreciate any suggestions!

Thanks,
Pasi
Permalink | Reply | 0 comments |
headers
John Border | 15 Oct 2009 21:56

A question about AES properties...

 

    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))?

 

 

 

John Border

 

 

<div>

<div class="Section1">

<p class="MsoNormal"><p>&nbsp;</p></p>

<p class="MsoNormal">&nbsp;&nbsp;&nbsp; I have what I thought was a simple
question about the properties of AES.&nbsp; But, I have not been able to find
an answer.&nbsp; Possibly that means the question itself is flawed (but I haven&rsquo;t
been able to figure that out either)&hellip;<p></p></p>

<p class="MsoNormal"><p>&nbsp;</p></p>

<p class="MsoNormal">&nbsp;&nbsp; With AES, does the order of the functions
matter, i.e. does EK(DK(P)) = DK(EK(P))?<p></p></p>

<p class="MsoNormal"><p>&nbsp;</p></p>

<p class="MsoNormal"><p>&nbsp;</p></p>

<p class="MsoNormal"><p>&nbsp;</p></p>

<p class="MsoNormal">John Border<p></p></p>

<p class="MsoNormal"><p>&nbsp;</p></p>

<p class="MsoNormal"><p>&nbsp;</p></p>

</div>

</div>
Permalink | Reply | 2 comments |
headers
Ken Raeburn | 19 Oct 2009 18:51
Picon
Favicon

Re: A question about AES properties...

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))?

AES block encryption with a specific key is a permutation of 2^128  
values -- a bijection from the set to itself.  Decryption with the  
same key is just the inverse of that permutation.  Both E(D(P)) and  
D(E(P)) perform some permutation and then reverse it, giving you back  
the starting value.

The same argument applies to block cipher modes of encryption that  
operate on multiple blocks, in cases that don't do any message  
expansion.  They're still reversible permutations, just over larger  
sets.  But, for example, if your encryption mode is "CBC encryption  
with padding", and P isn't a multiple of the block size, then D(E(P))  
= P' where P' has padding added, and E(D(P)) just doesn't work because  
D requires its input to be a multiple of the block size.

Ken
Permalink | Reply | 1 comment |
headers
bcn | 19 Oct 2009 22:49
Picon
Favicon

Re: A question about AES properties...

Quoting Ken Raeburn <raeburn <at> MIT.EDU>:

> 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
Permalink | Reply | 0 comments |
headers
DB | 21 Oct 2009 23:41
Picon
Favicon

for your comments Internet draft

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: <saag-request <at> ietf.org>
To: <saag <at> ietf.org>
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
> saag <at> ietf.org
>
> 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
> saag-request <at> ietf.org
>
> You can reach the person managing the list at
> saag-owner <at> ietf.org
>
> 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... (bcn <at> ISI.EDU)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 19 Oct 2009 13:49:37 -0700
> From: bcn <at> ISI.EDU
> Subject: Re: [saag] A question about AES properties...
> To: Ken Raeburn <raeburn <at> MIT.EDU>
> Cc: John Border <John.Border <at> hughes.com>, "saag <at> ietf.org"
> <saag <at> ietf.org>
> Message-ID: <1255985377.4adcd0e19f8af <at> webmail.isi.edu>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Quoting Ken Raeburn <raeburn <at> MIT.EDU>:
>
>> 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
> saag <at> ietf.org
> 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
>
Permalink | Reply | 2 comments |
headers
Nicolas Williams | 21 Oct 2009 23:45
Picon

Re: for your comments Internet draft

On Thu, Oct 22, 2009 at 08:41:29AM +1100, DB wrote:
> 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

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
--

--
Permalink | Reply | 1 comment |
headers
Nicolas Williams | 22 Oct 2009 23:09
Picon

Re: for your comments Internet draft

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
--

--
Permalink | Reply | 0 comments |
headers
DB | 24 Oct 2009 08:45
Picon
Favicon

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


> 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
>
Permalink | Reply | 0 comments |
headers
Pasi.Eronen | 30 Oct 2009 10:37
Picon

Pasi's AD Notes for October 2009

Here's again a short status update about what things are going on from
my point-of-view. If you notice anything that doesn't look right, let
me know -- miscommunication and mix-ups do happen.

Best regards,
Pasi

MISC NOTES
- Preparing IETF76 SAAG agenda and SecDir lunch with Tim.
- Looking into RFC editor errata for security-related AD-sponsored 
  documents with Tim.
- Some IODEF/INCH related discussions.
- (Not wearing AD hat): Discussions about draft-krawczyk-hkdf on 
  CFRG list.
- Tools work: Django 1.x transition, test suite improvements, 
  retiring many old scripts (my lines-of-code-per-day average 
  productivity this month is heavily negative :-).
- I've been asked to sponsor draft-marin-eap-frm-fastreauth; waiting
  for me to take a look and reply to the authors [since 2009-10-26]

WORKING GROUPS

DKIM
- draft-ietf-dkim-deployment: currently in Publication Requested
  state, waiting for me to read it [since 2009-10-26]
- Waiting for Stephen and Barry for new charter text (noting that 
  current work items are completed and adding 4871bis)
- I still need to review what to do about errata 1385, 1532, and 1596
- Talking with chairs and others about mailing list (mis)behavior.

EMU
- EMU WG received a new liaison statement from ITU-T about X.1034; 
  the WG chairs have the token for doing something about it.

IPSECME
- draft-ietf-ipsecme-ikev2-resumption: was approved by the IESG;
  waiting for the secretariat to send the announcement.
- The IANA registrations for RFC 4543 have now been fixed, and RFC
  editor errata approved (see email on list for details).
- draft-ietf-ipsecme-traffic-visibility: went through IETF last call;
  waiting for authors to address the comments received [since 2009-10-30]
- draft-ietf-ipsecme-ikev2-ipv6-config (not wearing AD hat): went
  through IESG evaluation, and new version was submitted. Waiting
  for Tim to remove the RFC Editor Note and Russ to check the 
  new version, and clear his DISCUSS [since 2009-10-30]
- draft-kanno-ipsecme-camellia-xcbc (not WG item): the authors
  have asked if I would sponsor this as individual submission.
  I've sent some questions to them, and I'm currently waiting
  for their reply [since 2009-10-14]
- draft-ietf-ipsecme-ikev2-redirect (not wearing AD hat; Tim is 
  handling this one): currently in AUTH48, waiting for the authors
  (I think).
- Some discussions about clarifying IKEv2 IANA registries (for
  encryption algorithms) and fixing a bug in RFC 4307. Waiting
  for Tero to submit an errata about the latter.
- IANA registry entry for PRF_AES128_XCBC was fixed (thanks to 
  Alfred and Paul).
- Processed one errata for RFC 2410.

ISMS

KEYPROV
- Apparently waiting for the chairs to send some documents
  my way...

PKIX
- draft-ietf-pkix-sha2-dsa-ecdsa: was approved by IESG, now in RFC 
  editor queue.
- draft-ietf-pkix-rfc4055-update: in RFC Editor queue, waiting for
  draft-ietf-pkix-sha2-dsa-ecdsa.

SASL
- draft-ietf-sasl-scram: was approved by IESG; now in RFC editor 
  queue.
- draft-ietf-sasl-gs2: currently in IETF last call (ends 2009-11-18);
  hoping the authors submit a revised ID when submissions re-open.
- (not WG item) draft-melnikov-sasl-scram-ldap: waiting for authors 
  to submit a revised ID when submissions re-open; placed on the agenda 
  of the 2009-11-19 IESG telechat.
- (not WG item) draft-altman-tls-channel-bindings: currently in 
  IETF last call (ends 2009-11-02); active discussion ongoing.

SYSLOG
- draft-ietf-syslog-sign: in IESG evaluation; active discussions
  ongoing; waiting for me to reply to some of the emails; waiting
  for Alex to reply to some others.

TLS
- draft-ietf-tls-rfc4366-bis: the document was updated to address
  IETF last call comments; placed on the agenda of 2009-11-19 IESG
  telechat.
- draft-ietf-tls-extractor: waiting for Eric to reply to email
  [since 2009-10-05]; also in AUTH48.
- Processed two errata for RFC 4346.
- (not WG item) see SASL WG for draft-altman-tls-channel-bindings

OTHER DOCUMENTS

DISCUSSES (active -- something happened within last month)

- draft-ietf-bmwg-ipsec-meth: waiting for authors to reply
  to my comments [since 2009-10-22]
- draft-ietf-bmwg-ipsec-term: waiting for authors to reply
  to my comments [since 2009-10-22]
- draft-ietf-eai-downgraded-display: discussion ongoing; currently
  waiting for the authors to reply [since 2009-10-26]
- draft-ietf-mipshop-pfmipv6: discussion ongoing; currently
  waiting for the authors to reply [since 2009-10-29]
- draft-ietf-ntp-autokey: waiting for Ralph's proposal on
  how to proceed [since 2009-10-19]
- draft-ietf-roll-home-routing-reqs: text agreed, waiting for
  the authors to submit a revised ID [sincer 2009-10-29]
- draft-ietf-sip-certs: discussion ongoing; currently waiting
  for the authors to reply [since 2009-10-26]

DISCUSSES (stalled -- I haven't heard anything from the authors
or document shepherd for over one month)

- draft-cain-post-inch-phishingextns: waiting for authors
  to submit a revised ID [since 2009-09-04]
- draft-solinas-rfc4753bis: waiting for authors to reply
  to my comments [since 2009-09-24]

DISCUSSES (presumed dead -- I haven't heard anything from the authors
or document shepherd for over three months)

- draft-cheshire-dnsext-nbp: waiting for authors to reply to my
  comments [since 2008-12-03] (pinged again on 2009-04-30,
  2009-06-09, 2009-10-29)
- draft-ietf-bfd-base: text agreed, waiting for authors to submit 
  a revised ID [since 2009-03-19] (pinged again on 2009-04-30,
  2009-06-09, 2009-10-29)
- draft-ietf-dime-diameter-api: waiting for Dan to get WG's opinion 
  on whether this will be useful and if yes, why [since 2009-06-18]
- draft-ietf-sipping-policy-package: waiting for draft-ietf-sipping-
  media-policy-dataset to progress (or more information from Robert)
  [since 2008-10-28]

--end--
Permalink | Reply | 0 comments |

Gmane