RATS Working Group M. Richardson Internet-Draft Sandelman Software Works Intended status: Standards Track 26 April 2025 Expires: 28 October 2025 Proof of Position for Auditor managed Endorsements draft-richardson-rats-pop-endorsement-00 Abstract Some aspects of a device can not be intuited by the device itself. For instance, a router platform may have no way to know what color the case is, where in a cabinet it is located, or which electrical circuit it is connected to. This kind of information must be provided through an Endorsement: a statement from a third party. These statements may require human audiitors to inspect the device physically. But, which device is really in front of an auditor? This document describes a mechanism by which an auditor can make physical contact with a device and collect information to identify the device in a cryptographically strong manner. This protocol is not designed to run over Internet Protocol cabling, but rather over mechanisms such as USB cables, or serial consoles. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 28 October 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Richardson Expires 28 October 2025 [Page 1] Internet-Draft EAR POP April 2025 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Overview of mechanism . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Initial Handshake . . . . . . . . . . . . . . . . . . . . 4 3.2. Proof of Position . . . . . . . . . . . . . . . . . . . . 4 3.3. Collection of Endorsement Claims . . . . . . . . . . . . 5 3.4. Additional Commands . . . . . . . . . . . . . . . . . . . 6 3.5. Generation of Endorsement . . . . . . . . . . . . . . . . 6 4. Alternatives to USB/serial cables . . . . . . . . . . . . . . 7 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction In the RATS Architecture [RFC9334], an important input to the Verifier function is the Endorsement. Endorsements [I-D.ietf-rats-endorsements] provide information that the Attester can not inherently know. This includes a statement that a particular (Attester) keypair belongs to a device of a particular type. Some of this information might be placed into device identity certificate (such as an IDevID [IDevID]), but many other kinds of claims would not belong. For instance, the physical location or connectivity of a device would be subject to change. In some cases a GPS coordinate might make sense, but in other cases GPS might not be trustworthy, or might be inadequate. The physical location of a router, as being in "Building 4, Aisle 37, Cabinet 9, Rack Unit 2-3" would be a level of precision that GPS would be unable to provide. Other claims might involve Richardson Expires 28 October 2025 [Page 2] Internet-Draft EAR POP April 2025 knowledge of the color of a device ("the red car"), or the connectivity of the device ("the device plugged into the blue cable"). A relative claim might also be relevant: The house on top of the person with Ruby Slippers. In these cases an endorsement will need to be created, often by a human inspector/auditor that will have to physically visit the device and ascertain the state of the device. There are some challenges for such an auditor: they could be led astray by malicious intent to inspect the wrong device, or they could simply not locate the device they intended to audit. This results in an endorsement linked to the wrong device. 1.1. Overview of mechanism The auditor is equiped with a portable device (e.g., a tablet computer) containing an endorsement signing key. This is the audit device. (This could be an actual key, or it could just be a secure/ tamperproof container in which endorsements will be stored until a long-term/more-secure endorsement key can be employed) The auditor finds the device in question and then collects whatever information is relevant. For instance, the location in whatever form makes sense for the endorsement. That might include taking pictures of the device in-situ, scans of serial numbers on the outside of the case, and which cables are connected to which physical ports. The auditor then plugs a physical cable between their audit device and the device under audit. This cable is envisioned to be either a USB console "rollover" cable [rollover]. The audit device then initiates some commands over this cable that will result in a proof of the idnetity of connected device. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Audit Device: The device that is used to collect information that will go into endorsements. Device Under Audit: Abbreviated to DUA. The device for which endorsements are being made. Auditor: The human who inspects the Device Under Audit. Richardson Expires 28 October 2025 [Page 3] Internet-Draft EAR POP April 2025 3. Protocol It is assumed that the console port has been designed for use by humans. This protocol is designed to interact as if it's a human. Note that more sophisticated mechanisms such as SLIP or PPP would be more vulnerable to spoofing. 3.1. Initial Handshake The audit device sends carriage returns (octet 13) until it sees a response with a colon (":") in it. This is usually a "login:" or "username:" prompt of some kind. The audit device then sends the word "endorsementaudit" with a carriage return. This represents a user login, and for some systems this can be set as a real login with limited permissions. It could run a special audit shell that only can perform system audits. On other systems, this might just an unpriviledged account with the normal prompts and commands. The handshake is over when the word "endorsement" is seen. 3.2. Proof of Position (Proof of Position is probably a silly name that ought to be replaced) All commands are prefixed with "rfcXXXX" (with a trailing space, where XXXX is the number of this document). A second word indicates the command. The allows the device under audit to collect all operations under a single command or command sub-system. The audit device then sends the word/command "position-proof", followed by a 33 byte nonce, base64URL encoded into a 45 byte string. (33 bytes are recommended because being divisible by three, they encode evenly in base64, leaving no trailing =) The device under audit then responds with a CBOR format EAT object, encoded in base64URL, and wrapped in the strings "--- BEGIN COSE OBJECT ---" and "--- END COSE OBJECT ---" {XXX: or should we use CBOR Diagnostic Format?} The EAT payload should be constructed as follows. Shown are a few attributes that would make sense to include. The above provide nonce becomes the eat_nonce. Richardson Expires 28 October 2025 [Page 4] Internet-Draft EAR POP April 2025 { / eat_nonce / 10: h'948f8860d13a463e8e', / ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea', / oemid / 258: h'894823', / IEEE OUI format OEM ID / / hwmodel / 259: h'549dcecc8b987c737b44e40f7c635ce8' / Hash of chip model name /, / hwversion / 260: ["1.3.4", 1], / Multipartnumeric version / / swname / 271: "Acme OS", / swversion / 272: ["3.5.5", 1], } The EAT payload is signed using the device under audit's Attestation Key. (A TPM's Endorsement Key can not sign things) The hash of the Attestation Key is provided in the unprotected headers. 61( 18( [ h'A10126', / protected headers / { / x5t / 34: [16, h'1234456781234567812344567812345678'], }, / unprotected headers / h'A20B46024A6B0978DE0A49000102030405060708', / payload / h'9B9B2F5E470000F6A20C8A4157B5763FC45BE759 9A5334028517768C21AFFB845A56AB557E0C8973 A07417391243A79C478562D285612E292C622162 AB233787' / signature / ] ) ) x5t is from [RFC9360]. The hash algoritm SHOULD be SHA256, or newer. (Example to be updated. 3.3. Collection of Endorsement Claims The audit device then validates the received EAT object from the device. The audit device locates the public part of the device's Attestation Key. This will in most cases be part of the "work order" that the auditor has been provided, but in some cases, the auditor will have to collect it from the device. For instance, a device might have been replaced since the audit was requested, or there might be additional devices that the auditor thinks might be relevant. An example might be when a switching device has many cables connected into an adjacent optical media converter that puts multiple signals through a single multi-frequency optical cable. Such a layer of indirection might affect the audit's ability to indicate which port is physically connected to which cable. Richardson Expires 28 October 2025 [Page 5] Internet-Draft EAR POP April 2025 Some key physical information that an auditor might need to collect is which fibre patches are connected to which ports of the switch. This information would be ideally collected by scanning (and checking) labels on the fibre patches. 3.4. Additional Commands Some additional commands can be provided by the device under audit: "attestation-key": This command returns the public certificate for the device's Attestation Key in [RFC7468] Certificate format. "port-flash": This command takes an interface number/name (e.g., "GigabitEthernet 3/014"), and causes the LEDs adjacent to a particular port to flash in a distinct pattern. This is to help identity which physical port is which. "port-down": This command takes an interface number/name (as above), and causes the switch to mark the physical port as down, but not turn off the laser. Traffic SHOULD be re-routed as if the fibre has failed. This is a disruptive test! The auditor may then physically unplug the fibre as part of an audit of the fibre paths. This command might not perform the action immediately, but could signal to the network operations center that such a test is desired, and allow them to approve it. "port-up": Indicates the end of an path-audit started by "port- down". "endorsements": This command is followed by a base64URL encoded CBOR Sequence of Endorsements, wrapped in the same BEGIN COSE header and footer as before. To guard against failure during, the device under audit SHOULD time out this command after 120s if no END COSE OBJECT framing is seen. This command allows the auditor to load any resulting endorsements directly into the device to be passed up along with Evidence to a Verifier. "exit": This command indicates that the audit is over, and the device under audit can return the console interface to the normal state. 3.5. Generation of Endorsement The auditor, having collected one or more proofs, then transmits them to the endorsement agency. This may be via physical transfer, secured email, or some secured online API. The endorsement agency then needs to do the following: Richardson Expires 28 October 2025 [Page 6] Internet-Draft EAR POP April 2025 1. locate the Endorsement Certificate, if it was not collected from the device. 2. validate that the provided EAT is signed by the associated Endorsement Key. 3. validate that the claims in the EAT are consistent with that which is expected from the device. 4. validate the format of the additional information collected by the auditor. Location, type and number of connections, (colour of device even). From this, one or more Endorsements are then created and signed by the endorsing agency. In some cases the auditor might be entirely self-contained, producing the endorsements directly on their audit device. In that case, they would use the "endorsements" to load the resulting Endorsements directly into the device. 4. Alternatives to USB/serial cables There are a number of cases where a USB or serial console cable might be unavailable, or it's might be undesireable. Many smaller IoT devices, home routers and consumer items do not have any kind of console available. The console access might require removal of the case, which might be impossible to do while the device is operational, or while the device is physically installed. Console access might provide access to a priviledged prompt; that access might either be unsafe to give to the auditor, or might require a password to access that should not be shared. One alternative is to use Ethernet. Most routing platforms have many ethernet ports, and usually have at least one empty ethernet port. It is also common for there to be a dedicated copper ethernet port for management even on routing platforms that otherwise only have fiber-optic ports running at multiple hundred gigabits. The use of ethernet has problems because ethernet can easily be switched; transmitting the signal to another device elsewhere. This is often the whole point of the routing platform: to switch traffic elsewhere. This would result in a false audit if the auditor is diverted. The LLDP protocol [LLDP] is a one-hop protocol which is usually not forwarded. It can do things like tell a connected device which port of client device is connected to. While trustworthy devices will not forward LLDP frames, an untrustworthy device that has been programmed to participate in a subterfuge might well forward frames. It might Richardson Expires 28 October 2025 [Page 7] Internet-Draft EAR POP April 2025 be possible to construct a challenge/response system that has the auditor plug cables in some non-deterministic order in order to defeat the subterfuge. This process would probably need to augmented with some other forms of feedback; perhaps flashing of status LEDs on the device in a pattern. Note: the console/USB cable could also be redirected to another host! 5. Privacy Considerations The ability to walk up to a device and interogate it as to it's identity is potentially privacy violating if the device is associated with a person. This would include all kinds of small devices: phones, laptops, electric bicycles, automobiles, One countermeasure is that the device needs to be put into an audit mode before it can be interrogated. This is reasonable for some devices and some audit processes, but for other processees, the need to do random audits may countermand this need. For devices such as large routing platforms, they are often located in data centers with multiple layers of physical access control: locked buildings, locked machine rooms, and locked cabinets. For such devices, there are perhaps few privacy concerns, and the auditor needs credentials in order to access the device at all. 6. Security Considerations There are three concerns with this protocol. The first is the potential for unauthorized people to collect information about devices to which they have no authority to interogate. In industrial settings, this is mitigated by physical access controls. In those settings the ability to identify devices which may be physically misbehaving or are damaged and connect them to their digital identity significantly outweighs any concerns about device identity. In consumer and retail settings, the device SHOULD not respond to this protocol unless an operator/owner has put the device into device identication mode. The second concern with this protocol is that it might be spoofed or confuzzled. The auditor could be mislead as whether the device in front of them is really the device that is responding to their queries. The auditor SHOULD have the device identity with them already as part of the work order. They should therefore not be Richardson Expires 28 October 2025 [Page 8] Internet-Draft EAR POP April 2025 mislead as to which device they intend to audit, the issue is that it might not be the device that is physically in front of them. The device might be a mock-up designed to look right, but really it is wired secretly to the real device which is elsewhere, and is differently configured. This attack is called the "Sock-Puppet" attack. Such attacks require physical examination to detect. Some attacks may be mitigated through careful use of the "port-flash" commands to cause signals visible to the auditor that would ideally be difficult to fake. Efforts this way are the subject of further work. The third concern with this protocol is that it might open up the device to attacks via this console port. The Initial Handshake Section 3.1 mechanism is designed so that it can be easily implemented by typical router and operating system login mechanisms. A very limited account would be created, or even a mode within the login mechanism itself, and so no additional inquiries would be possible. Some operators prefer to never have a login process on the console/craft ports of their devices. This is usually done so that maintenance people do not need to have passwords that can then be re- used over a network, weaking the security of the device. They depend upon physical security for the console ports to provide security. Such operators might wish to rethink this policy for devices which will be subject to audit. 7. IANA Considerations IANA is asked to allocate a CBOR Tag for this object. Details TBD. 8. Acknowledgements Your name here. 9. Changelog 10. References 10.1. Normative References [I-D.ietf-rats-endorsements] Thaler, D., Birkholz, H., and T. Fossati, "RATS Endorsements", Work in Progress, Internet-Draft, draft- ietf-rats-endorsements-06, 3 March 2025, . Richardson Expires 28 October 2025 [Page 9] Internet-Draft EAR POP April 2025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, April 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9360] Schaad, J., "CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates", RFC 9360, DOI 10.17487/RFC9360, February 2023, . 10.2. Informative References [IDevID] IEEE Standard, "IEEE 802.1AR Secure Device Identifier", 2018, . [LLDP] IEEE Standard, "802.1AB-REV - Station and Media Access Control Connectivity Discovery", 19 June 2009, . [rollover] Wikipedia, "Console Rollover Cable", 26 April 2025, . Author's Address Michael Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca Richardson Expires 28 October 2025 [Page 10]