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

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 23 Sep 2014 12:09:59 -0700

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-masked]>
To: 	Charles E. Perkins <[email-masked]>, Vijay Devarapalli 
<[email-masked]>, Charles E.Perkins 
<[email-masked]>

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

---

From: <[email-masked]>
Date: Wed, 24 Sep 2014 15:56:04 +0000

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 ☺). 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 ☺

BR,
Pierrick

De : dmm [mailto:[email-masked]] De la part de Charles E. Perkins
Envoyé : mardi 23 septembre 2014 21:10
À : [email-masked]
Objet : [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt

Hello folks,

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-masked]><mailto:[email-masked]>

To:

Charles E. Perkins <[email-masked]><mailto:[email-masked]>, Vijay Devarapalli <[email-masked]><mailto:[email-masked]>, Charles E.Perkins <[email-masked]><mailto:[email-masked]>

IETF repository.

Revision:     00

Pages:        4

Abstract:

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.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 24 Sep 2014 17:48:02 +0000

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-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 24, 2014 8:56 AM
To: "Charles E. Perkins" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt

Hi Charlie,

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 :)). 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 :)

BR,
Pierrick

De : dmm [mailto:[email-masked]] De la part de Charles E. Perkins
Envoyé : mardi 23 septembre 2014 21:10
À : [email-masked]<mailto:[email-masked]>
Objet : [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt

Hello folks,

Regards,
Charlie P.

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:     00

Pages:        4

Abstract:

The IETF Secretariat

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 24 Sep 2014 23:58:42 +0300

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-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> To: "Charles E. Perkins" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> 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-masked]] *De la part de* Charles E. Perkins
> *Envoyé :* mardi 23 septembre 2014 21:10
> *À :* [email-masked] <mailto:[email-masked]>
> *Objet :* [DMM] Fwd: New Version Notification for
> draft-perkins-dmm-4283mnids-00.txt
>
> Hello folks,
>
> *Subject: *
> *Date: *
> *From: *
> <[email-masked]> <mailto:[email-masked]>
>
> *To: *
>
> 	
>
> Charles E. Perkins <[email-masked]>
> <mailto:[email-masked]>, Vijay Devarapalli
> <[email-masked]>
> <mailto:[email-masked]>, Charles
> E.Perkins <[email-masked]> <mailto:[email-masked]>
>
> 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:
>
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: <[email-masked]>
Date: Thu, 25 Sep 2014 08:09:03 +0000

De : Sri Gundavelli (sgundave) [mailto:[email-masked]]
Envoyé : mercredi 24 septembre 2014 19:48
À : SEITE Pierrick IMT/OLN; Charles E. Perkins; [email-masked]
Objet : Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt

Hi Pierrick,

>> I agree, thanks.

Regards
Sri

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 :)). 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 :)

BR,
Pierrick

Hello folks,

Regards,
Charlie P.

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:     00

Pages:        4

Abstract:

The IETF Secretariat

Thank you.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 25 Sep 2014 12:02:20 -0700

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:
> 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
>
> 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. 
> any impact on existing security mechanisms.” It’s maybe not so true 
> from the 3GPP point of view…
>
> 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
>

-- 
Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 25 Sep 2014 14:22:32 -0700

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:
>> 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 
>> privacy / confidentiality service set, when the identifier is based 
>> on some confidential data.
>>
>>
>> Regards
>> Sri
>>
>> 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
>>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 26 Sep 2014 01:40:51 +0000

Hi Charlie,

> Moreover, MNIDs  containing sensitive identifiers might only be used for signaling during initial network entry.

The below text looks good. I assume the "initial entry" below refers to the Authentication phase, where we allow temporary identifiers such as Chargeable user identifier to be used in all PBU/PBA messages. As you are aware, we currently do not have mechanisms to use different MN-Id's one for the initial BU/PBU exchange and a different identifier for the subsequent lifetime updates.

Regards
Sri

From: Charlie Perkins <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 25, 2014 2:22 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: Vijay Devarapalli <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt

Hello again folks,

Regards,
Charlie P.

Hello folks,

Regards,
Charlie P.

Regards
Sri

Hi Charlie,

BR,
Pierrick

Hello folks,

Regards,
Charlie P.

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:     00

Pages:        4

Abstract:

The IETF Secretariat

--
Regards,
Charlie P.

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/dmm