Re: 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 J). 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 J
>>
>> 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]
> https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm