Subject: [anonsec] Fwd: I-D ACTION:draft-komu-btns-api-01.txt

From: julien.IETF at laposte.net (Julien Laganier)
Date: Fri, 9 Mar 2007 10:40:24 +0100

FYI,
-------------- next part --------------
An embedded message was scrubbed...
From: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-komu-btns-api-01.txt 
Date: Thu, 08 Mar 2007 15:50:04 -0500
Size: 5644
Url: http://mailman.postel.org/pipermail/anonsec/attachments/20070309/612e8ae6/attachment.mht

---

From: miika at iki.fi (Miika Komu)
Date: Mon, 12 Mar 2007 14:08:49 +0200 (EET)

On Fri, 9 Mar 2007, Julien Laganier wrote:

Hi all,

a lot of things have changed in the API draft. Most importantly, the draft 
is now more concrete instead of just outlining some ideas. It includes 
C-based programming interfaces for defining application ipsec policy 
attributes and channel bindings. The use of the interfaces is illustrated 
in the appendix with some code examples.

I removed the dependency to draft-ietf-hip-native-api because the 
dependency is actually the other way around. The draft is not based on 
high layer interfaces (SASL or GSS) because they are more session or 
transport layer oriented, where as IPsec APIs should be working even at 
the datagram oriented level (sendmsg, sendto, etc). However, it should be 
ok to use e.g. GSS and the IPsec APIs at the same time in the same 
application.

The changes are based on comments from Nicolas Williams, Michael 
Richardson, Love ?strand and Julien Laganier. Sasu Tarkoma gave a thorough 
review for the preversion and promised to participate in editing the next 
versions of the draft, so I added him as a co-author. Thanks for the 
commentors good feedback!

Some things are still work in progress:

   * The exact set of policy attributes to be defined in the draft.
   * Code examples with SASL or GSS. Server side code examples.
   * Storing of channel bindings to long-term memory (disk?)
   * The comparison functions should allow comparison of attribute1 <
     attribute2, not just equality.
   * Querying of local / peer identitities
   * Forcing of IPsec based security vs. allow fallback to non-IPsec based
     communications?
   * Error values

All further comments are welcome!

http://www.ietf.org/internet-drafts/draft-komu-btns-api-01.txt

-- 
Miika Komu                                       http://www.iki.fi/miika/

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Sun, 18 Mar 2007 16:13:15 +0100

>     attribute2, not just equality.

Maybe. Creating a partial order of various attributes is non-trivial,
I think.

Is AES128 > 3DES?  (on what basis?  faster? more secure? lower latency?)

Is HMAC-MD5 > SHA2-256 ?
(No, the comparsion isn't valid. HMAC and non-HMAC uses are not the same,
and IPsec always uses HMAC... well. do we? We don't use it for XCBC-AES, right?)

I would like to have the partial order. I am not certain that it is something
that we will agree to. Perhaps I'm wrong, and the work is trivial.

I also don't want applications to ever hard code things like "AES128".
Instead, I want them to use something like "ENCRYPTION_STENGTH_MEDIUM",
and have some files, a la /etc/services that defines what that means for this system.

---

From: paul at xelerance.com (Paul Wouters)
Date: Sun, 18 Mar 2007 18:45:42 +0100 (CET)

> and have some files, a la /etc/services that defines what that means for this system.

Reminds me of Draytek Vigor's, which had a "medium" setting meaning modp768
with 1DES......

Not only do you have to agree on the order of this list, you also have to
maintain it in the light of faster hardware ove rtime.

Paul

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sun, 18 Mar 2007 16:07:43 -0500

> maintain it in the light of faster hardware ove rtime.

And cryptanalytic advances.

---

From: rcteigao at gmail.com (Rafael Coninck Teigão)
Date: Mon, 19 Mar 2007 07:04:19 -0300

> And cryptanalytic advances.

Maintaining the list in accordance to the cryptanalytic advances is a
work that you would already perform. Despite actually having it stored
on a file or not, someone would still need to review the policy in the
light of new advances.

I think having a file to configure BASIC, MEDIUM and HIGH strength
encryption would not only improve code/policy readability, but also
allow algorithm comparison, since we would already have a partial
ordering defined (and better yet, it would be defined at the
discretion of the administrator).

[]'s,
Rafael.

---

From: miika at iki.fi (Miika Komu)
Date: Mon, 19 Mar 2007 16:12:35 +0200 (EET)

> discretion of the administrator).

The BASIC, MEDIUM and HIGH will be added for the next version of the 
draft.

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 19 Mar 2007 16:38:28 +0100

> maintain it in the light of faster hardware ove rtime.

   Not relevant.
   The choice is not between "medium" vs "3DES". Medium security *WAS* 1DES (vs RC4)
ten plus years ago.  Of course, there are maintenance issues.

   The choice is between replacing all the binaries on the machine that use the
BTNS IPsec API, or replacing one file that defines what the "medium" profile is.

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 19 Mar 2007 16:44:37 +0100

Miika Komu wrote:
> The BASIC, MEDIUM and HIGH will be added for the next version of the draft.

There are two issues here, which are seperable:
1) should there be abstracted profiles instead of concrete protocols.
    I claim that applications should never do:
          if(cipher_algo == AES128) {  /* trust user */ }
          else { /* user is insecure */ }

    http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-ipsec-apireq.html#anchor7

2) should there be a partial order.

These are two decisions. I would appreciate feedback on section 7 of the API requirements draft.

---

From: rcteigao at gmail.com (Rafael Coninck Teigão)
Date: Mon, 19 Mar 2007 13:08:39 -0300

>     http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-ipsec-apireq.html#anchor7

To quote section 7:
"Hard-coding algorithm names into applications should be actively
discouraged; there SHOULD be generic "weak" or "strong" indications
instead of specific algorithm identifiers."

It think hard-coding algorithms should be forbidden, and identifiers
should be mandatory. This adds a lot to configurability. We should
just define correctly the identifiers and add special cases for when
they are not defined (should we default to some algorithm? or return
an error?)

> 2) should there be a partial order.

Yes. We certainly may want to accept stronger algorithms when
available, but not always (e.g. when there's not enough processing
power for using a strong cypher).

[]'s,
Rafael.