Hi Charlie, > Moreover, MNIDs containing sensitive identifiers might only be used for > signaling during initial network entry.
The below text looks good. I assume the "initial entry" below refers to the Authentication phase, where we allow temporary identifiers such as Chargeable user identifier to be used in all PBU/PBA messages. As you are aware, we currently do not have mechanisms to use different MN-Id's one for the initial BU/PBU exchange and a different identifier for the subsequent lifetime updates. Regards Sri From: Charlie Perkins <[email protected]<mailto:[email protected]>> Date: Thursday, September 25, 2014 2:22 PM To: Sri Gundavelli <[email protected]<mailto:[email protected]>> Cc: Vijay Devarapalli <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt Hello again folks, Here is a proposed text for a new paragraph in the Security Considerations: Some identifiers (e.g., IMSI) are considered to be private information. If used in the MNID extension as defined in this document, the packet including the MNID extension should be encrypted so that personal information or trackable identifiers would not be inadvertently disclosed to passive observers. Moreover, MNIDs containing sensitive identifiers might only be used for signaling during initial network entry. Subsequent binding update exchanges would then rely on a temporary identifier allocated during the initial network entry. Comments will be appreciated. Regards, Charlie P. On 9/25/2014 12:02 PM, Charles E. Perkins wrote: Hello folks, I think the best solution for this would be a section in the Security Considerations explaining the need. I will fashion some text for the upcoming revision ....-01.txt Regards, Charlie P. On 9/24/2014 10:48 AM, Sri Gundavelli (sgundave) wrote: Hi Pierrick, The NAI that is used in S2a/S5 procedures is a IMSI-NAI, based on 3GPP TS 23.003. It is sent in PBU/PBA messages. Not sure, if IMSI information is seen as a confidential IE. But, I agree on the need to include some text on how the signaling message can be protected with privacy / confidentiality service set, when the identifier is based on some confidential data. Regards Sri From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Wednesday, September 24, 2014 8:56 AM To: "Charles E. Perkins" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt Hi Charlie, Thanks for the list… it looks good. I’m just wondering about security considerations… Actually, from 3GPP standpoint, security constrains on IMSI and GPRSS/LTE temporary identifiers (P-TMSI, GUTI). AFAIK, IMSI is very rarely sent on the air (maybe only one time at the beginning of the 3GPP authentication process) for security reasons. So, I’m wondering if adding IMSI to the list of IDs, without any warnings, is somehow introducing security weakness to the 3GPP security process. Consequently, I’m not sure about the following statement “This document does not introduce any security mechanisms, and does not have any impact on existing security mechanisms.” It’s maybe not so true from the 3GPP point of view… Maybe we should state that the ID option MUST be used in a way that it does not harm existing security mechanisms (i.e. use the option with caution :)). For example, to address the issue above (maybe there are other examples… I don’t know…), we could state that the IMSI should be transmitted only during first binding update, and not transmitted anymore as long as the association IMSI/HoA/HNP is done…. Or... simpler way to address the issue: if nobody has use-case for transmitting the IMSI, we can simply remove the IMSI from the list :) BR, Pierrick De : dmm [mailto:[email protected]] De la part de Charles E. Perkins Envoyé : mardi 23 septembre 2014 21:10 À : [email protected]<mailto:[email protected]> Objet : [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt Hello folks, We have published a ...-00 version of the MNIDs draft. This is mainly for reference purposes. A new version should be out within a week or so, incorporating the suggestions and comments from people who responded to the earlier suggestion to revisit this work. Regards, Charlie P. -------- Original Message -------- Subject: New Version Notification for draft-perkins-dmm-4283mnids-00.txt Date: Tue, 23 Sep 2014 10:43:12 -0700 From: <[email protected]><mailto:[email protected]> To: Charles E. Perkins <[email protected]><mailto:[email protected]>, Vijay Devarapalli <[email protected]><mailto:[email protected]>, Charles E.Perkins <[email protected]><mailto:[email protected]> A new version of I-D, draft-perkins-dmm-4283mnids-00.txt has been successfully submitted by Charles E. Perkins and posted to the IETF repository. Name: draft-perkins-dmm-4283mnids Revision: 00 Title: MN Identifier Types for RFC 4283 Mobile Node Identifier Option Document date: 2014-09-23 Group: Individual Submission Pages: 4 URL: http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283mnids-00.txt Status: https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnids/ Htmlized: http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00 Abstract: Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- Regards, Charlie P. _______________________________________________ dmm mailing list [email protected]<mailto:[email protected]>https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
