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

[Ben Campbell <[e-mail]>]

> On Mar 5, 2018, at 2:37 PM, Yuval Lifshitz <[e-mail]> wrote:
> 
> Hi Ben,
> * Will remove the normative language from 15.2 and 15.3
> * "Is there reasonable guidance one could give to not encode personal information in the URL?". The other option is passing the personal info in some out-of-band way, it make the whole thing more complex, but could add that as a point to consider

Well, there’s a difference between constructing a a URL in form of “server/<rnd-number-that-changes-alot>/… vs “server/<user-name>/…”. Both may have privacy issues but the latter seem worse.


> * "Is there reasonable guidance that could be given to avoid putting privacy sensitive info in these?" - not really, the goal of these AVPs is to carry such information if needed by the credit-control server

The text said “depending on how the service-provider uses them”. Can you elaborate on that? It doesn’t need to be details, maybe just a sentence or two.

> 
> On a different note, is there any active work done on Diameter base privacy consideration and end2end/AVP encryption? Should this WG look into that?

There’s been off and on work on e2e encryption. RFC 7966 offers a problem statement and requirements. I don’t think we are likely to find energy in DIME to progress a solution at this time, but I’d love to be proven wrong :-)

> 
> Yuval
> 
> On Friday, March 2, 2018, 5:04:31 AM GMT+2, Ben Campbell <[e-mail]> wrote:
> 
> Hi Yuval,
> 
> Thanks, this looks really good. You’ve done a lot of work here.
> 
> I’m not sure the normative keywords are necessary; I think for something like this it’s better to describe the risks and what people can do about it, but we generally can’t force people to follow that guidance. Also, the added normative requirements in 15.2 and 15.3  are significant new requriements, and may need working group discussion.
> 
> I have a few more comments inline:
> 
> Thanks!
> 
> Ben.
> 
> > On Feb 26, 2018, at 1:14 AM, Yuval Lifshitz <[e-mail]> wrote:
> >
> > 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.
> 
> Is there reasonable guidance one could give to not encode personal information in the URL?
> 
> >
> >    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).
> >
> 
> for both 9 and 10: “… service-provider use it… “ s/use/uses
> 
> Is there reasonable guidance that could be given to avoid putting privacy sensitive info in these?
> 
> >    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.
> 
> I would avoid the above SHOULDs.  Rather, state these in terms of things people _can_ do to improve privacy.
> 
> >
> > 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.
> 
> Do you think people will actually do that? If not, there’s no point in a “RECOMMENDED” level requirement if we know it will be ignored. It would be better to say “… Clients and servers could encrypt AVPs…”
> 
> Also, since we don’t have an e2e crypto standard for Diameter (yet, anyway), it would be hard to do this in an interoperable way. People would have to agree on algorithms, key management, etc. That doesn’t mean we can’t mention it, but it argues against a normative requirement.
> 
> 
> >
> >    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
> 
> > _______________________________________________
> > DiME mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dime