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

[Julien Laganier]

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

[Miika Komu]

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

[Michael Richardson]

Post by Miika Komu
* The comparison functions should allow comparison of attribute1 <
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.

[Paul Wouters]

Post by Michael Richardson
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.

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

[Nicolas Williams]

Post by Paul Wouters

Post by Michael Richardson
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.

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.

And cryptanalytic advances.

[Rafael Coninck Teigão]

Post by Nicolas Williams

Post by Paul Wouters
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.

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.

[Miika Komu]

Post by Rafael Coninck Teigão
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).

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

[Michael Richardson]

Post by Rafael Coninck Teigão
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).

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.

[Rafael Coninck Teigão]

Post by Michael Richardson
1) should there be abstracted profiles instead of concrete protocols.
if(cipher_algo == AES128) { /* trust user */ }
else { /* user is insecure */ }
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?)

Post by Michael Richardson
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.

[Michael Richardson]

Post by Paul Wouters

Post by Michael Richardson
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.

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.

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.