Subject: [icnrg] CCNx key exchange protocol

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 5 Nov 2015 03:50:30 +0000

Listening to the presentation today I was wondering whether there is a possibility to re-use existing IETF work more in this area.
It seems that you more or less are re-building TLS. That's likely a bad idea for a number of reasons.

Why cannot you just re-use it as is? What are the additions you need?

Ciao
Hannes

PS: In other documents I read that object security is only useful security solution for ICN since the focus is on content rather than on securing communication channels. Is there a different view now?

________________________________

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: <[email-masked]>
Date: Thu, 5 Nov 2015 04:10:45 +0000

Hannes,

The CCNx-KE protocol is derived from TLS and QUIC. As I mentioned during the talk, it’s more or less a mapping of these existing protocols to the ICN communication model—Interests and Content Objects—with only a few additions and changes introduced where needed.

For example, QUIC supports what’s called a “source-address token,” which (cryptographically) binds packets from an IP address to a given session. This is done to prevent IP address spoofing—a common DDoS attack vector. In CCN and ICNs in general, Interests do not carry a source address. Consequently, CCNx-KE proposes extensions to the typical QUIC/TLS handshake that enable the producer to verify that the consumer which initiates a session is the same one that previously attempted to retrieve a server configuration structure.

Another extension is the ability to migrate session information from one an endpoint to another via a MoveToken and new name prefix. This could be useful to enable a service provider to perform client (consumer) authentication and authorization, and then leave the actual production and encryption of data to another endpoint.

We are not trying to re-invent the wheel. I believe we are doing quite the opposite by following the best practices set in place by the TLS and QUIC community.

I hope this clears up your concerns.

--
Christopher Wood

On November 4, 2015 at 7:50:42 PM, Hannes Tschofenig ([email-masked]<mailto:[email-masked]>) wrote:
Listening to the presentation today I was wondering whether there is a possibility to re-use existing IETF work more in this area.
It seems that you more or less are re-building TLS. That’s likely a bad idea for a number of reasons.

Ciao
Hannes

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
icnrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/icnrg

---

From: David Oran <[email-masked]>
Date: Thu, 5 Nov 2015 13:10:53 +0900

> On Nov 5, 2015, at 12:50 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
Well, DTLS might be more applicable than TLS, since we don’t either depend on TCP semantics nor benefit from them. Second, ICN exchange semantics are different from UDP in a number of ways, including being able to name keys directly rather than binding keys to address/port pairs.

From a crypto standpoint and a key derivation standpoint, there certainly is little reason to reinvent the wheel.

---

From: <[email-masked]>
Date: Thu, 5 Nov 2015 04:13:29 +0000

Hannes,

Our goal was to use the mechanisms from DTLS and QUIC but frame them in a named exchange.

We did use building blocks from (D)TLS and QUIC.  One of the main differences is the lack of a source IP address, so one cannot use the same techniques as TCP SYN-SYNACK or QUIC's address proof to tie messages together (DTLS does something with nonces I think, don't remember).  I think that's the major difference, is the use of names and a mechanism to prove that you are talking with the same parties through the 3 rounds.

Another difference is that in CCN/NDN, the first interest may go to any instance of a name and the 2nd Interest for the same name is not guaranteed to go there (and in some routing stratgies might be unlikely to go there), so there needs to be a mechanism to pin the conversation to the same instance.  This is the job of "prefix2" in the exchanges.  Finally, to handle distributed producers, we want a way to delegate the actual content production to a third prefix (the MoveToken) without having to send secret keys over the channel.

Marc

________________________________
From: icnrg [[email-masked]] on behalf of Hannes Tschofenig [[email-masked]]
Sent: Thursday, November 05, 2015 12:50 PM
To: [email-masked]
Subject: [icnrg] CCNx key exchange protocol

Ciao
Hannes

---

From: <[email-masked]>
Date: Thu, 5 Nov 2015 04:13:51 +0000

That’s correct. This is why we opted for QUIC. DTLS is a close relative.

I completely agree. We do not introduce new key derivation or cryptographic techniques.

Best,

Chris

---

From: David Oran <[email-masked]>
Date: Thu, 5 Nov 2015 13:14:05 +0900

And now responding separatelt to your PS…

> PS: In other documents I read that object security is only useful security solution for ICN since the focus is on content rather than on securing communication channels. Is there a different view n…
Actually the challenge is to use object security to get the same integrity, confidentiality and privacy properties you get with channel security. It’s not coincidently that if you want the same properties the solution is going to have a lot of similarities to “sessions”. The difference is whether there is state below the application layer and whether the binding of the keys that establish the spatial and temporal scope of the “session” are to addresses or names.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 5 Nov 2015 04:34:04 +0000

> Well, DTLS might be more applicable than TLS, since we don't either depend on TCP semantics nor benefit from them.

DTLS is good for me.

> Second, ICN exchange semantics are different from UDP in a number of ways, including being able to name keys directly rather than binding keys to address/port pairs.

There are different keys flying around in TLS/DTLS and most of them are not bound to IP addresses (or ports). The only keys that are bound to IP addresses and the ports are the symmetric keys established for the record layer. That's might be something you need to change (which is possible) and has been done with DTLS-SRTP, for example.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 5 Nov 2015 04:34:06 +0000

Ø  That’s correct. This is why we opted for QUIC. DTLS is a close relative.

The right choice would be to use TLS 1.3 (which is supposed to also support UDP) and was influenced by QUIC.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 5 Nov 2015 04:34:33 +0000

> PS: In other documents I read that object security is only useful security solution for ICN since the focus is on content rather than on securing communication channels. Is there a different view n…
Actually the challenge is to use object security to get the same integrity, confidentiality and privacy properties you get with channel security. It's not coincidently that if you want the same properties the solution is going to have a lot of similarities to "sessions". The difference is whether there is state below the application layer and whether the binding of the keys that establish the spatial and temporal scope of the "session" are to addresses or names.

This is interesting. I initially thought that the argument for application layer security was that you could sign and encrypt data by the source and then cache it somewhere. Now, it seems that this design is a bit different since you are OK with having multiple roundtrip message exchanges and the establishment of a security context. From a design point of view this obviously begs the question whether you want an in-band vs. an out-of-band key exchange and at what layer you then want to provide the content protection. It seems the content protection is supposed to happen at the application layer and the key exchange happens out-of-band. This is very similar to the design of DTLS-SRTP but in your case you would just not establish SRTP security associations but rather something else, some application layer security container (like a JWT or a COSE protected payload).

Ciao
Hannes

---

From: [email-masked]
Date: Wed, 4 Nov 2015 20:37:09 -0800

On November 4, 2015 at 8:34:28 PM, Hannes Tschofenig ([email-masked]) wrote:
Ø  That’s correct. This is why we opted for QUIC. DTLS is a close relative.

Right, yes, I didn’t meant to say that it’s only based on QUIC. I mentioned that we use TLS and QUIC earlier. We use elements of QUIC since it’s based on UDP, and TLS (1.3) since it’s the latest and greatest. 

Best,

Chris

---

From: <[email-masked]>
Date: Thu, 5 Nov 2015 04:39:40 +0000

DTLS is good for me.

:-)

Interesting. I’ll take a look at that draft. Thanks for the pointer!

Best,
Chris

---

From: <[email-masked]>
Date: Thu, 5 Nov 2015 04:44:22 +0000

There are some cases where broadcast encryption for cache distribution or public key object encryption for off-line encryption is the right choice.  There are other cases where one wants ephemeral transmission of data with forward security.  The current proposal addresses the second case, and does not mean to preclude other forms of key exchange or encryption for the long-term caching cases.

One of our goals with this work, and then some follow on work on actual encrypted envelope specification, is to get ICN to TLS-equivalent privacy to dispatch concerns that everything is in the clear or ICN is out of touch with privacy.  The TLS-equivalent privacy seemed an easier goal than the broadcast or identity or other forms of encryption people talk about.

I will need to look at TLS-SRTP to see if that could be adopted.  

Thank you,
Marc
________________________________________
From: icnrg [[email-masked]] on behalf of Hannes Tschofenig [[email-masked]]
Sent: Thursday, November 05, 2015 1:34 PM
To: David Oran
Cc: [email-masked]
Subject: Re: [icnrg] CCNx key exchange protocol

Ciao
Hannes

---

From: <[email-masked]>
Date: Thu, 5 Nov 2015 05:25:03 +0000

As some more followup, (D)TLS also specifies the security envelope (record format) used after the transport header.  There's some question about if ICN would do the same thing.  For example, we might want to selectively encrypt parts of the ICN TLV structure with different keys, such as one for infrastructure and one for end-to-end., or perhaps even with more keys.

So, while adopting the cryptographic mechanisms of (D)TLS makes sense, I am not sure that the use of the keys in the encryption envelope would be the same.  For example, some people talk about using the regular NDN/CCN TLV format but encrypting part the name suffix or just the application payload but MACing the whole packet.

We would need to see if these really are requirements and if they can be used in the TLS record format or not.  I also recognize that it's hard to evaluate this as we have not submitted our encryption envelope proposal yet, which covers some of the same ground as the TLS record format.

I think in the most basic ICN encrypted format, where there's an outer forwarding name and everthing else is in an encrypted TLV record, the TLS record format could be used inside there.  But that still leaves the question about how one MACs the outer name because TLS will only MAC stuff inside its record format.  It would be like wanting to authenticate the outer IP addresses and transport ports with the TLS MAC, I think.  Maybe we just wouldn't do that.  guess I'm just thinking out loud here.

Marc
________________________________________
From: icnrg [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Thursday, November 05, 2015 1:44 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [icnrg] CCNx key exchange protocol

Thank you,
Marc

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 5 Nov 2015 05:29:33 +0000

Hi Marc,

I agree that the record layer is something you might want to look into.
Here are two documents that we describe what was done for SRTP and why the record layer of DTLS was not used
http://tools.ietf.org/html/rfc5763
https://tools.ietf.org/html/rfc5764
Maybe there are some useful thoughts in there.

Ciao
Hannes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 05 November 2015 14:25
To: Hannes Tschofenig; [email-masked]
Cc: [email-masked]
Subject: RE: [icnrg] CCNx key exchange protocol

Marc

Thank you,
Marc

Ciao
Hannes