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

FYI,

_______________________________________________

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-btn
s-api-01.txt

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

_______________________________________________

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

On Mon, 19 Mar 2007, Rafael Coninck Teigão wrote:

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

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

_______________________________________________

> 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

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