Last Modified: 2003-02-12
RFC 2461 specifies that IPsec AH should be used to secure signaling for Neighbor Discovery. Due to bootstrapping issues, only manual keying works and that is impractical for most cases. This is in conflict with the goal of Neighbor Discovery, namely to allow complete address autoconfiguration of a node.
The objective of this working group is to define protocol support for securing IPv6 Neighbor Discovery without requiring manual keying. The following are charter items for the working group:
1) A threat assessment and trust model for local links will be worked out. The threat assessment will clearly describe which threats the Neighbor Discovery security solution(s) will address and which are not addressed. The trust model will describe what types of networks require what level of security solution. Together these form a clear problem statement and a set of requirements.
2) A protocol for assuring authenticatable distribution of public keys, that allows for example tying a public key to a node's IP address or interface ID, and for example authenticating a router's authorization to route, will be designed. The working group will consider the presentation by Steve Bellovin at the SEND BOF as a starting point.
3) The use of the key distribution protocol and public key cryptographic scheme for calculating digital signatures in IPsec AH and/or ESP headers will be specified. IANA may be requested to reserve one or more of the reserved SPIs (1-255) for the protocol.
The Working Group will attempt to use well-known and existing public key cryptographic protocols with good security properties, in order to reduce the risk of unintended side effects, and to expedite the completion of the work. The protocol will be designed to assure that all functions of RFC 2461 and RFC 2462 are addressed.
Specifically out of scope is IPv4 and ARP. Although ARP has similar problems, there is a huge installed base of ARP. It seems unlikely that any substantial fraction of that installed based would be updated quickly enough to make a difference. On the other hand, IPv6 deployment is still its initial stages, and changes to Neighbor Discovery are more likely to be widely adopted, if the Working Group executes quickly enough on its task.
| NOV 02 | First draft of draft-ietf-send-psreq-00.txt, the combined Neighbor Discovery threats and trust model drafts. | |
| DEC 02 | Complete draft-ietf-send-psreq-xx.txt and send to IESG for approval. | |
| MAR 03 | Complete selection of a public key scheme. Initial draft of key distribution protocol, draft-ietf-send-protocol-00.txt. | |
| JUL 03 | Intermediate draft of draft-ietf-send-protocol-xx.txt submitted to Security Directorate for security review. | |
| DEC 03 | Submit draft-ietf-send-protocol-xx.txt to IESG for approval. |
Securing Neighbor Discovery WG (send) Tuesday, March 18 at 1545-1645 =============================== CHAIRS: James Kempf <kempf@docomolabs-usa.com> Pekka Nikander <Pekka.Nikander@nomadiclab.com> 5 min. - Agenda discussion, chairs The agenda was accepted. The chairs later on changed it so that the second last item, interaction with PANA / DHCP, was moved after the last item, draft status and schedule. 10 min. - Last Call Issues as resolved for draft-ietf-send-psreq.txt, Pekka Nikander Pekka Nikander went over the issues raised during the WG last call. Most of the issues were minor. However, there were two larges issues, worth spending some face-to-face time. The first issue centered around using the term "trust". Currently the draft uses the term trusts, trusted, trustworthy, etc., in multiple places. However, it would be better to replace the word with more specific words, e.g. "delegation", "authorized", etc. Pekka described how the word is used right now, but also told that he is not very happy with the current resolution of the issue. Bill Sommerfeld came up and promised to come up with alternate wording suggestion by the end of next week (March 28th). It was decided that if Bill comes up with an acceptable alternate wording, that will be incorporated to the next version of the draft. Otherwise the current wording will be used. The other problematic issue was that the current draft discusses a number of possible solutions. Even though these solutions are only used for illustrative purposes, some people had been raised the question on the mailing list whether a problem statement document should include this kind of text at all. The discussion at the mailing list has inconclusive. James Kempf (taking his chair hat off) suggested that the solutions text should be left in the draft, after all, as examples. Bill Sommerfeld supported that, and Alper Yegin (who had raised the issue originally) agreed that the solutions can stay in as long as it is explained that they are just examples. Thus, the decision was to keep the solutions in the text. 10 min. - Self Signed Certificates for CGAs, Tuomas Aura (presented by Pekka Nikander) Pekka Nikander presented Tuomas Aura's slides on his generic draft on using Cryptographically generated IPv6 addresses (CGA). (See the slides). Pekka told that as far as he knows, the idea is covered by IPR at least by Ericsson and possibly by Microsoft. Ericsson has recently released the IPR on this; the statement has been posted to the mailing list and is available at the IETF IPR page. The chairs are discussing the issue with Microsoft now. Hesham Soliman asked whether is the IPR on the CGA idea, or on specific applications? Pekka replied that as far as he knows, the IPRs cover the CGA idea itself. One of the biggest technical problems with CGA so far has been the fact that the IPv6 address structure limits the hash length into 62 bits, which is somewhat insecure. The basic idea in draft-aura-cga-00.txt a method for removing this 64 bit limit by introducing a security parameter (sec) and a seconnd hash (see the slides). With this technique, the cost of address generation and the cost of attacks are increased, keeping their ratio 2^59, but the cost of verification remains constant. Furthermore, the additional cost possibly imposed at address generation can be divided over multiple addresses, since the second hash is independent on the routing prefix and can therefore be used multiple times. In addition to solving the problem with short hash lengths the draft provides exacts algorithms and formats for using CGA addresses. After the presentation Jari Arkko went to the microphone and expressed that he liked this draft, that he likes the idea of generating two separate hashes, and that it looks good for fast mobility. 20 min. - Open Issues on draft-ietf-send-ipsec-00.txt, Jari Arkko (see slides) The Design Team has worked on a solution for some time now, and the draft represents a snapshot of the current thinking. Jari first went through the overall design, and the continued to the most important issues with the document. The first issue with the document is that it has somewhat broad scope, describing several more or less independent techniques, and it looks like the final draft might become quite large. Furthermore, since CGA is covered by IPRs, it may be necessary to split the CGA dependent portions of the draft out. James Kempf opinioned that if the Working Group is able to get the CGA IPR released, the draft does not have to be split. A split could slow down the process. Thus, all parts should go together. Bill Sommerfeld seconded that splitting out CGA makes sense. Alper Yegin said that since there are two independent problems and solutions, Neighbor Discovery and Router Discovery, it makes sense to split, so that one or the other part can be replaced with alternative methods when they are available. After some discussion the chairs declared consensus on that if CGA IPR not resolved, we need to split CGA as a separate part. Otherwise, we'll go with one draft, since there doesn't seem to be any compelling reason to split, and there seems to be different suggestions for splitting, without any single one getting any larger support. The second open issue considered the presented transition scheme. The basic idea in the transition scheme is to view the link as two separate logical links, one being secured with SEND and the other one not. Alper Yegin noted that there is a problem with DAD when some nodes do not support SEND. That can lead to colliding link-local IPv6 addresses. Erik Nordmark noted that the two colliding addresses should be considered to be on two separate links, so no problem. However, this might require implementation considerations. Pekka Savola noted that possibley one could also look at the G bit. Erik Nordmark continued that what doesn't work in this case is that DAD is not going to detect two identical mac addresses being same. This has some disadvantages. In general, it looks like the transition scheme has still some open issues and requires more consideration. The next open issues considered solicitations. Some soliciations have side effects, and therefore they should be secured. However, some solicitations use unassigned source address, and therefore it is very hard to secure them with CGA. Dave Thaler said that there is clearly a threat with the solicitations, the solution should handle it. Additionally, the requirements draft should talk about this threat. It was agreed that the requirements draft must be updated to handle this. The overall plan is to run the Design Team for another couple of months to resolve the remaining technical issues. At the same time, the chairs continue talking to the IPR holders on CGA, to get the IPR released specifically for SEND. 5 min. - Draft Status and Schedule, chairs James Kempf discussed the draft status and schedule (see slides). There was no discussion. 10 min. - Interaction with PANA / DHCP, chairs The final item considered interaction with SEND and PANA and DHCP. Pekka Nikander described some possible scenarios, mainly made to give people something to think about. (see slides) Bernard Aboba said that passing PANA created keys between various parties is not a good idea. The overall system looks very complex, and analysing it would be a nightmare. Parijat Mishra said that in his opinion this is a good idea. If we don't do this, we'll end up with too many keys. Bill Sommerfelds reaction was similar to that of Bernard. There is gotta be a better way. Erik Nordmark said that a short write up on what kind of problems we are solving here would be useful. |