Subject: [seamoby] RE: [seamoby-context] requirements

From: "Shahrier, Sharif M." <[email-masked]>
Date: Fri, 6 Apr 2001 10:34:44 -0400

Gary,
 
    Thanks for responding. Saw that you were having problems with the
mailins-list -- same here.
 
Pat had some issues with the msec items that he wanted some clarification. I
had sent him a response. I would like to send the comments to you as well.
 
Please get back to us after you've had a chance to read it ....
 
Sharif.
 
---------------------------------------------------------------------
Pat:

This is a slightly revised response to your earlier question. Please
disregard the e-mail I sent earlier. Thanks.

I believe we had agreed that "security" is an important item when
considering the transfer of context from one peer to another -- did we not?

Well, "multicast security" is a natural extention of this.

In any well defined network there will be multicast goups, i.e. a number of
MNs, attached to a single context. Authorized MNs will be allowed to enter
and leave the group at will. Thus, we need to have a security protocol to
handle this case.

Let's choose as an example a multiparty videoconference within a private
corporation. 

In this scanraio, a context is maintained; has to be protected by some
security means, so that only authorized members can add to the group, and
members may freely leave the group.

I refer to this as a "local multiparty privacy".

Now, on top of this security, there is a firewall, preventing outside users
from getting into the company's enterprise network. Suppose that there is an
authorized MN for the multicast group, which is outside the firewall. Thus,
to join the group that MN has to get in through the firewall and
authenticate itself to join the multiparty videoconference. Thus, there are
two levels of security for MNs oustside of the enterprise network. 

Two question: what consitutes a "context transfer" when "multicast groups"
are invloved? 

              what authentication procedures are involved after "context
transfer" when "multicast    groups" are present?

The first question is complicated I don't have an answer to as yet; needs to
be discussion by the group.

The second question is what I am concerned with here wrt requirements.

Thanks. I hope this answers your questions. If you have any other questions
please send me a note otherwise if it is agreed to add a section on theis I
will be glad to provide the text.

Look forward to hearing back .....

Sharif.

----------------------------------------------------------------------------
------------------

Before we agree to even consider adding msec in the I-D, please explain to
me

its relevance in context transfer.

PatC

> Pat,

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, April 04, 2001 2:47 PM
To: 'Shahrier, Sharif M.'
Subject: RE: [seamoby-context] requirements

Thanks Sharif.

-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Wednesday, April 04, 2001 2:12 PM
To: [email-masked]'
Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Shahrier, Sharif M.
Subject: [seamoby-context] requirements

Gary,
 
    I am in agreement with all of these. In addition, I would like you and
the group to consider some additional ones, mostly regarding multicast
security. This is currently not fully exploited even within the fixed
network community in my opinion, thus I was wondering how much importance to
lay on them for mobile networks  at this time. All comments are welcome.

	Multicast Security: Authentication protocol for multicast groups of
MNs that are authorized to access a perticular context set. The protocol
should allow authorized MNs to freely enter and leave the group.

	Multicast Security: Authorized MNs may join or leave a multicast
group, while the "context transfer" is in progress from one entity to
another one. New authentication procedures for authorized MNs to join the
multicast group; removal of MNs from the authentication list during this
process.

	Multicast Security: Sub-sets of the multicast group are authorized
access to specific sub-context within a context. Develop an authentication
protocol to allow this occur in a non-overlapping manner.

	Multicast Security: Like case (2) above, authorized MNs may join or
leave the multicast group for case (3).

	Local Privacy: A set of MNs are authorized access to
context/sub-context within an administrative domain. Authorization &
authentication protocols MUST allow members to be added or deleted from the
set. 

	Higher level security allows MNs outside the administrative domain
to be authenticated and authorized access to the whole or part of the
context.

	Sharif

-----Original Message-----
From: Kenward, Gary [WDLN2:AN10:EXCH] [mailto:[email-masked]]
Sent: Tuesday, April 03, 2001 5:02 PM
To: [email-masked];
[email-masked]
Subject: RE: text for security requirement on CT protocol.

These statements look to me to be good candidates for the requirements 
document, not the problem statement. 

Gayr 

> -----Original Message----- 
> From: Theo Pagtzis [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Friday, March 30, 2001 6:38 PM 
> To: [email-masked] 
> Subject: Re: text for security requirement on CT protocol. 
> 
> 
> Gary/all, 
> 
>   I think that after Allisson's comments it would be better 
> to provide a small section on the 
> actual problem statement, not the appendix, about what MUST 
> be the security considerations. For 
> that purpose allow me to contribute the following text: 
> 
> 
> Security Considerations 
> 
> Context transfer MUST be effected securely between 
> participating entities. Depending on the 
> communication scenario such entities will encompass one or 
> more Access Routers and/or an 
> individual Mobile Node. The dimensions of security are 
> dependent on the type of context 
> transfer communications between the participating entities. 
> 
> The cases that need be considered are: 
> 
> 1. context transfer communications between two peer Access 
> Router entities. 
> 
> 2. context transfer communications between more than two 
> Access Router entities. 
> 
> 3. context transfer communications between a mobile node and 
> an Access Router entity. 
> 
> 
> 
> 1. CT comms between one-to-one AR entities 
> 
> The two AR communicating entities MUST be mutually 
> authenticated prior to context transfer 
> signaling. This is to ensure that the validity of the 
> participating entities and prevent 
> potential man-in-the-middle attacks in subsequent context 
> state transfer. Each authenticating 
> entity MUST be equipped with symmetric or asymmetric keying 
> information that MUST be instigated 
> manually or automaticaly. 
> 
> The AR entities MUST be capable of preventing by appropriate 
> secure mechanisms replay attacks, 
> such as ensuring freshness of context transfer signalling messages. 
> 
> Each AR entity SHOULD be able to provide encryption services 
> over specific feature contexts 
> such as AAA information. Each AR MUST advertise encryption 
> capabilities as well as the 
> supported feature contexts for which encryption services can 
> be offered. 
> 
> Each AR MAY provide out of band PFS capabilities to its 
> communicating entities for the purposes 
> of context state transfer. Such capability if so supported 
> MUST be effected out of band with 
> respect to the communicated context state transfer in either 
> reactive or proactive cases. This 
> is to ensure that potential compromize of a link cannot 
> persist for long periods of time. 
> 
> Each AR SHOULD provide transitive authentication capability 
> by exploiting transitive trust 
> (web of trust) as effected by examples such as PGP. This MAY 
> provide potential speedups in the 
> relevant security function during transfer of context state. 
> 
> 
> 2. CT comms between one-to-many AR entities 
> 
> More than two AR entities communicating for the purposes of 
> context state transfer in a network 
> domain MUST fulfill the requirements of the above case. 
> However, the distribution of keying 
> material, for the purposes of scalability MAY be constrained 
> to an subset or group AR shared 
> secret; this is in favour of scalability issue that may arise 
> from distributions issues of 
> individual AR keying material, depending on the methods of 
> distribution. 
> 
> 3.  CT comms between an AR and an MN entity 
> 
> The MN MUST be informed about from its CURRENT (or NEW) AR 
> entity on the set of context 
> transfer state that is required by the upcoming visiting 
> AR(s). Such information will assist 
> the mobile node to assess the viability of sustaining its 
> connection state within the upcoming 
> visiting domain and as such the accomodating AR. This is 
> particularly important over AAA 
> functions where the mobile node is expected to incur charges 
> as a result of its upcoming 
> movement towards a particular AR (domain). 
> 
> For the purposes of seamlessness the AR SHOULD not be 
> required to await authorization by a 
> mobile node entity for the purposes of effecting transfer of 
> any type of context state. This 
> will be mainly the case for proactive context transfer, where 
> the AR may attempt to provide 
> context state in advance of the mobile node's movement. This 
> important for the purposes of 
> seamless context transfer where any latency may count against 
> the transparent of the mobile 
> node's transition between ARs or domains. 
> 
> The reactive case for context transfer does not present the 
> above issue since the movement of 
> the mobile node towards a particular AR indicates an explicit 
> instruction to the accomodating 
> network that the mobile node accepts the implications of its 
> movement pattern. We assume that 
> the node is also in control of its connection and as such can 
> explicitly refuse accomodation in 
> the visiting network by terminating its connection. 
> 
> With regard to location privacy, the context transfer between 
> two or more ARs SHOULD not 
> provide the current location of the MN iff such function can 
> be supported by the underlying 
> mobility protocol. 
> 
> 
> Theo 
> 
> UCL/ Mobile Systems 
> 
> 
> 
> Michael Thomas wrote: 
> 
> > Madjid, 
> > 
> > I think it would better to not go down the rathole 
> > of how you key a security association (cf AAA reference), 
> > but instead make some definitive statements about: 
> > 
> > o Message Integrity 
> > o Confidentiality 
> > o Authentication 
> > o Authorization 
> > 
> > For the CT protocol. If pressed for what those would 
> > be, I'd say: 
> > 
> > o Message Integrity must be provided for to 
> >   counter insertion/deletion/replacement and 
> >   replay attacks 
> > o Confidentiality must be kept if transfering 
> >   confidential information, or if prefered by the 
> >   mobile node and/or AR 
> > o Authentication: the CT peers must be able to 
> >   mutually authentiate one another 
> > o Authorization: a CT peer must be able to decide 
> >   which pieces of context the other peer is authorized 
> >   to receive. Also: the mobile node must ultimately 
> >   authorize any CT which happens between CT peers 
> >   (explicitly or implicitly). 
> > 
> >   or something along these lines. 
> > 
> >               Mike 
> > 
> > Nakhjiri Madjid-MNAKHJI1 writes: 
> >  > Gary, 
> >  > 
> >  > Yes, please see the following text (revised from A9 in 
> problem statement) 
> >  > 
> >  > Regards, 
> >  > 
> >  > Madjid 
> >  > 
> >  > 
> >  > SubSection - Context Transfer Security Requirements 
> >  > 
> >  >    The mechanisms for establishing trust between the two 
> parties involved 
> >  >    in context transfer in order to transfer context data securely 
> >  >   (as described below) should be provided. 
> >  >    Prior to the process of context transfer, a mutual 
> authentication 
> >  >    Between the CT peers should happen (this could utilize the AAA 
> >  >    Hierarchy, in case AAA admin domains are present). During this 
> >  >    Authentication, the party receiving the context and the party 
> >  >    transmitting the context, each provides proof of legitimacy to 
> >  >    the other side. Data integrity protection should 
> provided, so that 
> >  >    the context information is protected from tampering 
> by a third party. 
> >  >    Encryption of context data might be necessary, in 
> case MH location 
> >  >    privacy and network topology and policy protection 
> are required. 
> >  >    In case security and AAA context are being 
> transferred, the context 
> >  >    Data must be encrypted. 
> >  > 
> >  >    The mobile node could ultimately retain control over 
> whether it moves 
> >  >    or not, and under what conditions it consents to have 
> a network 
> >  >    based move done on its behalf. In particular, the 
> mobile node must 
> >  >    have the ability to veto a move that could happen 
> transparently, but 
> >  >    may result in higher access charges, unexpected 
> service degradation, 
> >  >    loss of privacy, or other policy based exclusions. 
> >  > 
> >  > -----Original Message----- 
> >  > From: Kenward, Gary [WDLN2:AN10:EXCH] 
> [ mailto:[email-masked] <mailto:[email-masked]>
] 
> >  > Sent: Monday, March 26, 2001 4:20 PM 
> >  > To: [email-masked] 
> >  > Subject: Re: some requirements items 
> >  > 
> >  > 
> >  > Obviously, there seems to be a consensus concerning what 
> >  > Allison intended concerning security: that it was a recognized 
> >  > example for the problem statement. 
> >  > However, Sharif is correct in identifying an additional topic 
> >  > for the requirements draft(s): security of the context transfer 
> >  > itself. Definitely worth exploring, as long as we keep to the 
> >  > requirements space for now. 
> >  > Anyone care to volunteer to describe the requirements for 
> >  > "security context transfer" (we should be able to use them 
> >  > in the problem statement as well as in the requirements 
> >  > document). 
> >  > Gary 
> >  > > -----Original Message----- 
> >  > > From: Peter Lei [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> >  > > Sent: Monday, March 26, 2001 4:42 PM 
> >  > > To: [email-masked] 
> >  > > Subject: Re: some requirements items 
> >  > > 
> >  > > 
> >  > > This is not what I got from the teleconference at 
> all...  Rather, 
> >  > > I believe Allison was suggesting that we should use ROHC and 
> >  > > security as examples of things which would benefit from context 
> >  > > transfer, which would then make a clearer case for the problem 
> >  > > statement. (ie. it was not about secure transfer of context). 
> >  > > 
> >  > > --peter 
> >  > > 
> >  > > > Gary, 
> >  > > > 
> >  > > > Based on what the AD said in today's teleconference, 
> security is 
> >  > > > indeed an important issue on context transfer. Thus, 
> whether or not 
> >  > > > we ultimately decide to tranfer the context via a 
> encrypted tunnel, 
> >  > > > secure transfer of the context must be taken seriously. 
> >  > > > 
> >  > > > you are right, we are closing in on a common 
> agreement, and if 
> >  > > > nobody in the team has any objections, I would be 
> glad to look into 
> >  > > > the requirements issues for (a) quality of service, 
> and (b) secure 
> >  > > > transfer on context. 
> >  > > > 
> >  > > > Comments please ........... 
> >  > > > 
> >  > > > Sharif 
> >  > > 
> >  > > 
> >  > > --- 
> >  > > You are currently subscribed to seamoby_context as: 
> >  > > [email-masked] 
> >  > > To unsubscribe send a blank email to 
> >  > > [email-masked] 
> >  > > 
> >  > 
> >  > 
> >  > --- 
> >  > You are currently subscribed to seamoby_context as: [email-masked] 
> >  > To unsubscribe send a blank email to 
> [email-masked] 
> > 
> > --- 
> > You are currently subscribed to seamoby_context as: 
> [email-masked] 
> > To unsubscribe send a blank email to 
> [email-masked] 
> 
> 
> 
> --- 
> You are currently subscribed to seamoby_context as: 
> [email-masked] 
> To unsubscribe send a blank email to 
> [email-masked] 
> 

---
You are currently subscribed to seamoby_context as:
[email-masked]
To unsubscribe send a blank email to
[email-masked]