Proof of Position for Auditor managed Endorsements

Introduction In the RATS Architecture , an important input to the Verifier function is the Endorsement. 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 ), 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 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.

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 . The audit device then initiates some commands over this cable that will result in a proof of the idnetity of connected device.

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 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.

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.

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.

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. 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. x5t is from . The hash algoritm SHOULD be SHA256, or newer. (Example to be updated.

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. 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.

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 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.

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:

locate the Endorsement Certificate, if it was not collected from the device.
validate that the provided EAT is signed by the associated Endorsement Key.
validate that the claims in the EAT are consistent with that which is expected from the device.
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.

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 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 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!

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.

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 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 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.

IANA Considerations IANA is asked to allocate a CBOR Tag for this object. Details TBD.

Acknowledgements Your name here.

Changelog