OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [UC-1-04:ARundgrenPush]


All

>I think Bob Morgan was right to point out how 'loaded' the term
>'authentication' is, and so I think we should be very clear about the
>different ways we are using that term.  I see 3 ways currently (I'll give
>them some crummy names for now for the sake of discussion) - 'end user',
>'domain to domain', and 'peer to peer'.
>
>'End user' authentication is where one security domain asserts to another
>security domain the fact that an authentication event took place related
to
>a specific user.  When authC types are discussed in this context, they
>pertain to types of authentication an end user has presented to
authenticate
>themselves to the security domain.  So far there is some agreement that
'end
>user' authC should be part of the specification.  In my opinion, the 'end
>user' authentication information should be considered part of the session
>information (ISSUE:[UC-3-01:UserSession]) to be shared between security
>domains.

Even here we haven't gotten down to the level of detail we need to be at
in order to discuss this.  "end user authentication information" can be of
several types:

(1) information on the basis of which the user is authenticated (e.g. a
password).
    This is usually called "authentication data".
(2) information about how the user was authenticated (e.g. "SSL with HTTP
basicauth").
    I'd like to propose calling this an "authentication method assertion".
(3) information asserting that a user was authenticated by a particular
    authority (e.g. a Kerberos ticket); this goes by different names but
I'll
    propose calling it an "authentication event assertion".

The S2ML spec. passes "authentication data" for a reason I can understand,
but
I'm very uncomfortable with doing this, because it raises the possibility
of
impersonation by the recipient or by someone who intercepts the
information.

I'm completely comfortable with passing "authentication method assertions".

I'm less comfortable with passing "authentication event assertions", but
this stems from my general discomfort with assertions about sessions, which
I'm going to elaborate on some more in a future note.  However if you're
going
to do the session work you clearly need these.

>The 'domain to domain' authC being discussed is between the security
domains
>themselves in order to support UC-1.  There have been a few methods for
this
>discussed over the last few months - including using digital signatures,
>2-way authenticated SSL, or encryption.  I recall some debate about the
>advantages and drawbacks of each - mostly centered around performance
>considerations.  I think this is the type of authC that Anders desires,
and
>would suggest that his requirement could be stated as something like 'When
>providing the SSO behavior described in UC-1, use the validation of the
>digital signatures of the assertions for the purpose of authenticating the
>security domains to each other. ' + (privacy considerations requirements).

On this topic I don't believe that we should DIRECTLY define SSO protocols
AT ALL. I believe that domain-to-domain authentication is a feature of a
particular protocol binding and we should define it -- if at all -- as
part of our protocol bindings.

>The third type of authC is where an actor provides credentials to a
service,
>which returns what is essentially an authorization assertion.  This type
of
>authC is where the 'challenge response' non-goal applies - that the
service
>not support that type of authC.  This is related to
>ISSUE:[UC-4-01:SecurityService].

Again the terminology isn't really clear enough here.  If what's meant by
"authorization assertion" here is "security attribute assertion", then
a very simple challenge-response credential acquisition service would
clearly
provide these in response to an inbound name assertion.  However if what's
meant by "authorization assertion" is what security people would
traditionally
be called a "capability" then I don't think we should provide these AT ALL
(see my previous note).

Perhaps if we frame the conversation this way, we can come to agreement to
some parts at least.

>
> I completely concur with your opinion on this issue.  We do have a clear
> process to follow.
>
> We (Anders?) should write up a concrete use case, called something like
> "negotiate trust relationship between partners".  We should then
> discuss on
> the mailing list/concalls to make sure the use case is described
> enough for
> us to vote on.  We should then vote on the use-case.  My early
> prediction is
> that the use case will not pass muster - certainly a lot would have to be
> done to convince me to vote for it - but we will have followed the
process
> and we will have useful artifacts for future work.
>
> Cheers,
> Dave

I agree with Dave here.  You would have to do A LOT to convince me that
supporting negotiation of trust relationships between partners is in scope
for
us -- e.g. feed me many more Hurricanes than I suspect Eve had in New
Orleans!

> > -----Original Message-----
> > From: Evan Prodromou [mailto:evan@outlook.net]
> > Sent: Monday, February 12, 2001 2:27 PM
> > To: S2ML-USE
> > Subject: Re: [UC-1-04:ARundgrenPush]
> >
> >
> > >>>>> "HL" == Hal Lockhart <hal.lockhart@entegrity.com> writes:
> >
> >     >> You also lack a business case.  Why do you need a particular
> >     >> business case when we are talking about extending the access
> >     >> system of practially all computer systems (but with arbitrary
> >     >> granularity and semantics) to function over the web between
> >     >> different, independent and constantly changing organizations as
> >     >> well?  IMO that's *hell* of a use case!  If it is a hell to
> >     >> design I am not yet able to tell.
> >
> > I'm replying to the wrong message, so, sorry.
> >
> > But I think Anders has gotten to the kernel of this issue. I think for
> > most of us with experience with AuthXML or S2ML, we've dealt from the
> > get-go with expecting peer security systems to have arranged their
> > partnership out-of-band. In other words, there are configuration
> > options on each piece of software that say what data is sent as
> > credentials, what profile information to share, what keys belong to
> > what security system, etc.
> >
> > We explicitly have this called out in the current doc, saying that
> > "trust negotiations must be made out-of-band." I agree with Anders
> > that there's a momentous opportunity in dropping this non-goal and
> > allowing the trust relationship to be negotiated IN-band ("Who are
> > you? Who says that's you? What do you want?").
> >
> > However, I am extremely leery of this expansion of scope. I wonder if
> > there's an opportunity here to stow away this use case and use it for
> > a next version of [OSSML] or for even another effort of this
> > TC. Something that operates well with what we do, but not part of this
> > current effort.

Again, I agree.

--bob

Bob Blakley
Chief Scientist, Security
Tivoli Systems, Inc.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC