Re: [Atlas] Status Update

[Abhijan Bhattacharyya <[e-mail]>]

Hi Ben,
Thanks for your valuable comment. It helps further analysis.

There is a little difference in the intended purpose of this draft than 
N-S scheme (and subsequently Kerberos). In this draft we considered a 
situation where there is no 3rd entity in the form of Trusted Agent (TA). 
We assumed that the client is constrained with limited processing power 
and memory. The server is relatively powerful (at least enough to generate 
session-key pairs for multiple clients). Here we tried to stick to the 
philosophy of DTLS handshake (of course TLS 1.3 was not place when we 
proposed it) and tried to establish a secure session (both mutual 
authentication as well as key-pair distribution for channel security) 
mechanism which 
1) would be more lightweigh in terms of communication cost,  2) would have 
higher success rate of session-establishment in case of lossy channel and 
3) would not be less vulnerable than DTLS.  All the encrypted exchanges 
are done through standard AES-128-CCM-8.

So in this case the intention was to distribute the key-pair tuple from 
the server itself without burdening the constrained client. The IV 
generation is localized as in DTLS channel encryption. So, unlike 
Kerberos, the server (which is Bob to follow the standard crypto 
nomenclature) itself is the key generator and distributor. The session is 
not dependent on a single key but on a 2-tuple (server-write, 
client-write) to match the channel encryption parameter set required for 
re-using the underlying channel security of DTLS. So in this case there no 
distribution of tickets. The authentication is done by challenge / 
response through the server-rand and client-rand. So, from Fig. 2 of the 
draft, Server is able to authenticate the client in the 3rd flight and the 
client counter authenticates the server. Probably this way chosen-cipher 
text and known-session-key attacks can be prevented to ensure that an 
intruder is not able to fool the client.   Reuse of the channel encryption 
mechanism of DTLS ensures protection from replay-attack.

Note: The  AES_128_CCM_8. CCM algo needs 12 bit nonce for each encryption 
and an additional data.'hello_rand', 'server_rand' and 'client_rand' 
serves as the required nonce values in steps 2, 3 and 4 respectively. The 
'additional data' can be the header for each message of  CoAP.

Regarding the issue of freshness: Since there is no third-party ticket 
involved, so freshness of the ticket is not considered. But the draft 
speaks about session time out and resumption mechanism. Though the details 
are left TBD.

However, so-far as the freshness of the individual handshakes during key 
determination and exchange is concerned, just wondering whether a clever 
use of the MAX_AGE option can provide a frugal solution since we are 
anyway using the RESTful semantics of CoAP.

There are many things to improve in the draft and surely a detail 
attack-model based analysis from an expert would be helpful. 
Further things can be worked on provided there are forward moving 
activities in IETF regarding the concerned problem space.

Thank you.
 
With Best Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, TCS Research
Tata Consultancy Services
Building 1B,Ecospace
Plot -  IIF/12 ,New Town, Rajarhat,
Kolkata - 700160,West Bengal
India
Ph:- 033 66884691
Cell:- [phone]
Mailto: [e-mail]
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________




From:   Benjamin Kaduk <[e-mail]>
To:     Abhijan Bhattacharyya <[e-mail]>
Cc:     DAN GARCIA CARRILLO <[e-mail]>, [e-mail], SARA 
NIEVES MATHEU GARCIA <[e-mail]>, RAFAEL MARIN <[e-mail]>
Date:   06/26/2018 09:16 AM
Subject:        Re: [Atlas] Status Update



On Sat, Jun 23, 2018 at 01:19:16AM +0530, Abhijan Bhattacharyya wrote:
> +1 Dan.
> The draft 
https://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-01 also 
proposes how the session initiation part of DTLS can be switched to CoAP 
to optimise the resource usage during session establishment by leveraging 
the lightweight semantics of CoAP. Also, to accomplish the stated 
objective of establishing end-to-end security association in a secure 
manner and managed at the application itself. The draft also tries to be 
less disruptive to existing DTLS implementations by defining an adaptation 
layer that ensures channel security by allowing the reuse of the existing 
DTLS record-layer encryption through the session key tuple from the CoAP 
layer. Of course there can be several other ways to accomplish this than 
what has been described in the draft.

There seems to be some "novel crypto" in here; it would be good to build 
on
standard blocks like Needham-Schroeder (e.g., as realized in Kerberos), to
make sure all the needed key confirmation and freshness properties are
realized.  The best freshness properties tend to occur when one endpoint
proposes a subsession key that must be confirmed by the other, which then
produces its own sub-subsession key that is likewise confirmed by the
original party.  It's best if there is contributory behavior for the keys
as opposed to just encrypting sub-keys in the previous key, though that
does tend to involve more hashing which induces cost.

-Ben

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you