Francis Dupont writes: "The Authorization Delegation Discovery process
does not exclude other forms of discovering the certificate chains.
For instance, during ... " IMHO this is the right place to introduce
interaction with AAA systems.  If you'd like to use SEND in 802.11 hot
spots, you have to talk about this!

------

Jari Arkko responds to Francis Dupont: Do you have a specific
suggestion regarding the interaction? Do you wish to download certs
from the AAA, or what?

------

Jari Arkko writes: Now, I've been thinking about this a little bit.
If this is *only* about the discovery of the cert chains
via AAA, then it might be that, for instance, the 802.11
link layer authentication process has already learned
something about the network's certificates. For instance,
if 802.11 is running EAP TLS, and the authentication is
terminated directly at the AP/router, then the host already
has the cert chain from a trusted root to the router.

The only question at that point is whether the cert chain
is usable for other purpose, i.e. whether the authorizations
are sufficient for both purposes. TLS certs are a bit special,
as are SEND certs...

Also, cert-based authentication which terminates at the local
router may be rare in practise.

In any case, to move forward my proposal is that we simply
add some text explaining that as a side effect of attaching
to the network, it may be that the host already has some
cert chains from the network, and that it MAY use them in
order to optimize (skip) the SEND cert retrival. Does
that work for you?

------

------

Alper Yegin: It might even be the case that the cert used is not part
of any chain and the solution does not rely on global PKI. For
example, a more practical solution could be to deliver a public key
for the visited domain to the host during the access AAA. This PK can
be produced by the access network and its delivery to the host can be
protected by the local security association created during AAA. This
solution skips the cert chain discovery and removes the dependency on
any PKI.

Furthermore, we shouldn't even assume that secure router discovery will
always be used along with secure neighbor discovery. One can run a network
where potentially malicious hosts are always on one side of a bridge and the
bridge filters "router advertisements" coming from that side.

------

Hesham Soliman:

> Furthermore, we shouldn't even assume that secure router discovery
> will always be used along with secure neighbor discovery. One can
> run a network where potentially malicious hosts are always on one
> side of a bridge and the bridge filters "router advertisements"
> coming from that side.

Yes, which should be done anyway. Can this recommendation make its way
to the draft somehow?

------

Francis Dupont:

   Now, I've been thinking about this a little bit.
   If this is *only* about the discovery of the cert chains

=> no, my idea is that there are some interactions between AAA systems
and SEND, and the discovery of the cert chains should likely be one
of them.

   via AAA, then it might be that, for instance, the 802.11
   link layer authentication process has already learned
   something about the network's certificates. For instance,
   if 802.11 is running EAP TLS, and the authentication is
   terminated directly at the AP/router, then the host already

=> you don't need a "termination": local SEND and local AAA
can share some parts of the chains, the root for instance.

   has the cert chain from a trusted root to the router.
   
   In any case, to move forward my proposal is that we simply
   add some text explaining that as a side effect of attaching

=> I'd like to see the acronym AAA somewhere.

   to the network, it may be that the host already has some
   cert chains from the network, and that it MAY use them in

=> it seems we don't fully agree about the meaning of the term "chain" (:-).
And side effects of attaching to the network can go further than
to share some certs.

   order to optimize (skip) the SEND cert retrival. Does
   that work for you?

------

Jari Arkko: 
> => no, my idea is that there are some interactions between AAA systems
> and SEND, and the discovery of the cert chains should likely be one
> of them.

Fair enough. I agree that there might be more such interactions.
(Of course, we need to decide what to write in the current
document.)

>    via AAA, then it might be that, for instance, the 802.11
>    link layer authentication process has already learned
>    something about the network's certificates. For instance,
>    if 802.11 is running EAP TLS, and the authentication is
>    terminated directly at the AP/router, then the host already
> 
> => you don't need a "termination": local SEND and local AAA
> can share some parts of the chains, the root for instance.

Yes.
 
>    has the cert chain from a trusted root to the router.
>    
>    In any case, to move forward my proposal is that we simply
>    add some text explaining that as a side effect of attaching
> 
> => I'd like to see the acronym AAA somewhere.

Sufficient as an example? I may have trouble putting in
anything else than an example, given that we don't have
specific SEND-related procedures for AAA. But we can certainly
write something about certificate chain or partial chain
sharing with network access AAA. Would that work for you?

------

Francis Dupont: Fine, thanks!

------

Jari Arkko: Here is what has been added to the draft: The
Authorization Delegation Discovery process does not exclude other
forms of discovering the router's certificate or certificate chains to
a common trusted root. For instance, during fast movements mobile
nodes may learn information - including the certificate chains - of
the next router from the previous router. NEW Similarly, link layer
access control procedures and local Authentication, Authorization, and
Accounting (AAA) procedures may result in the host learning the same
information before Neighbor Discovery is run. END NEW

------

------