Use cases for names and EPRs Takuya Mori <moritaku@bx.jp.nec.com> NEC Corporation Sep. 22, 2004

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

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

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

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

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

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

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

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