[ogsa-wg] BES query

[Andrew Grimshaw]

Karl,
You raise an interesting point - the point 
"What are the ramifications for security and system stability?  What
happens if someone uses a poor implementation or malicously puts GUIDs
into EPRs such that they alias other services?  Do we have signature
validation for EPRs?  "

This was discussed in the design team over a year ago and the consensus was
that being able to strongly tie identity to the name, e.g.,
cryptographically, was not a requirement - but rather an option. (I agreed
it should not be required - but felt strongly that we must be able to
accommodate such linkage). As you may know the Legion implementation of
abstract names (called LOID's) include a public key so that clients can
ensure that only the holder of the corresponding private key can read the
message. Similarly in the "Secure Grid Naming Protocol" (SGNP) that Avaki
took to GGF there were keys in the names. That may have persisted into
LSID's - which were derived off of SGNP - I am not sure.

As the WS-naming DRAFT currently stands there is nothing to prevent a name
generator (minter?) from placing keys, signed certs, or anything else in the
AbstractName component. For example I might include the GUID and a signed
hash along with the cert that signed it. Or ... there are lots of options
that all fit in the purview of WS-Naming.

As to malicious name generation of spoofing - without some additional
mechanism it can happen - that's life. It is not the way I would prefer it,
but getting agreement on "how" would be difficult. My guess is that if we
are successful, that AbstractName "types" will be developed that allow
clients to verify the AbstractName.


Andrew

-----Original Message-----
From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] On Behalf Of Karl
Czajkowski
Sent: Thursday, September 01, 2005 12:11 AM
To: Mark Morgan
Cc: ogsa-wg at ggf.org
Subject: Re: [ogsa-wg] BES query

On Aug 31, Mark Morgan modulated:
> I have to admit that I am confused as to what makes adding an abstract
name
> to an EPR so much of a burden.  I know that Andrew and I are talking about
> something very lightweight (perhaps just generating a GUID when the EPR is
> generated).  So, in the technical sense, it's extra work that needs to be
> done, but in my mind it's far less honerous then writing good comments for
> your code and I think everyone would agree that the benefits of doing so
far
> outweight the burden.  In this case, AbstractNames give a potentially huge
> benefit for a line or two of code.  Why is this such a big deal?
> 
> -Mark 
> 


Mark:

In reflecting on this a bit, I personally would like to hear comments
from the security crowd.  It sounds like the main difference in having
this GUID is, as I tried to summarize earlier, that someone can
compare EPRs or otherwise reason about service identities without
consulting the referenced service.

What are the ramifications for security and system stability?  What
happens if someone uses a poor implementation or malicously puts GUIDs
into EPRs such that they alias other services?  Do we have signature
validation for EPRs?  I guess this depends on the "culture" that would
emerge around consumption and use of these GUIDs...

I wonder if there are unspoken architectural assumptions here that are
at the heart of the debate?

karl

-- 
Karl Czajkowski
karlcz at univa.com