Subject: [P2PSIP] Certificates with multiple NodeIds

From: Polina Goltsman <[email-masked]>
Date: Mon, 22 Apr 2013 20:30:39 +0200

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