1. Use cases for names and EPRs
Takuya Mori
NEC Corporation
Sep. 22, 2004

2. Objective To introduce a summary on a security issue
To show some use cases in regarding with security
To stimulate to agree on trust model
Sep. 22, 2004

3. What is naming – brief overview
Name Space
Address Space
Name
Name  Address Mapping
Address
Hosting Environment
Name
Name
Address
Name
Naming Authority
Name
Name
Address
Name
Address
Name
Hosting Environment
Name
Name
Abstract
Location Independent (may be…)
Unique Identifier
Unique in a namespace
Key for Security!
Authentication
Authorization (policy enforcement and policy description)
Examples
URI (URN, URL?) / X.500 Name / FQDN (DNS)
Address
Pointer to access point (endpoint)
Location dependent
Binding dependent
Unique in an address space
Endpoint Reference (EPR)
EPRs are assumed to be “addresses” for service endpoints or resources
Sep. 22, 2004

4. Basic Interaction What does “Client A” need?
name: res_b
address: adr_b
key: key_b
Client A
Resource B
name: res_b
address: adr_b
key: key_b
“Resource B” =>
What does “Client A” need?
Name to identify a resource
Address to specify a service endpoint for the named resource
Key to be used for authenticating the named resource
Assumptions in this slides:
A client connects to a resource if client’s policy allow itself to interact with a resource which is idenfified by name, address and key.
A client knows a key for the named resource it wants to connect
Sep. 22, 2004

5. Directory for Looking up Addresses
Directory C
query: address of “res_b”?
name - address
mapping
res_b: adr_b ::
address: adr_b
Connect and authenticate …
Client A
Resource B
name: res_b
address: adr_b
key: key_b
name: res_b
key: key_b
“Resource B” =>
Assumptions
“Client A” knows a name and a key of “Resource B”
“Client A” does not know an address for “Resource B”
“Directory C” maintains name to address mappings of resources and it can reply an address for a specified name to a requester
“Client A” asks “Directory C” an address of “Resource B”
Sep. 22, 2004

6. Possible Security Threats
Directory C
Naming Authority
name - address
Mapping ::
res_b:
adr_b
name:
address: adr_b
key: key_b
res_b
Client A
Resource B
name:
key: key_b
res_b
“Resource B” =>
Hosting Environment
Assumptions
Names and addresses are exchanged and stored in various entities
Possible threats are:
Alterations of names and addresses in storage or during communication
Alterations of name to address mappings
An unauthorized directory returns an unauthorized response about an address for an named resource
Sep. 22, 2004

7. Use Case 2: Trusted Directory Service
Directory C
query: address of “res_b”?
name - address
mapping
res_b: adr_b ::
address: adr_b
Client A
Resource B
name: res_b
address: adr_b
key: key_b
name:
key: key_b
res_b
“Resource B” =>
Assumptions
“Client A” trusts “Directory C” and “Resource B”.
“Client A” only knows a name and a key of “Resource B”.
“Client A” asks “Directory C” an address
“Directory C” replies to “Client A” with an address “adr_b”
“Client A” trusts the address provided by “Directory C”, if the address has good integrity
Sep. 22, 2004

8. Use Case 3: Untrusted Directory Service
Directory C
query: address of “res_b”?
name - address
mapping
res_b: adr_b ::
address: adr_b
Client A
Resource B
name: res_b
address: adr_b
key: key_b
name:
key: key_b
res_b
“Resource B” =>
Assumptions
“Client A” does not trust “Directory C” and “Resource B”.
“Client A” only knows a name and a key of “Resource B”.
“Client A” asks “Directory C” an address
“Directory C” returns an address “res_b” to “Client A”
“Client A” needs to verify that the given address is likely to be an address of “Resource B”.
Because “Client A” does not trust “Directory C”, it cannot trust the address provided by “Directory C”.
Sep. 22, 2004

9. Conclusion
Need more use case analysis to find out more requirements for naming…
Trust model for entities regarding with naming are basic but important
=> First we should agree on it…
Sep. 22, 2004