Subject: [I2nsf] What are the security issues for China Moble's draft-qi-i2nsf-access-network-usecase-00

From: Linda Dunbar <[email-masked]>
Date: Fri, 14 Nov 2014 18:03:46 +0000

Lars,

When China Mobile's MinPeng was presenting their use cases (draft-qi-i2nsf-access-network-usecase-00), you spoke at the microphone about security concerns.

I try to understand a little bit more. Their use cases are about services that operators can offer (which are made relatively easy by having  virtualized security functions)  to  clients (or UEs) who don't  own, and don't mind letting their operator manage their security functions, like firewalls,  AntiVirus, Anti-spam, Junk mail filter, etc.

For sophisticated clients, who own and manage their own devices, they don't have to subscribe those services.

Can you elaborate more of the security concerns?

Linda

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 17 Nov 2014 16:01:28 -0800

I can't speak directly to Lars' concerns, but I think there are several
security concerns associated with what was described.

For example with the provisioning mentioned, what is the scope of the
information provisioned?  How does the user control what is provisioned?

Also, what control is available over what service the user selects?   Is
the user forced to send all of their traffic to these additional inspection
and protection services or can they be more selective.   Does the user
realize that the junk mail filter possibly gives a third party complete
control over their email?

Cheers,

Joe

On Fri, Nov 14, 2014 at 10:03 AM, Linda Dunbar <[email-masked]>
wrote:

>  Lars,
>
>
>
> When China Mobile’s MinPeng was presenting their use cases
> (draft-qi-i2nsf-access-network-usecase-00), you spoke at the microphone
> about security concerns.
>
>
>
> I try to understand a little bit more. Their use cases are about services
> that operators can offer (which are made relatively easy by having
>  virtualized security functions)  to  clients (or UEs) who don’t  own, and
> don’t mind letting their operator manage their security functions, like
> firewalls,  AntiVirus, Anti-spam, Junk mail filter, etc.
>
>
>
> For sophisticated clients, who own and manage their own devices, they
> don’t have to subscribe those services.
>
>
>
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>

---

From: "Minpeng Qi" <[email-masked]>
Date: Wed, 19 Nov 2014 13:41:00 +0800

Hi Joe,

Before to clarify the details, I would like to build up some basic assumptions:

In the assumption that clients TRUST their operator can make correct behavior that ONLY operators is authorized to do. Under this assumption, everything goes well. Clients could authorize network through negotiation. Negotiation means network have no force to client doing anything and clients could choose any . And network could provide authorized service only for clients. For example, if network could provide junk mail filter service, firewall filter service, Anti-spam message services. It could send a list to client to show what it can provide, then client can choose 0~N services it want to use. Of course there is some pre-defined rules of which detailed authorization the services needs and clients can get it through public or through a notification. As a result, client will give authorization explicitly to the network for operation their data.

On the contrary, if the clients DOESN”T TRUST their operator, they can simply say “no” when the network negotiate with clients. Although network usually will provide no such security service and do nothing to clients’ data, if clients still suspect network would do something unauthorized, then personal security protection like encryption could be applied by themselves. 

So the basic thing here is, whether client trust operator or not. If clients trust network, they could enjoy the service provided by network. If not, then there still have many solutions to protect their privacy.

BRs,

Minpeng

发件人: Joseph Salowey [mailto:[email-masked]] 
发送时间: 2014年11月18日 8:01
收件人: Linda Dunbar
抄送: [email-masked]; [email-masked]; Minpeng Qi
主题: Re: [I2nsf] What are the security issues for China Moble's draft-qi-i2nsf-access-network-usecase-00

I can't speak directly to Lars' concerns, but I think there are several security concerns associated with what was described.  

For example with the provisioning mentioned, what is the scope of the information provisioned?  How does the user control what is provisioned?

Also, what control is available over what service the user selects?   Is the user forced to send all of their traffic to these additional inspection and protection services or can they be more selective.   Does the user realize that the junk mail filter possibly gives a third party complete control over their email?  

Cheers,

Joe

On Fri, Nov 14, 2014 at 10:03 AM, Linda Dunbar <[email-masked]> wrote:

Lars, 

When China Mobile’s MinPeng was presenting their use cases (draft-qi-i2nsf-access-network-usecase-00), you spoke at the microphone about security concerns. 

I try to understand a little bit more. Their use cases are about services that operators can offer (which are made relatively easy by having  virtualized security functions)  to  clients (or UEs) who don’t  own, and don’t mind letting their operator manage their security functions, like firewalls,  AntiVirus, Anti-spam, Junk mail filter, etc. 

For sophisticated clients, who own and manage their own devices, they don’t have to subscribe those services. 

Linda

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 20 Nov 2014 11:06:58 -0800

On Tue, Nov 18, 2014 at 9:41 PM, Minpeng Qi <[email-masked]>
wrote:

> In the assumption that clients TRUST their operator can make correct
> behavior that ONLY operators is authorized to do. Under this assumption,
> everything goes well. Clients could authorize network through negotiation.
> Negotiation means network have no force to client doing anything and
> clients could choose any . And network could provide authorized service
> only for clients. For example, if network could provide junk mail filter
> service, firewall filter service, Anti-spam message services. It could send
> a list to client to show what it can provide, then client can choose 0~N
> services it want to use. Of course there is some pre-defined rules of which
> detailed authorization the services needs and clients can get it through
> public or through a notification. As a result, client will give
> authorization explicitly to the network for operation their data.
>
>
>
On the contrary, if the clients DOESN”T TRUST their operator, they can
> simply say “no” when the network negotiate with clients. Although network
> usually will provide no such security service and do nothing to clients’
> data, if clients still suspect network would do something unauthorized,
> then personal security protection like encryption could be applied by
> themselves.
>
>
>
> So the basic thing here is, whether client trust operator or not. If
> clients trust network, they could enjoy the service provided by network. If
> not, then there still have many solutions to protect their privacy.
>
>
>

[Joe] I think this is an over simplification.  Trust should not be an all
or nothing concept.  I may trust my provider for some things and not
others.  I may trust my provider to firewall the ports I ask them to and
not to firewall the ports I do not ask for.    In addition, there are often
implicit trust assumptions that are made that may not be obvious or
controllable.  For example, it could mean that trusting someone to filter
spam mail might require that I trust them with the password to the mail
account and access to services registered to that email address.

I don't think it is a good solution where the only option is for the client
to have complete trust in the operator.

>
>
> BRs,
>
> Minpeng
>
>
>
> *发件人:* Joseph Salowey [mailto:[email-masked] <[email-masked]>]
> *发送时间:* 2014年11月18日 8:01
> *收件人:* Linda Dunbar
> *抄送:* [email-masked]; [email-masked]; Minpeng Qi
> *主题:* Re: [I2nsf] What are the security issues for China Moble's
> draft-qi-i2nsf-access-network-usecase-00
>
>
>
>  virtualized security functions)  to  clients (or UEs) who don’t  own,
> and don’t mind letting their operator manage their security functions,
> like firewalls,  AntiVirus, Anti-spam, Junk mail filter, etc.
>
>
>

---

From: "Minpeng Qi" <[email-masked]>
Date: Sat, 22 Nov 2014 18:20:20 +0800

Hi Joe,

Thanks for your detailed clarification. Pls see my reply inline. I copy it as following:

[Joe] I think this is an over simplification.  Trust should not be an all or nothing concept. I may trust my provider for some things and not others.  I may trust my provider to firewall the ports I ask them to and not to firewall the ports I do not ask for. 

//Minpeng: I agree it should not be an all or nothing concept. Of course you can have different position facing different services. That’s true. And it is in line with the example: if you trust your provider, then you can let them do everything for you. If you trust some services provided like firewall except others then you can only accept firewall services. Furthermore, if you are not trust entire firewall service but only some port open, you can only agree your provider to open such port open. That’s why network provide options rather than mandatory solutions. All conclusion should be based on the NEGOTIATION between client and network. The result relies on not network only, or not client only neither, but both.

[Joe] In addition, there are often implicit trust assumptions that are made that may not be obvious or controllable.  For example, it could mean that trusting someone to filter spam mail might require that I trust them with the password to the mail account and access to services registered to that email address.  

//Minpeng: Choose flying high, choose wind and rain. You always need some extent of trust to 3rd party who works for you. However, the implicit trust assumption could be avoid.

With your example, there are several different ways for the client not to give the password to the network provider. One simplest way is: when the client receive their mail in plain text if he doesn’t care about the leakage at all. The network provider does not need to get keys from client. And another way is to add some lables/tags outside the encrypted context from email provider, which is predefined and agreed involving client. The network provider could filter based on such lables/tags. So handing over the password is not the only choice for client  choosing. Even in the worst assumption, you encrypted email, have no lables/tags, don’t want to trust network provider with password, you still can keep your email in privacy by replying “no” during negotiation procedure. 

In the other aspect, running such service will bring serious cost for provider. So it only could be provided when it is request strongly from clients. And virtualization could effectively reduce unnecessary deployment and consumption, while providing flexible service also. 

In short, clients always have freedom to say “no” to deny what they don’t want, as well as network provider can also provide service to other clients who is really need it.

I don't think it is a good solution where the only option is for the client to have complete trust in the operator.  

//Minpeng: Pls see the first clarification reply. There is no need to have complete trust.

BRs,

Minpeng

发件人: I2nsf [mailto:[email-masked]] 代表 Joseph Salowey
发送时间: 2014年11月21日 3:07
收件人: Minpeng Qi
抄送: [email-masked]; [email-masked]; Linda Dunbar
主题: Re: [I2nsf] 答复: What are the security issues for China Moble's draft-qi-i2nsf-access-network-usecase-00

On Tue, Nov 18, 2014 at 9:41 PM, Minpeng Qi <[email-masked]> wrote:

Hi Joe,

 

[Joe] I think this is an over simplification.  Trust should not be an all or nothing concept.  I may trust my provider for some things and not others.  I may trust my provider to firewall the ports I ask them to and not to firewall the ports I do not ask for.    In addition, there are often implicit trust assumptions that are made that may not be obvious or controllable.  For example, it could mean that trusting someone to filter spam mail might require that I trust them with the password to the mail account and access to services registered to that email address.  

I don't think it is a good solution where the only option is for the client to have complete trust in the operator.  

BRs,

Minpeng

Cheers,

Joe

Lars, 

Linda

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 26 Nov 2014 10:26:37 -0800

On Sat, Nov 22, 2014 at 2:20 AM, Minpeng Qi <[email-masked]>
wrote:

> not to firewall the ports I do not ask for.
>
> //Minpeng: I agree it should not be an all or nothing concept. Of course
> you can have different position facing different services. That’s true. And
> it is in line with the example: if you trust your provider, then you can
> let them do everything for you. If you trust some services provided like
> firewall except others then you can only accept firewall services.
> Furthermore, if you are not trust entire firewall service but only some
> port open, you can only agree your provider to open such port open. That’s
> why network provide *options* rather than *mandatory* *solutions*. All
> conclusion should be based on the NEGOTIATION between client and network.
> The result relies on not network only, or not client only neither, but both.
>
>
>
[Joe] The options described in the presentation are very broad.  More fine
grained authorization and trust may be needed for many of the cases.  I
think it would be best to focus on one of the cases first such as firewall.

> [Joe] In addition, there are often implicit trust assumptions that are
> made that may not be obvious or controllable.  For example, it could mean
> that trusting someone to filter spam mail might require that I trust them
> with the password to the mail account and access to services registered to
> that email address.
>
> //Minpeng: Choose flying high, choose wind and rain. You always need some
> extent of trust to 3rd party who works for you. However, the implicit trust
> assumption could be avoid.
>
> With your example, there are several different ways for the client not to
> give the password to the network provider. One simplest way is: when the
> client receive their mail in plain text if he doesn’t care about the
> leakage at all. The network provider does not need to get keys from client.
> And another way is to add some lables/tags outside the encrypted context
> from email provider, which is predefined and agreed involving client. The
> network provider could filter based on such lables/tags. So handing over
> the password is not the only choice for client  choosing. Even in the worst
> assumption, you encrypted email, have no lables/tags, don’t want to trust
> network provider with password, you still can keep your email in privacy by
> replying “no” during negotiation procedure.
>
> In the other aspect, running such service will bring serious cost for
> provider. So it only could be provided when it is request strongly from
> clients. And virtualization could effectively reduce unnecessary deployment
> and consumption, while providing flexible service also.
>
>
>
> In short, clients always have freedom to say “no” to deny what they don’t
> want, as well as network provider can also provide service to other clients
> who is really need it.
>
>
>

[Joe]   I agree there is implicit trust in your email provider with
cleartext messages. If an entity is not my email provider then providing
access to email gives the entity more access than a user may realize.  If
someone has access to email messages then they effectively have access to
any password and account that were registered using the email address.
These side-effects are not necessarily clear to users and are not
represented in the models presented so far.

> I don't think it is a good solution where the only option is for the
> client to have complete trust in the operator.
>
> *发件人:* I2nsf [mailto:[email-masked]] *代表 *Joseph Salowey
> *发送时间:* 2014年11月21日 3:07
> *收件人:* Minpeng Qi
> *抄送:* [email-masked]; [email-masked]; Linda Dunbar
> *主题:* Re: [I2nsf] 答复: What are the security issues for China Moble's
> I don't think it is a good solution where the only option is for the
> client to have complete trust in the operator.
>
>
>
> BRs,
>
> Minpeng
>
>
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Nov 2014 14:23:33 -0500

Sent from my iPhone

> On Nov 26, 2014, at 1:26 PM, Joseph Salowey <[email-masked]> wrote:
> 
> 
> 
>> On Sat, Nov 22, 2014 at 2:20 AM, Minpeng Qi <[email-masked]> wrote:
>> Hi Joe,
>> 
>>  
>> 
> [Joe] The options described in the presentation are very broad.  More fine grained authorization and trust may be needed for many of the cases.  I think it would be best to focus on one of the cases first such as firewall.
>  

I'll just add that it's easier to describe security controls rather than talking about 'trust'.  For protocol design and security considerations, describing controls is more concrete than using a mushy term like trust.

Thanks,
Kathleen
> [Joe]   I agree there is implicit trust in your email provider with cleartext messages. If an entity is not my email provider then providing access to email gives the entity more access than a user may realize.  If someone has access to email messages then they effectively have access to any password and account that were registered using the email address.   These side-effects are not necessarily clear to users and are not represented in the models presented so far.  
> 
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 26 Nov 2014 22:03:06 +0100

Regarding the use of the term 'trust' I completely agree with Kathleen.
It is almost always better to replace trust with something else. If you
really want to use it then you need to add a few qualifiers, namely WHO
trust WHOM to-do WHAT.

Ciao
Hannes

On 11/26/2014 08:23 PM, Kathleen Moriarty wrote:
> 
> 
> Sent from my iPhone
> 
> On Nov 26, 2014, at 1:26 PM, Joseph Salowey <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>>
>>
>> On Sat, Nov 22, 2014 at 2:20 AM, Minpeng Qi <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     Hi Joe,____
>>
>>     __ __
>>
>>     Thanks for your detailed clarification. Pls see my reply inline. I
>>     copy it as following:____
>>
>>     __ __
>>
>>     [Joe] I think this is an over simplification.  Trust should not be
>>     an all or nothing concept. I may trust my provider for some things
>>     and not others.  I may trust my provider to firewall the ports I
>>     ask them to and not to firewall the ports I do not ask for. ____
>>
>>     //Minpeng: I agree it should not be an all or nothing concept. Of
>>     course you can have different position facing different services.
>>     That’s true. And it is in line with the example: if you trust your
>>     provider, then you can let them do everything for you. If you
>>     trust some services provided like firewall except others then you
>>     can only accept firewall services. Furthermore, if you are not
>>     trust entire firewall service but only some port open, you can
>>     only agree your provider to open such port open. That’s why
>>     network provide *options* rather than *mandatory* *solutions*. All
>>     conclusion should be based on the NEGOTIATION between client and
>>     network. The result relies on not network only, or not client only
>>     neither, but both.____
>>
>>     __ 
>>
>> [Joe] The options described in the presentation are very broad.  More
>> fine grained authorization and trust may be needed for many of the
>> cases.  I think it would be best to focus on one of the cases first
>> such as firewall.
>>  
> 
> I'll just add that it's easier to describe security controls rather than
> talking about 'trust'.  For protocol design and security considerations,
> describing controls is more concrete than using a mushy term like trust.
> 
> Thanks,
> Kathleen
>>
>>     __
>>
>>     [Joe] In addition, there are often implicit trust assumptions that
>>     are made that may not be obvious or controllable.  For example, it
>>     could mean that trusting someone to filter spam mail might require
>>     that I trust them with the password to the mail account and access
>>     to services registered to that email address.  ____
>>
>>     //Minpeng: Choose flying high, choose wind and rain. You always
>>     need some extent of trust to 3rd party who works for you. However,
>>     the implicit trust assumption could be avoid.____
>>
>>     With your example, there are several different ways for the client
>>     not to give the password to the network provider. One simplest way
>>     is: when the client receive their mail in plain text if he doesn’t
>>     care about the leakage at all. The network provider does not need
>>     to get keys from client. And another way is to add some
>>     lables/tags outside the encrypted context from email provider,
>>     which is predefined and agreed involving client. The network
>>     provider could filter based on such lables/tags. So handing over
>>     the password is not the only choice for client  choosing. Even in
>>     the worst assumption, you encrypted email, have no lables/tags,
>>     don’t want to trust network provider with password, you still can
>>     keep your email in privacy by replying “no” during negotiation
>>     procedure. ____
>>
>>     In the other aspect, running such service will bring serious cost
>>     for provider. So it only could be provided when it is request
>>     strongly from clients. And virtualization could effectively reduce
>>     unnecessary deployment and consumption, while providing flexible
>>     service also. ____
>>
>>     __ __
>>
>>     In short, clients always have freedom to say “no” to deny what
>>     they don’t want, as well as network provider can also provide
>>     service to other clients who is really need it.____
>>
>>     __ 
>>
>>
>> cleartext messages. If an entity is not my email provider then
>> providing access to email gives the entity more access than a user may
>> realize.  If someone has access to email messages then they
>> effectively have access to any password and account that were
>> registered using the email address.   These side-effects are not
>> necessarily clear to users and are not represented in the models
>> presented so far.  
>>
>>
>>  
>>
>>     __
>>
>>     I don't think it is a good solution where the only option is for
>>     the client to have complete trust in the operator.  ____
>>
>>     //Minpeng: Pls see the first clarification reply. There is no need
>>     to have complete trust.____
>>
>>     __ __
>>
>>     BRs,____
>>
>>     Minpeng____
>>
>>     __ __
>>
>>     *发件人:*I2nsf [mailto:[email-masked]
>>     <mailto:[email-masked]>] *代表 *Joseph Salowey
>>     *发送时间:*2014年11月21日3:07
>>     *收件人:*Minpeng Qi
>>     *抄送:[email-masked] <mailto:[email-masked]>; [email-masked]
>>     <mailto:[email-masked]>; Linda Dunbar
>>     *主题:*Re: [I2nsf] 答复: What are the security issues for China
>>     Moble's draft-qi-i2nsf-access-network-usecase-00____
>>
>>     __ __
>>
>>     __ __
>>
>>     __ __
>>
>>     On Tue, Nov 18, 2014 at 9:41 PM, Minpeng Qi
>>     <[email-masked] <mailto:[email-masked]>>
>>     wrote:____
>>
>>     Hi Joe,____
>>
>>      ____
>>
>>     Before to clarify the details, I would like to build up some basic
>>     assumptions:____
>>
>>      ____
>>
>>     In the assumption that clients TRUST their operator can make
>>     correct behavior that ONLY operators is authorized to do. Under
>>     this assumption, everything goes well. Clients could authorize
>>     network through negotiation. Negotiation means network have no
>>     force to client doing anything and clients could choose any . And
>>     network could provide authorized service only for clients. For
>>     example, if network could provide junk mail filter service,
>>     firewall filter service, Anti-spam message services. It could send
>>     a list to client to show what it can provide, then client can
>>     choose 0~N services it want to use. Of course there is some
>>     pre-defined rules of which detailed authorization the services
>>     needs and clients can get it through public or through a
>>     notification. As a result, client will give authorization
>>     explicitly to the network for operation their data.____
>>
>>      ____
>>
>>         On the contrary, if the clients DOESN”T TRUST their operator,
>>         they can simply say “no” when the network negotiate with
>>         clients. Although network usually will provide no such
>>         security service and do nothing to clients’ data, if clients
>>         still suspect network would do something unauthorized, then
>>         personal security protection like encryption could be applied
>>         by themselves. ____
>>
>>          ____
>>
>>         So the basic thing here is, whether client trust operator or
>>         not. If clients trust network, they could enjoy the service
>>         provided by network. If not, then there still have many
>>         solutions to protect their privacy.____
>>
>>          ____
>>
>>     __ __
>>
>>     __ __
>>
>>     [Joe] I think this is an over simplification.  Trust should not be
>>     an all or nothing concept.  I may trust my provider for some
>>     things and not others.  I may trust my provider to firewall the
>>     ports I ask them to and not to firewall the ports I do not ask
>>     for.    In addition, there are often implicit trust assumptions
>>     that are made that may not be obvious or controllable.  For
>>     example, it could mean that trusting someone to filter spam mail
>>     might require that I trust them with the password to the mail
>>     account and access to services registered to that email address.  ____
>>
>>     __ __
>>
>>     I don't think it is a good solution where the only option is for
>>     the client to have complete trust in the operator.  ____
>>
>>          ____
>>
>>         BRs,____
>>
>>         Minpeng____
>>
>>          ____
>>
>>         *发件人:*Joseph Salowey [mailto:[email-masked]]
>>         *发送时间:*2014年11月18日8:01
>>         *收件人:*Linda Dunbar
>>         *抄送:[email-masked] <mailto:[email-masked]>;
>>         [email-masked] <mailto:[email-masked]>; Minpeng Qi
>>         *主题:*Re: [I2nsf] What are the security issues for China
>>         Moble's draft-qi-i2nsf-access-network-usecase-00____
>>
>>          ____
>>
>>         I can't speak directly to Lars' concerns, but I think there
>>         are several security concerns associated with what was
>>         described.  ____
>>
>>          ____
>>
>>         For example with the provisioning mentioned, what is the scope
>>         of the information provisioned?  How does the user control
>>         what is provisioned?____
>>
>>          ____
>>
>>         Also, what control is available over what service the user
>>         selects?   Is the user forced to send all of their traffic to
>>         these additional inspection and protection services or can
>>         they be more selective.   Does the user realize that the junk
>>         mail filter possibly gives a third party complete control over
>>         their email?  ____
>>
>>          ____
>>
>>         Cheers,____
>>
>>          ____
>>
>>         Joe____
>>
>>          ____
>>
>>         On Fri, Nov 14, 2014 at 10:03 AM, Linda Dunbar
>>         <[email-masked] <mailto:[email-masked]>>
>>         wrote:____
>>
>>         Lars, ____
>>
>>          ____
>>
>>         (draft-qi-i2nsf-access-network-usecase-00), you spoke at the
>>         microphone about security concerns. ____
>>
>>          ____
>>
>>         I try to understand a little bit more. Their use cases are
>>         about services that operators can offer (which are made
>>         relatively easy by having  virtualized security functions)  to
>>          clients (or UEs) who don’t  own, and don’t mind letting their
>>         operator manage their security functions, like firewalls,
>>          AntiVirus, Anti-spam, Junk mail filter, etc. ____
>>
>>          ____
>>
>>         For sophisticated clients, who own and manage their own
>>         devices, they don’t have to subscribe those services. ____
>>
>>          ____
>>
>>         Can you elaborate more of the security concerns? ____
>>
>>          ____
>>
>>         Linda____
>>
>>          ____
>>
>>          ____
>>
>>          ____
>>
>>
>>         [email-masked] <mailto:[email-masked]>
>>         https://www.ietf.org/mailman/listinfo/i2nsf____
>>
>>          ____
>>
>>     __ __
>>
>>
>> [email-masked] <mailto:[email-masked]>

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Thu, 27 Nov 2014 02:57:59 +0000

Agree. "trust" may cause lots of confusions and should be used very carefully.

> -----Original Message-----
> From: I2nsf [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Thursday, November 27, 2014 5:03 AM
> To: Kathleen Moriarty; Joseph Salowey
> Cc: [email-masked]; [email-masked]; Minpeng Qi; Linda Dunbar
> Subject: Re: [I2nsf] 答复: 答复: What are the security issues for China
> Moble's draft-qi-i2nsf-access-network-usecase-00
> 
> It is almost always better to replace trust with something else. If you really
> want to use it then you need to add a few qualifiers, namely WHO trust WHOM
> to-do WHAT.
> 
> Ciao
> Hannes
> 
> 
> >> On Sat, Nov 22, 2014 at 2:20 AM, Minpeng Qi
> > I'll just add that it's easier to describe security controls rather
> > than talking about 'trust'.  For protocol design and security
> > considerations, describing controls is more concrete than using a mushy term
> like trust.
> >
> > Thanks,
> > Kathleen
> >>
> >>     __
> >>
> >> providing access to email gives the entity more access than a user
> >> may realize.  If someone has access to email messages then they