From kitten-bounces@ietf.org Tue Jul 8 17:17:40 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D13E3A6B4A; Tue, 8 Jul 2008 17:17:40 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92AE13A6B4A for ; Tue, 8 Jul 2008 17:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bksKXQjHOw6w for ; Tue, 8 Jul 2008 17:17:38 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id D27E03A6B37 for ; Tue, 8 Jul 2008 17:17:38 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m690Hnli027118 for ; Wed, 9 Jul 2008 00:17:49 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3P00601Q3SPU00@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM) for kitten@ietf.org; Tue, 08 Jul 2008 18:17:49 -0600 (MDT) Received: from [10.0.0.5] ([206.124.7.73]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3P009P1Q5OIM70@mail-amer.sun.com> for kitten@ietf.org; Tue, 08 Jul 2008 18:17:49 -0600 (MDT) Date: Tue, 08 Jul 2008 18:18:25 -0600 From: Shawn M Emery Subject: WGLC on draft-ietf-kitten-rfc2853bis-04 To: kitten@ietf.org Message-id: <487403D1.5090008@sun.com> MIME-version: 1.0 User-Agent: Thunderbird 2.0.0.14 (X11/20080505) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org This message officially starts the Kitten Working Group Last Call for the following document: Generic Security Service API Version 2 : Java Bindings Update http://tools.ietf.org/html/draft-ietf-kitten-rfc2853bis-04 The Working Group Last Call for this document starts today on Tuesday, July 8th and will end on Tuesday, July 29th. Please send any comments to the Kitten mailing list or directly to chairs. Reviews that found no issues are also welcomed, so if you review the document and find it acceptable, please let the mailing list/authors+chairs know as well. Thank you, Alexey and Shawn, Kitten WG chairs _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Jul 21 20:21:45 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9864D3A693C; Mon, 21 Jul 2008 20:21:45 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45C13A67AE for ; Mon, 21 Jul 2008 20:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvqUlcsr0VhH for ; Mon, 21 Jul 2008 20:21:42 -0700 (PDT) Received: from out002.atlarge.net (out002.atlarge.net [129.41.63.60]) by core3.amsl.com (Postfix) with ESMTP id 58FD23A6836 for ; Mon, 21 Jul 2008 20:21:42 -0700 (PDT) Received: from csi-01-ex.atlarge.net ([10.100.50.47]) by out002.atlarge.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 22:17:25 -0500 Received: from 10.100.70.6 ([10.100.70.6]) by csi-01-ex.atlarge.net ([10.100.50.47]) via Exchange Front-End Server owa.atlarge.net ([10.100.50.148]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Jul 2008 03:17:25 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Mon, 21 Jul 2008 22:22:17 -0500 Subject: Re: WGLC on draft-ietf-kitten-rfc2853bis-04 From: Wesley Leggette To: Message-ID: Thread-Topic: WGLC on draft-ietf-kitten-rfc2853bis-04 Thread-Index: AcjrqiSJUDlMG6O1wU2usA4X6ChrNw== Mime-version: 1.0 X-OriginalArrivalTime: 22 Jul 2008 03:17:25.0934 (UTC) FILETIME=[770C14E0:01C8EBA9] X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org By way of introduction, I am a senior software developer at Cleversafe, Inc. We are developing a "dispersed" storage technology called "dsNet" and have been using GSS-API within our new security framework. Our code is written in Java and the aspects of GSS-API we are especially interested in is the authentication negotiation with SPNEGO and credential delegation features. We anticipate migrating to Kerberos and SPKM authentication but realize that our users will require support for password-based authentication as well and to that end have implemented a password-based authentication mechanism based heavily on SSHv2. Working with GSS-API on an alternate mechanism (especially one that requires multiple exchanges) has uncovered a few bugs in the Java GSS-API and SPNEGO implementations, which is somewhat interesting. (We plan on taking this up with Sun directly. I just mentioned it here for color.) But to the point, because we have decided to integrate heavily with the Java Authentication and Authorization Service we've found that the major shortcoming of the GSS-API Java bindings is the lack of a mechanism independent way of obtaining java Subject objects for both the local and delegated credentials of a GSSContext. I can anticipate that Java-specific (especially JAAS-specific) objects were purposefully omitted from the Java bindings. Was this the case and if so what was the rationale? If this was not purposefully omitted I would request that this be considered for this draft. Wesley Leggette Senior Software Developer Cleversafe, Inc. http://www.cleversafe.com _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Jul 25 14:05:30 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0873A685F; Fri, 25 Jul 2008 14:05:30 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117F33A685F for ; Fri, 25 Jul 2008 14:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTB7lsQpWGmJ for ; Fri, 25 Jul 2008 14:05:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id E1E043A680D for ; Fri, 25 Jul 2008 14:05:27 -0700 (PDT) Received: from spaceape8.eur.corp.google.com (spaceape8.eur.corp.google.com [172.28.16.142]) by smtp-out.google.com with ESMTP id m6PL5Ike019899 for ; Fri, 25 Jul 2008 22:05:18 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1217019918; bh=qFp8LYdOARgqbZUsjToqg686Me0=; h=DomainKey-Signature:Message-ID:Date:From:Sender:To:Subject:Cc: MIME-Version:Content-Type:X-Google-Sender-Auth; b=cDt5HAifbYo3ByEk //e7tO19L//kGuArJp4OOWWU+InetVRNkqTOSG3ALt7RrdGMiEJLTL2EmCm0RlCs7oK 8uQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=message-id:date:from:sender:to:subject:cc:mime-version: content-type:x-google-sender-auth; b=NHxERv2Y04sQeyP9DiwBkbqj9n+uKPX29gSvc3qmlFd8ac0OTAQGGOZ8EDqyDnsli h1wHFCfmnRtSx4u1IqJcA== Received: from hs-out-0708.google.com (hsjj58.prod.google.com [10.44.36.58]) by spaceape8.eur.corp.google.com with ESMTP id m6PL4vqi016086 for ; Fri, 25 Jul 2008 14:05:17 -0700 Received: by hs-out-0708.google.com with SMTP id j58so538133hsj.6 for ; Fri, 25 Jul 2008 14:05:16 -0700 (PDT) Received: by 10.100.144.11 with SMTP id r11mr3785201and.52.1217019915897; Fri, 25 Jul 2008 14:05:15 -0700 (PDT) Received: by 10.100.126.4 with HTTP; Fri, 25 Jul 2008 14:05:15 -0700 (PDT) Message-ID: <6f7ed4930807251405q123e71fh2169502e135d22d2@mail.gmail.com> Date: Fri, 25 Jul 2008 14:05:15 -0700 From: "Mayank Upadhyay" To: "Wesley Leggette" Subject: Re: WGLC on draft-ietf-kitten-rfc2853bis-04 MIME-Version: 1.0 X-Google-Sender-Auth: b2b509cb6b9f8acc Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1341607933==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org --===============1341607933== Content-Type: multipart/alternative; boundary="----=_Part_10591_7447815.1217019915887" ------=_Part_10591_7447815.1217019915887 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Wesley, It's not unusual for the base Java platform (J2SE) to have additional requirements over what the JGSS API defines. Interaction with JAAS has traditionally been one of those areas. JGSS is unique in the sense that the API was originally defined at the IETF, but since it is included in J2SE, it also had to go though the Java Community Process (JCP) to be adopted. The JCP experts group placed additional requirements that had to do with JAAS interaction. These were only specified in the javadocs for J2SE (e.g., http://java.sun.com/javase/6/docs/api/org/ietf/jgss/package-summary.html#useSubjectCredsOnly), and not in the JGSS RFC. It was also realized at the time, that we would need a way to convert back from GSSCredential to a JAAS Subject. So Sun provided an API specific to Sun's JRE to do this. Please see: http://java.sun.com/javase/6/docs/jre/api/security/jgss/spec/com/sun/security/jgss/GSSUtil.html. It wasn't pushed through as a standard J2SE API because we were unsure if it would suffice. Perhaps the best thing to do would be to take the issue up with Sun and ask if the com.sun.jgss.GSSUtil API could be moved into J2SE as part of a standard auth package like javax.security.auth? There are already other classes in this and its sub-packages related to this space. -Mayank 2008/7/22 kitten-request : Today's Topics: 1. Re: WGLC on draft-ietf-kitten-rfc2853bis- > > 04 (Wesley Leggette) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 21 Jul 2008 22:22:17 -0500 > From: Wesley Leggette > Subject: Re: WGLC on draft-ietf-kitten-rfc2853bis-04 > To: > Message-ID: > > > Content-Type: text/plain; charset="US-ASCII" > > By way of introduction, I am a senior software developer at Cleversafe, > Inc. > We are developing a "dispersed" storage technology called "dsNet" and have > been using GSS-API within our new security framework. Our code is written > in > Java and the aspects of GSS-API we are especially interested in is the > authentication negotiation with SPNEGO and credential delegation features. > > We anticipate migrating to Kerberos and SPKM authentication but realize > that > our users will require support for password-based authentication as well > and > to that end have implemented a password-based authentication mechanism > based > heavily on SSHv2. > > Working with GSS-API on an alternate mechanism (especially one that > requires > multiple exchanges) has uncovered a few bugs in the Java GSS-API and SPNEGO > implementations, which is somewhat interesting. (We plan on taking this up > with Sun directly. I just mentioned it here for color.) > > But to the point, because we have decided to integrate heavily with the > Java > Authentication and Authorization Service we've found that the major > shortcoming of the GSS-API Java bindings is the lack of a mechanism > independent way of obtaining java Subject objects for both the local and > delegated credentials of a GSSContext. > > I can anticipate that Java-specific (especially JAAS-specific) objects were > purposefully omitted from the Java bindings. Was this the case and if so > what was the rationale? If this was not purposefully omitted I would > request > that this be considered for this draft. > > Wesley Leggette > Senior Software Developer > Cleversafe, Inc. > http://www.cleversafe.com > > > > > ------------------------------ > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > > End of Kitten Digest, Vol 46, Issue 2 > ************************************* ------=_Part_10591_7447815.1217019915887 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Wesley,

It's not unusual for the base Java platform (J2SE) to have additional requirements over what the JGSS API defines. Interaction with JAAS has traditionally been one of those areas.

JGSS is unique in the sense that the API was originally defined at the IETF, but since it is included in J2SE, it also had to go though the Java Community Process (JCP) to be adopted. The JCP experts group placed additional requirements that had to do with JAAS interaction. These were only specified in the javadocs for J2SE (e.g., http://java.sun.com/javase/6/docs/api/org/ietf/jgss/package-summary.html#useSubjectCredsOnly), and not in the JGSS RFC.

It was also realized at the time, that we would need a way to convert back from GSSCredential to a JAAS Subject. So Sun provided an API specific to Sun's JRE to do this. Please see: http://java.sun.com/javase/6/docs/jre/api/security/jgss/spec/com/sun/security/jgss/GSSUtil.html. It wasn't pushed through as a standard J2SE API because we were unsure if it would suffice.

Perhaps the best thing to do would be to take the issue up with Sun and ask if the com.sun.jgss.GSSUtil API could be moved into J2SE as part of a standard auth package like javax.security.auth? There are already other classes in this and its sub-packages related to this space.

-Mayank

2008/7/22 kitten-request <kitten-request@ietf.org>:

Today's Topics:

  1. Re: WGLC on draft-ietf-kitten-rfc2853bis-
04 (Wesley Leggette)


----------------------------------------------------------------------

Message: 1
Date: Mon, 21 Jul 2008 22:22:17 -0500
From: Wesley Leggette <wleggette@cleversafe.com>
Subject: Re: WGLC on draft-ietf-kitten-rfc2853bis-04
To: <kitten@ietf.org>
Message-ID: <C4AABC99.79C7%wleggette@cleversafe.com>
Content-Type: text/plain;       charset="US-ASCII"

By way of introduction, I am a senior software developer at Cleversafe, Inc.
We are developing a "dispersed" storage technology called "dsNet" and have
been using GSS-API within our new security framework. Our code is written in
Java and the aspects of GSS-API we are especially interested in is the
authentication negotiation with SPNEGO and credential delegation features.

We anticipate migrating to Kerberos and SPKM authentication but realize that
our users will require support for password-based authentication as well and
to that end have implemented a password-based authentication mechanism based
heavily on SSHv2.

Working with GSS-API on an alternate mechanism (especially one that requires
multiple exchanges) has uncovered a few bugs in the Java GSS-API and SPNEGO
implementations, which is somewhat interesting. (We plan on taking this up
with Sun directly. I just mentioned it here for color.)

But to the point, because we have decided to integrate heavily with the Java
Authentication and Authorization Service we've found that the major
shortcoming of the GSS-API Java bindings is the lack of a mechanism
independent way of obtaining java Subject objects for both the local and
delegated credentials of a GSSContext.

I can anticipate that Java-specific (especially JAAS-specific) objects were
purposefully omitted from the Java bindings. Was this the case and if so
what was the rationale? If this was not purposefully omitted I would request
that this be considered for this draft.

Wesley Leggette
Senior Software Developer
Cleversafe, Inc.
http://www.cleversafe.com




------------------------------

_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten


End of Kitten Digest, Vol 46, Issue 2
*************************************
------=_Part_10591_7447815.1217019915887-- --===============1341607933== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten --===============1341607933==-- From kitten-bounces@ietf.org Fri Jul 25 15:38:51 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90A753A68AE; Fri, 25 Jul 2008 15:38:51 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782E63A68AE for ; Fri, 25 Jul 2008 15:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBlyenahTOI0 for ; Fri, 25 Jul 2008 15:38:49 -0700 (PDT) Received: from out001.atlarge.net (out001.atlarge.net [129.41.63.69]) by core3.amsl.com (Postfix) with ESMTP id 398A83A688A for ; Fri, 25 Jul 2008 15:38:48 -0700 (PDT) Received: from csi-01-ex.atlarge.net ([10.100.50.47]) by out001.atlarge.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jul 2008 17:38:45 -0500 Received: from 10.100.70.6 ([10.100.70.6]) by csi-01-ex.atlarge.net ([10.100.50.47]) via Exchange Front-End Server owa.atlarge.net ([10.100.50.148]) with Microsoft Exchange Server HTTP-DAV ; Fri, 25 Jul 2008 22:38:45 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Fri, 25 Jul 2008 17:38:49 -0500 Subject: Re: WGLC on draft-ietf-kitten-rfc2853bis-04 From: Wesley Leggette To: Mayank Upadhyay Message-ID: Thread-Topic: WGLC on draft-ietf-kitten-rfc2853bis-04 Thread-Index: AcjupzSh/7+m+GxukUGtxqblxNQLqA== In-Reply-To: <6f7ed4930807251405q123e71fh2169502e135d22d2@mail.gmail.com> Mime-version: 1.0 X-OriginalArrivalTime: 25 Jul 2008 22:38:45.0888 (UTC) FILETIME=[32C68800:01C8EEA7] Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org Mayank, Thanks for your reply. Will take this up with Sun. Wesley On 7/25/08 16:05, "Mayank Upadhyay" wrote: > Wesley, > > It's not unusual for the base Java platform (J2SE) to have additional > requirements over what the JGSS API defines. Interaction with JAAS has > traditionally been one of those areas. > > JGSS is unique in the sense that the API was originally defined at the IETF, > but since it is included in J2SE, it also had to go though the Java > Community Process (JCP) to be adopted. The JCP experts group placed > additional requirements that had to do with JAAS interaction. These were > only specified in the javadocs for J2SE (e.g., > http://java.sun.com/javase/6/docs/api/org/ietf/jgss/package-summary.html#useSu > bjectCredsOnly), > and not in the JGSS RFC. > > It was also realized at the time, that we would need a way to convert back > from GSSCredential to a JAAS Subject. So Sun provided an API specific to > Sun's JRE to do this. Please see: > http://java.sun.com/javase/6/docs/jre/api/security/jgss/spec/com/sun/security/ > jgss/GSSUtil.html. > It wasn't pushed through as a standard J2SE API because we were unsure if it > would suffice. > > Perhaps the best thing to do would be to take the issue up with Sun and ask > if the com.sun.jgss.GSSUtil API could be moved into J2SE as part of a > standard auth package like javax.security.auth? There are already other > classes in this and its sub-packages related to this space. > > -Mayank > > 2008/7/22 kitten-request : > > Today's Topics: > > 1. Re: WGLC on draft-ietf-kitten-rfc2853bis- >> >> 04 (Wesley Leggette) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 21 Jul 2008 22:22:17 -0500 >> From: Wesley Leggette >> Subject: Re: WGLC on draft-ietf-kitten-rfc2853bis-04 >> To: >> Message-ID: >> > com> >>> >> Content-Type: text/plain; charset="US-ASCII" >> >> By way of introduction, I am a senior software developer at Cleversafe, >> Inc. >> We are developing a "dispersed" storage technology called "dsNet" and have >> been using GSS-API within our new security framework. Our code is written >> in >> Java and the aspects of GSS-API we are especially interested in is the >> authentication negotiation with SPNEGO and credential delegation features. >> >> We anticipate migrating to Kerberos and SPKM authentication but realize >> that >> our users will require support for password-based authentication as well >> and >> to that end have implemented a password-based authentication mechanism >> based >> heavily on SSHv2. >> >> Working with GSS-API on an alternate mechanism (especially one that >> requires >> multiple exchanges) has uncovered a few bugs in the Java GSS-API and SPNEGO >> implementations, which is somewhat interesting. (We plan on taking this up >> with Sun directly. I just mentioned it here for color.) >> >> But to the point, because we have decided to integrate heavily with the >> Java >> Authentication and Authorization Service we've found that the major >> shortcoming of the GSS-API Java bindings is the lack of a mechanism >> independent way of obtaining java Subject objects for both the local and >> delegated credentials of a GSSContext. >> >> I can anticipate that Java-specific (especially JAAS-specific) objects were >> purposefully omitted from the Java bindings. Was this the case and if so >> what was the rationale? If this was not purposefully omitted I would >> request >> that this be considered for this draft. >> >> Wesley Leggette >> Senior Software Developer >> Cleversafe, Inc. >> http://www.cleversafe.com >> >> >> >> >> ------------------------------ >> >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten >> >> >> End of Kitten Digest, Vol 46, Issue 2 >> ************************************* _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Jul 30 04:17:06 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B26583A6AA4; Wed, 30 Jul 2008 04:17:06 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862C63A69C2 for ; Wed, 30 Jul 2008 04:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqtO1ke3z73i for ; Wed, 30 Jul 2008 04:17:05 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id CE55A3A67FC for ; Wed, 30 Jul 2008 04:17:05 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6UBHJKw006898 for ; Wed, 30 Jul 2008 11:17:19 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4T00K01GLH9B00@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM) for kitten@ietf.org; Wed, 30 Jul 2008 05:17:19 -0600 (MDT) Received: from shawn-emerys-computer.local ([129.150.116.218]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4T00HSOGOUTCB0@mail-amer.sun.com> for kitten@ietf.org; Wed, 30 Jul 2008 05:17:19 -0600 (MDT) Date: Wed, 30 Jul 2008 05:15:27 -0600 From: "Shawn M. Emery" Subject: WGLC on draft-ietf-kitten-gssapi-extensions-iana-04 To: kitten@ietf.org Message-id: <48904D4F.4030300@sun.com> MIME-version: 1.0 User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org This message officially starts the Kitten Working Group Last Call for the following document: Namespace Considerations and Registries for GSS-API Extensions http://tools.ietf.org/html/draft-ietf-kitten-gssapi-extensions-iana-04 The Working Group Last Call for this document starts today on Wednesday, July 30th and will end on Wednesday, August 20th. Please send any comments to the Kitten mailing list or directly to chairs. Reviews that found no issues are also welcomed, so if you review the document and find it acceptable, please let the mailing list/authors+chairs know as well. Thank you, Alexey and Shawn, Kitten WG chairs _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten