Hi, I have several questions regarding certificates with multiple NodeIDs. It seems that different parts in the draft contradict each other.
First, section 6.6.1 defines requirements for future overlay link protocols. I suppose, that current overlay link protocol must meet these requirements.
Endpoint authentication When a node forms an association with another endpoint, it MUST be possible to cryptographically verify that the endpoint has a given Node-ID.
Certificates with multiple NodeIDs sometimes violate this requirement. Unless a connection was formed as a result of exchanging Attach messages, it is impossible to associate an endpoint and its NodeID, which is the case when new node connects to BootstrapPeer. As a consequence several reload requirements are hard or even impossible to implement IMHO. The first requirement is that ConnectionTable SHOULD use some indexes instead of mapping NodeIds to (D)TLS Connections. The second requirement is in section 6.1.2
If a node with a certificate with multiple Node-IDs attempts to route a message other than a Ping or Attach through a node without performing an Attach, the receiving node MUST reject the request with an Error_Forbidden error. The node MUST implement support for returning responses to a Ping or Attach request made by a joiningnode Attaching to its responsible peer.
The routing decisions must be made based on ForwardingHeader alone, and a ForwardingHeader does not contain information about type of the message, being sent. So this is practically NOT implementable. Section 3.2.1 Bullet 2 - about Clients, that connect to peers
A client connected this way using a certificate with only a single Node-ID can proceed to use the connection without performing an Attach (Section 6.5.1). A client wishing to connect using this mechanism with a certificate with multiple Node-IDs can use a Ping (Section >6.5.3) to probe the Node-ID of the node to which it is connected before doing the Attach.
As far as I understand, the procedure is as follows. The peer in the overlay, that listens on some known port, receives a connection from a client. This connection is in some unknown state because NodeId of at least one endpoint is not known. Then, the client must send a PingReq to the wildcard NodeId. It will be consumed by the peer as the next endpoint. Once the client has learned the peer's NodeID, it may send Attach, with, as I suppose, one static candidate. The peer must somehow find out that this static candidate is the connection, that is already formed and do not try to form it again. (Moreover the Attach section doesn't state what to do if the connection is already formed. This is also essential for the topology plugin, since some node may already have an opened connection with its new neighbour (consider peer-ready update), but in that case NodeIds are known and connection table can be searched). In my opinion, both client and peer could learn each other's NodeIDs from the Ping. Both PingReq and PingAns are signed and thus uniquely identify its senders. Since the connection to the client is in some unknown state and the destination was wildcard NodeID, the peer can assume that the sender of this message is another endpoint of this connection. The peer can also compare the client's certificate with the one, used to form TLS association. Another question, that I have, is shared-secret admission schemes for TLS. The TLS-PSK RFC states, that in case of TLS-PSK certificate exchange is optional. It is unclear from the RFC, that PSK ciphers with certificate exchange must be selected. It is also unclear, what should be sent in TLS-PSK identity field - username, NodeID, both or nothing. As of TLS-SRP RFC the client certificate cannot be requested. I also can imagine two possible solutions to the first problem. Solution 1(undesirable): Have a specified way of finding out peer's identity. If one of the certificates had multiple NodeIds, the first message, that is sent over this connection must identified both peers. This can be Ping, Attach or some dedicated "HelloReq" and it works as described above. After this exchange both peers must update their connection tables with NodeIDs of the endpoints. This solution is undesirable, since it increases message load on bootstrap nodes. Solution 2: Use TLS Extension to exchange not only the certificates, but also NodeID (in some form, e.g. the cert_hash_node_id form) during the TLS connection. The extension can use SupplementaryData [RFC 4680 <http://tools.ietf.org/html/rfc4680>] to exchange the actual NodeID. For example: struct { SupplementalDataType supp_data_type; uint16 supp_data_length; select(SupplementalDataType) { case reload_signer_identity: SignerIdentity } } SupplementalDataEntry; The 2 extensions, that look most suitable are: 1. user-mapping [RFC 4681<http://tools.ietf.org/html/rfc4681>]. The information, that is sent, is exactly what is needed,but the RFC defines only client's authentication, not the server's. 2. serverautz/clientauthz [RFC 5878 <http://tools.ietf.org/html/rfc5878>]. This RFC is not standard. I also want to propose more precise way for configuring TLS connection, by using a dedicated section and overlay-config for configuring underlay link layer for reload. For example, for TLS this would be: <tls:auth> normal/PSK/SRP</tls:auth> <tls:multiple-node-id-cerificates-allowed> true/false <tls:...> <tls:shared-secret-scheme>...</..> <tls:allowed-cipher-suites>...</...> Does it make sense? Regards, Polina _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
