Securing Neighbor Discovery Proxy: Problem Statement
RFC 5909
Yes
No Objection
Recuse
Note: This ballot was opened for revision 04 and is now closed.
Lars Eggert No Objection
(Ralph Droms; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
Section 5 The previous part of this document focused on the case where two nodes defend the same address (i.e. the node and the proxy). But, there are scenarios where two or more nodes are defending the same address. I read this a couple of times and it doesn't compute :-) Firstly I suggest you insert a reference in place of "the previous part of this document". Secondly: can you resolve the "But"? The second sentence seems to say, "but the first sentence is true"! --- A petty nit... Would you consider changing the title to... Problem Statement for Securing Neighbor Discovery Proxy ...or... Securing Neighbor Discovery Proxy : Problem Statement ...to add a little clarity.
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Pasi Eronen; former steering group member) (was Discuss) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
Several editorial improvements were suggested in the Gen-ART Review by Vijay Gurbani. Please consider them. > 1) You may want to expand SEND before first use in Section 2; > you do so later on (below Figure 1), but should move that up. > > 2) S2.3, below Figure 3: The text says that "An alternative > (alluded to in an appendix of ND Proxy)..." You may want to > provide a reference to the document containing this appendix. > > 3) S3.3: s/options) [RFC4389]/options) [RFC4389]./
(Tim Polk; former steering group member) (was Discuss, No Objection) No Objection
I am not, repeat NOT, a cryptographer, and am not familiar with ring signature schemes, but
my quick research on ring signature schemes came up with descriptions very different from those in section 4.1.3:
This is the case, for example, with ring signature algorithms. These
algorithms generate a signature using the private key of any member
from the same group, but to verify the signature the public keys of
all group members are required.
The abstract of "Cryptanalysis of a Generalized Ring Signature Scheme" (published in
vol. 6 no. 2 of IEEE Transactions on Dependable and Secure Computing) states:
In a ring signature, instead of revealing the actual identity of the message signer, it
specifies a set of possible signers. The verifier can be convinced that the signature
was indeed generated by one of the ring members; however, the verifier is unable to
tell which member actually produced the signature. A convertible ring signature
scheme allows the real signer to convert a ring signature into an ordinary signature
by revealing secret information about the ring signature.
These definitions seem in conflict. One of the cryptographers here at NIST noted that
both descriptions seem to fall into the "group signature" class of algorithms, but she
was not immediately familiar with the term "ring signature" so she couldn't tell me which
was the accepted definition.
I would strongly encourage you to include a reference for the class of algorithms identified
in 4.1.3, since there is some confusion even within the cryptographic community.
(Jari Arkko; former steering group member) (was Discuss) Recuse
Section 2.3 states: The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a method by which multiple link layer segments are bridged into a single segment and specifies the IP-layer support that enables bridging under these circumstances. The proxy in this case forwards messages while modifying their source and destination MAC addresses, and rewrites their Link-Layer Address Options, solicited, and override flags. This is a bit misleading. Classic bridging does not require ND proxying at all. However, there are circumstances outlined in RFC 4389 where its desirable to implement ND proxying / ARP proxying instead of classic bridging. I would suggest a small rewrite: The Neighbor Discovery (ND) Proxy specification [RFC4389] defines an alternative method to classic bridging. Just as with classic bridging, multiple link layer segments are bridged into a single segment, but with the help of proxying at IP layer rather than link layer bridging. The proxy in this case forwards messages while modifying their source and destination MAC addresses, and rewrites their Link-Layer Address Options, solicited, and override flags. Section 4.1.2 says: When sending its Binding Update to the HA, the MN would need to provide a certificate containing the subject(proxy-HA)'s public key and address, the issuer(MN)'s CGA and public key, and timestamps indicating when the authority began and when it ends. This certificate would need to be transmitted at binding time, possibly in a Certificate Path Advertisement [RFC3971]. Messaging or such an exchange mechanism would have to be developed. If I have understood correctly, you are suggesting that the MN sends a certificate to the router. If so, CPA seems the wrong message, as it goes from the router to the host per RFC 3971. (Much of the solution space discussion was enlightening, but details like this you could also remove.)