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: Issue Group 5 BALLOT -- comments on Group5.txt

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




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)

[2] RFC2246, The TLS Protocol Version 1.0, specifically chapter 7.

[3] RFC2617, HTTP Authentication: Basic and Digest Access Authentication

[4] RFC2222, Simple Authentication and Security Layer (SASL)

[5] RFC2831, Using Digest Authentication as a SASL Mechanism


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

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

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


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

Powered by eList eXpress LLC