Thank you for the edits and for letting me know the new version was ready. Best regards, Kathleen
On Sun, Mar 1, 2015 at 12:47 PM, Ersue, Mehmet (Nokia - DE/Munich) < mehmet.er...@nokia.com> wrote: > Dear Kathleen, > > > > just to inform you, we uploaded the agreed changes as > draft-ietf-opsawg-coman-probstate-reqs-05.txt. > > > > Cheers, > Mehmet > > > > *From:* ext Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com] > *Sent:* Thursday, February 26, 2015 9:14 PM > *To:* Juergen Schoenwaelder; Kathleen Moriarty; The IESG; opsawg@ietf.org; > Warren Kumari; draft-ietf-opsawg-coman-probstate-reqs....@ietf.org; > opsawg-cha...@ietf.org > *Subject:* Re: Kathleen Moriarty's Discuss on > draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) > > > > Hi, > > > > On Thu, Feb 26, 2015 at 3:10 PM, Juergen Schoenwaelder < > j.schoenwael...@jacobs-university.de> wrote: > > Hi, > > I am not sure what to do about this comment. My take is that the > document is primarily scoped on the management interface and 6.003 > talks about access control towards the managing system and access > control towards the managed device. > > I certainly agree that devices should be robust, bug free, have no > backdoors, be tamper resitant, etc. but then this is, in an ideal > world, true for any device. That said, there is already text in the > security considerations that devices should make sure credentials are > properly protected. Perhaps if we can address this discuss by > expanding this sentence: > > OLD > > As a > consequence, it is crucial to properly protect any security > credentials that may be stored on the device (e.g., by using hardware > protection mechanisms). > > NEW > > As a consequence, it is crucial that devices are robust and tamper > resistant, have no backdoors, do not provide services that are not > essential for the primary function, and properly protect any > security credentials that may be stored on the device (e.g., by > using hardware protection mechanisms). > > > > Yes, that works for me in combination with the updates to the use case > draft. Please let me know when the updated draft has been posted. > > > > Thank you, > > Kathleen > > > /js > > > On Thu, Feb 19, 2015 at 08:10:02AM -0800, Kathleen Moriarty wrote: > > Kathleen Moriarty has entered the following ballot position for > > draft-ietf-opsawg-coman-probstate-reqs-04: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I have not had time to read the full draft, but do see a gap in the > > security requirements that I'd like to see if we can address. The > > section on access controls for management systems and devices reads as > > follows: > > > > Req-ID: 6.003 > > > > Title: Access control on management system and devices > > > > Description: Systems acting in a management role must provide an > > access control mechanism that allows the security administrator to > > restrict which devices can access the managing system (e.g., using > > an access control white list of known devices). On the other hand > > managed constrained devices must provide an access control > > mechanism that allows the security administrator to restrict how > > systems in a management role can access the device (e.g., no- > > access, read-only access, and read-write access). > > > > Source: Basic security requirement for use cases where access > > control is essential. > > > > The way I read this, there is no statement about general access > > protections to the device outside of what is designated by a security > > administrator. I would think a statement on access controls on the > > device would be very important in consideration of safety concerns that > > put a strong need for security on such devices (medical, environmental > > monitors, etc.). Are there additional access mechanisms to the device > > besides what is possible by the management connection? Could there be > > factory defaults in place with local access work-arounds or even wireless > > int he even that there are issues accessing devices from management > > stations? Do these cause security problems? Are there ports other than > > those for management open that could lead to security breaches? Or are > > these out-of-scope because the discussion is about management > > connections? If it's out-of-scope, it would be good to state that it is > > even though that would be a concern. Text on this should be added to the > > security considerations section as a general discussion if it's a > > concern, but not in scope, similar to what was done for privacy. > > > > > > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > > > > > -- > > > > Best regards, > > Kathleen > -- Best regards, Kathleen
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
