[6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Fri, 31 January 2020 23:19 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: 6lo@ietf.org
Delivered-To: 6lo@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F45C120052; Fri, 31 Jan 2020 15:19:08 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6lo-ap-nd@ietf.org, Shwetha Bhandari <shwethab@cisco.com>, 6lo-chairs@ietf.org, shwethab@cisco.com, 6lo@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.116.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158051274858.21121.16988738930495243847.idtracker@ietfa.amsl.com>
Date: Fri, 31 Jan 2020 15:19:08 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/jhlOH82H5d4qORtvpPFqigCY9UI>
Subject: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2020 23:19:08 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-6lo-ap-nd-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The CIPO description specifies that a 5-bit Reserved1 field and a 13-bit Public Key Length field are combined to fit into a 16 (not 18)-bit space. (The Figure shows the Public Key Length field as 11 bits.) Why do we need to allow ambiguity/flexibility as to the point representation within a given Crypto-Type value (as opposed to fixing the representation as a parameter of the Crypto-Type)? Alternately, what does "(un)compressed" mean, as it's not really clarified directly? Furthermore, Table 2 lists an "(un)compressed" representation for type 0 (over P-256), but RFC 7518 notes that the compressed representation is not supported for P-256 (Section 6.2.1.1). I also am not finding the needed codepoints registered in the JOSE registries to use ECDSA25519 (crypto-type 2) -- do we need to register anything there? Per my comment on Section 4.4, there may be some implicit expectation/requirement of 128+-bit ROVRs for AP-ND, but I didn't find where such a requirement was stated. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this well-written document! It will be good to see this stuff getting deployed. What's the risk of DoS via (short) address exhaustion in terms of 6LBR resources (as distinct from 6LR resources mentioned at the end of Section 7.1)? Section 1 In this specification, a 6LN generates a cryptographic ID (Crypto-ID) and places it in the ROVR field during the registration of one (or more) of its addresses with the 6LR(s). Proof of ownership of the Crypto-ID is passed with the first registration exchange to a new 6LR, and enforced at the 6LR. The 6LR validates ownership of the cryptographic ID before it creates any new registration state, or changes existing information. I'll read on and see, but how much trust does this imply that we require of all 6LRs (as opposed to the 6LBR, which is kind of required to be pretty trusted)? [ed.: basically complete trust is required] The protected address registration protocol proposed in this document enables Source Address Validation (SAVI) [RFC7039]. This ensures that only the actual owner uses a registered address in the IPv6 source address field. A 6LN can only use a 6LR for forwarding packets only if it has previously registered the address used in the source field of the IPv6 packet. nit: this last sentence is written as if we not only enable, but also require, SAVI. The 6lo adaptation layer in [RFC4944] and [RFC6282] requires a device to form its IPv6 addresses based on its Layer-2 address to enable a better compression. This is incompatible with Secure Neighbor Discovery (SeND) [RFC3971] and Cryptographically Generated Addresses (CGAs) [RFC3972], since they derive the Interface ID (IID) in IPv6 addresses with cryptographic keys. Are we going to have some further discussion of the scope of that loss of functionality and/or alternative mechanisms to achieve those goals, or is this statement just intended to note the incompatibility? Section 3 The proof requires the support of Elliptic Curve Cryptography (ECC) and that of a hash function as detailed in Section 6.2. To enable the verification of the proof, the registering node needs to supply certain parameters including a Nonce and a signature that will demonstrate that the node has the private-key corresponding to the public-key used to build the Crypto-ID. nit: the proof itself may only indirectly involve a hash, since we use non-prehash Ed25519 (but the hash function is still needed to generate the Crypto-ID itself). nit(?): I think we tend to see "possesses the private key" more often than "has the private-key", for parallelism with the "proof of possession" term of art. The elliptic curves and the hash functions that can be used with this specification are listed in Table 2 in Section 8.3. The signature scheme that specifies which combination is used is signaled by a nit: this could be misread as saying that the Table is authoritative, not the registry. Section 4.1 The Crypto-ID is derived from the public key and a modifier as follows: 1. The hash function indicated by the Crypto-Type is applied to the CIPO. Note that all the reserved and padding bits MUST be set to zero. 2. The leftmost bits of the resulting hash, up to the size of the ROVR field, are used as the Crypto-ID. This construction seems to allow for some malleability, in that an attacker who observes a given Crypto-ID and CIPO could produce a related, valid, Crypto-ID by reducing the ROVR length and truncating what was received. I haven't attempted to explore what (if any) potential consequences there are of such malleability, and would like to know if anyone else has already done so. It looks like the NDPSO construction includes the length of the Crypto-ID, so it would be hard for an attacker to do much with such a truncated Crypto-ID, but attacks only get better... Section 4.2 nit: I confess I'm missing what compels us to produce a de novo definition of the "Status" field (and Length field) as opposed to deferring to the RFC 8505 definition, as we do for most of the other fields. Section 4.3 Crypto-Type: 8-bit unsigned integer. The type of cryptographic algorithm used in calculation Crypto-ID (see Table 2 in Section 8.3). Although the different signature schemes target similar cryptographic strength, they rely on different curves, hash functions, signature algorithms, and/or representation conventions. While the currently-defined signature schemes target similar cryptographic strength, do we need to imply that all future ones will also target a similar strength (especially since Section 8.3 admits the possibility of "better security")? Modifier: 8-bit unsigned integer. Set to an arbitrary value by the creator of the Crypto-ID. The role of the modifier is to enable the formation of multiple Crypto-IDs from a same key pair, which reduces the traceability and thus improves the privacy of a constrained node that could not maintain many key-pairs. It may be worth digging in a little further to the threat model being addressed here -- while I laud the ability to have multiple Crypto-IDs from a single keypair, it seems that the tracking-prevention this affords implies an attacker who can observe Crypto-IDs, most likely at multiple points in the network. Are Crypto-IDs used for anything other than EAROs? I don't have a great sense for how likely it is that an attacker in position to observe (a subset of) EAROs would not also be in a position to observe at least one associated CIPO, which includes all the information needed to generate the Crypto-ID other than the Modifier. With only an 8-bit Modifier space, brute-forcing the other possible Crypto-IDs for that keypair is not terribly strenuous, whereas allowing for a (potentially variable length?) larger Modifier, say 64 bits, would substantially increase the work-factor needed to predict (and store!) other Crypto-IDs that might be used for this keypair. Given that the CIPO already carries the public key itself, it's not entirely clear how space-constrained we are so as to limit this to just 8 bits of modifier. Padding: A variable-length field completing the Public Key field to align to the next 8-bytes boundary. (MUST be set to zero by sender and ignored by receiver, as well?) The implementation of multiple hash functions in a constrained devices may consume excessive amounts of program memory. But multiple signature algorithm implementations will not? Section 4.4 Is there some more discussion to have about how NDPSO includes only a specific fixed set of information under the signature but RSAO signs all options that appear prior to it in the message? nit: style suggests parallelism between the Section 4.3 and 4.4 introductory remarks (e.g., "this specification defines the NDP Signature Option (NDPSO)"). As opposed to the RSA Signature Option (RSAO) defined in section 5.2. of SEND [RFC3971], the NDPSO does not have a key hash field. The hash that can be used as index is the 128 leftmost bits of the ROVR field in the EARO. nit: this last sentence perhaps leaves more context implicit than the reader might like; I suggest "Instead, the leftmost 128 bits of the ROVR field in the sibling EARO are used to lookup the key used for signature verification, [left-padded with zeros if needed]". (I added the part in square brackets because I'm not sure that anything guarantees the ROVR will actually contain 128 bits -- when AP-ND is not in use its typically just 64 bits, right?) Pad Length: 8-bit unsigned integer. The length of the Padding field. (In octets?) Padding: A variable-length field making the option length a multiple of 8, containing as many octets as specified in the Pad Length field. Typically there is no need of a padding and the field is NULL. Just to check: nothing requires the use of minimal-length padding to achieve the required alignment, and padding of 200+ bytes is permitted by the spec, albeit silly? Section 6 This specification enables the 6LR to verify the ownership of the binding at any time assuming that the "C" flag is set. The verification prevents other nodes from stealing the address and trying to attract traffic for that address or use it as their source address. nit: I think that the verification cannot be done unilaterally by the 6LR, so maybe "enables the 6LR to challenge the node to verify its ownership of the binding at any time" is better. A node may use multiple IPv6 addresses at the same time. The node MAY use the same Crypto-ID, to prove the ownership of multiple IPv6 addresses. The separation of the address and the cryptographic nit: no comma material avoids the constrained device to compute multiple keys for nit: "avoids the need for" multiple addresses. The registration process allows the node to use the same Crypto-ID for all of its addresses. nit(?): We could potentially mention again the ability to use different Crypto-IDs with a single keypair, though there's not any clear need to do so. Section 6.1 Mostly just for my own elucidation, where is it first specified to put the address being registered in the Target Address field of the NS message? detrimental to the battery lifetime. Alternatively, the device may use an always-incrementing value saved in the same stable storage as the key, so they are lost together, and starting at a best effort random value, either as Nonce value or as a component to its computation. nit: "as the Nonce value". and the NDPSO containing the signature. The information associated to a Crypto-ID stored by the 6LR on the first NS exchange where it appears. The 6LR MUST store the CIPO parameters associated with the nit: I think there's a verb missing in this sentence ("MUST be"?) |------- NS with EARO, CIPO, NonceLN and NDPSO -------->| (This still includes the Crypto-ID, even if there's not room in the figure to explicition indicate that, right?) * Upon the first exchange with a 6LR, a 6LN will be challenged to prove ownership of the Crypto-ID and the Target Address being How is the "first exchange" tracked? Just whether the 6LR knows about the registered IPv6 address, or the L2 address, or something else? In particular, if a 6LR has cached an IP address/ROVR binding, and an attacker tries to join that 6LR with that address/ROVR, what controls whether the 6LR will challenge the attacker's 6LN? Is it purely at the 6LR's discretion? * The challenge is triggered when the registration for a Source Link-Layer Address is not verifiable either at the 6LR or the 6LBR. In the latter case, the 6LBR returns a status of "Validation Requested" in the DAR/DAC exchange, which is echoed by the 6LR in the NA (EARO) back to the registering node. The challenge MUST NOT alter a valid registration in the 6LR or the 6LBR. nit(?): the previous bullet describes a case where the 6LR MUST issue a challenge; my understanding is that this bullet describes an additional way in which challenges can occur (i.e., when the 6LBR doesn't know about the address registration either). Stylistically, it might be more clear to reword this as being an "additional case" on top of the previous one, as opposed to the current wording which tries to be very general about when a challenge can happen, which is neither a parallel construction to the previous bullet nor particularly clear about what new information is being conveyed by this bullet. * In order to validate the ownership, the 6LR performs the same steps as the 6LN and rebuilds the Crypto-ID based on the parameters in the CIPO. If the rebuilt Crypto-ID matches the ROVR, the 6LN also verifies the signature contained in the NDPSO option. If at that point the signature in the NDPSO option can be verified, then the validation succeeds. Otherwise the validation fails. I worry a little bit that we haven't fully specified the entire list of steps the 6LR takes to follow the cryptographic chain and validate that the 6LN holds the key in question and registers the address in question to the Crypto-ID in question. I don't have a specific thing in mind that the 6LR might forget, but if we explicitly state what things are bound to what other things, the 6LR is less likely to make a security-relevant mistake. Section 6.2 Might we want to include the Modifier or the Crypto-ID itself in the signed data, in addition to the public key, to avoid any potential misbinding? 2. JWK-encoded public key [just to check: JWK-encoding means that we have an injective map and aren't subject to some sort of extension attack? Not that such a thing would be easy to pull off, with a strict registry of Crypto-Types, of course] 6. The length of the ROVR field in the NS message containing the Crypto-ID that was sent. nit: is this really the NS "that was sent" as opposed to the NS under construction that contains the NDPSO? (This is related to my question up in Section 6.1.) Tying the initial NS to the followup one requires more state on the 6LR (though the 6LR probably already had to keep state for the Nonce) and makes some of the verification steps a bit tougher to implement correctly. 7. 1-byte (in network byte order) Crypto-Type value sent in the CIPO option. nit: Is there any byte order with distinct representation from network byte order, for a 1-byte quantity? ;) * Depending on the Crypto-Type, apply the hash function on this concatenation. nit: is this clearer as "Apply the hash function (if any) specified by the Crypto-Type to the concatenated data"? * Depending on the Crypto-Type, sign the hash output with ECDSA (if curve P-256 is used) or sign the hash with EdDSA (if curve Ed25519 (PureEdDSA)). nit: this text is not very consistent with the idea of an extensible registry of Crypto-Types; similar "apply the signature algorithm specified by the Crypto-Type" language to what I suggested above may be appropriate. The 6LR on receiving the NDPSO and CIPO options first regenerates the Crypto-ID based on the CIPO option to make sure that the leftmost bits up to the size of the ROVR match. If and only if the check is In the vein of my previous questions about where the Crypto-ID appears and truncation/malleability, this text seems to leave some room for confusion about how many bits of output are being compared, and compared to what. * Depending on the Crypto-Type indicated by the (6LN) in the CIPO, apply the hash function on this concatenation. [similar comment as above] * Verify the signature with the public-key received and the locally computed values. If the verification succeeds, the 6LR and 6LBR add the state information about the Crypto-ID, public-key and Target Address being registered to their database. This might be a place to reiterate the FCFS nature of address registration, though it's hardly necessary. Section 6.3 In a multihop 6LoWPAN, a 6LBR sends RAs with prefixes downstream and the 6LR receives and relays them to the nodes. 6LR and 6LBR communicate using ICMPv6 Duplicate Address Request (DAR) and Duplicate Address Confirmation (DAC) messages. The DAR and DAC use the same message format as NS and NA, but have different ICMPv6 type values. In AP-ND we extend DAR/DAC messages to carry cryptographically generated ROVR. In a multihop 6LoWPAN, the node exchanges the messages shown in Figure 6. The 6LBR must identify who owns an address (EUI-64) to defend it, if there is an attacker on another 6LR. This description feels a little vague to me -- I'm interested in knowing how the 6LBR gains confidence that a proof-of-possession was provided to the 6LR, and how the ROVR gets validated at 6LBR and 6LR when the 6LN in question moves to a new 6LR. What information remains local to (each) 6LR and what is communicated between 6LR and 6LBR? This also relates to the "how trusted are 6LRs?" question I mentioned earlier. Section 7 It might be appropriate to talk about how the NonceLR and NonceLN combine to ensure contributory behavior from both 6LR and 6LN, and that each protects against a different type of replay attack. Section 7.1 Duplicate Address Detection DoS Attack: Inside the LLN, Duplicate Addresses are sorted out using the ROVR, which differentiates it from a movement. DAD coming from the backbone are not forwarded over the LLN, which provides some protection against DoS attacks inside the resource-constrained part of the network. Over the backbone, the EARO option is present in NS/NA messages. This protects against misinterpreting a movement for a duplication, and enables the backbone routers to determine which one has the freshest registration and is thus the best candidate to validate the registration for the device attached to it. But this specification does not guarantee that the backbone router claiming an address over the backbone is not an attacker. Where do we specify the behavior of the 6LBR to reject EAROs when the 6LBR is not the one with the freshest registration? Or do I misunderstand the discussion of "freshest registration"? Replay Attacks Using Nonces (NonceLR and NonceLN) generated by both the 6LR and 6LN provides an efficient protection against replay attacks of challenge response flow. The quality of the protection still depends on the quality of the Nonce, in particular of a random generator if they are computed that way. It's probably worth noting explicitly that we do not require unpredictable nonces, just non-repeating ones. Neighbor Discovery DoS Attack: A rogue node that managed to access the L2 network may form many addresses and register them using AP- ND. The perimeter of the attack is all the 6LRs in range of the attacker. The 6LR MUST protect itself against overflows and reject excessive registration with a status 2 "Neighbor Cache Full". This effectively blocks another (honest) 6LN from registering to the same 6LR, but the 6LN may register to other 6LRs that are in its range but not in that of the rogue. Are there L2 technologies where L2 media keys are tied to L2 address, so a rogue node might be rate-limited or given a quota based on L2 address? Section 7.2 address. This specification frees the device to form its addresses in any fashion, thereby enabling not only 6LoWPAN compression which derives IPv6 addresses from Layer-2 addresses but also privacy addresses. We noted in Section 1 that the 6lo adaptation layer requires use of L2-address-based IPv6 address selection, so it's not clear how it would be valid to use privacy addresses with this specification. Section 7.3 We seem to be assuming for these calculations/discussion that the hash used for calculating the Crypto-ID is a well-behaved cryptographic hash and thus that random collisions are the only ones possible. It would be worth mentioning that weaknesses in the hashes associated with a given Crypto-Type could allow attackers to make more targetted collision attempts. The formula for calculating the probability of a collision is 1 - e^{-k^2/(2n)} where n is the maximum population size (2^64 here, 1.84E19) and K is the actual population (number of nodes). If the nit: minuscule vs. majuscule 'k'/'K' Section 7.4 The signature schemes referenced in this specification comply with NIST [FIPS186-4] or Crypto Forum Research Group (CFRG) standards [RFC8032] and offer strong algorithmic security at roughly 128-bit security level. These signature schemes use elliptic curves that Do we want to make any forward-looking statement about the expected strength of future-defined Crypto-Types? ("No" is a fine answer...) Section 7.5 The text here is more about cross-algorithm attacks than cross-protocol ones. It would be great to see some text about cross-protocol attacks added, too (e.g., prohibiting use of the keypair for anything other than AP-ND). Section 7.6 This specification distributes the challenge and its validation at the edge of the network, between the 6LN and its 6LR. The central 6LBR is offloaded, which avoids DOS attacks targeted at that central entity. This also saves back and forth exchanges across a nit: "the central 6LBR is offloaded" reads very oddly, as the offloading is of work from the 6LBR, but the 6LBR itself remains in place. The downside is that the 6LBR needs to trust the 6LR for performing the checking adequately, and the communication between the 6LR and the 6LBR must be protected to avoid tempering with the result of the test. I'd prefer to see some more details about the nature of the required protection for 6LR/6LBR communications. If a 6LR is compromised, it may pretend that it owns any address and defeat the protection. It may also admit any rogue and let it take ownership of any address in the network, provided that the 6LR knows the ROVR field used by the real owner of the address. nit: this language could probably be tightened up to be more precise about the hazards. Section 8.3 New Crypto-Type values providing similar or better security (with less code) may be defined in the future. I'm not sure what purpose the "with less code" requirement serves. It seems to needlessly constrain future actions. Section 11 Curve25519 support is a MAY, so I think RFC 7748 belongs as normative; likewise for RFCs 8032 and 6234. It's probably better to cite RFC 7696 as BCP 201 directly. Section B.3 It would be great if the document shepherd could diff the paramters listed here against [CURVE-REPRESENTATIONS].
- [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-… Benjamin Kaduk via Datatracker
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Pascal Thubert (pthubert)
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Rene Struik
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Pascal Thubert (pthubert)
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Pascal Thubert (pthubert)
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Pascal Thubert (pthubert)
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Pascal Thubert (pthubert)
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Pascal Thubert (pthubert)
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Pascal Thubert (pthubert)
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Pascal Thubert (pthubert)
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Pascal Thubert (pthubert)
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Pascal Thubert (pthubert)
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Pascal Thubert (pthubert)
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk