[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: draft-sstc-bindings-model-02.html
draft-sstc-bindings-model-02.html is attached, and also available in the doc repository.. http://www.oasis-open.org/committees/security/docs/draft-sstc-bindings-model-02.html http://www.oasis-open.org/committees/security/docs/draft-sstc-bindings-model-02.pdf This is the version for BobB to use in the overall SSTC draft. thanks, JeffH & PrateekTitle: draft-sstc-bindings-model-02
Oasis Security Services Bindings ModelPrateek MishraChris Ferris Jeff Hodges draft-sstc-bindings-model-02.html 26-Feb-2001 comments to: security-bindings@lists.oasis-open.org This document is an OASIS-Draft and is [largely] in conformance with
relevant OASIS SSTC document standards as described in draft-sstc-doc-guidelines-00.txt.
IntroductionThe purpose of this document is to (1) characterize the scope of work and deliverables for the bindings sub-committee, (2) identify relevant work items and open issues, (3) point to relevant references. It should provide a reasonably complete starting point for the efforts of the binding sub-committee.Definitions/terminology[JeffH: the below list isn't definitive. Many of the terms have found their way into [Glossary]. We need to decide whether we place particular terms in this doc as well as [Glossary], or just in [Glossary]. Also we will need to refine the terminology expressed here and in [Glossary] (the latter being an overall item for SSTC, not just this subcommittee). ]assertion (aka "security assertion"?) authn - authentication authz - authorization business payload - [Chris F: how is this different or distinguished from "message payload" below? JeffH: good question. I pulled this term, and "message payload" from [S2ML] and we need to figure out semantically what was being referred to in that doc, and then name them appropriately (imho).] message payload - [Chris F: how is this different or distinguished from "business payload" above? I pulled this term, and "business payload" from [S2ML] and we need to figure out semantically what was being referred to in that doc, and then name them appropriately (imho).] originating site package == assertions [+ entitlements] + payload ? - [Chris F: do we want to use the term "message" here? JeffH: I agree it's possible that we do (want to use "message" rather than "package") and should discuss it.] payload principal receiving site Relying party root -- "root of the message" (from mime?) scruitinize security package - one or more s2ml documents combined into a single MIME entity. security services subject web service
ScopeOther Oasis Security Services TC subcommittes (e.g. Core Assertions and Protocol) are producing a specification of security assertions and services.The high-level goal of the Bindings subcommittee is to specify how.. (1) security assertions are embedded in or combined with other objects (e.g. files of various types), communicated from site to site over various protocols, and subsequently scrutinized, and, (2) security services defined with SAML as message exchanges (1) and (2) MUST be specified in sufficient detail to yield interoperability when independently implemented. Deliverables
[JeffH:I'm wondering just how distinct this is from the third item below. Perhaps the intent of this item is more: embedding security assertions into other objects (independent of protocols)? cf. S2ML 4.4][Chris F: I see this as being distinct from the actual bindings as it provides the overall guidelines that SHALL or SHOULD be followed when defining a protocol binding] These should include considerations of the case where the assertions are "secret" versus the case when they are "scoped". cf. [S2ML] Assertion BindingsAssertion bindings will be provided for the following standard protocols:(a) HTTP [Section 6.2, S2ML] provides some discussion of a HTTP binding which
is not constrained by the use of web browsers. (b) MIME [Section 6.3 S2ML] (c) SMTP [Open Issue-2: Relationship to (b) above] [JeffH: I seriously wonder if there are any viable use cases for a SMTP binding that aren't addressed by a definition of MIME packaging for security assertions?] [Chris F: note that BEEP,
HTTP and ebXML also leverage or are MIME aware. One could make
the same argument for all of these ;-)] (d) ebXML (e) SOAP/XP (f) BEEP Registration/Profiling Templates[JeffH: the below text is extracted from [BEEP] and [SASL] as boilerplate/example text that will need substantial massaging -- but whose underlying concepts are applicable here.] Registration of a profile for using SAMLThe perspective here is from the specification of some other protocol (e.g., say, ebXML, cXML, OBI, etc.) that is incorporating SAML. From [BEEP]: 5. Registration Templates 5.1 Profile Registration Template When a profile is registered, the following information is supplied: Profile Identification: specify a URI[10] that authoritatively identifies this profile. Message Exchanged during Channel Creation: specify the datatypes that may be exchanged during channel creation. Messages starting one-to-one exchanges: specify the datatypes that may be present when an exchange starts. Messages in positive replies: specify the datatypes that may be present in a positive reply. Messages in negative replies: specify the datatypes that may be present in a negative reply. Messages in one-to-many exchanges: specify the datatypes that may be present in a one-to-many exchange. Message Syntax: specify the syntax of the datatypes exchanged by the profile. Message Semantics: specify the semantics of the datatypes exchanged by the profile. Contact Information: specify the postal and electronic contact information for the author of the profile. 5.2 Feature Registration Template When a feature for the channel management profile is registered, the following information is supplied: Feature Identification: specify a string that identifies this feature. Unless the feature is registered with the IANA, the feature's identification must start with "x-". Feature Semantics: specify the semantics of the feature. Contact Information: specify the postal and electronic contact information for the author of the feature. From [SASL]: 4. Profiling requirements In order to use this specification, a protocol definition must supply the following information: 1. A service name, to be selected from the IANA registry of "service" elements for the GSSAPI host-based service name form [RFC 2078]. 2. A definition of the command to initiate the authentication protocol exchange. This command must have as a parameter the mechanism name being selected by the client. The command SHOULD have an optional parameter giving an initial response. This optional parameter allows the client to avoid a round trip when using a mechanism which is defined to have the client send data first. When this initial response is sent by the client and the selected mechanism is defined to have the server start with an initial challenge, the command fails. See section 5.1 of this document for further information. 3. A definition of the method by which the authentication protocol exchange is carried out, including how the challenges and responses are encoded, how the server indicates completion or failure of the exchange, how the client aborts an exchange, and how the exchange method interacts with any line length limits in the protocol. 4. Identification of the octet where any negotiated security layer starts to take effect, in both directions. 5. A specification of how the authorization identity passed from the client to the server is to be interpreted. Registration of SAML MechanismsThe perspective here is from the specification of some mechanism (e.g., say, some authorization mechanism) that one "plugs into" SAML. For example, the manner in which one may define and register SASL mechanisms. [JeffH: as I recall, whether or not SAML will provide for "plugin" of mechanisms (of whatever sort) into itself proper was a notion that was vigorously debated on a concall or two. The spirit of including this subsection is therefore for present completness' sake.] From [SASL]: 6. Registration procedures Registration of a SASL mechanism is done by filling in the template in section 6.4 and sending it in to iana@isi.edu. IANA has the right to reject obviously bogus registrations, but will perform no review of clams made in the registration form. There is no naming convention for SASL mechanisms; any name that conforms to the syntax of a SASL mechanism name can be registered. While the registration procedures do not require it, authors of SASL mechanisms are encouraged to seek community review and comment whenever that is feasible. Authors may seek community review by posting a specification of their proposed mechanism as an internet- draft. SASL mechanisms intended for widespread use should be standardized through the normal IETF process, when appropriate. 6.1. Comments on SASL mechanism registrations Comments on registered SASL mechanisms should first be sent to the "owner" of the mechanism. Submitters of comments may, after a reasonable attempt to contact the owner, request IANA to attach their comment to the SASL mechanism registration itself. If IANA approves of this the comment will be made accessible in conjunction with the SASL mechanism registration itself. 6.2. Location of Registered SASL Mechanism List SASL mechanism registrations will be posted in the anonymous FTP directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl- mechanisms/" and all registered SASL mechanisms will be listed in the periodically issued "Assigned Numbers" RFC [currently STD 2, RFC 1700]. The SASL mechanism description and other supporting material may also be published as an Informational RFC by sending it to "rfc- editor@isi.edu" (please follow the instructions to RFC authors [RFC 2223]). 6.3. Change Control Once a SASL mechanism registration has been published by IANA, the author may request a change to its definition. The change request follows the same procedure as the registration request. The owner of a SASL mechanism may pass responsibility for the SASL mechanism to another person or agency by informing IANA; this can be done without discussion or review. The IESG may reassign responsibility for a SASL mechanism. The most common case of this will be to enable changes to be made to mechanisms where the author of the registration has died, moved out of contact or is otherwise unable to make changes that are important to the community. SASL mechanism registrations may not be deleted; mechanisms which are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended use" field; such SASL mechanisms will be clearly marked in the lists published by IANA. The IESG is considered to be the owner of all SASL mechanisms which are on the IETF standards track. 6.4. Registration Template To: iana@iana.org Subject: Registration of SASL mechanism X SASL mechanism name: Security considerations: Published specification (optional, recommended): Person & email address to contact for further information: Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) Author/Change controller: (Any other information that the author deems interesting may be added below this line.) Security Assertion-based Authn & Authz Services[Section 7, AuthXML] gives some examples of mapping a security service intoSOAP messages over HTTP. References[AuthXML] AuthXML: A Specification for Authentication Information in XML.http://www.oasis-open.org/committees/security/docs/draft-authxml-v2.pdf [BEEP] The Blocks Extensible Exchange Protocol Core [Glossary] OASIS Security Services TC: Glossary. [S2ML] S2ML: Security Services Markup Language, Version 0.8a, January 8, 2001.
[SASL] Simple Authentication and Security Layer (SASL) [Shib] Shiboleth Overview and Requirements [Straw2] Oasis Security Services Use Cases And Requirements, Straw Man
Draft 2, 9 Feb 2001
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC