Re: CARD: Details on signing unsolicited CARD Reply messages

Eunsoo,

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

----- 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
>