[ogsa-wg] Proposal to split "Secure channel" profile

[Andreas Savva]

During the review of the "Basic Security Profile - Secure Channel" today
it was pointed out that Section 3.4 (Security Token), Section 4 (SAML
Token Profile 1.0) and Appendix D (Key Information Exchange) are 'more
basic' than the other parts of the profile and that it would be worth
splitting them off in a separate document. Doing so would allow other
future security profiles (e.g., an MLS profile) to use these sections
without creating unnecessary dependencies with the Secure Channel (TLS)
profile.

Therefore the proposal is to separate these sections in an "OGSA Basic
Security Profile" document. This document would expose the claim
required to satisfy the WSRF BP security profile requirements
(http://www.ggf.org/namespaces/2005/07/OGSABasicSecurity-1.0) but would
 have no normative dependency on the WSRF BP.

In addition it was proposed that this profile would have explanatory
text stating that it is defining an 'anonymous channel' (one requiring
no security or authentication for service interaction) and would also
expose the following claim:
http://www.ggf.org/namespaces/2005/11/OGSABasicSecurityProfile-1.0-AnonymousChannel

(This second proposal is optional and is primarily to reduce the number
of security profiles we have to write.)

The "Secure Channel" profile will then reference the "OGSA Basic
Security Profile" and will expose in turn the following conformance claims:
http://www.ggf.org/namespaces/2005/07/OGSABasicSecurity-1.0 (as required
for composition with the WSRF BP)
and
http://www.ggf.org/namespaces/2005/08/OGSABasicSecurityProfile-1.0-SecureChannel

Comments on the list, or please join next Monday's call where this
proposal is scheduled to be discussed.
Andreas

>From the minutes:
>   - 1698: Strictly speaking the features described in section 3.4 and
>     section 4 are orthogonal to the rest of the profile. Tokens, and
>     the key exchange mini-specification would apply to both TLS and
>     MLS.
>     - If this text is left here then the MLS profile would have to
>       depend on this profile; or worse, duplicate the same text.
>     - Frank proposed that if these sections are needed in general then
>       it might be worth deleting these sections from the Secure
>       Channel Profiel and adding them to the WSRF Basic Profile.
>     - Agreed, in principle, to remove the sections from this spec. and
>       discuss how to make them apply to any profile.
>     - Andreas proposed that these sections should be part of a Basic
>       Security Profile and that Profile could then be combined with
>       the WSRF BP or be referenced by the Channel profiles. The Claim
>       URI mechanism defined in the WSRF BP allows multiple Security
>       profiles to be composed with it so there would be no problem
>       with this approach.
>     - Hiro proposed that such a Basic Security Profile could also
>       serve as an 'anonymous' channel profile (one that makes no
>       statements on channel security) and could also solve the problem
>       of having a separate, essentially empty, profile document with
>       no security statements.
>     - Andreas was tasked to write up the proposal for splitting up the
>       Secure Channel Profile and send it to the list to collect
>       feedback from stakeholders not on the call.


-- 
Andreas Savva
Fujitsu Laboratories Ltd