From: Mike Eisler (mre@eng.sun.com)
Date: 04/01/99-08:50:48 AM Z
Date: Thu, 1 Apr 1999 06:50:48 -0800 (PST) From: Mike Eisler <mre@eng.sun.com> Subject: Minutes, CAT-WG Minneapolis meeting (Fwd) Message-ID: <Roam.SIMC.2.0.6.922978248.19592.mre@eng.sun.com> I'm forwarding this excerpt from the CAT WG meeting minutes from the Minneapolis meeting several weeks ago (held one week after the NFS V4 WG meeting where I mentioned LIPKEY as possible mandatory to implement security mechanism for NFS V4). The upshot is that LIPKEY is now a work item for the CAT wg, and I'll be purising the refinement of the document (http://www.ietf.org/internet-drafts/draft-ietf-cat-lipkey-00.txt). -mre >----------------Begin Forwarded Message----------------< Date: Thu, 1 Apr 1999 09:19:20 -0500 From: "Linn, John" <jlinn@securitydynamics.com> Subject: Minutes, CAT-WG Minneapolis meeting To: "'minutes@ietf.org'" <minutes@ietf.org> Cc: "'CAT-WG List'" <ietf-cat-wg@lists.Stanford.EDU> [...] Mike Eisler (of Sun's NFS group) led discussion on the Low-Infrastructure Public-Key (LIPKEY) proposal. About 5 attendees indicated that they had read the draft. The LIPKEY mechanism adapts SPKM's SPKM-1 unilateral mode for an environment where servers are registered with public-key certificates, but where client users authenticate with passwords. Mike cited several LIPKEY priorities. Familiarity breeds acceptance (people will adopt what they understand and are used to). Server authentication in Internet environments was considered more important than client authentication. Reduced client impact is important since there are more clients than servers. Almost all OSs have some form of native password support, and this can and should be leveraged without user reregistration. LIPKEY's form is like TLS with passwords, so uses a level of infrastructure that has achieved a status of common practice. As a result, it may be more easily grasped and accepted than Kerberos, though can be suitable for application protocols (e.g., UDP-based applications, RPC) that cannot or will not use TLS. LIPKEY's usage of the SPKM context establishment request varies from RFC-2025, since certificate acquisition is assumed to take place in-band; it may be appropriate to describe this variant usage as a new SPKM-3 mode. Mike noted his neutrality about the general issue of encoding conventions, but does not propose to redefine SPKM's existing ASN.1 structures to use different encoding. It was noted that LIPKEY usage requires that a user's password be obtained and accessible via a user's credentials. At the end of the session, a straw poll of attendees was taken to determine interest in pursuing standardization of various low-infrastructure GSS-API alternatives. Attendees were allowed to express support for multiple options. Greatest interest was apparent in LIPKEY (19 attendees recorded), followed by GSS-Easy (12 attendees), and various forms of digest authentication (10 attendees). One attendee indicated interest in pursuing EKE/SPEKE/SRP methods. No attendees indicated opposition to pursuing standardization of one or more low-infrastructure mechanism candidates within the GSS framework. >----------------End Forwarded Message----------------<
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:57 AM Z CST