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
