Re: [Dime] AD Evaluation of draft-ietf-dime-rfc4006bis-06

[Yuval Lifshitz <[e-mail]>]

Hi All,Would appreciate if you can review/comment on the the following new section:15.  Privacy Considerations

   As the Diameter protocol, and especially credit control application,
   deals with subscribers and their actions, extra care should be taken
   regarding the privacy of the subscribers.  In terms of [RFC6973],
   both the credit-control client and credit-control server are
   intermediary entities, wherein the subscribers' privacy may be
   compromised even if no security issues exists, and only authorized
   entities have access to the privacy-sensitive information.

15.1.  Privacy Sensitive AVPs

   The following AVPs contain privacy-sensitive information at different
   levels:

   1.   CC-Correlation-Id AVP: may contain privacy-sensitive information
        as the service-provider may encode personal information that
        helps it correlate different subscriptions and access
        technologies.

   2.   Check-Balance-Result AVP: contains information on the balance
        status of the subscriber.

   3.   Currency-Code AVP: contains information on the subscriber's
        locale.

   4.   Cost-Unit AVP: contains privacy-sensitive information, as a
        human readable format of the Cost-Information AVP.

   5.   Service-Identifier AVP: may contain privacy-sensitive
        information about the subscriber's internet activity.

   6.   Rating-Group AVP: may contain privacy-sensitive information
        about the subscriber's internet activity.

   7.   Restriction-Filter-Rule AVP: the information inside IPFilterRule
        may be used to infer services used by the subscriber.

   8.   Redirect-Server-Address AVP: the service-provider may embed
        personal information on the subscriber in the URL/I (e.g. to
        create a personalized message).  Similar AVPs are: Redirect-
        Address-URL, Redirect-Address-SIP-URI.

   9.   Service-Context-Id AVP: depending with how the service-provider
        use it, it may contain privacy-sensitive information about the
        service (e.g. access technology).

   10.  Service-Parameter-Info AVP: depending with how the service-
        provider use it, it may contain privacy-sensitive information
        about the subscriber (e.g. location).

   11.  Subscription-Id-Data AVP: contains the identity of the
        subscriber.  Similar AVPs are: Subscription-Id-E164,
        Subscription-Id-IMSI, Subscription-Id-SIP-URI, Subscription-Id-
        NAI, Subscription-Id-Private.

   12.  User-Equipment-Info-Value AVP: contains the identity of the
        device of the subscriber.  Similar AVPs are: User-Equipment-
        Info-IMEISV, User-Equipment-Info-MAC, User-Equipment-Info-EUI64,
        User-Equipment-Info-ModifiedEUI64, User-Equipment-Info-IMEI.

   13.  QoS-Final-Unit-Indication AVP: grouped AVP which may contains
        privacy-sensitive information in its sub-AVPs (e.g IPFilterRule,
        redirect address).

   Note that some AVPs which are used in this document are defined in
   [RFC6733] and may contain privacy-sensitive information.  These AVPs
   are not listed above.

15.2.  Data Minimization

   Due to the nature of the credit control application, some personal
   data and identity information must be stored in both credit-control
   client and credit control server.  This, however, could be minimized
   by following these guidelines:

   1.  Data stored in the credit-control client does not need to be
       persisted across sessions.  All data could be deleted once the
       session end, and reconstructed once a new session is initialized.
       Note that, while the credit-control server is usually owned by
       the service provider with which the subscriber already has some
       direct legal or business relationship (where privacy level could
       be agreed upon), this is not always true for the credit-control
       client, that may be owned by a third-party.

   2.  Some information about the subscriber has to be stored in
       persistent storage in the credit-control server (e.g. identity,
       balance), however, per transaction information does not have to
       be stored in persistent storage, and per session information may
       be deleted from persistent storage once the session ends.

   3.  In some cases, per transaction information has to be stored on
       the credit-control server, client, or both, for regulatory,
       auditability or debugging reasons.  However, this could be
       minimized by following these guidelines:

       A.  Data retention SHOULD NOT exceed the required durations

       B.  Transaction information SHOULD be aggregated as much as
           possible.  E.g.  prefer information per sessions vs.
           information per rating-group; prefer hourly byte summary vs.
           per transaction byte counts.

       C.  If not strictly needed, the more sensitive information (E.g.
           location, equipment type) SHOULD be filtered out from such
           logs.  Such information is often used to make rating
           decisions, and in this case, the rating decision should be
           logged instead of the data used to make them

       D.  The credit-control server SHOULD be preferred over the
           credit-control client as the place where per transaction
           information is stored, if needed.  This is due to the reasons
           explained in 1.

15.3.  Diameter Agents

   Diameter agents, as described in [RFC6733], may be owned by third-
   parties.  To prevent from privacy sensitive information from leaking
   into them, it is RECOMMENDED to encrypt AVPs holding such
   information, as listed in Section 15.1.

   In some cases, the Diameter agent requires access into privacy-
   sensitive AVPs, in order to take correct routing decisions, or even
   modify the content of these AVPs.  In such a case it is RECOMMENDED
   to anonymize the identity of the subscriber, and encrypt any other
   AVP not used by the agent and can be used to identify the subscriber.


 

    On Wednesday, February 14, 2018, 7:12:49 PM GMT+2, Ben Campbell <[e-mail]> wrote:  
 
 Even if we add privacy considerations to the base protocol, I think 4006bis would still need privacy considerations that discuss the specific AVPs it defines. So I would go ahead and add considerations to 4006bis and avoid the delay. The WG can discuss whether it would like to add more general considerations to the base protocol (either in a bis draft or an update).

Thanks!

Ben.

> On Feb 14, 2018, at 11:06 AM, Yuval Lifshitz <[e-mail]> wrote:
> 
> Regarding "privacy considerations". Note that the base protocol RFC does not have that.
> Ideally, this is added to base Diameter first, as many of the sensitive AVPs come from there.
> Should we try to tackle that first (though this would delay the RFC4006bis process)?
> Should we cover only 4006 AVPs and issues?
> 
> Best Regards,
> 
> Yuval
> 
> 
> On Wednesday, February 14, 2018, 5:56:52 PM GMT+2, Yuval Lifshitz <[e-mail]> wrote:
> 
> 
> Ben,
> First, thanks for the comments!
> 
> Regarding the major comment, agree this should be added, it was already agreed in the meeting we had in IETF96, but somehow slipped :-(
> 
> Sections 12: all the AVPs mentioned in this section exists in RFC4006, and has values that are already registered. As part of RFC4006bis we did not add any AVP that requires values enumeration (this was actually one of the issue we tried to tackle). What would you like to see different in this section?
> What is the process for updating IANA with the references to the new doc? Can this happen before RFC4006bis is officially accepted?
> 
> Appendix B: the new AVPs do not impact the flows, therefore not added to the sample flows
> 
> 8.34 agree, this is pretty bad. How about:
> If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT
>    and the classification of the restricted traffic cannot be expressed
>    using IPFilterRule, or different actions (e.g., QoS) than just
>    allowing traffic needs to be enforced, then the QoS-Final-Unit-
>    Indication AVP SHOULD be used instead of the Final-Unit-Indication
>    AVP.
> 
> 
> 14. agree we should simplify as you suggested
> 
> Best Regards,
> 
> Yuval
> On Tuesday, February 13, 2018, 1:33:22 AM GMT+2, Ben Campbell <[e-mail]> wrote:
> 
> 
> Hi,
> 
> This is my AD Evaluation of draft-ietf-dime-rfc4006bis-06. Thanks for the work on this; it’s overall a good update. However, I have one major comment and a few minor or editorial comments. I’d like to discuss the major comment prior IETF last call. The rest can be handled along with any last call feedback.
> 
> Note that for all but the major comment, I mostly reviewed the diff from RFC 4006.
> 
> Thanks!
> 
> Ben.
> 
> —————————————
> 
> Major Comment:
> 
> I strongly suggest that you add more privacy considerations. I realize that it inherits its existing privacy considerations from RFC 4006, but that was published in 2005. The IETF’s focus on privacy has evolved considerably since then, and I think this draft will get objections during IESG review without adding some more.
> 
> I suggest the following:
> — Create a “Privacy Considerations” section separate from the security considerations.
> — Enumerate the AVPs that you think contain user identifiable information, persistent identifiers, or other privacy sensitive data.
> — Make some non-normative recommendations concerning data minimization. That is, add a few sentences recommending that clients and servers avoid capturing and/or log personal information beyond that needed for the application's purpose.
> 
> Minor Comments:
> 
> -Section 12 and subsections: Please clarify that many of these elements were already registered by RF 4006, and are not being “re-registered” here. ( It’s perfectly okay to pull the registration information forward into the bis draft; it just needs clarification.) Also, please consider wether existing registrations should be updated to point to this document rather than 4006.
> 
> Appendices: Would any of the example flows benefit from including one or more of the new AVPs?
> 
> Editorial and Nits:
> 
> -Section 8.34: “ If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT
> and the classification of the restricted traffic cannot be expressed
> using IPFilterRule, or different actions (e.g., QoS) than just
> allowing QoS needs to be enforced traffic, … “
> 
> I have trouble parsing the sentence.
> 
> -14: "Even without any modification to the messages, an adversary can
>  invite a security threat by eavesdropping, as the transactions contain private information about the user.
> ”
> I suggest “ … an adversary can eavesdrop on transactions that contain privacy-sensitive imformation”
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime