Re: CARD: Details on signing unsolicited CARD Reply messages

> >
> > The issue of authentication of advertised messages is common to many
> > other protocols. The question is whether or not the CARD protocol spec
> > sould be specific to a solution. If there are more efficient solutions
> > in the future, why not keeping the flexibility to adopt the CARD
> > protocol to that mechanism?
>
> IMO, if you have a mechanism such as the unsolicited multicast replies,
> which cannot be secured with standard security protocols, then the
> security mechanism should be specified in the protocol spec for
> interoperability. If interoperability is not needed, then it can be left
> open.
>
> Vijay's suggestion, to just say that the mechanism is not defined here,
> might be an easy way to handle this issue and maybe sufficient for an
> experimental RFC.
>
> > But I am also fine with adding some more details here. Any
> > proposals for details on a mechanisms?
>
> You could look at how TLS does this and use some PKCS standard with RSA.
> This would still leave open how MN learns the public key of AR.
>


Henrik,

There are some examples of unsecured broadcast/multicast messages such as
Router Advertisement (Mobile IP). A typical solution to secure such messages
is using public key to authenticate the messages but it could be a quite
heavy computation for the MN. Also it requires a key distribution system
behind it as you pointed out above. I am quite reluctant to put all these
issues into the CARD protocol specification at this stage. If any good
solution to secure such broadcast/multicast messages comes up, we could
revise the specification later to incorporate it.

So I'd support Vijay's suggestion that the current specification simply
points out the security issue and the security mechanism is not defined. The
statements can be inserted into the "security considerations" section.

Eunsoo