Subject: Re: [P2PSIP] Certificates with multiple NodeIds

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 14 Jun 2013 09:38:11 -0700

Hi Polina,

Please find below my answers to some of your comments.  Note that I am not a
co-author of the spec, so that will be just my opinion.

On 04/22/2013 11:30 AM, Polina Goltsman wrote:
> 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.

I am not sure where in the spec you found this requirement.

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

I agree that there is a layer violation here.

But this applies only to bootstrap nodes, which anyway require special
processing on their public address, as they accept connections without Attach.
So the special code that parses the message in addition to the header can be
isolated to that special kind of nodes.

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

Not sure what you mean by next endpoint.  The Ping will be answered by this
peer, returning a SecureBlock containing the Certificate of this peer.

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

My understanding is that the Attach creates a new connection and that the first
one is closed.  But this is underspecified so this will create an
interoperability problem.

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

I think it is clearly stated in 1.3 that certificate must be used with TLS-PSK
in the context of RELOAD:

"This feature is used together with certificate-based
 access control, not as a replacement for it."

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

The identity field is used to select a specific key, when there is a choice
between different keys.  In the case of RELOAD I suppose that having multiple
keys does not make sense so that field (and so the ServerKeyEchange record)
should be omitted.

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

AFAIK, this is how things are suppose to work in RELOAD.  Note that the
increased load is only when joining the overlay, so that seems like normal
workload to me.

https://www.ietf.org/mail-archive/web/p2psip/current/msg05856.html

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

Yes, I proposed something like this back in 2011:

https://www.ietf.org/mail-archive/web/p2psip/current/msg05856.html

That was not the solution selected by the authors.

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

I would suggest to write an I-D about this.

Thanks.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Polina Goltsman <[email-masked]>
Date: Sat, 15 Jun 2013 21:35:21 +0200

Dear Marc,

Thank you very much for your comments.

On 14.06.2013 18:38, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi Polina,
>
A have found this requirement in section 6.3.2.2. at the bottom of page 
53 (-26)

 >One possible encoding of the 16 bit integer version as an opaque
 >identifier is to encode an index into a Connection Table.
and so on.

I am not very good at this, but as I understood one must have very good 
reasons not to
implement "SHOULD".
> isolated to that special kind of nodes.
 From -base: Section 3.2.1 Client Routing

    **Clients** may insert themselves in the overlay in two ways:

...

    (bullet 2)Establish a connection with an arbitrary peer in the overlay

...

    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.

Do I understand this wrong, or any client can connect to any peer it 
wants, so the issue
is not only with BP.

Moreover, did I miss a requirement that forbids me to for direct 
connection (without Attach) if
I know IP-Address of the Node I wish to connect to.
(This didn't make it to the -base, did it 
?https://www.ietf.org/mail-archive/web/p2psip/current/msg05853.html) 
<https://www.ietf.org/mail-archive/web/p2psip/current/msg05853.html%29**>
> peer, returning a SecureBlock containing the Certificate of this peer.
Exactly this. I mean endpoint as in the "endpoint of connection or link"
>   access control, not as a replacement for it."

The point is that IMHO it(together with 3.2.1) should be specified somewhere
after section 5.
> keys does not make sense so that field (and so the ServerKeyEchange record)
Thank you very much for the explanation. Do you think it should be 
specified, that this key
SHOULD be omitted?
> https://www.ietf.org/mail-archive/web/p2psip/current/msg05856.html
1) This would increase load on the Bootstrap Peer, which IMHO is not 
desirable.
2) From your message:
*
*>Because there is no Attach, the peer has to spy on the first message 
sent by the

    client to extract the Node-ID from the SignerIdentity and "label"
    the newly
    created connection in the connection table.

Well, it was not that obvious to me. Was there a reason why it didn't 
make it to the -base?

I believe it is relatively hard to spy on the messages, that are routed 
through, since
they can be fragmented. So IMHO the first message should be destined to 
the connection
endpoint.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQIcBAEBCAAGBQJRu0bxAAoJECnERZXWan7ECRcP/jw5CphA7aO4vizign7o7Kdp
> B9xNUuiDB1sV8Vxv/HftIRJmzbXecJLTOj8BuVwZnsTNeZqz7IGJCgRqkaH4Q2sF
> HIsHls2OI49T7iIYUu7FNcY1h9PsMO/gtOd2195K4NY16GqluOMisCtwlcopTsBY
> /fhNokoQ6SjSMtt02NjxZAxqFyrggZc9f02ig+TXEOHRKG1vxNA/7g6q/h3+mR7j
> RNCw2J1kJSZu9fqWIcLWWUSV8GJQevSVHzja88jCxFMd7FrmvkCJ1HJGC7i+/8Q6
> hxyNl/I4v8kBdN/Pn0wK2hBbSPPNIyYvLKGa76nwIeMmSkjmJbbfH4cWLQy2qDqf
> OsJIibUyMurOyLf8zWpcorj4z4Y3E/pdXVrzlQ78zCxZ8hxh2Nem9q/xcaAeE9yh
> HETN084rkEC0F/9Ro6T/TT2ZCXR8Xc+PYTPAk76dAS2wdQxwQ6wMXbLTIwtOH+Vf
> BcbvMXI1qIwJ/Y4l5u7zZ/ype4lcjwZXXr+1iu2k9h2uAOg/REfL7dKRuEmSdOb7
> yVEx6ZuxXDacgBn8uZVyrJvvUdgu8+/sMjAAcajXmW1lyA0ekIViTJPnRsWD7Ax4
> FLQbFzxAdJ6cPUF3EUQ52JosqMM9hAQBXOSfVzXLLAA+XpqVlpMxvktALl8F3zvW
> HwUMrudMecpks9f80p0q
> =pzTn
> -----END PGP SIGNATURE-----
Thanks.
  Polina

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 16 Jun 2013 08:29:01 -0700

Hi Polina,

On 06/15/2013 12:35 PM, Polina Goltsman wrote:
> On 14.06.2013 18:38, Marc Petit-Huguenin wrote: Hi Polina,
> 
> Please find below my answers to some of your comments.  Note that I am not
> a co-author of the spec, so that will be just my opinion.
> 
>>>> I have several questions regarding certificates with multiple
>>>> NodeIDs. It seems that different parts in the draft contradict each
>>>> other.
>>>> 
>>>> 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.

This is not a requirement for the management of the Connection Table, just a
compression algorithm to reference an entry in the Connection Table in the
destination_list.

>> reasons not to implement "SHOULD".

Yes, but because the entity decoding the 16 bit opaque_id is the same that
encode it, it does not matter.  There is no interoperability problem that can
be created by following or not the SHOULD.  IMO, as this cannot create any
interoperability issue, the whole paragraph should have been moved to an
appendix, as this is more an implementation note, than normative stuff.

>>>>> 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.
> processing on their public address, as they accept connections without
> Attach. So the special code that parses the message in addition to the
> header can be isolated to that special kind of nodes.
>> A **client** connected this way using a certificate with only a single
>> (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.
> 
> 
>> wants, so the issue is not only with BP.

My understanding of this is that an Attach is required to do that, so the
special processing really applied only to bootstrap nodes.  You can Attach to
any node and never send an Update, relying on a stored Destination_list to be
reached and the via_list to receive responses, but the initial still have to
go through a bootstrap node.

>> connection (without Attach) if I know IP-Address of the Node I wish to
>> connect to. (This didn't make it to the -base, did it 

My
understanding is that you cannot directly connect to a random node.  You
always have to do through a bootstrap node.

Note that this understanding seems to contradict 11.4.  IMO the whole 11.4
should have been removed, as there is no way to be sure 100% that an IP
address can be directly reached.  Caching peers to serve as future bootstrap
nodes would require to use a TURN server to contact them.  And as you said, it
increase the load on all node as they all can be bootstrap candidates.

>>>>> 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.
> Not sure what you mean by next endpoint.  The Ping will be answered by
> this peer, returning a SecureBlock containing the Certificate of this
> peer.
>>>> 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.
> My understanding is that the Attach creates a new connection and that the
> first one is closed.  But this is underspecified so this will create an 
>>>> (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.
> I think it is clearly stated in 1.3 that certificate must be used with
> TLS-PSK in the context of RELOAD:
> 
> "This feature is used together with certificate-based access control, not
> as a replacement for it."
> 
>> The point is that IMHO it(together with 3.2.1) should be specified
>> somewhere after section 5.

Yes, the whole shared-secret/TLS-PSK/TLS-SRP/self-signed-certificate is
underspecified.  A good candidate for an Internet-Draft.

>>>> username, NodeID, both or nothing. As of TLS-SRP RFC the client
>>>> certificate cannot be requested.
> The identity field is used to select a specific key, when there is a
> choice between different keys.  In the case of RELOAD I suppose that having
> multiple keys does not make sense so that field (and so the
> ServerKeyEchange record) should be omitted.
>> specified, that this key SHOULD be omitted?
>>>> 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.
>> desirable. 2) From your message: * *>Because there is no Attach, the peer
>> has to spy on the first message sent by the
> 
>> client to extract the Node-ID from the SignerIdentity and "label" the
>> newly created connection in the connection table.
> 
> 

None that I can think of.  Again a good candidate for an Internet-Draft.

>> through, since they can be fragmented. So IMHO the first message should
>> be destined to the connection endpoint.
>>>> 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.
>>>> <http://tools.ietf.org/html/rfc4680>] to exchange the actual NodeID.
>>>> For example: struct { SupplementalDataType supp_data_type; uint16 
>>>> 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>...</..> 

- -- 
Marc Petit-Huguenin