Subject: [ppsp] Kathleen Moriarty's No Objection on draft-ietf-ppsp-base-tracker-protocol-11: (with COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Mon, 14 Dec 2015 18:29:50 -0800

Kathleen Moriarty has entered the following ballot position for
draft-ietf-ppsp-base-tracker-protocol-11: No Objection

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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-ppsp-base-tracker-protocol/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. Section 5.2.7
Please make mention and reference to security provisions for SNMP and
Syslog.  RFC5424 is just for syslog, so a pointer for SNMP security
considerations should be added in this section as well.  They use a
boilerplate for the text and add considerations specific to a draft.  
Benoit - do you have a good reference for them to use?  A more generic
SNMP draft might not be up-to-date with the latest boilerplate text.  If
that's the case, the recent changes are small and could be stated with a
pointer to an RFC with the older boilerplate text.

- Thanks for adding an SNMP reference.  I would think there is a better,
more recent one that could be used.  Moving to a comment for your AD to
help you with and not hold up on this one.

2. Are there any considerations for the statistics collected, can they be
used in a malicious way?  I would think so and that this would be an
important security consideration.  Mentioning possible issues would be
helpful to the reader.

- Thanks for adding in text about this one!

3. Section 6
Reference to RFC2616 isn't enough for the security considerations of HTTP
since that's a really old RFC.  If you want authentication options, you
could point to the HTTPAuth documents, which include updated versions of
HTTP basic (RFC7616) and digest (RFC7617).  While there are still lots of
security issues with these options, the RFCs spell out what the actual
considerations are, which are helpful to the reader.  This raises the
need for TLS 1.2 as well to provide session protection for the session
(passive and active attacks) as well as for the authentication used.

You mention HTTPAuth's digest in 6.1, but there's no reference.  This is
a little better, so I am moving this to a comment from discuss.

4. Section 6.1
Why isn't TLS a must here to protect the session data?
If you are relying on OAuth Bearer tokens, they offer no security
protection without TLS, so to rely on this, I'd say TLS really should be
a MUST.  The authentication types to get a bearer token (at least in RFC
documentation and in the registry) are all pretty weak and require TLS
protection to have any level of security.

With the TLS MUST, we are recommending TLS 1.2 as the minimum in drafts. 
It would be good to see a mention of TLS 1.2 as a minimum recommendation
and a reference to the BCP for TLS 1.2 configurations RFC7525 (it even
includes cipher suite recommendations).

- Thanks for adding in the MUST for TLS and the reference to RFC7525.

5. Privacy
I would have expected some discussion on the protection of the 2 ID types
and the tracker capabilities and that session encryption (TLS) ought to
be used when this is a consideration.  Is there a reason this isn't
covered?  If it's not a concern, I'd like to understand why.

-Thanks for adding in a privacy section!

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 16 Dec 2015 07:12:21 +0000

Hi Kathleen,

Thank you for all the valuable comments. Please see my replies inline.

BR,
Rachel

> -----Original Message-----
> From: ppsp [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
> Sent: Tuesday, December 15, 2015 10:30 AM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: [ppsp] Kathleen Moriarty's No Objection on
> draft-ietf-ppsp-base-tracker-protocol-11: (with COMMENT)
> 
> 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 make mention and reference to security provisions for SNMP and Syslog.
> RFC5424 is just for syslog, so a pointer for SNMP security considerations should
> be added in this section as well.  They use a boilerplate for the text and add
> considerations specific to a draft.
> Benoit - do you have a good reference for them to use?  A more generic SNMP
> draft might not be up-to-date with the latest boilerplate text.  If that's the
> case, the recent changes are small and could be stated with a pointer to an
> RFC with the older boilerplate text.
> 
> - Thanks for adding an SNMP reference.  I would think there is a better, more
> recent one that could be used.  Moving to a comment for your AD to help you
> with and not hold up on this one.

[Rachel]: Will referring to [RFC5590] be better?

> 
> 
> 2. Are there any considerations for the statistics collected, can they be used in
> a malicious way?  I would think so and that this would be an important
> security consideration.  Mentioning possible issues would be helpful to the
> reader.
> 
> since that's a really old RFC.  If you want authentication options, you could
> point to the HTTPAuth documents, which include updated versions of HTTP
> basic (RFC7616) and digest (RFC7617).  While there are still lots of security
> issues with these options, the RFCs spell out what the actual considerations
> are, which are helpful to the reader.  This raises the need for TLS 1.2 as well to
> provide session protection for the session (passive and active attacks) as well
> as for the authentication used.
> 
> You mention HTTPAuth's digest in 6.1, but there's no reference.  This is a little
> better, so I am moving this to a comment from discuss.

[Rachel]: Yes. I propose following changes for the last paragraph of 6.1:

OLD
"
   OAuth 2.0 Authorization [RFC6749] SHOULD be also considered when
   digest authentication and HTTPS client certificates are required.
"
NEW
"
   When peer (Client) authentication is desired at the tracker, HTTP Digest Authentication [RFC7616] MUST be supported.
"

> If you are relying on OAuth Bearer tokens, they offer no security protection
> without TLS, so to rely on this, I'd say TLS really should be a MUST.  The
> authentication types to get a bearer token (at least in RFC documentation and
> in the registry) are all pretty weak and require TLS protection to have any level
> of security.
> 
> and a reference to the BCP for TLS 1.2 configurations RFC7525 (it even includes
> cipher suite recommendations).
> 
> I would have expected some discussion on the protection of the 2 ID types and
> the tracker capabilities and that session encryption (TLS) ought to be used
> when this is a consideration.  Is there a reason this isn't covered?  If it's not
> a concern, I'd like to understand why.
> 
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 17 Dec 2015 03:42:49 +0000

Hi Kathleen,

I'll update it according to your suggestion. Thank you very much.

BR,
Rachel

> From: Kathleen Moriarty [mailto:[email-masked]]
> Sent: Wednesday, December 16, 2015 9:37 PM
> To: Huangyihong (Rachel)
> Cc: The IESG; [email-masked]; [email-masked];
> Subject: Re: [ppsp] Kathleen Moriarty's No Objection on
> Hi Rachael,
> On Wed, Dec 16, 2015 at 2:12 AM, Huangyihong (Rachel)
> <[email-masked]> wrote:
> > Hi Kathleen,
> >
> >> email addresses included in the To and CC lines. (Feel free to cut
> >> this introductory paragraph, however.)
> >>
> >>
> >> Please refer to
> >> https://www.ietf.org/iesg/statement/discuss-criteria.html
> Syslog.
> >> RFC5424 is just for syslog, so a pointer for SNMP security
> >> Benoit - do you have a good reference for them to use?  A more
> >> generic SNMP draft might not be up-to-date with the latest
> >> boilerplate text.  If that's the case, the recent changes are small
> >> and could be stated with a pointer to an RFC with the older boilerplate text.
> >>
> >> - Thanks for adding an SNMP reference.  I would think there is a
> >> better, more recent one that could be used.  Moving to a comment for
> >> your AD to help you with and not hold up on this one.
> >
> >> 2. Are there any considerations for the statistics collected, can
> >> they be used in a malicious way?  I would think so and that this
> >> would be an important security consideration.  Mentioning possible
> >> issues would be helpful to the reader.
> >>
> >> Reference to RFC2616 isn't enough for the security considerations of
> >> HTTP since that's a really old RFC.  If you want authentication
> >> options, you could point to the HTTPAuth documents, which include
> >> updated versions of HTTP basic (RFC7616) and digest (RFC7617).  While
> >> there are still lots of security issues with these options, the RFCs
> >> spell out what the actual considerations are, which are helpful to
> >> the reader.  This raises the need for TLS 1.2 as well to provide
> >> session protection for the session (passive and active attacks) as well as for
> the authentication used.
> >>
> >> You mention HTTPAuth's digest in 6.1, but there's no reference.  This
> >> is a little better, so I am moving this to a comment from discuss.
> >
> >    When peer (Client) authentication is desired at the tracker, HTTP Digest
> Authentication [RFC7616] MUST be supported.
> > "
> 
> I think what you had is better as it allowed for certificate based authentication
> as well.  HTTP Digest has it's problems, which are cited in RFC7616.  A MUST
> for that isn't a good idea.  Just include the reference for RFC7616 with the
> older text.
> 
> Thank you,
> Kathleen
> 
> >
> >>
> >> 4. Section 6.1
> >> protection without TLS, so to rely on this, I'd say TLS really should
> >> be a MUST.  The authentication types to get a bearer token (at least
> >> in RFC documentation and in the registry) are all pretty weak and
> >> require TLS protection to have any level of security.
> >>
> >> It would be good to see a mention of TLS 1.2 as a minimum
> >> recommendation and a reference to the BCP for TLS 1.2 configurations
> >> RFC7525 (it even includes cipher suite recommendations).
> >>
> >> I would have expected some discussion on the protection of the 2 ID
> >> types and the tracker capabilities and that session encryption (TLS)
> >> ought to be used when this is a consideration.  Is there a reason
> >> this isn't covered?  If it's not a concern, I'd like to understand why.
> >>
> --
> Best regards,
> Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 16 Dec 2015 08:36:39 -0500

Hi Rachael,

>    When peer (Client) authentication is desired at the tracker, HTTP Digest Authentication [RFC7616] MUST be supported.

I think what you had is better as it allowed for certificate based
authentication as well.  HTTP Digest has it's problems, which are
cited in RFC7616.  A MUST for that isn't a good idea.  Just include
the reference for RFC7616 with the older text.

Thank you,
Kathleen

-- 

Best regards,
Kathleen