Oasis Security Services Use Cases And Requirements: Issues List

8 Feb 2001

Purpose

This document catalogs issues with the requirements and use cases for the XML standard derived by the Oasis Security Services Technical Committee.

Introduction

The issues list presented here is a catch-all of issues brought up in response to Use Case and Requirements Draft 1 as well as other issues mentioned on the security-use and security mailing lists, in conference calls, and in other venues.

Each issue is formatted according to the proposal of David Orchard to the general committee:

ISSUE:[Document/Section Abbreviation-Issue Number: Short name]
Issue long description.
Possible resolutions, with optional editor resolution
Decision

The issues are informally grouped according to general areas of concern. For this document, the "Issue Number" is given as "#-##", where the first number is the number of the issue group.

The issues are in varying levels of resolution. Some are stated as questions or placeholders for further investigation. Others are stated as problems with resolutions, and still others have full-blown use case scenarios attached.

Issues

Group 0: Document Format & Strategy

ISSUE:[UC-0-01:MergeUseCases] There are several use case scenarios in the Straw Man 1 that overlap in purpose. For example, there are several single sign-on scenarios. Should these be merged into a single use case, or should the multiplicity of scenarios be preserved?

Possible Resolutions:

  1. Merge similar use case scenarios into a few high-level use cases, illustrated with UML use case diagrams. Preserve the detailed use case scenarios, illustrated with UML interaction diagrams. This allows casual readers to grasp quickly the scope of [OSSML], while keeping details of expected use of [OSSML] in the document for other subcommittees to use.
  2. Merge similar use case scenarios, leave out detailed scenarios.

Group 1: Single Sign-on Push and Pull Variations

ISSUE:[UC-1-01:Shibboleth] Which requirements of the Shibboleth security system for Internet 2 (http://middleware.internet2.edu/shibboleth/index.shtml) are to be included? In particular, how to address the requirements for anonymity and privacy that Shibboleth makes? Should an additional use case scenario explicitly using Shibboleth be added to the use case and requirements document?

ISSUE:[UC-1-02:ThirdParty] Use case scenario 3 (single sign-on, third party) describes a scenario in which a Web user logs in to a particular 3rd-party security provider which returns an authentication reference that can be used to access multiple destination Web sites. Is this different than Use case scenario 1 (single sign-on, pull model)? If not, should it be removed from the use case and requirements document?

ISSUE:[UC-1-03:ThirdPartyDoable] Questions have arisen whether use case scenario 3 is doable with current Web browser technology. An alternative is using a Microsoft Passport-like architecture or scenario. What is the difference? Should this be done?

ISSUE:[UC-1-04:ARundgrenPush] Anders Rundgren has proposed on security-use an alternative to use case scenario 2 (single sign-on, push model). The particular variation is that the source Web site requests an authorization profile for a resource (e.g., the credentials necessary to access the resource) before requesting access. Should this scenario replace the existing use case scenario 2? Should it be made an additional scenario?

The use case would be inserted as follows:
Single Sign-on, Push
	    Model #2
Fig X. Single Sign-on, Push Model #2.
Steps:

  1. Web user authenticates with source Web site.
  2. Web user requests link to destination Web site.
  3. Source Web site request authorization profile for the resource to be accessed (unsigned)
  4. Destination Web site returns authorization profile (signed)
  5. Source Web site requests authorization for Web user to use destination resource from destination Web site (signed)
  6. Destination Web site returns authorization reference to Source Web site (signed)
  7. Source Web site provides user with authorization reference and redirects user to destination Web site.
  8. User requests destination resource from destination Web site, providing authorization reference.
  9. Destination Web site provides resource to Web user.

ISSUE:[UC-1-05:FirstContact] A variation on the single sign on use case that has been proposed is one where the Web user goes directly to the destination Web site without authenticating with a definitive authority first. Should this be added as a use case?

ISSUE:[UC-1-06:Anonymity] What part does anonymity play in [OSSML] conversations? Can assertions be for anonymous parties? What levels of anonymity can be maintained, and how should this be called out in the requirements document? Is an anonymous use case scenario needed, or should it be simply noted as a requirement?

Group 2: B2B Scenario Variations

ISSUE:[UC-2-01:AddAuthzAssertions] Some use cases proposed on the security-use list (but not in the straw man 1 document) use a concept of an "authz assertion." In concept an authz assertion is a statement of policy about a resource, such as that user "evanp" is granted "execute" privileges on file "/usr/bin/emacs." Should this type of assertion be supported in [OSSML]?

Possible Resolutions:

  1. Policy about privileges should be part of [OSSML]. Use cases and/or requirements featuring authz assertions should be added.
  2. Policy about privileges should not be part of the [OSSML] conversation. We should explicitly make this a non-goal.

ISSUE:[UC-2-02:OutsourcedManagement] A use case scenario provided by Hewlett Packard illustrates using [OSSML] enveloped in a CIM/XML request. Should this scenario be included in the use case document?

The use case would be inserted as follows (some editing for clarity):

This scenario shows an enterprise A that has outsourced the management of its network devices to a management service provider B. Management messages are exchanged using CIM/XML over HTTP. (CIM or Common Information Model, is a management standard being developed by the Distributed Management Task Force - http://www.dmtf.org/, an XML DTD for CIM has been defined.)

Suppose the operator, Joe, wants to invoke the StopService method. This will be executed by the XML/CIM agent on the managed device, if authorized.

Outsourced Management
Fig X. Outsourced Management.

Steps:

  1. This [OSSML] assertion has been generated by B's attribute authority (or Policy Decision Point) and confers the role "System Manager for A" to Joe.
  2. The CIM management console generates the XML content and attaches an [OSSML] assertion. The CIM management console signs the request and sends it as an HTTP request.
  3. The request now has to traverse A's firewall or the boundary into A's network. The gateway at this boundary uses its [OSSML] evaluation engine (or Policy Enforcement Point) to verify that this incoming message is allowed. It does this, by verifying the signature and discovering the request is from Joe. Next it uses two assertions to authorize the incoming message: the assertion issued by B's attribute authority that is attached to the message (conferring the role "System Manager for A" on Joe); an assertion issued by A's attribute authority granting "Gateway Access" to any entity that has a valid "System Manager for A" assertion issued by B's attribute authority. Note that the second assertion can be pushed to the gateway (part of its configuration), or retrieved dynamically from a repository (or indeed the issuer) (the last case is shown here).
  4. The request is forwarded by the gateway to the managed device.
  5. The [OSSML] evaluation engine on the managed device needs to determine if a "StopService" request from Joe is allowed. It does this by using two assertions: the "System Manager for A" assertion issued by B's attribute authority; an assertion issued by A's attribute authority granting "Full Management Rights" to any entity with a valid "System Manager for A" assertion issued by B's attribute authority.
  6. The managed device executes the "StopService" method.

ISSUE:[UC-2-03:ASP] A use case scenario provided by Hewlett Packard illustrates using [OSSML] for a secure interaction between an application service provider (ASP) and a client. Should this scenario be included in the use case document?

The use case would be inserted as follows (some editing for clarity):

In this scenario an ASP, A, is providing an application (possible examples could be a word processor or an ERP application) to users in another enterprise, B. A VPN (for example IPSEC) is used to provide a secure end-to-end tunnel between the client and server.

A major difference between this scenario and the outsource management service scenario is that all assertions are "pulled" in this scenario. This means the assertions are not attached to application messages; instead they must be retrieved either directly from the attribute authority, or a repository. For example, once the client has been authenticated, the [OSSML] evaluation engine in the server needs to retrieve the [OSSML] assertions issued by A and B. This will involve making a request to a repository inside B, traversing both A and B's firewall as shown in the diagram. Similarly the [OSSML] engines in the gateway and client will have to retrieve assertions issued by both authorities.

Application Service Provider
Fig X. Application Service Provider.

Steps:

  1. The client authenticates with B's attribute authority.
  2. B's attribute authority provides an authentication assertion that the client is a "valid user."
  3. The client requests an application through A's gateway, providing a reference to the authentication assertion.
  4. The gateway needs to know that incoming packets from a client in B are allowed. It needs an assertion from B's attribute authority that the client is a valid user, and an assertion from A's attribute authority that entities issued "valid user" assertions from B are allowed access. The gateway requests the assertion from B's attribute authority.
  5. B's attribute authority provides the assertion.
  6. The gateway requests an authorization assertion from A's attribute authority.
  7. A's attribute authority provides the authorization assertion.
  8. The gateway forwards the request to the Server.
  9. The server requests the assertion from B's attribute authority.
  10. B's attribute authority provides the assertion.
  11. The server requests an authorization assertion from A's attribute authority.
  12. A's attribute authority provides the authorization assertion.
  13. The server authenticates with A's attribute authority.
  14. A's attribute authority provides a reference to an authentication assertion that the server is an "Approved Application".
  15. The server returns the application to the client.
  16. It is also important that the client check that the application is valid. This avoids problems such as an attacker spoofing the service provider and providing a word processor service that silently emails copies of all documents generated by the client to the attacker. This might be done by the client [OSSML] evaluation engine checking two assertions: one from A granting "Approved Application" status to the server; one from B granting the attribute "execute" to any entity with "Approved Application" status issued by A. The Client requests the authentication assertion from A's attribute authority.
  17. A's attribute authority provides the assertion.
  18. The client requests an authorization assertion from B's attribute authority.
  19. B's attribute authority provides the authorization assertion.

ISSUE:[UC-2-04:HealthCare] A request for a use case focussing on health care and particularly HIPPA has been made in the Security Services TC. Should such a use case scenario be added to the use case document? What are the particulars of HIPPA and how are they different from other use cases?

Group 3: Sessions

ISSUE:[UC-3-01:UserSession] AuthXML includes an entity called a "session" that is not specified by any of the use cases in Straw Man 1. What is a session, and what use case scenarios should be developed to specify the need for sessions and their use?

ISSUE:[UC-3-02:ConversationSession] Is the concept of a session between security authorities separate from the concept of a user session? If so, should use case scenarios or requirements supporting security system sessions be supported?

ISSUE:[UC-3-03:Logout] Should [OSSML] support transfer of information about logout (e.g., a principal intentionally ending a session)? Should a logout use case be added to an existing use case scenario, or should a new scenario about logout be added to the document?

ISSUE:[UC-3-04:StepUpAuthc] "Step-up" authentication is when a receiving party refuses to accept an authentication from an authenticating party and asks for a higher level of authentication. For example, the RP can refuse password authc and require certificate authc. Should [OSSML] support step-up authentication? Should a use case be developed illustrating step-up authc?

ISSUE:[UC-3-05:SessionTimeout] Session timeout is an event that occurs when a security system invalidates a principal's session after a period of inactivity, without action by the principal. Should communication about timeout of sessions be supported by [OSSML]? Should a use case illustrating session timeout be developed?

Group 4: Security Services

ISSUE:[UC-4-01:SecurityService] Should part of the use case document be a definition of a security service? What is a security service and how is it defined?

ISSUE:[UC-4-02:AttributeAuthority] Should a concept of an attribute authority be introduced into the [OSSML] use case document? What part does it play? Should it be added in to an existing use case scenario, or be developed into its own scenario?

ISSUE:[UC-4-03:PrivateKeyHost] A concept taken from S2ML. A user may allow a server to host a private key. A credentials field identifies the server that holds the key. Should this concept be introduced into the [OSSML] use case document? As a requirement? As part of an existing use case scenario, or as its own scenario?

ISSUE:[UC-4-04:SecurityDiscover] UC-1-04:ARundgrenPush describes a single sign-on scenario that would require transfer of authorization data about a resource between security zones. Should a service for security discovery be part of the [OSSML] standard?

Possible Resolutions:

  1. Yes, a service could be provided to send authorization data about a service between security zones. This would require some sort of AuthZ assertions (UC-2-01:AddAuthzAssertions).
  2. No, this extends the scope of [OSSML] too far. AuthZ in [OSSML] should be concerned with AuthZ attributes of a principal, not of resources.

Group 5: AuthC Protocols

ISSUE:[UC-5-01:AuthCProtocol] Straw Man 1 explicitly makes challenge-response authentication a non-goal. Is specifying which types of authc are allowed and what protocols they can use necessary for this document? If so, which types and which protocols?

ISSUE:[UC-5-02:SASL] What relationship does [OSSML] have to SASL (RFC 2222)? SASL (Simple Authentication and Security Layer, http://asg.web.cmu.edu/sasl/) is a way to add authentication to a connection-based protocol. Is there a design model for [OSSML] in SASL? Could [OSSML] augment SASL, or vice-versa?

ISSUE:[UC-5-03:AuthCThrough] All scenarios in Straw Man 1 presume that the user provides authentication credentials (password, certificate, biometric, etc.) to the authenticating system out-of-band. Could and should [OSSML] be used directly for authentication? Or should this be explicitly stated as a non-goal?

Group 6: Protocol Bindings

ISSUE:[UC-6-01:XMLProtocol] Should mention of a SOAP binding in the use case and requirements document be changed to a say "an XML protocol" (lower case, implying generic XML-based protocols)? Or "XML Protocol", the specific W3 RPC-like protocol using XML (http://www.w3.org/2000/xp/)?

Group 7: Enveloping vs. Enveloped

ISSUE:[UC-7-01:Enveloping] [OSSML] data will be transferred with other types of XML data not specific to authc and authz, such as financial transaction data. What should the relationship of the documents be?

Note that of the solutions below, 2. is more useful when the conversation is mostly an [OSSML] conversation, such as for single sign-on. 3. is more useful for conversations that are mostly "other," such as XML-based server-to-server commerce.

Possible Resolutions:

  1. [OSSML] data and other data are sent as separate messages.
  2. Enveloping the other data in an [OSSML] message.
  3. [OSSML] data is enveloped in the other data message type.
  4. Some combination of the above.

Group 8: Intermediaries

ISSUE:[UC-8-01:Intermediaries] The use case scenarios in the S2ML 0.8a specification include one where an intermediary passes an S2ML message from a source party to a destination party. What is the part of intermediaries in an [OSSML] conversation? Can intermediaries add, subtract, or alter data in an [OSSML] message? Should a use case scenario involving a 3rd-party intermediary be included in the use case and requirements document?

Group 9: Privacy

ISSUE:[UC-9-02:PrivacyStatement] Important private data of end users should be shared as needed between peers in an [OSSML] conversation and protected entirely from hostile 3rd parties. In addition, the user should have control over what data is exchanged. How should the requirement be expressed in the use case and requirements document? Should a use case scenario illustrating privacy protection be provided?

ISSUE:[UC-9-01:RuntimePrivacy] Should protecting the privacy of the user be part of the [OSSML] conversation? In other words, should user consent to exchange of data be given at run time, or at the time the user establishes a relationship with a security system?

Group 10: Framework

ISSUE:[UC-10-01:Framework] Should [OSSML] provide a framework that allows delivery of security content negotiated out-of-band. A typical use case is authorization extensions to the core [OSSML] constructs. The contra-position is to rigidly define the constructs without allowing extension.

Possible Resolutions:

  1. Specify only the explicitly allowable content of messages, no framework
  2. Allow full extensibility of message content (verbs and nouns) as well as flexible intermediary processing
  3. Allow full extensibility of message content (verbs and nouns) with rigidly defined intermediary processing.

Group 11: AuthZ Use Case

ISSUE:[UC-11-01:AuthzUseCase] The use case scenarios outlined in straw man 2 include explicitly only authc use cases. Should a use case featuring an authz conversation, such as a policy enforcement point (PEP) querying a policy decision point (PDP) for authorization for a user to execute an action?

The use case would be included as follows:

This use case illustrates an authorization service that provides authorization checks for resource access.

Authorization Service
Fig X. Authorization Service.

Steps:

  1. User authenticates to security system.
  2. Security system provides authentication assertion to user.
  3. User requests resource from application (where the resource can be execution of an action, a file, a database record, etc.), providing authentication assertion.
  4. Application requests a check of permissions from the security server for user to access resource.
  5. Security system decides on user's authorization and provides permission information.
  6. Application provides resource to user.

Group 12: Encryption

ISSUE:[UC-12-01:Encryption] UC-9-02:PrivacyStatement addresses the importance of sharing data only as needed between security zones (from asserting party to relying party). However, it is also important that data not be available to third parties, such as snoopers or untrusted intermediaries.

One possible solution for implementors is to use secure channels between relying party and asserting party. Another is to use encryption, either with a shared secret or with public keys.

Possible Resolutions:

  1. Allow for explicit use of encryption, such as XML Encryption (http://www.w3.org/Encryption/2001/). [OSSML] messages would then be transferred securely on any protocol.
  2. Require transport protocols to support some form of encryption. Examples: S/MIME for MIME, HTTP/S for HTTP.