RE: ISSUE[UC-5-01:AuthCProtocol]

["Edwards, Nigel" <Nigel_Edwards@hp.com>]

Dave makes a very good point about non-goals serving useful 
purposes such as demonstrating we have considered things 
that are not in the final output. I agree with this.

My reason for wanting positive requirements are as outlined by
Hal. They serve as very clear statements of focus.

As to whether Challenge-Response should be listed as a non goal,
I agree with Hal. My vision of how assertions will work is that
they will carry around information about how entities have authenticated.
(At least those assertions that are concerned with authentication.)

I does not seem too onerous to define lots of methods. It also doesn't
mean all conforming implementations have to support all authentication
schemes. If a principal authenticates at a site A, using scheme X, site 
A could create an assertion and make that available to site B. Site B could 
understand this assertion without itself directly supporting authentication
scheme X.

Also I believe we should allow for extensibility, so that new types
can be added if a deployment requires it (another requirement ;-)).

Nigel

> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Friday, February 09, 2001 4:03 PM
> To: 'Orchard, David'; Edwards, Nigel;
> 'security-use@lists.oasis-open.org'
> Subject: RE: ISSUE[UC-5-01:AuthCProtocol]
> 
> 
> I understood Nigel's comment to be that this particular requirement be
> stated positively rather than as a non-goal, rather than all 
> non-goals be
> dropped.
> 
> I agree with this idea. For example the non-goal that we not 
> invent any new
> crypto or authn schemes seems a good one.
> 
> It is hard for me to express what I think the difference is, 
> but it seems
> like non-goals like the one above are about the fundamental 
> scope of the
> project, the design philosophy or the intended priority of tradeoffs.
> 
> The support for authn types seems much more like an 
> enumerated requirement,
> similiar to the decision as to what bindings will be supported.
> 
> Maybe the difference is that I think the non-goals will not 
> change, but the
> enumerated reqmnts. may.
> 
> As far as the substance of this particular requirement or 
> non-goal goes, I
> see two issues.
> 
> 1) So far as I can determine so far, the only thing we plan 
> to do with authn
> is define a way for somebody to say "I have authenticated so 
> & so, and I
> used the such and such method." We have said we are not 
> designing any new
> authn methods. I see nothing to suggest we are going to 
> define a series of
> methods for passing authentication tokens back and forth, in 
> the manner of
> GSSAPI or RADIUS.
> 
> If I am correct, is seems all we need is a registered set of 
> values for each
> type of authn and that is the end of it. If this is the case, why not
> support lots of methods?
> 
> 2) Anders seems to want to persist in using "challenge 
> response" for what I
> refer to as "credentials negotiation". I believe most people 
> have in mind
> something like the Microsoft challenge response protocol. 
> Since the term
> challenge response is firmly imbeded in the literature to refer to the
> latter, I suggest to Anders that he adopt credentials 
> negotiation or some
> other descriptive term.
> 
> Hal 
> 
> > -----Original Message-----
> > From: Orchard, David [mailto:dorchard@jamcracker.com]
> > Sent: Friday, February 09, 2001 2:49 AM
> > To: Edwards, Nigel; 'security-use@lists.oasis-open.org'
> > Subject: RE: ISSUE[UC-5-01:AuthCProtocol]
> > 
> > 
> > Respectfully, I disagree with dropping of non-goals.  
> > Explicitly stating
> > which requirements are out of scope serves many purposes.  
> > The out-of-scope
> > requirements give us a clear stated direction to move forward 
> > for future
> > revisions, they prevent the "did you think about" questions, 
> > and they give a
> > complete picture of the landscape of the security arena.
> > 
> > Cheers,
> > Dave
> >  
> > > -----Original Message-----
> > > From: Edwards, Nigel [mailto:Nigel_Edwards@hp.com]
> > > Sent: Wednesday, February 07, 2001 9:40 AM
> > > To: 'security-use@lists.oasis-open.org'
> > > Subject: ISSUE[UC-5-01:AuthCProtocol]
> > > 
> > > 
> > > > ISSUE[UC-5-01:AuthCProtocol] Straw Man 1 explicitly makes
> > > > challenge-response authentication a non-goal. Is 
> specifying which
> > > > types of authc are allowed and what protocols they can 
> > use necessary
> > > > for this document? If so, which types and which protocols?
> > > > 
> > > > 
> > > In my opinion it is better to drop the non-goal in favour 
> of listing
> > > explicitly
> > > what is in scope.
> > > 
> > > I propose that we reuse much of the text from version 0.8a 
> > of the S2ML
> > > specification section 2.1. Except that we drop the third 
> > bullet point
> > > (it is too vague). This gives us the flowing.
> > > 
> > > <suggestedtext>
> > > 
> > > [R-SupportedAuthenticationModes]
> > >   *Server-authenticated SSL connections from browser to web server
> > >   *Password and user-certificate authentication from web browser
> > >   *Existing secure peer-to-peer programming infrastructure based
> > >    on SSL, S/MIME, and XML Signature [XML-SIG].
> > > 
> > > </suggestedtext>
> > > 
> > > In the last bullet listed above, I have changed 
> > "server-to-server" to
> > > "peer-to-peer" 
> > > 
> > > The following bullet has been removed (I believe it to be 
> > too vague).
> > >  *Existing web server and related user authentication mechanisms
> > > 
> > > One question to which I don't have the answer, is should SASL 
> > > [RFC 2222] be mentioned?
> > > 
> > > Nigel.
> > > 
> > 
>