Practical Considerations and Implementation Experiences in Securing Smart Object Networks
draft-ietf-lwig-crypto-sensors-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-05-14
|
06 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-04-24
|
06 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-04-23
|
06 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-03-13
|
06 | (System) | IANA Action state changed to No IC from In Progress |
2018-03-13
|
06 | (System) | RFC Editor state changed to EDIT |
2018-03-13
|
06 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-03-13
|
06 | (System) | Announcement was received by RFC Editor |
2018-03-13
|
06 | (System) | IANA Action state changed to In Progress |
2018-03-13
|
06 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-03-13
|
06 | Amy Vezza | IESG has approved the document |
2018-03-13
|
06 | Amy Vezza | Closed "Approve" ballot |
2018-03-13
|
06 | Amy Vezza | Ballot approval text was generated |
2018-03-13
|
06 | Suresh Krishnan | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2018-02-26
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-02-26
|
06 | Mohit Sethi | New version available: draft-ietf-lwig-crypto-sensors-06.txt |
2018-02-26
|
06 | (System) | New version approved |
2018-02-26
|
06 | (System) | Request for posting confirmation emailed to previous authors: Mohit Sethi , Jari Arkko , Heidi-Maria Back , Ari Keranen , lwig-chairs@ietf.org |
2018-02-26
|
06 | Mohit Sethi | Uploaded new revision |
2018-02-22
|
05 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2018-02-22
|
05 | Cindy Morgan | Changed consensus to Yes from Unknown |
2018-02-22
|
05 | Eric Rescorla | [Ballot comment] Review in context at: https://mozphab-ietf.devsvcdev.mozaws.net/D4040 both parties, there are some remaining vulnerabilities that may or may not be acceptable for the … [Ballot comment] Review in context at: https://mozphab-ietf.devsvcdev.mozaws.net/D4040 both parties, there are some remaining vulnerabilities that may or may not be acceptable for the application in question. For example, leap-of-faith or trust-on-first-use based pairing methods assume that This is not strictly correct. SAS is an example that requires neither of these. the attacker is not present during the initial setup and are vulnerable to eavesdropping or man-in-the-middle (MitM) attacks. You might be interested in Secure In-Band Wireless Pairing Shyamnath Gollakota, Nabeel Ahmed, Nikolai Zeldovich, and Dina Katabi USENIX Security 2011, San Francisco, CA, August 2011. not completely secure method where the last few digits of the identity are printed on a tiny device just a few millimeters across. Alternatively, the packaging for the device may include the full This is subject to trivial attacks no? Igrp = h(Pdev1|Pdev2|...|Pdevm) 1.Where do you use Idev? This does work, I guess, but requires you to have the public keys of every device. Why not use a Merkle tree? filtering, storage and other actions, again without impacting the security of the data being transmitted or stored. It's not clear from this text why these benefits obtain (caching especially). Is that because the data is in self-contained PDUs which can be interpreted even if there is transport/network level modification? different symmetric key algorithms such as AES, triple DES and SkipJack. It provides RSA as an asymmetric key algorithm. Parts of the library were written in AVR-8 bit assembly language to Skipjack? 3DES? Back to the future! of a large variety of cryptographic algorithms. This not only includes RSA and ECC, but also pairing based asymmetric cryptography, Boneh-Lynn-Schacham, Boneh-Boyen short signatures It might be useful to know whether it's just the NIST curves or also X25519 and X448. based public key cryptography on sensor networks. It is written in nesC programming language and as such is designed for specific use on TinyOS. However, the library can be ported to standard C What is the nesC programming language? Maybe a cite? implementation as well as X509 certificate handling. The library provides an intuitive API for developer with a minimal code footprint. It is intended for various ARM platforms such as ARM "intuitive" seems a bit subjective. +--------------+------------------------+---------------------------+ | 2048 | 1587567 | 1,280 | +--------------+------------------------+---------------------------+ The time value would be easier to read if you used comma separators, as you did with memory footprint. In Table 2 we present the results obtained by manually porting TinyECC into C99 standard and running ECDSA signature algorithm on the Arduino Uno board. TinyECC supports a variety of SEC 2 Nit: "the ECDSA" | secp192k1 | 3425 | 1008 | 1536 | | secp192r1 | 3578 | 1008 | 1536 | +-------------+---------------+-----------------+-------------------+ Note: IETF's minimal size is 256-bit and we also wouldn't use any of the k1 curves probably. Do you have a cite for the key length comparisons. Opinions vary a bit here. And I understood the consensus to be that 192-bit was rather stronger than 1536. | NIST K233 | 1736 | 3675 | 2048 | | NIST B233 | 4471 | 3261 | 2048 | +-----------------+--------------+----------------+-----------------+ You should use the same naming convention as with the precious tables. that the IETF community uses these curves for protocol specification and implementations. I'm confused by this statement. I would in fact expect X25519 to be faster, but your table 6 show Relic out performing this: NIST B233 | 6100 | 2737 | 2048 | did note that it is possible for such devices to generate a new key pair. Given that this operation would only occur in rare circumstances (such as a factory reset or ownership change) and its You should probably note that RSA key pair generation is very expensive compared to signing, whereas ECDSA key pair generation is quite cheap compared to signing (it is a fixed-base operation). Sequence numbers can wrap-around at their maximum value and, therefore, it is essential to ensure that sequence numbers are Nit: no hyphen in wrap around because it' sbeing used as a verb. time it passes through an application level entity, it is not clear that there are attacks beyond denial-of-service. This is very dependent on exactly how you build the data object protection protocol. ability to scale to hundreds of millions of devices, let alone billions. But the authors do not believe scaling is an important differentiator when comparing the solutions. I don't believe about PKs not scaling is true at this point. Even if you don't count TLS, here are several widely used PK-based IM protocols. |
2018-02-22
|
05 | Eric Rescorla | Ballot comment text updated for Eric Rescorla |
2018-02-22
|
05 | Eric Rescorla | [Ballot comment] both parties, there are some remaining vulnerabilities that may or may not be acceptable for the application in question. For example, … [Ballot comment] both parties, there are some remaining vulnerabilities that may or may not be acceptable for the application in question. For example, leap-of-faith or trust-on-first-use based pairing methods assume that This is not strictly correct. SAS is an example that requires neither of these. the attacker is not present during the initial setup and are vulnerable to eavesdropping or man-in-the-middle (MitM) attacks. You might be interested in Secure In-Band Wireless Pairing Shyamnath Gollakota, Nabeel Ahmed, Nikolai Zeldovich, and Dina Katabi USENIX Security 2011, San Francisco, CA, August 2011. not completely secure method where the last few digits of the identity are printed on a tiny device just a few millimeters across. Alternatively, the packaging for the device may include the full This is subject to trivial attacks no? Igrp = h(Pdev1|Pdev2|...|Pdevm) 1.Where do you use Idev? This does work, I guess, but requires you to have the public keys of every device. Why not use a Merkle tree? filtering, storage and other actions, again without impacting the security of the data being transmitted or stored. It's not clear from this text why these benefits obtain (caching especially). Is that because the data is in self-contained PDUs which can be interpreted even if there is transport/network level modification? different symmetric key algorithms such as AES, triple DES and SkipJack. It provides RSA as an asymmetric key algorithm. Parts of the library were written in AVR-8 bit assembly language to Skipjack? 3DES? Back to the future! of a large variety of cryptographic algorithms. This not only includes RSA and ECC, but also pairing based asymmetric cryptography, Boneh-Lynn-Schacham, Boneh-Boyen short signatures It might be useful to know whether it's just the NIST curves or also X25519 and X448. based public key cryptography on sensor networks. It is written in nesC programming language and as such is designed for specific use on TinyOS. However, the library can be ported to standard C What is the nesC programming language? Maybe a cite? implementation as well as X509 certificate handling. The library provides an intuitive API for developer with a minimal code footprint. It is intended for various ARM platforms such as ARM "intuitive" seems a bit subjective. +--------------+------------------------+---------------------------+ | 2048 | 1587567 | 1,280 | +--------------+------------------------+---------------------------+ The time value would be easier to read if you used comma separators, as you did with memory footprint. In Table 2 we present the results obtained by manually porting TinyECC into C99 standard and running ECDSA signature algorithm on the Arduino Uno board. TinyECC supports a variety of SEC 2 Nit: "the ECDSA" | secp192k1 | 3425 | 1008 | 1536 | | secp192r1 | 3578 | 1008 | 1536 | +-------------+---------------+-----------------+-------------------+ Note: IETF's minimal size is 256-bit and we also wouldn't use any of the k1 curves probably. Do you have a cite for the key length comparisons. Opinions vary a bit here. And I understood the consensus to be that 192-bit was rather stronger than 1536. | NIST K233 | 1736 | 3675 | 2048 | | NIST B233 | 4471 | 3261 | 2048 | +-----------------+--------------+----------------+-----------------+ You should use the same naming convention as with the precious tables. that the IETF community uses these curves for protocol specification and implementations. I'm confused by this statement. I would in fact expect X25519 to be faster, but your table 6 show Relic out performing this: NIST B233 | 6100 | 2737 | 2048 | did note that it is possible for such devices to generate a new key pair. Given that this operation would only occur in rare circumstances (such as a factory reset or ownership change) and its You should probably note that RSA key pair generation is very expensive compared to signing, whereas ECDSA key pair generation is quite cheap compared to signing (it is a fixed-base operation). Sequence numbers can wrap-around at their maximum value and, therefore, it is essential to ensure that sequence numbers are Nit: no hyphen in wrap around because it' sbeing used as a verb. time it passes through an application level entity, it is not clear that there are attacks beyond denial-of-service. This is very dependent on exactly how you build the data object protection protocol. ability to scale to hundreds of millions of devices, let alone billions. But the authors do not believe scaling is an important differentiator when comparing the solutions. I don't believe about PKs not scaling is true at this point. Even if you don't count TLS, here are several widely used PK-based IM protocols. |
2018-02-22
|
05 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-02-21
|
05 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-02-21
|
05 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-02-21
|
05 | Ben Campbell | [Ballot comment] I'm balloting "yes", because I think this is interesting and useful material. But, as others have mentioned, it's confusing that this appears to … [Ballot comment] I'm balloting "yes", because I think this is interesting and useful material. But, as others have mentioned, it's confusing that this appears to be a working group document, but it seems to be about the authors' personal design and experimentations. Otherwise, I just have a few editorial comments: §2, first paragraph, third sentence: Missing article before "CoAP base specification". §4.1, paragraph 4: "Once both peers...": What peers? Does this use the term "peer" for the server? §4.1, last _word_: missing article before Igrp. §4.2: "While this is not impossible in data object security solutions either, it is not the typical arrangement either." I suspect the first "either" was not intended. §5: "It is written in nesC programming language..." missing article before "nesC". |
2018-02-21
|
05 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2018-02-21
|
05 | Min Ye | Request for Telechat review by RTGDIR Completed: Has Nits. Reviewer: Emmanuel Baccelli. |
2018-02-21
|
05 | Benoît Claise | [Ballot comment] From Eric Vyncke, as OPS DIR reviewer: This informational draft is about the challenges associated with securing resource-constrained smart object devices (such as … [Ballot comment] From Eric Vyncke, as OPS DIR reviewer: This informational draft is about the challenges associated with securing resource-constrained smart object devices (such as those using CoAP). It describes a possible deployment model and some preliminary experiences. It is part of a set of documents (draft- arkko-core-security-arch). The challenges section includes many operational aspects: provisioning, scalability, ... The document proposes a simple system to generate the device identity based on its public key. The authors made some tests using 6 different crypto-libraries on Arduino 8-bit processors, this is the main part of the document. Finally, sections 7 and 8 describe a simple test application and some considerations about implementations. So, a rather practical document. *My only regret is that ‘key pair renewal’ is mentioned twice in the document (section 4.1 and 8.1) but without any detail... Key renewal is a big operational issue and it deserves more text or be explicitly cited as a non-goal in the abstract.* |
2018-02-21
|
05 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2018-02-21
|
05 | Terry Manderson | [Ballot Position Update] New position, Yes, has been recorded for Terry Manderson |
2018-02-21
|
05 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-02-21
|
05 | Kathleen Moriarty | [Ballot comment] Thank you for your research work supporting this document and for a well written draft. A agree with Spencers comments on scaling from … [Ballot comment] Thank you for your research work supporting this document and for a well written draft. A agree with Spencers comments on scaling from DDoS attacks and with Warren's comments. I only caught one other typo that I didn't see mentioned in another review. Section 7: These battery-operated or energy scavenging nodes do not have enough power to be stay on at all times. |
2018-02-21
|
05 | Kathleen Moriarty | Ballot comment text updated for Kathleen Moriarty |
2018-02-21
|
05 | Kathleen Moriarty | [Ballot comment] Thank you for your research work supporting this document and for a well written draft. A agree with Spencers comments on scaling from … [Ballot comment] Thank you for your research work supporting this document and for a well written draft. A agree with Spencers comments on scaling from DDoS attacks. I only caught one other typo that I didn't see mentioned in another review. Section 7: These battery-operated or energy scavenging nodes do not have enough power to be stay on at all times. |
2018-02-21
|
05 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2018-02-21
|
05 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-02-21
|
05 | Warren Kumari | [Ballot comment] I enjoyed this document and liked the fact that it contains actual data and research. I do somewhat agree with the "the tone … [Ballot comment] I enjoyed this document and liked the fact that it contains actual data and research. I do somewhat agree with the "the tone of this is researchy", but I'm also more than fine with that for an Informational document. Editorial: "The workshop recommended that additional work is needed in developing suitable credential management mechanisms " -- I suspect that this is incorrect - I think it is "The workshop recommended that additional work should be undertaken in" or "The workshop discovered that additional work is needed in..." The wording of: "In any case, as with sensor networks the amount of configuration information is minimized: just one short identity value needs to be fed in. Not both an identity and certificate. Not shared secrets that must be kept confidential." feels odd. Perhaps "... to be fed in (not both an identity and certificate or shared secrets that must be kept confidential)" would flow better? "For example, leap-of-faith or trust-on-first-use based pairing methods assume that the attacker is not present during the initial setup and are vulnerable to eavesdropping or man-in-the-middle (MitM) attacks." - this is ambiguous, it could be read that this assumes that the attacker is not present and that the attacker is vulnerable to evesdropping. This is a minor issue and can be ignored. Section 4.1: "Each device generates its own identity in a random, secure key generation process." - I think it would be useful to reinforce here that it is hard for new devices to have enough entropy to make good randomness. You do mention this further in the document - perhaps point at that? Section 6: Implementation Experiences Generating an RSA 2048 bit key took 1587567ms -- I think it would be useful to mention that this is ~26 minutes ( 1587567 is many digits, and is hard to grock without conversion) We decided to use the Arduino Mega which has the same 8-bit architecture like the Arduino Uno but has a much larger RAM/ROM for testing relic-toolkit. -- somewhat ambiguous. This could be read that the Mega was designed to have more RAM/ROM specifically for testing relic-toolkit. This can also be ignored. (well these are all comments, so technically they can all be ignored, but this more than most :-)) For instance, a sensor that wakes up every now and then can likely spend a fraction of a second for the computation of a signature for the message that it is about to send. Or even spend multiple seconds in some cases. -- I'd suggest joining this into one sentence. It is important for the smart object to write the sequence number into the permanent flash memory after each increment -- it may be worth noting that many flash technologies have very limited write cycles, and so this may not be practical. 9. Summary This document makes several security recommendations based on our implementation experience. We summarize some of the important ones here: ... o 32-bit microcontrollers are much more easily available, at lower costs and are more power efficient. Therefore, real-world deployments are better off using 32-bit microcontrollers. While very true, it isn't really a security recommendation. |
2018-02-21
|
05 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2018-02-21
|
05 | Suresh Krishnan | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-02-21
|
05 | Alexey Melnikov | [Ballot comment] A good piece of work, even if a bit "researchy" at times. |
2018-02-21
|
05 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2018-02-19
|
05 | Spencer Dawkins | [Ballot comment] I'm a little confused to read Section 4 discusses a deployment model that the authors are considering for constrained environments. in … [Ballot comment] I'm a little confused to read Section 4 discusses a deployment model that the authors are considering for constrained environments. in a working group draft. Is the working group proposing this? The Introduction skips over Section 7, which could make sense for an Example, but will likely mystify readers. Looking at this text, o There may be a large number of devices. Configuration tasks that may be acceptable when performed for one device may become unacceptable with dozens or hundreds of devices. I think recent DDOS attacks have shown that many more than "hundreds of "owned" Things can cooperate to cause problems. ("It's worse than you think") Should Temporary identities (such as IPv6 addresses) can be used for network communication protocols once the device is operational. be qualified? I'm thinking that some IPv6 addressing practices would not qualify as "temporary identities". I wasn't sure what A 64-bit x86 linux machine serves as the broker and the RD, while a similar but physically different 64-bit x86 linux machine serves as the client that requests data from the sensor. meant by "physically different". I was guessing "similar but physically distinct", but I'm guessing. |
2018-02-19
|
05 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2018-02-19
|
05 | Mirja Kühlewind | [Ballot comment] This document reads more like a research paper (especially as it often talks about „the authors“ and „we“). While I would find it … [Ballot comment] This document reads more like a research paper (especially as it often talks about „the authors“ and „we“). While I would find it more appropriate to publish the experimentation report as a research paper or maybe some kind of extended technical report and only document the resulting recommendations in a short informational RFC, I don’t object to the publication as it was at least an interesting read. I guess the authors could consider to move some parts to the appendix (I guess sections 5-7 and maybe even some more text) but it’s probably not worth the effort. |
2018-02-19
|
05 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-02-19
|
05 | Suresh Krishnan | Ballot has been issued |
2018-02-19
|
05 | Suresh Krishnan | [Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan |
2018-02-19
|
05 | Suresh Krishnan | Created "Approve" ballot |
2018-02-19
|
05 | Suresh Krishnan | Ballot writeup was changed |
2018-02-19
|
05 | Christian Huitema | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Christian Huitema. Sent review to list. |
2018-02-19
|
05 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-02-16
|
05 | Éric Vyncke | Request for Telechat review by OPSDIR Completed: Has Issues. Reviewer: Éric Vyncke. |
2018-02-16
|
05 | Henrik Levkowetz | Request for Telechat review by OPSDIR is assigned to Éric Vyncke |
2018-02-16
|
05 | Henrik Levkowetz | Request for Telechat review by OPSDIR is assigned to Éric Vyncke |
2018-02-16
|
05 | Henrik Levkowetz | Request for Telechat review by OPSDIR is assigned to (None) |
2018-02-16
|
05 | Henrik Levkowetz | Request for Telechat review by OPSDIR is assigned to (None) |
2018-02-13
|
05 | Dan Romascanu | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Dan Romascanu. Sent review to list. |
2018-02-08
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Christian Huitema |
2018-02-08
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Christian Huitema |
2018-02-08
|
05 | Min Ye | Request for Telechat review by RTGDIR is assigned to Emmanuel Baccelli |
2018-02-08
|
05 | Min Ye | Request for Telechat review by RTGDIR is assigned to Emmanuel Baccelli |
2018-02-08
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2018-02-08
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2018-02-08
|
05 | Alvaro Retana | Requested Telechat review by RTGDIR |
2018-02-07
|
05 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2018-02-07
|
05 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-lwig-crypto-sensors-05, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-lwig-crypto-sensors-05, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-02-05
|
05 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-02-05
|
05 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-02-19): From: The IESG To: IETF-Announce CC: lwip@ietf.org, zhencao.ietf@gmail.com, lwig-chairs@ietf.org, draft-ietf-lwig-crypto-sensors@ietf.org, suresh@kaloom.com … The following Last Call announcement was sent out (ends 2018-02-19): From: The IESG To: IETF-Announce CC: lwip@ietf.org, zhencao.ietf@gmail.com, lwig-chairs@ietf.org, draft-ietf-lwig-crypto-sensors@ietf.org, suresh@kaloom.com, Zhen Cao Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Practical Considerations and Implementation Experiences in Securing Smart Object Networks) to Informational RFC The IESG has received a request from the Light-Weight Implementation Guidance WG (lwig) to consider the following document: - 'Practical Considerations and Implementation Experiences in Securing Smart Object Networks' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-02-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes challenges associated with securing resource- constrained smart object devices. The memo describes a possible deployment model where resource-constrained devices sign message objects, discusses the availability of cryptographic libraries for small devices and presents some preliminary experiences with those libraries for message signing on small devices. Lastly, the memo discusses trade-offs involving different types of security approaches. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lwig-crypto-sensors/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lwig-crypto-sensors/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-02-05
|
05 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-02-05
|
05 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Éric Vyncke |
2018-02-05
|
05 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Éric Vyncke |
2018-02-05
|
05 | Suresh Krishnan | Placed on agenda for telechat - 2018-02-22 |
2018-02-05
|
05 | Suresh Krishnan | Last call was requested |
2018-02-05
|
05 | Suresh Krishnan | IESG state changed to Last Call Requested from Last Call Requested::External Party |
2018-02-05
|
05 | Suresh Krishnan | Last call was requested |
2018-02-05
|
05 | Suresh Krishnan | Last call announcement was generated |
2018-02-05
|
05 | Suresh Krishnan | Ballot approval text was generated |
2018-02-05
|
05 | Suresh Krishnan | Ballot writeup was generated |
2018-02-05
|
05 | Suresh Krishnan | IESG state changed to Last Call Requested::External Party from AD Evaluation::External Party |
2017-12-29
|
05 | Suresh Krishnan | Waiting for feedback from INT, IoT and Sec Directorate reviewers on the new version. |
2017-12-29
|
05 | Suresh Krishnan | IESG state changed to AD Evaluation::External Party from AD Evaluation |
2017-12-25
|
05 | Mohit Sethi | New version available: draft-ietf-lwig-crypto-sensors-05.txt |
2017-12-25
|
05 | (System) | New version approved |
2017-12-25
|
05 | (System) | Request for posting confirmation emailed to previous authors: Mohit Sethi , Jari Arkko , Heidi-Maria Back , Ari Keranen |
2017-12-25
|
05 | Mohit Sethi | Uploaded new revision |
2017-11-12
|
04 | Suresh Krishnan | IESG state changed to AD Evaluation from Publication Requested |
2017-11-06
|
04 | Samita Chakrabarti | Request for Early review by IOTDIR Completed: Ready with Nits. Reviewer: Samita Chakrabarti. Sent review to list. |
2017-10-31
|
04 | Ari Keränen | Request for Early review by IOTDIR is assigned to Samita Chakrabarti |
2017-10-31
|
04 | Ari Keränen | Request for Early review by IOTDIR is assigned to Samita Chakrabarti |
2017-10-29
|
04 | Tim Chown | Request for Early review by INTDIR Completed: Ready. Reviewer: Tim Chown. Sent review to list. |
2017-10-15
|
04 | Christian Huitema | Request for Early review by SECDIR Completed: Has Nits. Reviewer: Christian Huitema. Sent review to list. |
2017-10-05
|
04 | Tero Kivinen | Request for Early review by SECDIR is assigned to Christian Huitema |
2017-10-05
|
04 | Tero Kivinen | Request for Early review by SECDIR is assigned to Christian Huitema |
2017-09-30
|
04 | Bernie Volz | Request for Early review by INTDIR is assigned to Tim Chown |
2017-09-30
|
04 | Bernie Volz | Request for Early review by INTDIR is assigned to Tim Chown |
2017-09-29
|
04 | Suresh Krishnan | Requested Early review by IOTDIR |
2017-09-29
|
04 | Suresh Krishnan | Requested Early review by INTDIR |
2017-09-29
|
04 | Suresh Krishnan | Requested Early review by SECDIR |
2017-09-28
|
04 | Zhen Cao | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? a. Informational; b. This document provide engineering advice without specifying any protocol features; c. Yes. This type information has been indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes challenges associated with securing smart object devices in constrained implementations and environments. It includes a number of guidelines for implementers to use proper security protocols and tradeoffs needed for certain applications, all steming from the hands-on experiences. Working Group Summary This document has been well received by the working group. During the first WGLC in Feb., 2017, a well-known security expert has provided thorough review and comments which prosponed the shepherd to IESG, but it helped the document mature better. It was WGLCed again in July of 2017, the consensus of which has been confirmed. Document Quality The authors of the document write this document all based on their hands-on experience, which is a good model of IETF. There is already running code. Hannes Tschofenig, as a security expert, has provided a thorough review of a early version. The most updated version has reflected his comments. Personnel Zhen Cao is the document shepherd. Suresh Krishnan is the responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd has thoroughly reviewed through the document and considers it ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been submitted for review on the lwig WG mailing lists and has had a small amount of discussion. Feedback comments have been incorporated. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The Document Shepherd think that he document requires review from IoT directoriate, which is a default step for any documents from this working group. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd has no specific concerns or issues with the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. The authors have confirmed that there are no IPR disclosures required for full conformance with BCP 78 and BCP 79. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures that reference the document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? It has been discussed in recent meetings and on the mailing list therefore the conclusion is that the WG understands and agrees with the document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Not done yet at Sept. 29, 2017. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? There are no normative references in this document. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There are no IANA considerations. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There are no parts of the document written in a formal language. |
2017-09-28
|
04 | Zhen Cao | Responsible AD changed to Suresh Krishnan |
2017-09-28
|
04 | Zhen Cao | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2017-09-28
|
04 | Zhen Cao | IESG state changed to Publication Requested |
2017-09-28
|
04 | Zhen Cao | IESG process started in state Publication Requested |
2017-09-28
|
04 | Zhen Cao | Tag Doc Shepherd Follow-up Underway cleared. |
2017-09-28
|
04 | Zhen Cao | Intended Status changed to Informational from None |
2017-09-28
|
04 | Zhen Cao | Changed document writeup |
2017-09-28
|
04 | Zhen Cao | Notification list changed to Zhen Cao <zhencao.ietf@gmail.com> |
2017-09-28
|
04 | Zhen Cao | Document shepherd changed to Zhen Cao |
2017-08-11
|
04 | Zhen Cao | Tag Doc Shepherd Follow-up Underway set. |
2017-08-11
|
04 | Zhen Cao | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2017-08-09
|
04 | Mohit Sethi | New version available: draft-ietf-lwig-crypto-sensors-04.txt |
2017-08-09
|
04 | (System) | New version approved |
2017-08-09
|
04 | (System) | Request for posting confirmation emailed to previous authors: Mohit Sethi , Jari Arkko , Heidi-Maria Back , Ari Keranen |
2017-08-09
|
04 | Mohit Sethi | Uploaded new revision |
2017-07-26
|
03 | Mohit Sethi | New version available: draft-ietf-lwig-crypto-sensors-03.txt |
2017-07-26
|
03 | (System) | New version approved |
2017-07-26
|
03 | (System) | Request for posting confirmation emailed to previous authors: Mohit Sethi , Jari Arkko , Heidi-Maria Back , Ari Keranen |
2017-07-26
|
03 | Mohit Sethi | Uploaded new revision |
2017-02-10
|
02 | Mohit Sethi | New version available: draft-ietf-lwig-crypto-sensors-02.txt |
2017-02-10
|
02 | (System) | New version approved |
2017-02-10
|
02 | (System) | Request for posting confirmation emailed to previous authors: "Mohit Sethi" , "Heidi-Maria Back" , "Jari Arkko" , "Ari Keranen" |
2017-02-10
|
02 | Mohit Sethi | Uploaded new revision |
2016-11-06
|
01 | Zhen Cao | Added to session: IETF-97: lwig Thu-1110 |
2016-10-31
|
01 | Mohit Sethi | New version available: draft-ietf-lwig-crypto-sensors-01.txt |
2016-10-31
|
01 | (System) | New version approved |
2016-10-31
|
00 | (System) | Request for posting confirmation emailed to previous authors: "Mohit Sethi" , "Heidi-Maria Back" , "Jari Arkko" , "Ari Keranen" |
2016-10-31
|
00 | Mohit Sethi | Uploaded new revision |
2016-09-06
|
00 | Zhen Cao | This document now replaces draft-aks-lwig-crypto-sensors instead of None |
2016-09-06
|
00 | Mohit Sethi | New version available: draft-ietf-lwig-crypto-sensors-00.txt |