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

[Hal Lockhart <hal.lockhart@entegrity.com>]

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