[Nfd-dev] review request: tunnel authentication protocol

[Marc.Mosko at parc.com]

Just to clarify, I didn’t mean that you should use DTLS (though I wouldn’t argue against that), but only that the DTLS RFC spells out many of the things one needs to do about replay attacks, IP fragmentation issues, and so forth, in establishing a cryptographic association, even if there is no encryption of the channel.  I agree with Mark S that if you do not include a MAC in each packet, there’s no on-going assurance.  And using a MAC means you negotiate session keys and then signing keys, so you might as well do DTLS.  DOCSIS does a similar thing too.

You could also look at the history of GRE tunnels (https://tools.ietf.org/html/rfc2784 and then https://tools.ietf.org/html/rfc2890). RFC 2890 says that one must use IPSec with the tunnel (either ESP or simple AH), especially if using the sequence number to re-order tunnel packets due to DoS issues with the re-order buffer.  Note that the Key field in GRE is really a flow label, not a security mechanism.

In DTLS, there is on-going authentication and the connection is identified by a session ID that only the holder of the parties certificate keys can use.

In your proposal, I think it suffers from a man in the middle attack: Alice - Eve - Bob.  Alice sends a signed interest, Eve intercepts it and now sends the packet to Bob with her socket endpoint.  Bob accepts the packet as from alice and opens a tunnel with Eve.  There’s nothing in the signed envelope that restricts the tunnel to Alice nor anything encrypted that requires Eve to have Alice’s of Bob’s key.  For example, if Alice included her socket endpoint in the signed information that would preclude this specific attack, but that’s not a proof that it’s sufficient for secure association.  If there’s no MAC, Eve could still inject packets as a MITM.  Generally one needs a handshake where each party proves they actually have the keys purported through a multi-round protocol (which could have a quick-resume).

I’m not a cryptographer, and this is the type of thing you want a cryptographer working on.  Or use a protocol that’s been vetted.

Marc


On Jan 28, 2015, at 6:32 AM, Mark Stapp <mjs at cisco.com> wrote:

> hmm - having looked at the ppt, there are still a lot of questions - it's not clear that there's enough info in the slides to understand what is actually proposed.
> 
> what do you mean by the word "tunnel"? is there some encap being discussed somewhere that will be used? or do you mean "tcp connection"? or do you mean "udp packets from some specific source IP+port tuple"?
> 
> is there any MAC/MIC proposed? if so, how does it work?
> 
> if there's no MAC, nothing's stopping packet injection, right? if there's no MAC, what prevents DOS-ing the tunnel by just sending a bad "request" message?
> 
> what about fragments - who fragments what, and how is the threat of fragment injection handled?
> 
> what about replay attacks?
> 
> I take it there's some magic happening somewhere that allows every router to know the acceptable public key for every valid "client" ?
> 
> above all, as Marc M asked, if you're using IP, why not just use a TLS or dTLS tunnel with mutual auth? that would even add privacy, which would not be a bad thing at all for NDN to consider.
> 
> Thanks,
> Mark
> 
> On 1/27/15 5:26 PM, Junxiao Shi wrote:
>> Dear folks
>> 
>> I have written the high-level ideas about NFD tunnel authentication
>> protocol, and I need someone to review the design.
>> 
>> http://redmine.named-data.net/attachments/download/174/tunnel-auth_20141118.pptx
>> 
>> If you do not yet know what tunnel authentication protocol is, please
>> see: http://redmine.named-data.net/issues/1285#note-1
>> 
>> If you are willing to have a look at the design, I'll appreciate that.
>> You don't have to be an expert in order to do a design review.
>> 
>> Yours, Junxiao
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev