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: "pierrick.se...@orange.com <mailto:pierrick.se...@orange.com>"
<pierrick.se...@orange.com <mailto:pierrick.se...@orange.com>>
Date: Wednesday, September 24, 2014 8:56 AM
To: "Charles E. Perkins" <charl...@computer.org
<mailto:charl...@computer.org>>, "dmm@ietf.org <mailto:dmm@ietf.org>"
<dmm@ietf.org <mailto:dmm@ietf.org>>
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:dmm-boun...@ietf.org] *De la part de* Charles E. Perkins
*Envoyé :* mardi 23 septembre 2014 21:10
*À :* dmm@ietf.org <mailto:dmm@ietf.org>
*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: *
<internet-dra...@ietf.org> <mailto:internet-dra...@ietf.org>
*To: *
Charles E. Perkins <charl...@computer.org>
<mailto:charl...@computer.org>, Vijay Devarapalli
<unknown-email-vijay-devarapa...@ietfa.amsl.com>
<mailto:unknown-email-vijay-devarapa...@ietfa.amsl.com>, Charles
E.Perkins <charl...@computer.org> <mailto:charl...@computer.org>
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
