Presentation is loading. Please wait.

Presentation is loading. Please wait.

Www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体.

Similar presentations


Presentation on theme: "Www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体."— Presentation transcript:

1 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 11/19/08 IETF CSI WG Minneapolis, MN, USA Sean Shen Tony Cheneau Michaela Vanderveen Maryline Macknavicius SeND & CGA PKI Agility Support

2 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 RFC 3971 constraints… and way out “If the node has been configured to use SEND, then [NS, NA, RA][..] and Redirect messages MUST contain the RSA Signature option.” “RSA is mandated because having multiple signature algorithms would break compatibility between implementations” “A second signature algorithm is only necessary as a recovery mechanism, in case a flaw is found in RSA. If this happens, a stronger signature algorithm can be selected, and SEND can be revised. “ The “flaw” has been found: RSA is prohibitive for some types of nodes…. SO: Let’s revise

3 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 Current PKI trends NIST-approved elliptic curve cryptography standards are making their way into other standards; Some protocols have been updated to support ECC: e.g. TLS, IKEv2; Low-power and/or memory/computationally-constrained devices are joining the internet; Finite field crypto (RSA) is burdensome compared to elliptic curve crypto (ECC). Backward compatibility is thus not feasible for these nodes.

4 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 More possible PKIs IEEE P1363 project: develops standard specifications for Public-Key Cryptography, towards the goal of issuing a series of IEEE standards documents. Traditional: Integer factoring (RSA) Discrete logarithm Problem (DSA) Elliptic Curve Cryptography (MQV) Lattice-Based Public-Key Cryptography (P1363.1) Password Based Public-Key Cryptography (P1363.2) Identity Based Public-Key Cryptography Using Pairing (P1363.3)

5 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 Basic Starting Points 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 be able to perform secure neighbor discovery Examples:  Node A supports SEND with RSA only. Node B supports SEND with ECC only or does not support SEND at all. The signaling defaults to plain ND  Node A supports SEND with ECC only. Node B supports SEND with ECC and RSA. The signaling is SEND with ECC.

6 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 CGA Computation If we want “new” pki-agility nodes to perform secure ND with “old” RSA only nodes, we must burn TWO addresses: Modifier RSA Public Key ECC Public Key SHA-1 Hash1Hash2 IPv6 Intfc Identifier1Sec CGA1 SHA-1 Hash1Hash2 IPv6 Intfc Identifier2Sec CGA2 IPv6 Prefix Modifier

7 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 New: Supported PKI option Supported PKI# field indicates the nr. of supported PKI algorithms. PKI algorithms are sorted by order of preference PKI Algorithm field can be assigned: Value 1: RSA Value 2: ECC... 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This option is attached to all spontaneous messages (Neighbor Solicitation, periodic Router Advertisement). Allows the emitters to propose a list of supported PKI algorithms. This option is also attached to ICMP Unsupported PKI message to specify the neighboring node that the PKI algorithm it was using may not part of its supported PKI algorithms.

8 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 New Unverifiable SEND Msg option SEND secured packet is the packet that the node fails to verify Option included when a node is not using the same PKI and can't understand the other node Used in conjunction with signature options for protection. Also used with Supported PKI option. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + SEND secured packet + | (NDP packets should fit completely) |

9 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 New ICMP Unsupported PKI message SEND secured packet is the packet that the node fails to verify This message can include one option: Supported PKI option Packet emitted when a node is not using the same PKI and can't understand the other node Uses SEND options to provide its protection. This message gives receiving node possible alternatives through one option. 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) |

10 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 Example 1a: typical negotiation process Node 1 Supporting : {ECC,RSA} Addresses: N1_ECC, N1_RSA Node 2 Supporting : {ECC} Address: N2_ECC NS, RSA signed (source N1_RSA) Supported PKI option={ECC,RSA} Can't understand its RSA signature I compute intersection between its supported PKI alg. and mine NA, ECC signed (source N2_ECC) Supported PKI option={ECC}, Unverifiable SEND Msg option […] Signature is OK. I see I should use N1_ECC *Resume normal process* * Successful neighbor discovery *

11 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 Example 1b: typical negotiation process Node 1 Supporting : {ECC,RSA} Addresses: N1_ECC, N1_RSA Node 2 Supporting : {ECC} Address: N2_ECC NS, RSA signed (source N1_RSA) Supported PKI option={ECC,RSA} Can't understand its RSA signature I compute intersection between its supported PKI alg and mine ICMP Unsupported PKI message ECC signed (source N2_ECC) Supported PKI option={ECC} Signature is OK I see I should use N1_ECC *Resume normal process* * Successful neighbor discovery *

12 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 Example 2: PKIs supported differ, so do the best you can Node 1 Supporting : {RSA} Address: N1_RSA Node 2 Supporting : {ECC,RSA} Addresses: N2_ECC, N2_RSA NS, RSA signed (destination N2_ECC) Supported PKI option={RSA} I check the signature I answer him normally even if I know he may not understand me I can't check the signature. So try next IP address NA, ECC signed (source N2_ECC) Supported PKI option={RSA,ECC} NS, RSA signed (destination N2_RSA) Supported PKI option={RSA} NA, RSA signed (source N2_RSA) Supported PKI option={RSA,ECC} * Successful neighbor discovery *

13 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 Example 3: only announce PKIs that were used in own CGAs Node 1 Supporting : {ECC,RSA} Address: N1_RSA Node 2 Supporting : {ECC,RSA} Addresses: N2_ECC, N2_RSA NS, RSA signed (destination N2_ECC) Supported PKI option={RSA} I check the signature I answer him normally even if I know he may not understand me I can check signature! NA, ECC signed (source N2_ECC) Supported PKI option={ECC, RSA} Because I don’t have any address generated with ECC * Successful neighbor discovery *

14 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 Extended PKI agility support (optional) Router (ECC, RSA) Node (ECC) Node (RSA)

15 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 Example 2 bis Router Supporting : {RSA,ECC} Addresses: R_RSA, R_ECC Node 2 Supporting : {ECC,RSA} Addresses: N2_ECC, N2_RSA NS, RSA signed (destination N2_ECC) Supported PKI option={RSA} I check the signature I answer him normally even if I know he won't understand me NA, ECC signed (source N2_ECC) Node 1 Supporting : {RSA} Address: N1_RSA Notary signature check on received NA (destination R_RSA) Notary signature status: OK Checks emitter signature Checks inner packet signature I can trust Link-Layer address in the NA

16 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 Router to act as notary Allows nodes that don't speak the same PKI algorithm to securely discover each other Can be seen as a transition mechanism. Routers should be authorized to act as notaries through their certificates. Nodes can then ask the router to check the signature on a received packet, on their behalf. Request and response to the router are new ICMP messages secured with SEND options (message can't be tampered with). Based on the assumption that routers are more powerful than nodes, so they can support more PKI algorithms. Router should rate-limit the processed packets in order to avoid DoS attacks.

17 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 ICMP 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) | Emitted by a node when the situation is blocked due to an unsupported signature algorithm. SEND protected by the emitter Request ID. field is random « SEND secured packet » field contains the packet on which the router will perform the checks Secured with SEND options, in order to avoid message tampering Router processes the packet this way: it verifies the CGA of the emitter it verifies the signature of the emitter (CGA of the source address) it verifies the CGA and signature of the inner packet

18 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 ICMP Notary Signature Status Message 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 busy) Secured with SEND options in order to avoid message tampering 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. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It is the response to a Notary Signature Check Request message. Upon receipt, emitter acts as if it arrived at this signature check result by itself

19 www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体 Future work: Multicast Router Advertisement Routers send RA periodically They must have at least one address per PKI algorithm. Common case: router will use one preferred PKI algorithm when sending RAs. When receiving an ICMP Unsupported PKI message from a host, router will select one PKI algorithm of the list provided by the host and will then advertise another RA using this PKI algorithm. DAD also uses broadcast, but with current message, we can already secure it.


Download ppt "Www.huawei.com 英文标题 :40-47pt 副标题 :26-30pt 字体颜色 : 反白 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文标题 :35-47pt 字体 : 黑体 副标题 :24-28pt 字体颜色 : 反白 字体 : 细黑体."

Similar presentations


Ads by Google