Re: [802.21] Security SG: Definition of Administrative Domain
Gabor,
On Mon, Dec 10, 2007 at 08:10:23PM -0600, Gabor.Bajko@nokia.com wrote:
> Yoshi,
>
> I may be paranoic, but this is not true when I am one of the end
> systems:
>
> Yoshi wrote:
> > If my computer is attached in my corporate network, then I can trust
> other computers including servers and other employee's computers in the
> corporate network to run some applications (Windows file-share, VoIP,
> etc.) on them. In a large-scale enterprise network, the trust may be
> hierarchically formed, but that is also covered in the definition.
>
> In an enterprise network, there is policy, but there should not be any
> trust. Policy may be enforced, trust can not be.
I agree that trust is not something that is enforced.
> On the other hand, what is an end system? Is my laptop with an HSPA card
> an end system?
Yes.
> If so I am not part of the domain, as I certainly do not
> trust the other subscribers of the same cellular carrier of which my
> laptop became part when I inserted the HSPA card into.
That's also fine. In this case, your laptop and your carrier's
infrastructure would form one administrative domain, effectively
excluding (untrusted) end-systems of other subscribers of the same
cellular carrier. Probably the other (N-1) subscribers would do the
same thing, forming N administrative domains that shares the cellular
carrier's infrastructure. For each subscriber, only it's
administrative domain matters and other (N-1) administrative domains
would not matter.
> Trust is always between an end system and the authority. Intermediate
> Systems are opaque to end systems, they are only trusted by the
> authorities as separate agreements exist between them (a 3 party key
> distribution would change that, but we do not have it yet).
So once your laptop with an HSPA card is connected to your cellular
carrier's network, you still don't trust the cellular carrier's base
stations to function as base stations to carry your data? Certainly
you do. End-systems need to trust not just the authority but also
intermediate systems in the same administrative domain in order to
operate, even if the intermediate systems are transparent to the
end-systems.
>
> I do not have a better definition, but I think the definition should
> make it clear that trust only exists between end systems and authorities
> and authorities and intermediaries. No other trust is necessary to build
> an administrative domain.
Please see my comment above.
> And trust can only be inherited within a very limited scope: if B and C
> both trust A, that does not mean that B and C trust each other. In a
> cellular network the fact that users B and C trust the carrier means,
> that when B calls C, it can be certain that it is C's phone's ringing,
> not someone else's. Thus trust has a very limited scope.
I agree, but the current definition of administrative domain can work
for this case, as I explained above using N administrative domains.
BTW, if HOKEY WG comes up with clear definition of domain that is more
useful for our study than administrative domain, we can certainly
revisit the definition. Until then it is safer to reuse existing
definition in RFC1136, IMO.
Regards,
Yoshihihro Ohba
>
> - gabor
>
>
> >
> > Even if we clarify the definition in this respect, I will hardly be
> > able to map this abstract definition to the use cases discussed in .21
>
> > security SG.
>
> To use the definition for our use cases, if an MN belonging to a
> particular administrative domain attaches to a PoA of the same
> administrative domain, there will be authentication and authorization
> signaling within the administrative domain, but is no external signaling
> with other administrative domains. On the other hand, if the MN first
> attaches to a PoA in a visited administrative domain, then the PoA's
> administrative domain is suspicious about the MN, and thus external
> authentication and authorization signaling with the MN's administrative
> domain will happen to create a mutual trust between the MN and the
> visited administrative domain so that MN can be part of the visited
> administrative domain.
>
> Regards,
> Yoshihiro Ohba
>
>
>
>
>
> >
> > - gabor
> >
> > -----Original Message-----
> > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> > Sent: Monday, December 10, 2007 11:02 AM
> > To: Bajko Gabor (Nokia-SIR/MtView)
> > Cc: yohba@tari.toshiba.com; STDS-802-21@LISTSERV.IEEE.ORG
> > Subject: Re: [802.21] Security SG: Definition of Administrative Domain
> >
> > Hi Gabor,
> >
> > If my understanding is correct, HOKEY WG is trying to define their
> > notion of domain because they define a domain-specific root key (DSRK)
>
> > and they need to have a clear definition on what "domain" is in term
> > of DSRK.
> >
> > Since we (802.21 Security SG) are not defining DSRK, we don't need to
> > define a key management domain at least in the course of "study", and
> > a more general term "administrative domain" would be sufficient, IMO.
> >
> > Also, end systems in the same administrative domain are assumed to
> > interoperate with mutual trust even if the administrative domain is
> > defined in terms of AAA operation. Otherwise, how a NAS in a AAA
> > realm can trust the authorization result sent by the AAA server in the
>
> > same AAA realm? Note that existence of mutual trust still requires
> > mutual authentication between end systems in the same administrative
> domain.
> >
> > Regards,
> > Yoshihiro Ohba
> >
> >
> > On Mon, Dec 10, 2007 at 11:23:17AM -0600, Gabor.Bajko@nokia.com wrote:
> > > Yoshi,
> > >
> > > Based on the discussions we had in HOKEY last week, I am not sure
> > > this
> >
> > > is a good definition.
> > >
> > > Why would we want to say that end systems are assumed to
> > > interoperate with mutual trust? That is not true today in a AAA
> > > based administrative domain. Besides, we probably should look at the
>
> > > definition of a 'key management domain', rather than an
> > 'administrative domain'.
> > >
> > > It may be easier to find a definition if we scope it down to the
> > > context.
> > >
> > > - gabor
> > >
> > > -----Original Message-----
> > > From: ext Yoshihiro Ohba [mailto:yohba@TARI.TOSHIBA.COM]
> > > Sent: Wednesday, December 05, 2007 6:16 PM
> > > To: STDS-802-21@LISTSERV.IEEE.ORG
> > > Subject: [802.21] Security SG: Definition of Administrative Domain
> > >
> > > We have a home work raised in November meeting to revise the
> > > definition of Administrative Domain (AD).
> > >
> > > RFC 1136 has a good definition of AD. Here is revised definition of
>
> > > AD with borrowing and slightly modifying text in RFC 1136:
> > >
> > > "
> > > Administrative Domain
> > >
> > > A collection of End Systems, Intermediate Systems, and authority.
> > > The components which make up the domain are assumed to
> interoperate
> > > with a significant degree of mutual trust among themselves, but
> > > interoperate with other Administrative Domains in a mutually
> > > suspicious manner.
> > >
> > > Administrative Domains can be organized into a loose hierarchy
> > > that reflects the availability and authoritativeness of
> > > authentication and authorization information. This hierarchy does
> > > not imply administrative containment, nor does it imply a strict
> > > tree topology.
> > > "
> > >
> > > I believe this addresses all issues related to administrative domain
>
> > > definition.
> > >
> > > Comments?
> > >
> > > Yoshihiro Ohba
> > >
> > >
> > >
> >
> >
>
>