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,
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.
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".
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.
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**>
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.
Exactly this. I mean endpoint as in the "endpoint of connection or link"
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."
The point is that IMHO it(together with 3.2.1) should be specified somewhere
after section 5.
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.
Thank you very much for the explanation. Do you think it should be
specified, that this key
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
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.
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 protected]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----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
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
