RE: [UC-1-04:ARundgrenPush]

[Darren Platt <dplatt@securant.com>]

All,

I apologize for picking up an old thread (and leaving most of it in the
message).  Just getting caught up on email now, and thought it best to leave
as much text in as possible so that it's clear what I'm agreeing with when I
say 'I agree' :~).

<snip>
> 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.

I agree on all three counts - and feel we need to include authentication
event assertions b/c we need to do the session work.


>
> >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.
>

I agree.


> >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.

My mistake here - a typo really.  What I meant to say was that it was
essentailly an 'authentication assertion' that was returned here.  Not
'authorization assertion'.  The type of authN I was trying to describe is
the kind where what you described above as 'authentication data' and a UID
are sent to a 'service' which returns a signed assertion which asserts your
identity.  I think that it was this area of authN to which the non-goal of
Challenge-Response applied.



> > 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!

I agree that trust negotiation is out of scope.


Regards,

Darren