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

And yes we tried to get folks into senses here and allow temporary 
identities.. but no. Our dear telco vendors insisted having IMSI in the 
NAI in the MN-ID.. ;-)

- Jouni (with a flashback to 2008)

9/24/2014 8:48 PM, Sri Gundavelli (sgundave) kirjoitti:
> 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.
>
>
>
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm
>