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

[Misha Zaytsev <[e-mail]>]

Hi Yuval,

Thanks for your answers!

(3) Why Destination-Realm AVP (mandatory for CCR) cannot be used by DRL for
making routing decisions?
In the referred section 2.8.1. RFC6733, I think this is NAS that may try to
parse NAS id to extract a realm value.
In my understanding, when routing DRL should deal only with so called
routing AVPs, section 6.7 in RFC6733.

(4) I think you can list both 2 options to cover a privacy aspect.

/Misha



2018-02-27 17:00 GMT+03:00 Yuval Lifshitz <[e-mail]>:

> Hi Misha,
> Thank you very much for the comments!
>
> (1) will fix
>
> (2) "credit-control" is the common form in RFC4006 - will fix in the doc.
> Will use "privacy-sensitive", though I could not find other references to
> this term (not used in RFC6973)
>
> (3) Will add the following text: "
> For example, a relay agent may need to look into the Subscription-Id-NAI
> AVP, in order to extract the realm of the user, and use it to lookup the
> destination to which the request should be routed (see: section 2.8.1 in
> [RFC6733])
> "
>
> (4) will fix the typo.
> Regarding AVP level encryption, this is more complicated. This idea
> existed in RFC3588 (the old diameter base RFC), but removed from
> RFC6733.Actually, section 13.3 (in RFC6733) deals with security-sensitive
> AVPs, and recommend end2end encryption (At message level) as well as
> avoiding agents, or making sure that the agents are trusted and don't
> create a security issue. Given the privacy guidelines in RFC6973, this is
> not sufficient, as security and privacy are two different things.
> There was an effort to reintroduce that here:
> https://tools.ietf.org/html/draft-korhonen-dime-e2e-security-03 but seems
> like this did not materialized into a formal specification.
>
> So, I see 2 options here:
> * Use the security guidelines for privacy. This would mean that privacy is
> going to be compromised unless the agent is managed by the same entity as
> the credit-control server
> * Recommend AVP level encryption and mention that the actual mechanism is
> outside the scope of the diameter RFC
>
> Unrelated question to the group - do you think it is worthwhile to revive
> the end2end security work? Do you know why was it abandoned?
>
> Yuval
>
> On Tuesday, February 27, 2018, 12:36:45 PM GMT+2, Misha Zaytsev <
> [e-mail]> wrote:
>
>
> Hi Yuval,
>
> Just firstly some editorial comments + questions:
>
> 1. 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 *exist*, and only authorized
>    entities have access to the privacy-sensitive information.
>
> 2. Let's use one form of writing: either "credit-control" or "credit control". The same is related to "privacy-sensitive" and "privacy sensitive"
>
> 3. What are privacy-sensitive AVPs used for making routing decisions meant here? Please list some of them.
>
> 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.
>
> 4. What do you mean under "encrypt AVPs"? Encryption is not part of
> Diameter functions... Could you elaborate your idea?
>
> To prevent *from (typo?)* privacy sensitive information from leaking
>    into them, it is RECOMMENDED to encrypt AVPs holding such
>    information, as listed in Section 15.1
>
> Thanks in advance!
>
> /Misha
>
>
> 2018-02-26 10:14 GMT+03:00 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
> <https://www.ietf.org/mailman/listinfo/dime>
>
> ______________________________ _________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/ listinfo/dime
> <https://www.ietf.org/mailman/listinfo/dime>
>
>
>