[ogsa-wg] Minutes of OGSA-WG Security session 2007-05-31

[Alan Sill]

Here are the minutes of OGSA-WG Security call 2007-05-31, 8:00 - 9:00  
am CDT.

Hiro, can you adjust the list of attendees as necessary?

Thanks,
Alan

Minutes of OGSA Security session

Attendees:
Jack
Andrew Grimshaw
Duane Merrill
Mark Morgan
Chris
Alan Sill
Frank Siebenlist
Hugo Mills

Minutes approval
    - Apr. 23: https://forge.gridforum.org/sf/go/doc14410
    - OGF20:   https://forge.gridforum.org/sf/go/doc14473
    - F2F AuthZ: https://forge.gridforum.org/sf/go/doc14536

-- Approved as posted

Action Item review
     *  AI-0409b: Liberty spec statements on EPRs (compatibility or  
intent vs OGSA BSP) should be checked; are these true and is there  
some difference in interpretation that is unresolvable? - Duane will  
do an initial review to be discussed on the April 23 teleconference

-- Duane concludes that the language and policies are not  
inconsistent, but  not wire compatible.  Liberty is not only an EPR  
provider, but also authentication service.  We have not profiled such  
an implementation, but observe that the schemas are different and  
will require different parsing.  At this level, they are not  
compatible as different implementations of a standard might be, but  
are not incompatible in concept.  There is no equivalent to some  
Liberty ideas in terms of use of identity as a client in what we have  
profiled so far.  There is also a difference in semantics that Duane  
regards as a deficiency in that security mechanisms used to transport  
the message-level content are limited to single strings in Liberty  
EPRs.  The different URI components referenced are not as flexible as  
the Secure Addressing profile.

Andrew refers to a mesage sent out March 20 by Duane (he will refresh  
this reference with a new e-mail shortly) and proposes closing this  
action item.  This was agreed.  Note the discussion can be moved to  
the tracker item on this topic.

2) Use case document and profile review

Andrew noted comments made by by Alan regarding discoverability and  
service requirement description features and indicated that these are  
or will be addressed in the OGSA Security Profile 2.0 - Secure  
Addressing document.  He displayed this document, which is on the  
repository, on Glance for discussion.  This covers usage of EPRs that  
are descriptive, and allow the client to know what it needs to do to  
talk to a given service.  The heart of the document is in he  
definition of hte security context in section 4.  The security  
contacts go into the metadata piece in the EPR.  An example is given  
in the document (see XML beginning with  
"<secaddr:SecurityContext>...").  The example given in the document  
describes a service that expects transport-level X.509, as is common  
practice now, followed by message-leel security for some portion of  
the transaction.  In this particular case, it also says how you would  
expect to authenticate.  The "contexts" allow you to define items  
that can be described in later profiles.

 From a process point of view, Andrew wanted to address a few  
comments received so far at this point.  The trackers are the ones in  
GridForge in the OGSA-WG by Hiro for these items (see  
forge.gridforge.org and navigate to OGSA-WG then Trackers to get  
there).  Under "Addressing" there are a couple of specific items that  
need to be dealt with at this point:

   - A comment was made by Hiro that WS-SecurityPolicy has a  
mechanism for describing how to do such descriptions, but not where.   
Andrew responded that this has been slow to converge, and is more  
general than what we are trying to accomplish here.  Progress is  
being made on that front (i.e., SecurityPolicy) and Duane has been  
studying the draft spec, but the intent here is more specific and  
aimed to be quicker.  We may have to redraft the OGSA work once the  
WS-SecurityPolicy work is complete, but it is not clear yet how or  
when.  The syntax of the schemas are likely to be different once the  
OASIS work is complete.  (See www.oasis-open.org for further details  
on this progress -- look for the ws-wx TC public documents.)  Andrew  
proposes an action item to look into this in detail and see if an  
early recast of our work can be made based on the current status of  
Ws-SecurityPolicy.  Alan noted from the Glance session that an use  
case examples document has recently been posted in WS-SX (May 15)  
that may be useful.

   - Another comment was made by Hiro that use of a MUST ought to  
appear in the profile documents for security contexts, i.e. "A  
provider MUST support one of the following..."  No one seems to own  
this comment, which had come up in the face-to-face meeting.  Some  
discussion with Frank followed, in which the necessity to avoid an  
empty security context was pointed out.  Andrew was concerned that  
any specific limitation will necessarily lose some portion or other  
of the community, and he, Alan and Frank agreed that what is  
necessary is for a given community to specify its accepted set of  
authentication mechanisms and be able to discover, advertise and  
select inclusion of services based on conformance with their desired  
set.  Section 4.4 of the Secure Addressing document fives an example  
of such use.

Comments were made at this point that the Secure Addressing profile  
becomes more of a meta-profile when viewed in this context.   
Interoperability is then expected to be provided in the derived  
profiles for particular security authentication mechanisms (TLS, X. 
509, etc.).  Frank pointed out that this introduces another layer,  
and in this sense is not a true profile in and of itself in the sense  
that it could ensure ineroperability, but Duane and Andrew and Alan  
felt that  the existence of this layer is in fact essential for  
ultimate interoperability.  After discussion, this was agreed to and  
the comment was closed as "resolved."

   - Would this make the OGSA BSP and SP secure channel obsolete?   
Andrew believes that it will, once complete.  Both intend to put key  
information into the EPR.  The combination of Secure Addressing and  
specification of the transport (by the Secure Transport document)  
will eventually supply a key set that will supersede BSP and secure  
channel for the reason that the BSP core does not provide all of the  
features described here.

The comment was closed with notations made by Andrew to this effect.

Next call in this series will be on June 18 (Monday) 6 pm Eastern.


Alan Sill, Ph.D
TIGRE Senior Scientist, High Performance Computing Center
Adjunct Professor of Physics
TTU

====================================================================
:  Alan Sill, Texas Tech University  Office: Admin 233, MS 4-1167  :
:  e-mail: Alan.Sill at ttu.edu   ph. 806-742-4350  fax 806-742-4358  :
====================================================================