[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC