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

Hi Rachael,

On Wed, Dec 16, 2015 at 2:12 AM, Huangyihong (Rachel)
<rachel.huang@huawei.com> wrote:
> Hi Kathleen,
>
> Thank you for all the valuable comments. Please see my replies inline.
>
> BR,
> Rachel
>
>
>> -----Original Message-----
>> From: ppsp [mailto:ppsp-bounces@ietf.org] On Behalf Of Kathleen Moriarty
>> Sent: Tuesday, December 15, 2015 10:30 AM
>> To: The IESG
>> Cc: ppsp-chairs@ietf.org; ppsp@ietf.org;
>> draft-ietf-ppsp-base-tracker-protocol@ietf.org
>> Subject: [ppsp] Kathleen Moriarty's No Objection on
>> draft-ietf-ppsp-base-tracker-protocol-11: (with COMMENT)
>>
>> 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.
>
> [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.
>>
>> - 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.
>
> [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.
> "

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
>> 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!
>>
>>
>> _______________________________________________
>> ppsp mailing list
>> ppsp@ietf.org
>> https://www.ietf.org/mailman/listinfo/ppsp

-- 

Best regards,
Kathleen