Re: Issue Group 5 BALLOT -- comments on Group5.txt

[Jeff Hodges <jhodges@oblix.com>]

Attached are my comments on the issues group 5 write-up (i.e. the file
Group5.txt contained within the file group5-OSSML.ZIP, attached to this
message..

  http://lists.oasis-open.org/archives/security-use/200102/msg00125.html

)

thanks,

JeffH
this file: Group5-hodges-2001-02-24.txt

orig file: Group5.txt
orig author: Prateek Mishra
orig date: Wed, 21 Feb 2001 22:13:11 -0500

comments by Jeff Hodges, 24-Feb-2001

> ISSUE:[UC-5-03:AuthCThrough]
> 
> All the scenarios in Straw Man 1 presume that the user provides
> authentication credentials (password, certificate, biometric, etc)
> to the authentication system out-of-band.
> 
> 
> (a) Should [OSSML] be used directly for authentication? In other
> words should the [OSSML] model or express one or more authentication
> methods or a framework for authentication?
> 
> 
> Resolution: Yes/No
> 
> 
> (b) Should this be explicitly stated as a non-goal? 


The way I suggest to state this is below as [No-AuthnMech].


> 
> Resolution: Yes/No
> 
> (c) Should the following
> statement would be added to the non-goals section:
> 
> [NO-Authc] Authentication methods or frameworks are outside the
> scope of [OSSML]

Suggested revision:

                   +++++

[No-AuthnMech] Definition of authentication mechanisms per se -- mechanisms 
essentially equivalent to, for example, Kerberos [1],  the TLS/SSL handshake
protocol [2],  HTTP Authn [3], SASL [4], SASL mechanisms such as Digest [5]  --
is outside the scope of [OSSML]. 

[1] RFC1510, The Kerberos Network Authentication Service (V5)
    http://www.ietf.org/rfc/rfc1510.txt

[2] RFC2246, The TLS Protocol Version 1.0, specifically chapter 7.
    http://www.ietf.org/rfc/rfc2246.txt

[3] RFC2617, HTTP Authentication: Basic and Digest Access Authentication
    http://www.ietf.org/rfc/rfc2617.txt

[4] RFC2222, Simple Authentication and Security Layer (SASL)
    http://www.ietf.org/rfc/rfc2222.txt

[5] RFC2831, Using Digest Authentication as a SASL Mechanism
    http://www.ietf.org/rfc/rfc2831.txt

                   +++++

rationale: we need to be precise about what we mean and reference existing,
well-specified work in order to make our intent clear.

note: I would vote "yes" on including the above [No-AuthnMech] statement (or
something built from it) and the references in the "use case & reqs strawman
doc".



> 
> Resolutiom: Yes/No
> 
> -------------------------------------------------------------------
> ISSUE:[UC-5-02:SASL]
> 
> Is there a need to develop materials within [OSSML] that explore its 
> relationship to SASL [SASL]?
> 
> Resolution: Yes/No
> 
> 
> [SASL] RFC 2222:
> ---------------------------------------------------------------------
> 
> [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, what types
> and which protocols?
> 
> As written, this issue covers a lot of ground. 
> Issue:[UC-5-03:AuthCthrough] covers the core issue
> of the removal of all considerations of modeling authentication 
> methods within [OSSML], which need not be discussed further in 5-01.
> 
> There is an aspect of these requirements that has been discussed
> and noted as important on the list. There is a need for describing 
> different forms of credentials (name-password, public key,
> X509 certificates etc) within OSSML. In this sense there is
> a connection to the different "permitted forms of authc" [2] 
> and OSSML.
> 
> I suggest the following sub-parts for voting:
> 
> (a) The Non-Goal
> "Challenge-response authentication protocols are outside the
> scope of the [OSSML]"
> 
> be removed from the Strawman 3 document.
> 
> Resolution: Yes/No
> 
> (b) The following requirements be added to the Strawman 3 document:
> 
> [R-StandardCreds] [OSSML] should provide a data format for
                                   ^^^^^^^ ^            ^
                                  specify, |            (s)
                                           |
                                           |
                                         ..or normatively refer to, 
                                           specific..


> credentials including those based on name-password, 
             ^ ^^^^^^^^^^^^^^
             .   For example, this MAY include ones..


> X509v3 certificates, public keys, X509 Distinguished
> name, and empty credentials.
                             ^
                            ..and MAY include others.





> [R-ExtensibleCreds] [OSSML] The credentials data format
> must support extensibility in a structured fashion.

Suggested rewrite:

[R-ExtensibleCredsSet] [OSSML] MUST provide for future extension of the
credentials set it supports without necessitating reissue of the [OSSML]
specification itself. 


> 
> Resolution: Yes/No
> 
> REFERENCES:
> 
> I believe these requirements are consistent with or can be derived
> from Nigel's suggestion [1] but is perhaps closer to the current 
> style of specification in Strawman 2. It also reflects the discussion in 
> [2] and [3].
> 
> [1] http://lists.oasis-open.org/archives/security-use/200102/msg00029.html
> [2] http://lists.oasis-open.org/archives/security-use/200102/msg00038.html 
> [3] http://lists.oasis-open.org/archives/security-use/200102/msg00064.html

---
end