Subject: [saag] Fwd: Request for Comments: NIST SP 800-57 Part 1 (Rev 4): Recommendation for Key Management: Part 1: General

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Sep 2015 15:50:27 +0100

FYI

-------- Forwarded Message --------
Subject: Request for Comments:  NIST SP 800-57 Part 1 (Rev 4):
Recommendation for Key Management: Part 1: General
Date: Mon, 14 Sep 2015 13:57:11 +0000
From: Caswell, Sara J. <[email-masked]>
To: [email-masked] <[email-masked]>

NIST requests comments on a revision of Special Publication (SP) 800-57,
Part 1, Recommendation for Key Management, Part 1 (Rev. 4). This
Recommendation provides general guidance and best practices for the
management of cryptographic keying material. A list of changes is
provided in Appendix D of the document.

Please send comments to
[email-masked]<mailto:[email-masked]?subject=Comments%20on%20SP%20800-57,%20Part%201>
by October 31, 2015.

Details and a link to Draft SP 800-57 Part 1 Revision 4 can be found on
the NIST CSRC Draft publications page at:
http://csrc.nist.gov/publications/PubsDrafts.html#800-57pt1r4<http://links.govdelivery.com/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkPTIwMTUwOTEwLjQ4OTY5MDExJm1lc3NhZ2VpZD1NREItUFJELUJVTC0yMDE1MDkxMC40ODk2OTAxMSZkYXRhYmFzZWlkPTEwMDEmc2VyaWFsPTE3MTg2MjE4JmVtYWlsaWQ9c2FyYS5jYXN3ZWxsQG5pc3QuZ292JnVzZXJpZD1zYXJhLmNhc3dlbGxAbmlzdC5nb3YmZmw9JmV4dHJhPU11bHRpdmFyaWF0ZUlkPSYmJg==&&&100&&&http://csrc.nist.gov/publications/PubsDrafts.html#800-57pt1r4>

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Fri, 18 Sep 2015 15:16:48 +0530

Dear Saag ML,
May I please seek your attention to the following experimental draft:
https://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-00. 
The draft is due to expire in October, 2015.
The draft was originally submitted in Dice. However it seems, dice is not 
chartered to discuss this kind of draft. So, would highly appreciate if 
experts in the Saag ML spare some time to judge the proposed approach on 
the basis of its merit and share there views.

Specifically, this draft tries to channel-secure the communication between 
Constrained Application layer Protocol (CoAP) end-points. The key driving 
factor behind this draft was that we had a feeling that the session 
establishment in DTLS, even with pre-shared-key, might be bit too heavy 
for very much bandwidth constrained environments. However, ones the 
channel is established DTLS-PSK provides a very robust yet 
resource-efficient mechanism to keep the channel secure.

So, the basic idea is:
Leverage the lightweight yet reliable nature of CoAP and push the 
responsibility for session establishment to the application layer. That 
way the application layer has more control on the exchanges, which is 
desirable for constrained networks.

Once the session is established transfer the control to the transport 
layer which for channel security. This will completely re-use the 
channel-security provided by DTLS-PSK (thus getting all sorts of 
reliability and protection from replay attack, etc. ). An interface layer 
would map the <Server_write_key, Client_write_key, Server_IV, Client_IV> 
tuple  available from the session establishment process at the application 
layer to the DTLS session parameters.

Since CoAP already mandated DTLS for secure exchanges, the intention was 
to create a solution which will not be disruptive, rather will be able to 
co-exist with legacy DTLS implementation. The implementers will be able to 
mostly reuse modules from a standard DTLS implementation and can quickly 
build a system. Only the session establishment part of the DTLS protocol 
needs to be switched.

There can be many engineering issues to be solved. However, before 
proceeding we need to validate the basic approach and the usefulness of 
the proposal from experts. Any review comment is highly appreciated. The 
draft contains the experimental results in the form of tables. A snapshot 
of the graphs of the results from the original paper is also attached.

The R&D behind this draft was published as a paper in  "Workshop on 
Pervasive Internet of Things and Smart Cities (PITSaC-2015)" in 
conjunction with "Advanced Information Networking and Applications 
(AINA-2015)", Gwangju, Korea, March, 2015 . 
The original paper can be found here:  
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7096256
Some figures from the paper has been attached with this mail as ready 
references.

Awaiting your responses please.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: [email-masked]
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________

From:   Stephen Farrell <[email-masked]>
To:     "[email-masked]" <[email-masked]>
Date:   09/14/2015 08:21 PM
Subject:        [saag] Fwd: Request for Comments: NIST SP 800-57 Part 1 
(Rev 4): Recommendation for Key Management: Part 1: General
Sent by:        "saag" <[email-masked]>

FYI

-------- Forwarded Message --------

Please send comments to
[email-masked]<
mailto:[email-masked]?subject=Comments%20on%20SP%20800-57,%20Part%201
by October 31, 2015.

Details and a link to Draft SP 800-57 Part 1 Revision 4 can be found on
the NIST CSRC Draft publications page at:
http://csrc.nist.gov/publications/PubsDrafts.html#800-57pt1r4<
http://links.govdelivery.com/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkPTIwMTUwOTEwLjQ4OTY5MDExJm1lc3NhZ2VpZD1NREItUFJELUJVTC0yMDE1MDkxMC40ODk2OTAxMSZkYXRhYmFzZWlkPTEwMDEmc2VyaWFsPTE3MTg2MjE4JmVtYWlsaWQ9c2FyYS5jYXN3ZWxsQG5pc3QuZ292JnVzZXJpZD1zYXJhLmNhc3dlbGxAbmlzdC5nb3YmZmw9JmV4dHJhPU11bHRpdmFyaWF0ZUlkPSYmJg==&&&100&&&http://csrc.nist.gov/publications/PubsDrafts.html#800-57pt1r4

_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

=====-----=====-----=====
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

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 30 Sep 2015 12:07:19 +0530

Hi Dave,
Thanks for your response. Indeed the end-points need to have the keys 
provisioned before they can start to establish a secure session. However, 
the focus of the draft is on secure session establishment followed by 
secure exchange of full application layer message. It would be very 
interesting to know if the proposed algorithm has any merit for practical 
applications. 

Regards
Abhijan Bhattacharyya
Associate Consultant

From:   David Misell <[email-masked]>
To:     Abhijan Bhattacharyya <[email-masked]>
Date:   09/18/2015 03:36 PM
Subject:        Re: [saag] draft-bhattacharyya-dice-less-on-coap-00

Abhijan
Within containers it is required they have ssh keys, maybe thus could be 
used at provisioning time.
Also have you seen the 1 certificate one address 
http://blog.pivotal.io/labs/labs/sslip-io-a-valid-ssl-certificate-for-every-ip-address 
code

Kind Regards,

Dave

David S. Misell MBCS CISSP
Skype misell.dave
+44(0)7710380044
0207 7239135
Http://linkedin.com/in/misell
https://db.tt/ncfgMm3J

On 18 Sep 2015, at 10:46, Abhijan Bhattacharyya <
[email-masked]> wrote:

Dear Saag ML, 

So, the basic idea is: 
1.      Leverage the lightweight yet reliable nature of CoAP and push the 
responsibility for session establishment to the application layer. That 
way the application layer has more control on the exchanges, which is 
desirable for constrained networks. 
2.      Once the session is established transfer the control to the 
transport layer which for channel security. This will completely re-use 
the channel-security provided by DTLS-PSK (thus getting all sorts of 
reliability and protection from replay attack, etc. ). An interface layer 
would map the <Server_write_key, Client_write_key, Server_IV, Client_IV> 
tuple  available from the session establishment process at the application 
layer to the DTLS session parameters. 
3.      Since CoAP already mandated DTLS for secure exchanges, the 
intention was to create a solution which will not be disruptive, rather 
will be able to co-exist with legacy DTLS implementation. The implementers 
will be able to mostly reuse modules from a standard DTLS implementation 
and can quickly build a system. Only the session establishment part of the 
DTLS protocol needs to be switched.

Regards
Abhijan Bhattacharyya
Associate Consultant

---

From: David Misell <[email-masked]>
Date: Wed, 30 Sep 2015 07:54:50 +0100

Agreed, it's a start bill concurs too about the principle

Best Regards,

Dave

[email-masked]
07710380044
misell.dave on skype

> On 30 Sep 2015, at 07:37, Abhijan Bhattacharyya <[email-masked]> wrote:
> 
> Hi Dave, 
> Thanks for your response. Indeed the end-points need to have the keys provisioned before they can start to establish a secure session. However, the focus of the draft is on secure session establishment followed by secure exchange of full application layer message. It would be very interesting to know if the proposed algorithm has any merit for practical applications. 
> 
> Regards
> Abhijan Bhattacharyya
> Associate Consultant
> Within containers it is required they have ssh keys, maybe thus could be used at provisioning time. 
> Also have you seen the 1 certificate one address http://blog.pivotal.io/labs/labs/sslip-io-a-valid-ssl-certificate-for-every-ip-address code
> 
> Kind Regards, 
> 
> Dave 
> 
> On 18 Sep 2015, at 10:46, Abhijan Bhattacharyya <[email-masked]> wrote:
> 
> Dear Saag ML, 
> The draft was originally submitted in Dice. However it seems, dice is not chartered to discuss this kind of draft. So, would highly appreciate if experts in the Saag ML spare some time to judge the proposed approach on the basis of its merit and share there views. 
> 
> Specifically, this draft tries to channel-secure the communication between Constrained Application layer Protocol (CoAP) end-points. The key driving factor behind this draft was that we had a feeling that the session establishment in DTLS, even with pre-shared-key, might be bit too heavy for very much bandwidth constrained environments. However, ones the channel is established DTLS-PSK provides a very robust yet resource-efficient mechanism to keep the channel secure. 
> 
> So, the basic idea is: 
> 1.        Leverage the lightweight yet reliable nature of CoAP and push the responsibility for session establishment to the application layer. That way the application layer has more control on the exchanges, which is desirable for constrained networks. 
> 2.        Once the session is established transfer the control to the transport layer which for channel security. This will completely re-use the channel-security provided by DTLS-PSK (thus getting all sorts of reliability and protection from replay attack, etc. ). An interface layer would map the <Server_write_key, Client_write_key, Server_IV, Client_IV>  tuple  available from the session establishment process at the application layer to the DTLS session parameters. 
> 3.        Since CoAP already mandated DTLS for secure exchanges, the intention was to create a solution which will not be disruptive, rather will be able to co-exist with legacy DTLS implementation. The implementers will be able to mostly reuse modules from a standard DTLS implementation and can quickly build a system. Only the session establishment part of the DTLS protocol needs to be switched. 
> 
> There can be many engineering issues to be solved. However, before proceeding we need to validate the basic approach and the usefulness of the proposal from experts. Any review comment is highly appreciated. The draft contains the experimental results in the form of tables. A snapshot of the graphs of the results from the original paper is also attached. 
> 
> The R&D behind this draft was published as a paper in  "Workshop on Pervasive Internet of Things and Smart Cities (PITSaC-2015)" in conjunction with "Advanced Information Networking and Applications (AINA-2015)", Gwangju, Korea, March, 2015 . 
> The original paper can be found here:  http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7096256 
> Some figures from the paper has been attached with this mail as ready references. 
>