Hello CSI people,
We (Michaela, Sean, Maryline and myself) are currently working on the PKI
agility for SEND. This will offer, for example, support of ECC based CGA
(see draft draft-shen-csi-ecc-01) to SEND. Our work is primarily focused
on a negotiation algorithm for nodes supporting different PKI algorithms.
We introduce a new ICMP error message called "ICMP Unsupported PKI" and an
option to this ICMP message called "supported PKI option". This addition
allows use to have a basic negotiation mechanism that permit
interoperability in most cases.
For scenario where nodes aren't sharing any common PKI algorithm, we then
introduce a new optional entity called "notary" (functionality assumed by
the router for now).
This all will be part of work that Sean will present next Wednesday during
the CSI meeting.
With this mail, you will have an email attachment that contains more
details on the basic ideas to permit PKI agility.
Thanks you in advance for all your review and comments.
Best regards,
Tony Cheneau1. PKI agility basic support:
The PKI agility basic support implies:
- Two IPv6 nodes supporting at least plain ND (RFC 4861) must be able to
perform neighbor discovery
- Two IPv6 nodes supporting SEND and the same PKI algorithm should/must(?) be
able to perform secure neighbor discovery
- We DON'T assume that if a node has two IPv6 addresses, they are for the
assigned to the same interface (i.e. share the same link-layer address).
To achieve this, we define 1 new ICMP error message and 1 option.
The ICMP error message, named ICMP unsupported PKI message, allows a node to
indicate to another node that it doesn't understand the PKI algorithm he is
using. The newly defined option contains the available algorithms.
1.1 ICMP unsupported PKI message:
Packet emitted when a node is not using the same PKI and can't
understand the other node. It uses SEND options to provide its protection.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ SEND secured packet +
| (NDP packets should fit completely) |
- Type and Code are to be defined in the future.
- Packet length is the length of the field SEND secured packet.
- Checksum is a CRC-16 of the whole packet (except this field)
When emitted this packet always carries (in the following order):
- SEND's CGA option
- optional "supported PKI option" (defined in the next section)
- SEND's Timestamp option and SEND's Nonce option (with no particulate order)
- SEND's signature option (adapted to the source address PKI algorithm)
Upon reception, CGA and the signature option are checked in this order.
Only then the inner SEND secure packet is analysed. The destination address is
extracted. The supported PKI option allows a emitting node to find a supported
address a source of the packet. The same packet is then resend, but this time,
with a different PKI algorithm and a different source address (upon which
checks will be performed).
This packet containing this error message is emitted only when:
- the supported PKI algorithms contained in the support PKI option of the
triggering packet and receiving node's support PKI algorithms's intersection
is not void.
When the intersection is void, the SEND returns to its normal process and send
the correct response (a NA to a NS message or a RA to a RS message) since it is
the best a responder can do for the other node.
1.2 Supported PKI option:
This option indicates the available supported PKI algorithms. For Neighbor
Solicitation, Redirect, Router Solicitation, periodic and spontaneous Router
Advertisement and spontaneous Neighbor Advertisement messages , it means PKI
algorithms from which a CGAs were generated. For non-periodic or
non-spontaneous Router Advertisement and non-spontaneous Neighbor Advertisement
messages it is the supported PKI algorithms (whether CGAs were generated from
them or not).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Supported PKI#| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKI Alg. 1 | PKI Alg. 2 | PKI Alg 3. | PKI Alg 4. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| ... |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PKI Alg. N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Length indicates the size of the packet, starting from "PKI Alg. 1"
- Supported PKI# is the number of following supported PKI algorithms. It can be
0, in which case it means that the two nodes don't or won't have a
matching supported PKI algorithm.
- Reserved should be set to 0 when sending and ignored on reception
- PKI Alg. 1 to PKI Alg. N represents the available supported PKI Algorithms.
This field could be:
- value 1: RSA
- value 2: ECC
PKI Alg. X are sorted by order of preference, the first one being the most
preferred one.
When this option appears in spontaneous messages (Neighbor Solicitation,
periodic Router Advertisement, Router Solicitation, Redirect), it contains only
PKI algorithms with which CGAs were generated (even if the node supports
additional PKI algorithms).
When this option appears in an answer of a spontaneous messages, it carries the
intersection between node's supported PKI algorithm and received packet
"Supported PKI option"'s PKI algorithms. Allowing the node that emit the
request, upon receiving this packet to know which PKI algorithm to use.
2. Routers-as-a-notary function (PKI agility optional but recommended support):
Routers can be authorized to act as notary through the certificate there were
delivered. This authorization is very similar to what was proposed in CGA-EXT
ML about router's authorization to act as proxies. It is a field in router's
certificate that explicitly allows the routers to act as a notaries. Similarly,
delegation of SEND function on behalf of other nodes is an approach
investigated in other work-in-progress (i.e. draft-
haddad-csi-symbiotic-sendproxy-00).
Nodes can ask the router to check packets on which signatures were done using
an unsupported PKI algorithm. Routers are much more powerful than node, they
are supposed to be able to support a lot of PKI algorithms.
This is, of course, only used when nodes can't speak the same PKI algorithm.
The router will perform checks on their behalf (can also be a transition
mechanism in "mixed" networks). The router should have the ability to limit the
processed packets in order to avoid DoS attacks.
Two news type of ICMP messages are defined. To remain secure, these messages
use SEND options (signature added when emitted and checked upon
reception).
To simplify, we said that routers were to act as notaries. But a specific node
without routing can be able to act as a notary. This is left for future work.
2.1 Notary signature check request message:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ SEND secured packet +
| (NDP packets should fit completely) |
- Type & Code are to be defined later
- Packet length is the size of the SEND secured packet
- Checksum is a CRC-16 of the whole packet (except this field)
- Request ID. helps to match the signature check request and the signature
status (response) messages.
- Request ID. field is randomly generated.
- SEND secured packet is the packet that the node was not able to verify on his
own.
This message is protected by usual SEND NDP options (TS, Nonce, Signature). It
contains the whole packet than node wants to be checked on the router (so it
can't be tampered with).
Router acting as notaries processes the packet this way:
- it verifies the CGA of the emitter
- it verifies the signature of the emitter (linked to CGA of the source address)
- it verifies the CGA and signature of the inner packet
Notary signature status message:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-Type & Code are to be defined later
- Status can be:
- 0: everything is OK
- 1: inner packet CGA verification check failed
- 2: inner packet signature verification check failed
- 3: unsupported hash algorithm (to compute Hash1)
- 4: unsupported PKI algorithm
- 5: ask later (router is busy)
This message is a response to a Notary signature check request message and is
protected by SEND options (throught the public key of the router that what
contained in the certificate that authorized the router to act as a notary).
On reception of this message, a node performs CGA check and signature check
request. Then, if the status message is 0, it will trust the original packet
that created the need for a Notary signature check request message, resuming
the SEND protocol for secured packets.
On a status value different from 0, the packet will be considered as unsecure
and be treated this way.
Routers multicasting advertisement:
Generally, routers send RA periodically.
In our scenario, routers have at least one address generated by each supported
PKI algorithm. In the basic case, a router will use only its preferred PKI
algorithm to send RAs. Upon receiving an ICMP unsupported
PKI message from a node, he will broadcast on querying node supported PKI
algorithm.
What to do when a node send an ICMP unsupported PKI message because it doesn't
support a PKI and doesn't have an address yet ? Accept it of course.
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
