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

[Yuval Lifshitz <[e-mail]>]

(3) The destination-realm is the realm of the destination-host, not necessarily the realm inside the subscriber's NAI. But anyway, to fix both issues, I suggest an example based on the MCC/MNC chunk of an IMSI with a proxy agent:"
For example, a proxy agent may need to look into the Subscription-Id-IMSI AVP, in order to extract the mobile country and network codes of the user, and use them to lookup the destination to which the request should be routed (see: section 2.8.2 in [RFC6733])
"
    On Wednesday, February 28, 2018, 12:26:28 PM GMT+2, Misha Zaytsev <[e-mail]> wrote:  
 
 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/dr aft-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.1Thanks 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
  
______________________________ _________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/ listinfo/dime