Re: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS)

[Kathleen Moriarty <[e-mail]>]

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) <
[e-mail]> 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:[e-mail]]
> *Sent:* Thursday, February 26, 2015 9:14 PM
> *To:* Juergen Schoenwaelder; Kathleen Moriarty; The IESG; [e-mail];
> Warren Kumari; [e-mail];
> [e-mail]
> *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 <
> [e-mail]> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>



-- 

Best regards,
Kathleen