RFC 6273

The Secure Neighbor Discovery (SEND) Hash Threat Analysis

📅 published June 2011, from ietf

The Secure Neighbor Discovery (SEND) Hash Threat Analysis 🎀

RFC number and title: RFC 6273, The Secure Neighbor Discovery (SEND) Hash Threat Analysis ✨

Authors: A. Kukec (University of Zagreb), S. Krishnan (Ericsson), and S. Jiang (Huawei Technologies Co., Ltd) 👯‍♀️

Category: Informational 📚

Date: June 2011 📅

ISSN: 2070-1721

Obsoletes / Updates: The header doesn't list anything this document obsoletes or updates 🦋

Abstract

okay so this doc is literally all about hashes in SEND 🔐 It covers how SEND uses them, what threats could hit them, and how recent attacks on hash functions that SEND relies on could affect things. Quick tea: SEND currently uses the SHA-1 hash algorithm plus PKIX certificates, and it doesn't support hash algorithm agility 🙈 So this doc analyzes the possible threats to the hash algorithms SEND uses. Main character energy 👑

Status of This Memo

This one is not an Internet Standards Track spec. It's published for informational purposes, so no pressure 💅

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ Not every IESG-approved doc is a candidate for any level of Internet Standard, though. See Section 2 of RFC 5741 for the deets 🧚

For info on the current status of this doc, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6273 🌸

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🌈

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Impact of Collision Attacks on SEND . . . . . . . . . . . . . . 3
     2.1.  Attacks against CGAs Used in SEND . . . . . . . . . . . . . 3
     2.2.  Attacks against PKIX Certificates in Authorization
           Delegation Discovery Process  . . . . . . . . . . . . . . . 3
     2.3.  Attacks against the Digital Signature in the SEND RSA
           Signature Option  . . . . . . . . . . . . . . . . . . . . . 4
     2.4.  Attacks against the Key Hash Field of the SEND RSA
           Signature Option  . . . . . . . . . . . . . . . . . . . . . 4
   3.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5

1. Introduction 🌷

Okay, so SEND [RFC3971] uses the SHA-1 hash algorithm [SHA1] to make the contents of the Key Hash field and the Digital Signature field in the RSA Signature option 🔑 It also indirectly uses a hash algorithm (SHA-1, MD5, etc.) through the PKIX certificates [RFC5280] that handle router authorization in the Authorization Delegation Discovery (ADD) process 🛡️

Here's the tea: there have been demonstrated attacks against the collision-free property of these hash functions [SHA1-COLL], and attacks on PKIX X.509 certificates that use the MD5 hash algorithm [X509-COLL] 😭 This document looks at how these attacks impact SEND, and it recommends mechanisms to make SEND resistant to them. Protect the queen 👑

2. Impact of Collision Attacks on SEND 💅

[RFC4270] summarizes a study that assesses the threat these attacks pose to cryptographic hashes in Internet protocols 📊 This document checks out hash usage in SEND using the approach recommended by [RFC4270] and [NEW-HASHES] 🔍

The sections below dig into the different parts of hash usage in SEND and figure out whether each one is affected by attacks on the underlying hash functions. Let's go, bestie ✨

2.1. Attacks against CGAs Used in SEND 🦋

Cryptographically Generated Addresses (CGAs) are defined in [RFC3972]. They're used to securely associate a cryptographic public key with an IPv6 address in the SEND protocol 🔐 The impact of collision attacks on current uses of CGAs is analyzed in [RFC4982] 📖 The basic idea behind collision attacks, as described in Section 4 of [RFC4270], is about the non-repudiation feature of hash algorithms. But CGAs don't provide non-repudiation features, so, as [RFC4982] points out, CGA-based protocols, including SEND, are not affected by collision attacks on hash functions 🙌

Now the part that's giving a little scary 💀 If pre-image attacks ever became feasible, an attacker could find new CGA Parameters that generate the same CGA as the victim. This class of attacks could be potentially dangerous, since the security of SEND messages relies on the strength of the CGA 😳

2.2. Attacks against PKIX Certificates in Authorization Delegation Discovery Process 🏰

To protect Router Discovery, SEND requires that routers be authorized to act as routers 🚦 Routers get authorized by being provisioned with certificates from a trust anchor, and hosts are configured with the trust anchor(s) used to authorize routers 🧾

Researchers demonstrated attacks against PKIX certificates with MD5 signatures in 2005 [NEW-HASHES], in 2007 [X509-COLL] [STEV2007] [SLdeW2007], and in 2009 [SSALMOdeW2009] [SLdeW2009] 🕵️‍♀️ An attacker can use these vulnerabilities to get a certificate with a different identity and then use that certificate to impersonate a router 🎭 For this attack to work, the attacker has to predict the content of all fields that appear before the public key (some of them are human-readable), including the serial number and validity periods 🙈

Even though a relying party can't verify the content of these fields, the CA can identify the forged certificate, if necessary. ⚠️

2.3. Attacks against the Digital Signature in the SEND RSA Signature Option ✍️

The digital signature in the RSA Signature option is made by signing, with the sender's private key, the SHA-1 hash over certain fields in the Neighbor Discovery message, as described in Section 5.2 of [RFC3971] 🖊️ It's possible for an attacker to come up with two different Neighbor Discovery messages, m and m', that end up with the same value in the Digital Signature field 🤯 But the structure of Neighbor Discovery messages is well defined, so it's not practical to use this vulnerability in real-world attacks 🙅‍♀️

2.4. Attacks against the Key Hash Field of the SEND RSA Signature Option 🔑

The SEND RSA signature option described in Section 5.2 of [RFC3971] defines a Key Hash field. This field holds a SHA-1 hash of the public key that was used to generate the CGA 🗝️ To pull off a collision attack on this field, the attacker would need to come up with another public key, k', that produces the same hash as the real key, k 🧐 But the real key k is already authorized through a parallel mechanism (either CGAs or router certificates), so collision attacks are not possible on the Key Hash field 🚫

Pre-image attacks on the Key Hash field aren't useful for the same reason. Any other key that hashes into the same Key Hash value will be caught by a mismatch with the CGA or the router certificate 🛑

Part 1 of 2 💖 Part 2 picks up at Section 3 (Conclusion) and wraps up with the Security Considerations, Acknowledgements, and References.

Authors' Addresses ✨

Okay bestie, these are the humans who wrote this whole thing, so here are their contact details. Reach out if you have questions 🫶

Ana Kukec 🌸

Ana Kukec
University of Zagreb
Unska 3
Zagreb
Croatia

EMail: ana.kukec@fer.hr

Suresh Krishnan 💜

Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada

EMail: suresh.krishnan@ericsson.com

Sheng Jiang 🦋

Sheng Jiang
Huawei Technologies Co., Ltd
Huawei Building, No.3 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing
P.R. China

EMail: jiangsheng@huawei.com

That's the whole doc, bestie! 🌈✨ Go slay your protocol day 💅

📦 where this page comes from