Use case and service protection requirements: a start.

[Moberg Dale <dmoberg@axway.com>]

Sander has suggested that our Tc begin to organize the requirements needed to cover the use case presentations by  Susanne Wigard, Roger Bass, Pim van der Eijk, and me.

 

It is convenient to view the functional use cases as based on a core of “cloud” or intermediary services. For PEPPOL and Codex, the services are those pertaining to data exchange that involve cloud/intermediaries. One basic service needed for this interaction pattern is what I will call “application layer routing.”

 

Most often we think of routing as a network layer problem, involving IP addresses of two hosts, and the decisions made by routers and other network devices about where to forward IP packets. But at higher (application) layers, routing is also needed between a sequence of hosts that use a sequence of steps, each step dropping to the network layer to exchange data.

 

The application layer routing ends with an IP address but can start with any number of different kinds of metadata about recipients, senders, business action types, etc. If a hostname is available for the next step, then DNS address (A) records yield the IP address. But if an email address is the application level starting point, then the steps may involve DNS retrieval of a MX record, followed by retrieval of an A record. And for more structured information in URLs, some processing to find the hostname precedes the DNS processing. It is, however, reasonable to require that the lookup of an address of the next application level transfer step, make use of DNS records in some IETF defined manner. (Or, if none prove suitable, start up a BOF at IETF to see whether there is wider interest in some addition! But I don’t think this will be necessary.)

 

In the 4-corner process of PEPPOL, the upper layers make use of  services (SMP) to find the 3^rd endpoint (URL) information. But prior to this, another service (SML) is used to locate and then query a  metadata service (SMP) for the endpoint information of the 3^rd corner. Services like SML are generically called “service discovery services”, and the service to be discovered provides the start of an answer to the original application layer routing problem. (Of course, after finding the endpoint, the hostname needs to be extracted, DNS consulted, and a protocol server (HTTP or HTTPS, for example) contacted.)

 

My interest has been in asking that the specifications and designs that BDXR produces be compatible with “protected” data exchange services. More specifically, the security protection requirements for services based on HTTP based protocols must minimally be that:

 

1.       The service be identifiable as “on” the remote host that our discovery process has found.

2.       That the service be capable of protecting itself from unauthorized access.

3.       That data confidentiality be possible for both queries and responses.

 

There may be additional security requirements, but these seem pretty much standard for “important” interactions. Needs 1 and 3 are commonly met using SSL/TLS in the HTTPS protocol. Need 2 is met by authorization, and within HTTP protocols,  using an Authorization header containing credentials such as a username and a password is one mechanism that should be available.  Authorization then presupposes that there has been a registration process at some point that has aligned the service consumer with the service provider on the credentials that are to be used.

 

The identification of the server likewise presupposes a prior registration process, of course. In this case, the server needs to have registered to get a domain name. Additionally the server needs an X.509 certificate with a domain hostname (or wildcard) present, and the client needs to be able to verify that the host’s certificate is found in a chain of signatures to a client-trusted anchor point.  Trust anchors have traditionally been part of PKI, but are on the verge of moving, for TLS, to be part of the DNS infrastructure also.

 

The direction for generalizing the PEPPOL service discovery service is found in a set of IETF RFC specifications numbered 3401 to 3405 on the “Dynamic Delegation Discovery Service.”  Also potentially relevant are RFC 3958 on Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service [DDDS] and RFC 4848 on Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service [DDDS]. In particular, the “metadata” service URLs can be retrieved from DNS.

 

The URL scheme found in DDDS can be for a protected service (using HTTPS, for example) and both the path and the query parameters can be adjusted to fit various metadata-service-defined query formats. Covering organizations/persons not having a registered domain, but having an email address, has been suggested as an additional requirement emerging from Roger’s use case. Detailed design options for these cases can be developed, as well as others that might use a telephony based identifier DNS query string.

 

Pim has also asked whether a CPP URN can be made the basis for discovery of the metadata service’s endpoint URL. And the DDDS is capable of supporting this resolution, and there even exists some defined internet infrastructure in the urn.arpa or uri.arpa domains that might be leveraged. OASIS has registered itself as a namespace identifier for URNs; that is, with syntax “urn:” <nid>”:” <nss>, urn:oasis:<nss> is eligible for registration.  However, while there is a BCP (best current practice) document for urn resolution, some other alternative ways to discover a metadata service url for a given organization/person can be investigated.

 

I think that the above summarizes some of the requirements pertaining service discovery services, metadata services, and protected services that have been introduced this far.

 

Registration services will also have requirements, and protection of these services needs to be considered IMO. At this point,  some discussion of “who” will run these services, and “how” they will verify registrations as legitimate would be useful before exploring detailed designs.