Subject: [anonsec] first steps in APIs

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Mon, 24 Apr 2006 17:19:58 -0400

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20060424/6abe9e6d/attachment.bin

---

From: miika at iki.fi (Miika Komu)
Date: Tue, 25 Apr 2006 09:48:56 +0300 (EEST)

On Mon, 24 Apr 2006, Michael Richardson wrote:

>>>>>> "marcelo" == marcelo bagnulo braun <marcelo at it.uc3m.es> writes:
>    marcelo> So bottom line is, the commonality comes from these two
>    marcelo> characteristics that seems to be available in the differetn
>    marcelo> scenarios:
>
>    marcelo> - there are multiple addresses that need to be managed - a
>    marcelo> mechanism for failure detection and path exploration is used by
>    marcelo> the different protocols and it needs to be tuned/managed
>
>    marcelo> The functions related to such functions can be made common to
>    marcelo> all the protocols.
>
>    marcelo> Makes any sense?
>
>  So do you feel that there is any overlap between shim6 and IPsec?
>  I think we have two APIs here.
>
>  And that's fine -- decoupling is good.
>  The HIP folks have to coordinate twice, but we don't have to come to a
> consensus among three groups.

So, it seeems like we would have two APIs: one for security (IPsec) and 
the other one for locators. We'd need consensus between BTNS-HIP and 
SHIM6-HIP. It might even make things easier.

If we split things already at this point, it may not make sense to create 
"core" drafts. Otherwise, we may end up with too many documents (?):

   * locator core
   * SHIM6 locator extensions
   * HIP locator extensions
   * IPsec security core
   * BTNS security extensions
   * HIP security extensions

On the other hand, this separation might be better for other lower layer 
protocols as well. Comments, opinions?

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

---

From: miika at iki.fi (Miika Komu)
Date: Tue, 25 Apr 2006 10:00:51 +0300 (EEST)

On Tue, 25 Apr 2006, marcelo bagnulo braun wrote:

> I don't know...

I think there is some overlap even between shim6 and btns, but the overlap 
is somewhat marginal. Consider these examples:

* You could request current IPsec security parameters from shim6 module
   and it would tell you that there is none
* To set-up BTNS IPsec policies and associations, you also need locators

However, there is no reason why these APIs couldn't be decoupled.

> what about MOBIKE? wouldn't mobike need similar locator management and 
> failure detection functions?
>
> what about MIP? (with the HA) in this case we would need to manage 
> multiple locators and deal with failure detection over the IPSec tunnel 
> with the HA...
>
> but again, i don't really know just exploring

There is some overlap, but I think it is possible to abstract it. HIP is 
the common denominator, so HIP people need to make sure that the "gray 
area" is covered in the drafts.

In any case, it would be very useful for everyone to review all drafts 
with a close attention what their working group wants from the APIs.

---

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Tue, 25 Apr 2006 12:41:15 +0300

To me, one of the more important parts of this exercise is to see  
whether, from an application's point of view, one could more or less  
implement HIP-functionality with BTNS+CGA+SHIM6.  In other words, my  
gut feeling is that that it would be good if

   HIP api == BNTS api + SHIM6 api + possibly some CGA-related stuff.

--Pekka

On Apr 25, 2006, at 10:00, Miika Komu wrote:

> _______________________________________________
>

---

From: miika at iki.fi (Miika Komu)
Date: Tue, 25 Apr 2006 15:53:27 +0300 (EEST)

On Tue, 25 Apr 2006, Pekka Nikander wrote:

> To me, one of the more important parts of this exercise is to see whether, 
> from an application's point of view, one could more or less implement 
> HIP-functionality with BTNS+CGA+SHIM6.  In other words, my gut feeling is 
> that that it would be good if
>

This would work for me.

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Tue, 25 Apr 2006 09:24:58 -0400

>>>>> "marcelo" == marcelo bagnulo braun <marcelo at it.uc3m.es> writes:
    marcelo> what about MOBIKE? wouldn't mobike need similar locator
    marcelo> management and failure detection functions?

  MOBIKE is about moving the outer part of an IPsec tunnel around.

  The addresses inside (the identifiers if you prefer), remain the same,
so applications do not see any change. 

  A MOBIKE daemon *itself* might benefit from the mechanisms provided by
shim6 (if it were available for IPv4), but the end-user application
would never see the changes. That's the purpose of MOBIKE.

  As for MIP, again, the point of the effort is to maintain the same set
of identifiers for the application.

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

    "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 25 Apr 2006 10:22:35 -0500

> * To set-up BTNS IPsec policies and associations, you also need locators

<clarification>

Er, let's be careful and avoid confusion on the BTNS list about this:

 - BTNS is, at its core, about NOT authenticating peers
 - BTNS allows for anonymity and pseudonymity

 - (BTNS pseudonymity &&
	(application-driven enrolment ||
	 application-driven leap-of-faith)) == ad-hoc IPsec authentication

 - Some BTNS applications (channel bindings) don't care for
   pseudonymity, and, therefore, don't care for ad-hoc IPsec
   authentication.

So, BTNS can be said to have locators, but it isn't strictly the case
that it does have locators -- "BTNS locators" are an application
construct, not a fundamental BTNS construct.

</clarification>

> However, there is no reason why these APIs couldn't be decoupled.

Yes, but I think there's a point where they may meet: at the API for
obtaining the end-point IDs of a latched connection, and, therefore, the
representation of these IDs (IKEv2-style representation, + BTNS
publickey ID type, + HITs).

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 25 Apr 2006 10:37:30 -0500

>    HIP api == BNTS api + SHIM6 api + possibly some CGA-related stuff.

What is CGA?

Anyways, what you call "BNTS api" is really an IPsec API:

 - APIs for getting latched connection peer IDs (enough for
   channel bindings and application-driven LoF and enrolment)

    - APIs for requesting services beyond what the SPD requires (e.g.,
      confidentiality where the SPD requires only integrity protection,
      or any protection at all where the SPD allows bypassing)

    - APIs for requesting bypass (requiring privilege, of course)

 - APIs for editing the IPsec policy databases (PAD, SPD) (which could
   be used for application-driven LoF and enrolment, but this is a much
   bigger hammer than the above)

Given a canonical tokenization of IKE/IPsec/BTNS IDs and HITs I think
this comes very close to a basic HIP API.

Still needed:

 - additional APIs to deal with mobility/NAT (again, this would be
   fairly generic)

 - APIs to locate peers (this being rather specific to HIP).

Nico
--

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Tue, 25 Apr 2006 15:32:03 -0400

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20060425/398ddf9a/attachment.bin

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 25 Apr 2006 15:30:32 -0500

On Tue, Apr 25, 2006 at 03:32:03PM -0400, Michael Richardson wrote:
>     Pekka> HIP api == BNTS api + SHIM6 api + possibly some CGA-related stuff.
> 
>   So, you do not so much want us to find common pieces, but rather to
> delinate clearly where one starts and one ends.

Dunno about Pekka, but, I see what he termed "BTNS api" above as a
generic IPsec API, which I describe, in broad terms, in the BTNS
connection latching I-D[0].

Given this I think we're talking about a well-delineated generic IPsec
API[1] that is commonly useful in the BTNS, HIP and SHIM6 spaces.

[0] http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-latching-00.txt

[1] There's another proposed IPsec API for editing IPsec policy
    databases, but I think this API would not be common to the BTNS, HIP
    and SHIM6 spaces.

Nico
--

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Tue, 25 Apr 2006 17:05:43 -0400

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20060425/ba48dd74/attachment.bin

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 25 Apr 2006 16:15:52 -0500

On Tue, Apr 25, 2006 at 05:05:43PM -0400, Michael Richardson wrote:
> 
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
>     Nicolas> Yes, but I think there's a point where they may meet: at the API
>     Nicolas> for obtaining the end-point IDs of a latched connection, and,
>     Nicolas> therefore, the 
>     Nicolas> representation of these IDs (IKEv2-style representation, + BTNS
>     Nicolas> publickey ID type, + HITs).
> 
> When you receive a latched connection that was accepted due to BTNS,
> and the ID that was asserted in IKE was ID_IPV6 (recalling that BTNS
> made you not care that much about how valid it was for them to assert that),
> would you expect to see the end-point ID be:
>       a) the IPV6 that was asserted via IKE.
>       b) the HIT that the transport/shim6 layer asserted
>       
> Aren't these two different things?
> Particularly when the IE in IKE was in fact FQDN or something.

You would expect to get the coerced peer ID, the BTNS publickey ID whose
value is the peer's public key.

You want to see the IP addresses?  Sure, you can do that today.  You
want to see your NATed address, Ok, that's something new.

> I can see applications that take a connection the first time, set
> up some kind of account, have the account validated by out-of-band method
> (e.g. the user paid for the service), and recall the public key used to sign
> on. Subsequent sign-ons are authenticated nicely by public alone.

Yes, exactly, that's ad-hoc authentication based on enrolment of BTNS
public keys.