Subject: Re: [P2PSIP] D/TLS with client authentication

From: Michael Chen <[email-masked]>
Date: Thu, 01 Oct 2009 13:44:10 -0700

Eric Rescorla wrote:
>
>
> On Sep 30, 2009, at 8:10 PM, Michael Chen <[email-masked]> 
> wrote:
>
>> Hi,
>>
>> In an earlier thread, David A. Bryan asked about implementation 
>> experience of this draft. Two things pop out immediately from my head 
>> (they both feel like reinventing the wheel):
>>
>> 1. Digital signature related requirements seem rehashing what's being 
>> done in TLS and DTLS.
>> 2. Fragmentation handling seems to be reinventing TCP using UDP.
>>
>> The second one may be unfounded, but I like to toss around an idea 
>> while implementing the first. What if this draft mandates the 
>> following regarding TLS and DTLS connections:
>>
>> A. Client authentication is required for all TLS and DTLS connections;
>> B. Both parties (peers) in a D/TLS connection uses the same digital 
>> credentials (certificates and public/private keys) for the DHT overlay.
>>
>> For example, say peer X connects to peer Y via TLS. X will get Y's 
>> overlay certificates and public key during the first part of the TLS 
>> handshake. Then Y request X (the 'client') to send its certificates 
>> and public key during client authentication.  The TLS session will be 
>> honored if and only if the overlay information in the certificates 
>> are validated on both sides.  This is fully supported by TLS and DTLS 
>> (plus a few callbacks).
>
> This is already true
I don't see this being explained in the draft. Are you saying it based 
on implementation?
>
>
>> The level of trust established this way is equivalent to that 
>> provided by the current draft-03. The intend is that with these 
>> mandates, the RELOAD protocol itself can be simplified by removing 
>> all certificate and signature related requirements.  For example, in 
>> my earlier post, an overhead of 1292 bytes can be trimmed down to 
>> only 69 bytes!!! (removing the security block and the STORE signature).
>
>> I still need to think about messages forwarded by instead of 
>> originated from a peer, but let the discussion begin.
>
> Uh this is the base case. Which is why the messages have signatures
>
> Ekr
Let's give it some more thought. With client authentication, any two 
directly connected peers "trust" each other based on their overlay 
credentials.  Therefore, single hop messages like DHT stablization can 
be exchanged between them with no signature/certificates attached.  
That's a great saving to consider.

If a message is forwarded, say X->Y->Z, Y can doing man in the middle 
attack. For Z to truly ensure that the message is from X, Z must FETCH 
X's certificate from the overlay to verify the signature. For that 
reason, sending the certificate has no real security meaning.

--Michael

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 1 Oct 2009 13:51:20 -0700

On Thu, Oct 1, 2009 at 1:44 PM, Michael Chen <[email-masked]> wrote:
> Eric Rescorla wrote:
>> This is already true
>
> I don't see this being explained in the draft. Are you saying it based on
> implementation?

5.5.1.13.

   The procedures of Section 11 apply to RELOAD as well.  However, in
   this case, the "media" takes the form of application layer protocols
   (RELOAD or SIP for example) over TLS or DTLS.  Consequently, once ICE
   processing completes, the agent will begin TLS or DTLS procedures to
   establish a secure connection.  The node which sent the Attach
   request MUST be the TLS server.  The other node MUST be the TLS
   client.  The nodes MUST verify that the certificate presented in the
   handshake matches the identity of the other peer as found in the
   Attach message.  Once the TLS or DTLS signaling is complete, the
   application protocol is free to use the connection.

12.6.2.

  Admission to an RELOAD Overlay Instance is controlled by requiring
  that each peer have a certificate containing its peer ID.  The
  requirement to have a certificate is enforced by using certificate-
  based mutual authentication on each connection.

>>> The level of trust established this way is equivalent to that provided by
>>> the current draft-03. The intend is that with these mandates, the RELOAD
>>> protocol itself can be simplified by removing all certificate and signature
>>> related requirements.  For example, in my earlier post, an overhead of 1292
>>> bytes can be trimmed down to only 69 bytes!!! (removing the security block
>>> and the STORE signature).
>>
>>> I still need to think about messages forwarded by instead of originated
>>> from a peer, but let the discussion begin.
>>
> credentials.  Therefore, single hop messages like DHT stablization can be
> exchanged between them with no signature/certificates attached.  That's a
> great saving to consider.

Yes, this is a potential optimization. But unless something is seriously
wrong with the design (or the overlay is essentially quiescent), then
this sort of stabilization traffic should be a small amount of the overall
traffic, so it's not clear what the overall savings is.

> attack. For Z to truly ensure that the message is from X, Z must FETCH X's
> certificate from the overlay to verify the signature. For that reason,
> sending the certificate has no real security meaning.

No, this is not correct. Certificates are independently verifiable by chaining
back to the overlay's root key. That's pretty much the point of certificates:
you can verify them no matter how you received them.

Now, it's true that there is no SECURITY value in sending the certificate
along with the message. Data origin authentication authentication is supplied
by a digital signature computed using the private key that corresponds to
the public key in the certificate. The certificate is attached to the message
to avoid the complexity of a system where you have to hold the message
while you try to retrieve the certificate.

-Ekr

---

From: Jouni Mäenpää <[email-masked]>
Date: Fri, 02 Oct 2009 08:49:47 +0300

Hi,

> traffic, so it's not clear what the overall savings is.

Just one comment. I agree that if the overlay is experiencing very
little or no churn at all, the amount of stabilization traffic is rather
low. However, based on my experiences of running a P2P overlay in
PlanetLab, I would say that if the overlay is churning even at a
moderate rate, optimizations like this might well be worth doing. When
there is churn, you need to increase the amount of stabilization
messages and it is not unusual that a considerable percentage of the
total traffic is stabilization traffic.

-Jouni

---

From: Michael Chen <[email-masked]>
Date: Fri, 02 Oct 2009 07:20:50 -0700

Eric,

>    application protocol is free to use the connection.
This is vague. It should be explicitly stated using SSL terminology 
"client authentication". SSL started as a client-server protocol, and in 
its most common use HTTPS, clients are almost always anonymous. This 
draft should be explicit about the client authentication mandate.

>   based mutual authentication on each connection.
Here should again explicitly echo that mutual authentication refers to 
TLS/DTLS server and client authentication during handshake.

> traffic, so it's not clear what the overall savings is.
This optimization requires hardly any effort either in your part to 
write or in mine to implement. A short paragraph in the draft saying, 
"If the message is originated from a directly connected peer, the 
security block may contain a zero length certificates list, zero length 
signer ID and zero length signature."

> you can verify them no matter how you received them.
In the attack by Y described above, Y would sign and put its own 
certificate chain in the security block, so the whole message is 
verifiably correct. The only way Z can know this is an attack is by 
enforcing other constrain of this draft.  For example, if the STORE 
resource ID is between Y and Z, then this is an attack.

Aha! What if the resource ID in X's request is between X and Y or before 
X in the ring? Then Z will never notice the attack.  Y can map calls to 
X@domain to Y's destination list.  Am I right?

> -Ek
A security warning should be included in this draft about the potential 
danger of trusting the certificate in the SecurityBlock. It's the proper 
thing to do.

One more thing about SecurityBlock.certificates, in an overlay that 
requires an enrollment server, what is the use case in which the peer's 
certificate is not issued/signed by the enrollment server?  In another 
word, what is the use case where SecurityBlock.certificates contains 
more than one (the peer's) certificate?

By the way, there is no need to include the certificate chain that 
issued the enrollment server's certificate, because that chain would 
have been verified during enrollment by each peer.

Thanks

--Michael

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 02 Oct 2009 07:46:13 -0700

At Fri, 02 Oct 2009 07:20:50 -0700,
> draft should be explicit about the client authentication mandate.

I'll take a look at doing this, but as usual, it would help if you send
text.

> signer ID and zero length signature."

I'm not convinced this is that simple: it requires carrying this
origin information from the connection level around to the signature
processing level, as well as new logic for the sender to know when
this is safe or not. That's new logic and new code paths, which means
new things to get wrong--bad in security systems. I'd like to see
some data suggesting this is an important optimization.

> resource ID is between Y and Z, then this is an attack.

Huh?

How is it in attack for Y to take a message originated by X and 
claim it was originated by itself? Y can always generate any message
it wants and sign it. That's how signature-based message authentication
works. Moreover, why would this be an attack on X or Z, since Y
is *legitimately* allowed to generate messages and Z would
(correctly) conclude that the message came from Y, not X. The
fact that Y is copying X's message is irrelevant.

> X@domain to Y's destination list.  Am I right?

I have no idea what you are talking about.

> danger of trusting the certificate in the SecurityBlock. It's the proper 

I don't understand what you're talking about here either.

The cryptographic elements of an authenticated message in RELOAD
are:

- The contents
- A signature, generated using the sender's private key
- The sender's identity
- A certificate binding the sender's public key to the sender's
  identity.

In order to validate this, the verifier needs to:

- Verify the signature on the certificate (using the CA's public
  key, which is known a priori)
- Verify that the sender's identity matches the identity in the
  certificate
- Verify that the signature on the contents is correct
  (using the sender's public key, which is found in the
  certificate). 

This can be (needs to be) done regardless of the provenance of the
certificate because the certificate is directly verifiable. The
system does not depend on the certificate being provided by 
a trusted source. 

The only time when you do not need to verify the certificate is
if you have previously verified it and cached the result. You
never trust that the certificate is correct otherwise.

> more than one (the peer's) certificate?

When there are elements which need to be verified with different
certificates. For instance, if node A stores a value with node
B, which then does a replica store to node C, then the B->C 
store will have two signatures:

- The signature over the value, using A's key
- The signature over the message, using B's key

The SecurityBlock will then contain both A and B's certificates.

-Ekr

---

From: Michael Chen <[email-masked]>
Date: Fri, 02 Oct 2009 12:16:54 -0700

> I have no idea what you are talking about.
Let me try again. Say X just joint the overlay, and its logical position 
in the ring is X->Y->Z. The overlay has no record of how to contact X. X 
hash his AoR "X@domain" to its resource ID Rx. Just so happen that the 
logical position of Rx is Y->Rx->Z. X sends a STORE message via Y to Z 
that maps Rx to Dx, where Dx is X's destination list.

When Y receives this STORE message from X, it replaces Dx with Dy, where 
Dy is Y's destination list. Then Y sign the message with Y's own cert 
before forwarding it to Z. The message seems legitimate to Z, so it 
stores the mapping of Rx to Dy.  When A wants to call "X@domain" and 
FETCH Rx from Z, A gets Dy. A's call to X goes to Y.

X can find out about Y's attack when X FETCH Rx from Z.  Y does not have 
an effective attack on the FETCH message, because Y's node-ID is in 
front of Rx (Y->Rx->Z) and cannot be the owner of Rx.

Thanks

--Michael

---

From: Michael Chen <[email-masked]>
Date: Fri, 02 Oct 2009 13:02:23 -0700

Eric,

In my list post, Z can discover Y's attack if the AoR itself "X@domain" 
is included in the STORE such that  hash("X@domain") = Rx.  Since the 
message is resigned by Y, so Z can conclude that it's illegal for Y to 
STORE an AoR of "X@domain".  Y can only STORE an AoR of "Y@domain" 
(unless of course a replica).

If I am not mistaken, the current STORE does not send the AoR, only the 
resource ID Rx. Then Z cannot verify how Rx was calculated and cannot 
discover that Y is storing "X@domain".

--Michael

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 02 Oct 2009 13:55:47 -0700

At Fri, 02 Oct 2009 13:02:23 -0700,
Michael Chen wrote:
> 
> [1  <text/plain; ISO-8859-1 (7bit)>]
> Eric,
> 

This is not correct.

To recap: 
When a node receives a store to location Rx, that store is signed
with the private key corresponding to the public key in some
certificate C. The node then checks that whatever identity is in
C is allowed to store at location Rx. The precise checks depend on
the kind. 

For the particular case of AORs (more properly SIP-REGISTRATION)
the Access Control Model is USER-NODE-MATCH. (S 7 of draft-ietf-p2psip-sip).
This means:

   The USER-NODE-MATCH policy may only be used with dictionary types.
   In the USER-NODE-MATCH policy, a given value MUST be written (or
   overwritten) if and only if the request is signed with a key
   associated with a certificate whose user name hashes (using the hash
   function for the overlay) to the Resource-ID for the resource.  In
   addition, the dictionary key MUST be equal to the Node-ID in the
   certificate.

[draft-ietf-p2psip-base; S 6.3.3]

Thus, X does not need to supply the AOR, because the check is to take the
user name in the certificate and see of it hashes to Rx. This check
precludes Y storing at Rx.

-Ekr

---

From: Michael Chen <[email-masked]>
Date: Fri, 02 Oct 2009 14:09:08 -0700

Eric,

Thanks for the clarification.

--Michael