RE: [802.21] Security SG: Definition of Administrative Domain
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.
On the other hand, what is an end system? Is my laptop with an HSPA card
an end system? 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.
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).
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.
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.
- 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
> >
> >
> >
>
>