Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt

["Charles E. Perkins" <[e-mail]>]

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: "[e-mail] <mailto:[e-mail]>" 
> <[e-mail] <mailto:[e-mail]>>
> Date: Wednesday, September 24, 2014 8:56 AM
> To: "Charles E. Perkins" <[e-mail] 
> <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" 
> <[e-mail] <mailto:[e-mail]>>
> 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:[e-mail]] *De la part de* Charles E. Perkins
> *Envoyé :* mardi 23 septembre 2014 21:10
> *À :* [e-mail] <mailto:[e-mail]>
> *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: *
>
> 	
>
> <[e-mail]> <mailto:[e-mail]>
>
> *To: *
>
> 	
>
> Charles E. Perkins <[e-mail]> 
> <mailto:[e-mail]>, Vijay Devarapalli 
> <[e-mail]> 
> <mailto:[e-mail]>, Charles 
> E.Perkins <[e-mail]> <mailto:[e-mail]>
>
> 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.