Re: CARD: Details on signing unsolicited CARD Reply messages

>
> The example you give (Router Advertisements) is the subject of the
Securing
> Neighbor Discovery Working Group (SEND) for IPv6. The SEND specification
> defines an authentication option for RAs. The protocol depends on
> certificate distribution between router and host and defines a
certification
> distribution message for the local link (specifically for that, it likely
> won't work well in multilink situations due to fragmentation). A similar
> solution, or possibly even SEND itself for IPv6, could be used by CARD.
>
> That said, I agree with Henrik's point that it can be left open, but it
> should be explicitly listed as an open issue in the Security
Considerations
> section.
>
>             jak

James,

It is fine with me to leave it as an open issue in the Security
Considerations section. It is what I said anyway in my previous email.
So I guess Henrik, Vijay, you and I are all in the same page. I remember it
was also an option positively considered among the authors of the draft.

Eunsoo

>
> ----- Original Message ----- 
> From: "Eunsoo Shim" <[email protected]>
> To: "Henrik Petander" <[email protected]>; "Marco Liebsch"
> <[email protected]>
> Cc: "Henrik Petander" <[email protected]>; "Seamoby"
> <[email protected]>
> Sent: Tuesday, October 14, 2003 6:10 AM
> Subject: Re: [Seamoby] 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
> >
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
>