gomberg@GATEWAY.MITRE.ORG (02/27/90)
At the last ISO/IEC JTC 1/SC 21 meetings in November, a New Work Item (NWI)was proposed on an "Authentication Exchange ASE". The US (ANSI) must vote on the ballot for this NWI. At its January meeting, ANSI X3T5.5 prepared a DRAFT response which is reproduce below. X3T5.5 meets again next week and will make its ballot recommendation then. If you have comments on this matter, please e-mail responses to me. To make the draft response a little more comprehensible, the following is a PARTIAL quote from the NWI: The Authentication ASE will provide ... support [for] n-way peer authentication ... [and] may also carry other security related information such as keying material ... The authentication exchange may also be associated with any nominated security exchange mechanisms. The specification of particular mechanisms is not within the scope of this work. General methods for specifying the aspects of such mechanisms relevant to this ASE (e.g., data types of transferred parameters) are within the scope... Since Kerberos is one of the suggested candidates, comments from the Project Athena folks or Kerberos users are welcomed with respect to whether they believe its inclusion is appropriate (either now or at some other time). Thanks, Dave Gomberg ___________________________________________________________________________ The Security Ad Hoc group [of X3T5.5] proposes that the US vote "No" on this NWI, with the provision that it will change its vote to "Yes" subject to the condition that specific protocols be included in the scope of work for one or more authentication schemes, each of which would become one part of a multi-part standard. Candidate schemes include: 1. The authentication exchange mechanism specified in ISO 9594-8 for Directory Authentication. 2. The Kerberos authentication mechanism distributed by MIT Project Athena. 3. A key distribution mechanism based on, and supporting, procedures in ANSI X9.17, coupled with an appropriate authentication exchange. It is felt that an ASE for authentication is conceptually necessary, but the NWI as written provides only incremental "added value" toward that goal. Some of the funtionality mentioned in the scope of work as justification for this NWI, in fact, already exists in the OSI Upper Layers. In particular, there are already wasys for an "Authentication ASE" to exchange authentication information at times other than association establishment via direct use of the Presentation Service. What is missing are standards specifying abstract syntax definitions for actual strong authentication mechanisms. Without examples of such definintions, it is difficult to pin down whether or not any commonality can be factored out into a generalized "Authentication ASE". It is proposed that the scope of work be broadened to include specific mechanisms. At least one such mechanism can be readily extracted from the Directory work so as to be made generally available for use by other OSI applications. In addition, other candidate mechanisms have been noted above. Comment is solicited on the above US ballot response, and on the following questions: 1. Should the scope of work be broadened to "Security ASE" to include other security mechanisms for other services such as access control? 2. What authentication mechanisms are suitable for inclusion? 3. Should SC 27 [new SC on Security Techniques] play any role in producing such standards?
joey@geac.com (Joey DeWiele) (03/05/90)
I thought I'd make a quick reply to the item on ANSI's draft response to the NWI proposal for an Authentication Exchange ASE. I am not quite sure that this newsgroup is an appropriate forum for discussion of ANSI draft responses to NWI proposals however. SC21 is a political animal, and you might want to consider the benefits of distributing U.S. draft text internationally, where everyone can look at it in advance of official circulation. In article <9002261922.AA00211@polka.mitre.org> gomberg@GATEWAY.MITRE.ORG writes: <the work should consider> > > 2. The Kerberos authentication mechanism distributed by MIT Project > Athena. > I don't know anything about Kerberos. In particular, I don't how widely accepted in the international community Kerberos is, or the implications of the proposal that this mechanism must be considered for the NWI to be accepted. I do have an idea about what would happen to the standards process if every country involved voted NO to everything that didn't specifically consider nationally developed related material. > > > 1. Should the scope of work be broadened to "Security ASE" to include > other security mechanisms for other services such as access control? > CCITT Q19/VII (DAF) has submitted a liaison statement to JTC1/SC21/WG6 proposing collaborative work on a Security Exchange Service Element. Is this what the above is referring to? If so, maybe you want to reference the liaison statement (JTC1/SC21/N3991). It is my understanding that this was proposed earlier by CCITT and that N3991 is the second go, but I am not sure. By the way, I believe Canada will be submitting a contribution stating that the scope of the proposed NWI should be expanded to cover the specification of a generic security-exchange ASE, which would provide a standard means of transporting security exchange information in application-contexts where no other ASE provides for this transport.
jon@athena.mit.edu (Jon A. Rochlis) (03/06/90)
There are some very good reasons for wanting to be able to use Kerberos. The issue is not one of "not invented here" at all. Some of the issues only effect the US (like having to pay royalties for the use of public key technology), and others are not addressed well at all by the ISO standards (revocation, for example). There is also the trivial point that Kerberos has been shown to work in production use for several years. It works.
wesommer@athena.mit.edu (Bill Sommerfeld) (03/06/90)
In article <1990Mar5.154434.21726@geac.com> joey@geac.com (Joey DeWiele) writes:
I don't know anything about Kerberos.
Kerberos is a "paranoid" extension of the original Needham and
Schroeder secret-key based authentication system; it was developed at
MIT's Project Athena. Within the U.S., a reasonably portable
implementation is freely available via anonymous FTP. The current
version of the protocol (version 4) is in production use by thousands
of people at a number of different sites within the U.S. The protocol
is also used by at least one commercial product now in beta test.
A significant revision of the protocol is currently under way. Changes
include additional functionality, removal of limits, use of multiple
encryption algorithms, and conversion to using ASN.1 encoding for all
messages.
Kerberos currently assumes the use of a secret-key based encryption
system such as DES; however, the extensions in version 5 may allow for
the use of public key systems such as RSA.
In particular, I don't how
how widely accepted in the international community Kerberos is.
One reason why this may be the case is the !@#$ U.S. export
regulations on encryption and related technologies. Apparently,
Kerberos is considered to be "encryption control machinery", so
exporting an implementation requires an export license.
There is an "implementation" of Kerberos (known as "bones") which has
all reference to encryption removed, and is exportable without a
license; using the protocol specification, the source to "bones", and
a DES library, it may be possible to convert "bones" back into "the
real thing".
Information on Kerberos is available via anonymos FTP from
athena-dist.mit.edu, in pub/kerberos/*. The source code for all of
Kerberos is also available there, but you may be violating export
rules if you ftp it from outside the U.S.
If you can't FTP, you can also retrieve some of the available
information automatically via electronic mail via an archive server;
send mail to archive-server@athena-dist.mit.edu with a subject line of
"help" for more information.
There's also a usenet newsgroup comp.protocols.kerberos which is
bidirectionally gatewayed with an Internet mailing list. If you can't
read news and wish to join the mailing list, send mail to
kerberos-request@athena.mit.edu.
Bill Sommerfeld
Visiting engineer from HP/Apollo
at MIT/Project Athena.
--
Henry Spencer is so much of a | Bill Sommerfeld at MIT/Project Athena
minimalist that I often forget | sommerfeld@mit.edu
he's there - anonymous |