Oslo minutes

[Tristan Debeaupuis <Tristan.Debeaupuis@hsc.fr>]

  1.  Agenda


  9:00-9:10       Agenda bashing
  9:10-11:15      Document reviews
                  draft-ietf-grip-user-02.txt
                  draft-ietf-grip-isp-expectations-01.txt
                  addendum for SSH
                  user security expectation of vendors

  11:15-11:30     Next steps


  No changes proposed.

  21 attendees.



  2.  draft-ietf-grip-user-02.txt

  Tony Hansen led a discussion on the current draft. We weren't able to
  complete the full review and remaining issues will be discussed on the
  list. The following are the issues that were discussed.


  o  Tristan remarks that we should define what we consider to be an
     ISP.  Tristan will provide a definition. This definition will
     include organizations providing connectivity to the Internet as
     well as organizations who may not provide connectivity but rather
     provide services like web hosting, or email service.

  o  There was discussion about what we mean when we refer to the term
     policy. There was concern that we were suggesting that ISPs should
     disclose their internal policies. Nevil Brownlee proposed that we
     add a sentence to explain that we are referring to a high-level
     general view and not the implementation details that an ISP may
     use. It was suggested by Tony that we probably should include a
     definition for security policy within the context of this document.

  o  Discussion continued as to whether we should go more deeply into a
     discussion on policy in the document. It was suggested that perhaps
     an example in an appendix might be helpful to the reader. This is
     still an open issue and will be discussed on the list. Espen
     Torseth (espen.torseth@sds.no) will submit several sentences to the
     list for incorporation into the document.

  o  In section "Sanctions", the sentence "You should also expect your
     ISP to be forthcoming in announcing to the community when such
     sanctions are imposed" will be removed.

  o  2.1.4 Announcement of Policies : "You should expect your ISP to
     publish their security" : this policy will be included in the
     announcement of security policies.

  o  Incident Handling : The document is more generaly is focused on
     helping the customer solicit information about what incident
     handling services the ISP provides and doesn't attempt to delve
     into how the ISP accomplishes those services.

  o  Assistance with inbound security incident : "inform you of the
     attack" removed.
  o  "2.2.3 Notification of Vulnerabilities" : Report incident that
     might affect you.  The new first bullet is : "What information will
     the ISP make available to you when security vulnerabilities that
     might affect you are discovered in their services?"

  o  2.2.3. A new bullet is added : "What information will the ISP make
     available to you when incidents occurring at the ISP may impact
     you"

  o  Modification in "When security incidents occur that ..." : "When
     security incidents occur that affect components of an ISP's
     infrastructure and that may affect you, your ISP should promptly
     report to you"

  o  "Many ISPs have established procedures for notification of
     customers for outadges and service degradation. It is reasonable
     for the ISP to use these channels for some internal incidents. In
     these cases, the customer's security point of contact will probably
     not be the person notified. Rather to the normal POC will received
     the report."

  o  Contact information : "Who should contact <delete>via
     email</delete> for ..."

  o  Add something about authentication and communication.

  o  There was concern that the language of the document implied it was
     only for individual end users. The working group intends for it to
     apply to any size customer of an ISP so we will add some sentences
     to clearly communicate this to the reader.

  o  2.6 References: new first bullet: "Will the ISP provide a list of
     reference customers that have security incident handled by the ISP.
     All references must be voluntary."


  o  "can be found in the Site Security Handbook RFC2196". There is
     concern that we're asking for an ISP's internal proprietary
     information.

  o  "You should also expect your ISP to be forthcoming in announcing to
     the community when such sanctions are imposed." This sentence is
     inappropriate.

  o  2.1.4. Announcement of Policies: "If the AUP changes, will you be
     notified of changes to it, and if so, how?" We need to tweak this
     and it will be discussed on the list.

  o  2.2.1. ISPs and Security Incident Response Teams: "Does the ISP
     have a Security Incident        Response Team (SIRT)?" We want the
     user to care about whether the ISP has a service. Need the customer
     to know that security and privacy concerns may preclude the ISP
     from divulging certain kinds of information. The important thing is
     to get disclosure to the user of what procedures the ISP has, or
     doesn't have.

  o  "2.2.3. Notification of Vulnerabilities and Reporting of Incidents"
     replaced by "Notification of vulnerabilities and reporting of
     incidents that may affect you."

  o  "When security incidents occur that affect components of an ISP's
     infrastructure, your ISP should promptly report to you:" is
     replaced by "When security incidents occur that affect components
     of an ISP's infrastructure, and may affect you, your ISP should
     promptly report to you:"

  o  "Who should you contact via email for network security issues?" Add
     a bullet:  "** What mechanisms are being used to provide
     authentication and privacy?"

  o  "** Is the ISP up-to-date in applying security patches to their
     software/firmware running on their production equipment?" we need
     to resolve whether this stays in or goes.



  3.  draft-ietf-grip-isp-expectations-01.txt



  o  The definition ISPs should be added. Tristan will provide a short
     definition of what we mean by "ISP".

  o  Message submission : remove the explicit reference to the work in
     progress.

     The paragraph "The (undocumented) XTND XMIT POP3 extension which
     allows clients to send mail through the POP3 session rather than
     using SMTP may also be considered.  It also provides a way to
     support mobile users at sites where open relaying is disabled, and
     has the benefit of an authenticated connection and a better audit
     trail" will be deleted.


  4.  Addendum for SSH

  The draft document is not issued yet.

  The main ideas of the document are :

  o  technical operations of services

  o  security issues surrounding the way they manage and operate their
     network

  o  section 7,8,9,10


  Work done :

  o  document mainly based on Tom's work

  o  deletion of the different paragraphs

             2.4 Notification of vulnerabilities and Reporting of Incidents
             3. Appropriate Use Policy
                     3.1 Announcement of Policy
                     3.2 Sanctions
             4.1 Cooperation (conforming december minutes)
             4.4 Registry Data Maintenance



  o  new ideas for the chapter named "Network Infrastructure" ? We will
     discussed that on the list.



  5.  Next steps



  o  ISP expectation update from Tom next week

  o  SSH addendum from Tristan this week,

  o  User document update from Tony

  o  WG last call will be issued shortly after the next draft of the ISP
     expectations document is released.

  o  An interested subset of the WG will meet for lunch tomorrow to
     hammer out some of the unresolved issues in the user document.

  o  Barbara mentioned that Klaus-Peter Kossakowski and she had pulled
     together past content intended for a document expressing the
     community's expectations of technology vendors. This draft will be
     submitted to ID in 2 weeks.

-- 
Tristan.Debeaupuis@hsc.fr -=- Herve Schauer Consultants -=- TD1678