[anonsec] [MULTIMOBSEC-API] Re: first steps in APIs

[Nicolas Williams]

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.