From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 5 14:41:34 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03837 for ; Wed, 5 May 2004 14:41:33 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i45IVf60002803 for ietf-cat-wg-out720680; Wed, 5 May 2004 11:31:41 -0700 (PDT) Received: from konishi-polis.mit.edu (STRATTON-THREE-SIXTY-SEVEN.MIT.EDU [18.187.6.112]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i45IVdNK002783 for ; Wed, 5 May 2004 11:31:40 -0700 (PDT) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 129FF15200A; Wed, 5 May 2004 14:31:39 -0400 (EDT) To: ietf-cat-wg@lists.Stanford.EDU Subject: Selecting a BOF chair From: Sam Hartman Date: Wed, 05 May 2004 14:31:39 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Greetings. The Scheduling has opened for the San Diego IETF so we should get busy with our plans to have e a BOF there. I plan to work on a draft proposed charter later this week. If someone else wants to take over that work I'm OK with simply contributing to it, but since no one has expressed a desire to own the charter I was going to volunteer. I think we also need to select a proposed chair. Clearly the security ADs will have the ultimate decision, but we need to have a name to give to them. How would people feel about Jeffrey ALtman as a proposed chair. He's been involved as a GSSAPI user with the Kermit Project and has been involved specifying protocols that use GSSAPI. Jeffrey has also previously chaired a BOF at the IETF. He has been following the Kerberos, CAT and SASL working groups. In short, Jeffrey has significant experience with GSSAPI, but is not an advocate for a strong position or proposal. My experience in the Kerberos working group suggests that he will do a good job building and judging consensus. --Sam -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 11 15:47:07 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20754 for ; Tue, 11 May 2004 15:47:07 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i4BJbeaH015096 for ietf-cat-wg-out720680; Tue, 11 May 2004 12:37:40 -0700 (PDT) Received: from konishi-polis.mit.edu (STRATTON-FOUR-FIFTY-TWO.MIT.EDU [18.187.6.197]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i4BJbONK015064 for ; Tue, 11 May 2004 12:37:25 -0700 (PDT) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id C95ED15200A; Tue, 11 May 2004 15:37:20 -0400 (EDT) To: ietf-cat-wg@lists.Stanford.EDU Subject: Draft 0 of proposed charter Message-Id: <20040511193720.C95ED15200A@konishi-polis.mit.edu> Date: Tue, 11 May 2004 15:37:20 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Here's a proposed charter. I realize that it's too long for a real charter. For now I'd like to have an exaustive list of all the work we plan to do so we can evaluate whether our scope is too extensive. I'd appreciate suggestions on how to actually organize things for a normal length charter. Also, feedback is needed on work items. We need to know if any should be removed or added. The Generic Security Services API [RFC 2743, RFC 2744] provides an API for applications to set up security contexts and to use these contexts for per-message protection services. The Common Authentication Technology Next Generation Working Group (Kitten) will work on standardizing extensions and improvements to the GSSAPI that the IETF believes are necessary based on experience using GSSAPI over the last 10 years. Extensions may be published as separate drafts or or included in a GSSAPI version 3. While version 2 of the GSSAPI may be clarified, no backward incompatible changes may be made to this version of the API. This working group is chartered to work on the following extensions to GSSAPI: - Definitions of channel bindings for TLS, IPSec and other cryptographic channels based on work started in the NFSV4 working group. - AN interface to store credentials based on draft-williams-gss-store-deleg-creds-xx.txt - Extensions to solve problems posed by the Global Grid Forum's GSSAPI extensions document. - Extensions to deal with mechanism-specific extensibility in a multi-mechanism environment. - Clarify the portable use of channel bindings and better specify channel bindings in a language-independent manner. - Specify threading requirements for GSSAPI. - Extend GSSAPI to support mechanisms that do not have a single canonical name for each authentication identity. - Extensions to support stackable GSSAPI mechanisms. In addition to these extensions the following mechanism work is chartered: - The CCM mechanism - Revisions to RFC 2748 (SPNEGO) to correct problems that make the spec unimplementable and to document problems in widely-deployed attempts to implement this spec. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 11 17:06:11 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25486 for ; Tue, 11 May 2004 17:06:10 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i4BKudVc024330 for ietf-cat-wg-out720680; Tue, 11 May 2004 13:56:39 -0700 (PDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i4BKuaNK024306 for ; Tue, 11 May 2004 13:56:37 -0700 (PDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i4BKuV6b012736; Tue, 11 May 2004 13:56:31 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i4BKuF4F028917; Tue, 11 May 2004 14:56:15 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i4BKsNoq488880; Tue, 11 May 2004 15:54:38 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i4BKsMov488879; Tue, 11 May 2004 15:54:22 -0500 (CDT) Date: Tue, 11 May 2004 15:54:22 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: Draft 0 of proposed charter Message-ID: <20040511205422.GI488605@binky.central.sun.com> References: <20040511193720.C95ED15200A@konishi-polis.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040511193720.C95ED15200A@konishi-polis.mit.edu> User-Agent: Mutt/1.4.1i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Tue, May 11, 2004 at 03:37:20PM -0400, Sam Hartman wrote: > Extensions may be published as separate drafts or > or included in a GSSAPI version 3. While version 2 of the GSSAPI may > be clarified, no backward incompatible changes may be made to this > version of the API. Right. It should be clear that many of these extensions are "optional" from the point of view of GSS-API v2 implementors. It should also be clear that, while in some cases we seek to make the use of mechanism-specific or platform-specific extensions more feasible (particularly in a mechglue environment) we mostly seek to do generic exntension work (plus mechanisms, like CCM). I believe most of your list can be summarized in a paragraph or two. Add to the list of work items to consider: - Guidelines for GSS-API mechanism designers - Guidelines for GSS-API application protocol designers Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 11 17:35:33 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27538 for ; Tue, 11 May 2004 17:35:32 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i4BLR1dt027983 for ietf-cat-wg-out720680; Tue, 11 May 2004 14:27:01 -0700 (PDT) Received: from pomegranate.cc.columbia.edu (IDENT:cu41754@pomegranate.cc.columbia.edu [128.59.59.134]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i4BLQwNK027972 for ; Tue, 11 May 2004 14:26:58 -0700 (PDT) Received: from columbia.edu (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by pomegranate.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i4BLQuDk013694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 11 May 2004 17:26:57 -0400 (EDT) Message-ID: <40A145AC.6040503@columbia.edu> Date: Tue, 11 May 2004 17:29:16 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU Subject: Re: Draft 0 of proposed charter References: <20040511193720.C95ED15200A@konishi-polis.mit.edu> In-Reply-To: <20040511193720.C95ED15200A@konishi-polis.mit.edu> Content-Type: multipart/alternative; boundary="------------070700050701030807010705" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a multi-part message in MIME format. --------------070700050701030807010705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I do not believe this proposed charter is too long. It does indicate that there are a lot of work items which the KITTEN working group would be expected to complete. In order to gain permission for the BOF we should put together a document for the IESG containing an executive summary of each of the proposed charter items. I think a relative priority associated with each item would also be useful. With a list this long the two things we are going to have to demonstrate to the IESG is that there are enough participants interested in performing the work; as well as the will to get the work done in a timely manner. Jeffrey Altman Sam Hartman wrote: >Here's a proposed charter. I realize that it's too long for a real >charter. For now I'd like to have an exaustive list of all the work >we plan to do so we can evaluate whether our scope is too extensive. >I'd appreciate suggestions on how to actually organize things for a >normal length charter. > > --------------070700050701030807010705 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I do not believe this proposed charter is too long.  It does indicate that there
are a lot of work items which the KITTEN working group would be expected
to complete.

In order to gain permission for the BOF we should put together a
document for the IESG containing an executive summary of each of the
proposed charter items.  I think a relative priority associated with each
item would also be useful.  With a list this long the two things we are
going to have to demonstrate to the IESG is that there are enough
participants interested in performing the work; as well as the will to get
the work done in a timely manner.

Jeffrey Altman


Sam Hartman wrote:
 
Here's a proposed charter.  I realize that it's too long for a real
charter.  For now I'd like to have an exaustive list of all the work
we plan to do so we can evaluate whether our scope is too extensive.
I'd appreciate suggestions on how to actually organize things for a
normal length charter.
--------------070700050701030807010705-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon May 17 14:44:44 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13566 for ; Mon, 17 May 2004 14:44:43 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i4HIh5Mg015611 for ietf-cat-wg-out720680; Mon, 17 May 2004 11:43:05 -0700 (PDT) Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i4HIh1NK015603 for ; Mon, 17 May 2004 11:43:01 -0700 (PDT) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 6FC50151FE0; Mon, 17 May 2004 14:43:00 -0400 (EDT) To: ietf-cat-wg@lists.Stanford.EDU Subject: naming problem Message-Id: <20040517184300.6FC50151FE0@konishi-polis.mit.edu> Date: Mon, 17 May 2004 14:43:00 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I've committed to Jeffrey to have a draft describing the naming problem Nico and I are trying to solve by allowing mechanisms that do not have a single canonical name. I'll have this in time to make the IETF 60 draft 00 cutoff. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 18 15:32:31 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09186 for ; Tue, 18 May 2004 15:32:30 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i4IJTpH3022551 for ietf-cat-wg-out720680; Tue, 18 May 2004 12:29:51 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i4IJTiNK022544 for ; Tue, 18 May 2004 12:29:45 -0700 (PDT) Received: from columbia.edu (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i4IJTUSx006315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 May 2004 15:29:31 -0400 (EDT) Message-ID: <40AA6422.2040309@columbia.edu> Date: Tue, 18 May 2004 15:29:38 -0400 From: Jeffrey Altman Reply-To: ietf-cat-wg@lists.Stanford.EDU Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU CC: Kerberos WG , security-wg@ggf.org, nfsv4@ietf.org, ietf-kitten@central.org, saag@mit.edu Subject: Please review proposed letter to the IESG regarding the creation of the KITTEN Working Group with the IETF Security Area Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030601060907060305020601" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms030601060907060305020601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit My apologies ahead of time for the cross-posting to multiple lists. Following up on the recent discussions regarding GSSAPI v2 extensions which have taken place within the Global Grid Forum Security Working Group; on the IETF CAT Working Group mailing list; the IETF Kerberos Working Group mailing list; and many Zephyr and Jabber chat sessions, it appears to be time to form a working group as a follow up to CAT (aka KITTEN) to complete the necessary work. Prior to sending a formal request to the IESG I would like to obtain feedback from the interested parties. I have posted to: /afs/athena.mit.edu/user/j/a/jaltman/Public/kitten-iesg-letter.html http://web.mit.edu/~jaltman/Public/kitten-iesg-letter.html a proposed letter to the IESG providing the justification for the creation of the KITTEN working group. This letter includes a proposed charter as well as a set of milestones. Please read the proposal letter and send feedback to ietf-cat-wg@lists.stanford.edu. Replies to this e-mail will be redirected to the CAT mailing list. Thank you. Jeffrey Altman --------------ms030601060907060305020601 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJOzCC AvgwggJhoAMCAQICAwwjmjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDE2MDIxODM0WhcNMDUwNDE2MDIxODM0 WjBGMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRq YWx0bWFuQGNvbHVtYmlhLmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKyS 7eWrak81hbARkTT+lqX+uujXLK3tDmCn/6IQH9tDKYtf5A8/llZJdPYHUA9p1FH9hwk23iGY scSkJq84FJenlWKOOqOsT6BlueWsrlKuseJCdMf9uhN28p+UnZvrcVhcLLTYfRvQT9OUw/k3 h4TzNdyAXbBJ3LnL1ySbFRaNVkq7cW/2ircAWpcyqHH4ZKstdSLbo6axsDHWRZL8yHUsI1Gz esRSYQf2aUeUqvmGbEKEKFwbfqgfLwlBLiv1Lqib/++J3s5g3syhqWe3T8tUffmhdibUdX2W umT2uiWl/WGEBvc1+o5k0T2JqWMNR9VgzPyk8P+iZRHl76Yb49ECAwEAAaNUMFIwDgYDVR0P AQH/BAQDAgP4MBEGCWCGSAGG+EIBAQQEAwIFoDAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVt YmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGXYUcZvaLEqctXUsgt0 fUMFXukM3E5fpLBkk3+BbcY457WQE38ZM1AOvcYOHqB1xhJCxP1U0pSJu2Xfe9Z1M2mU4C4V 2w4sDcWkZteM9EW7VYbXzSCKCw0TKKp3Wl9TFIWFdiFwPvhOzhXUonGTdYbOvRuAXQuJdNQW O4v2sQg1MIIC+DCCAmGgAwIBAgIDDCOaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA0MTYwMjE4MzRaFw0wNTA0 MTYwMjE4MzRaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG 9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArJLt5atqTzWFsBGRNP6Wpf666Ncsre0OYKf/ohAf20Mpi1/kDz+WVkl09gdQD2nU Uf2HCTbeIZixxKQmrzgUl6eVYo46o6xPoGW55ayuUq6x4kJ0x/26E3byn5Sdm+txWFwstNh9 G9BP05TD+TeHhPM13IBdsEncucvXJJsVFo1WSrtxb/aKtwBalzKocfhkqy11ItujprGwMdZF kvzIdSwjUbN6xFJhB/ZpR5Sq+YZsQoQoXBt+qB8vCUEuK/UuqJv/74nezmDezKGpZ7dPy1R9 +aF2JtR1fZa6ZPa6JaX9YYQG9zX6jmTRPYmpYw1H1WDM/KTw/6JlEeXvphvj0QIDAQABo1Qw UjAOBgNVHQ8BAf8EBAMCA/gwEQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdEQQYMBaBFGphbHRt YW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZdhRxm9o sSpy1dSyC3R9QwVe6QzcTl+ksGSTf4FtxjjntZATfxkzUA69xg4eoHXGEkLE/VTSlIm7Zd97 1nUzaZTgLhXbDiwNxaRm14z0RbtVhtfNIIoLDRMoqndaX1MUhYV2IXA++E7OFdSicZN1hs69 G4BdC4l01BY7i/axCDUwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwwjmjAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NDA1MTgxOTI5MzhaMCMGCSqGSIb3DQEJBDEWBBSAVDJZEgpmdZ6fNs1nJt4E5G8mmjBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDCOaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwwj mjANBgkqhkiG9w0BAQEFAASCAQAShZrDgRGagIfPEAb8JNm5sLcJjRUQQiaP9hgW3zUJXyQ3 QRyg7D+kxFNTW7776TG1U1Ui+F5+XKcqoiOfENKQZb7dq0woGvctwn3K5r5sfcv6DJLRWKjj uMrP+R4JUsMRpj9HaFTGiqQMb3FHULkRwANwfoSbP0cMzCqrpzkOM2R3inHzhG2/sdjZKlkr SNN+msYgEVVV99bK7yRo/ZPL8BJibVHRk5stmYJlvSNYEEEzV3FCfNz7akBz8AdQhwb58pT+ WzkDDUmr8VvrH3Cp6JkU7zbiaME5LwT+fu4oCNvJU3IYz+w69gjU1q3mXCjLUGNTlhPQzUzA UVtlqVQdAAAAAAAA --------------ms030601060907060305020601-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 19 15:03:15 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01667 for ; Wed, 19 May 2004 15:03:15 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i4JIvAw1014968 for ietf-cat-wg-out720680; Wed, 19 May 2004 11:57:10 -0700 (PDT) Received: from hermes.ctd.anl.gov (hermes.ctd.anl.gov [130.202.113.27]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i4JIv7NK014953 for ; Wed, 19 May 2004 11:57:07 -0700 (PDT) Received: from hermes.ctd.anl.gov (localhost [127.0.0.1]) by hermes.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA15314 for ; Wed, 19 May 2004 13:57:01 -0500 (CDT) Received: from anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by hermes.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA15309; Wed, 19 May 2004 13:56:59 -0500 (CDT) Message-ID: <40ABADE6.8276197B@anl.gov> Date: Wed, 19 May 2004 13:56:38 -0500 From: "Douglas E. Engert" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU CC: Kerberos WG , security-wg@ggf.org, nfsv4@ietf.org, ietf-kitten@central.org, saag@mit.edu Subject: Re: Please review proposed letter to the IESG regarding the creationof the KITTEN Working Group with the IETF Security Area References: <40AA6422.2040309@columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Jeff, This look very good. I know I have requested the GGF and IETF to review the situation of extensions to GSSAPI, and I am sure many of the active GGF members (who also attend the IETF) will participate in the BOF and join the new WG. And thanks for volunteering to lead this effort. Jeffrey Altman wrote: > > My apologies ahead of time for the cross-posting to multiple lists. > > Following up on the recent discussions regarding GSSAPI v2 extensions > which have taken > place within the Global Grid Forum Security Working Group; on the IETF > CAT Working > Group mailing list; the IETF Kerberos Working Group mailing list; and > many Zephyr and > Jabber chat sessions, it appears to be time to form a working group as a > follow up to CAT > (aka KITTEN) to complete the necessary work. > > Prior to sending a formal request to the IESG I would like to obtain > feedback from > the interested parties. I have posted to: > > /afs/athena.mit.edu/user/j/a/jaltman/Public/kitten-iesg-letter.html > http://web.mit.edu/~jaltman/Public/kitten-iesg-letter.html > > a proposed letter to the IESG providing the justification for the > creation of the KITTEN working group. This letter includes a > proposed charter as well as a set of milestones. > > Please read the proposal letter and send feedback to > ietf-cat-wg@lists.stanford.edu. > Replies to this e-mail will be redirected to the CAT mailing list. > > Thank you. > > Jeffrey Altman -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 19 16:18:41 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11415 for ; Wed, 19 May 2004 16:18:38 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i4JK99pM023403 for ietf-cat-wg-out720680; Wed, 19 May 2004 13:09:09 -0700 (PDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i4JK95NK023374 for ; Wed, 19 May 2004 13:09:05 -0700 (PDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i4JK8NLr018951; Wed, 19 May 2004 13:08:23 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i4JK8McE021340; Wed, 19 May 2004 14:08:23 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i4JK5T8Q804932; Wed, 19 May 2004 15:05:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i4JK5SJQ804931; Wed, 19 May 2004 15:05:28 -0500 (CDT) Date: Wed, 19 May 2004 15:05:28 -0500 From: Nicolas Williams To: Internet-Drafts@ietf.org Cc: Brian Pawlowski , Spencer Shepler , Mike Eisler , ietf-cat-wg@lists.Stanford.EDU, Bill Sommerfeld Subject: draft-ietf-nfsv4-channel-bindings-01.txt Message-ID: <20040519200528.GY101103@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Network Working Group Nicolas Williams INTERNET-DRAFT Sun Microsystems November 2004 On the Use of Channel Bindings to Secure Channels Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines and formalizes the concept of channel bindings to secure layers and defines the actual contents of channel bindings for several secure channels. The concept of channel bindings allows applications to prove that the end-points of two secure channels are the same by binding authentication at one network layer to the session protection negotiation at a lower network layer. The use of channel bindings allows applications to delegate session protection to lower layers. N. Williams [Page 1] DRAFT Channel Bindings to Secure Channels Expires November 2004 1. Introduction pg. 3 2. Definitions pg. 4 3. Authentication protocols and channel bindings pg. 6 3.1. The GSS-API and channel bindings pg. 6 3.2. SASL and channel bindings pg. 7 3.3. Kerberos V and channel bindings pg. 7 4. Channel bindings to secure layers pg. 7 4.1. Bindings to SSHv2 channels pg. 7 4.2. Bindings to TLS channels pg. 7 4.3. Bindings to IPsec pg. 8 4.3.1. Interfaces for creating IPsec channels pg. 8 4.4. Bindings to other types of channels pg. 9 5. Benefits of channel bindings to secure channels pg. 9 6. Security considerations pg. 10 7. References pg. 10 7.1. Informative references pg. 10 7.2. Normative references pg. 11 8. Acknowledgements pg. 12 9. Author's Address pg. 12 N. Williams [Page 2] DRAFT Channel Bindings to Secure Channels Expires November 2004 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1. Introduction [NOTE: This I-D text has been split out from the "The Channel Conjunction Mechanism (CCM) for GSS" I-D, which will be updated soon to define only the CCM-BIND and CCM-MIC GSS-API pseudo-mechanisms and describe their use. CCM-BIND is particularly relevant to the use of channel bindings with GSS-API applications. See draft-ietf-nfsv4-ccm-01.txt.] Over the years several attempts have been made to delegate session protection at one network layer to another, for performance and/or scalability as well as for design elegance and also to avoid having to reinvent the wheel for every new application or security layer. The critical security problem to solve in order to achieve such delegation of session protection is always the same: how to ensure that there is no man-in-the-middle (MITM), from the point of view the application, at the lower network layer to which session protection is to be delegated. Alternative statement of the problem: how does one ensure that the end-points of two secure channels at different network layers are the same? And there may well be a MITM, particularly if the lower network layer either provides no authentication or if there is no connection between the authentication or principals used at the application and those used at the lower network layer. Such MITM attacks can be effected by, for example, spoofing IP address lookups (which is possible, for example, when using DNS but not DNSSEC) in a way that the application may not detect but which directs the client application or network stack to connect to a different host than had been intended (e.g., to the MITM's host). Even if such MITM attacks seem particularly difficult to effect, the problem must be solved. For example: a user decides to use TELNET, with Kerberos V authentication, over TLS to connect to some server but an attacker spoofs the name service lookup and causes the TELNET client to be redirected to some other host which TLS authenticates correctly and where the attacker forwards the connection, with or without TLS, to the server that the user had intended. In this example there is an MITM from the point of view of the application (TELNET), even though there is no MITM as far as TLS is concerned. The TELNET client and N. Williams [Page 3] DRAFT Channel Bindings to Secure Channels Expires November 2004 server cannot assume that there is no MITM and so cannot leverage the protection afforded by the TLS channel, unless they prove to each other that there is no MITM. A solution to this problem is highly desirable, particularly where multi-user applications are run over secure network layers (e.g., NFS over IPsec). For such applications the authentication model used at the application layer (usually user<->server) is generally very different from that used by secure, lower network layers, such as IPsec (usually client<->server or single-user<->server), and may even use different authentication infrastructures altogether (e.g., Kerberos V for the application layer, x.509 certificates at the lower layer). Such applications cannot generally leverage the security provided by the lower network layers, which, if they could, would allow them to offload session security to the secure lower layer. One solution involves ensuring the use of secure name services for hostname to network address translation and the use of secure networks (e.g., IPsec). This approach can prevent the MITM attack described above, but does not offer applications any guarantees that there is no MITM in the lower layer. Another solution is to use "channel bindings" (a GSS-API concept [RFC2743]) to bind authentication at application layers to secure transports at lower layers in the network stack. This solution is only applicable to applications that provide for user authentication. "Channel bindings" are data which securely identify a secure channel such that, when verified to match on both endpoints of end-to-end application connections, leave no doubt that the endpoints of two secure channels (the one identified by the bindings and the one used to exchange/verify the bindings) are the same. Because many applications exist which provide for authentication at the application layer, because many such applications use generic authentication frameworks, such as the GSS-API and SASL and are already deployed along with a common authentication infrastructure (e.g., Kerberos V, PKI, etc...), because such applications exist which multiplex multiple users onto a single session (and so cannot leverage network [e.g., IKE] authentication), the use of channel bindings is an elegant solution even where secure name services and networks are deployed. A formal definition of the channel bindings concept is given below, as well as the specific formulation of channel bindings for various protocols that provide for session security. 2. Definitions The GSS-API [RFC2743] is a generic interface to GSS-API security mechanisms which provides for authentication and session cryptographic protection. One facility provided by the GSS-API is a concept of "channel bindings" which consists of some data which must N. Williams [Page 4] DRAFT Channel Bindings to Secure Channels Expires November 2004 be provided, if at all, by initiators and acceptors and which the GSS-API security mechanisms ensure are the same for both, the initiator and acceptor of any given GSS-API security context - if the channel bindings provided by them do not match then the mechanism fails to establish a security context. o Channel bindings Generally some data which names a channel or its end-points. o Channel bindings to secure channels Channel bindings that securely identify a secure channel or its end-points. Applications can exchange authenticated, integrity-protected verifiers of their same channel bindings data to prove that the end-points of the channel identified by the channel bindings are the same as the application endpoints and thus, there can be no MITM at the lower layer. More formally, there are two types of channel bindings: - bindings that name a channel in a cryptographically secure manner (e.g., the session ID in SSHv2; see below) - bindings that name the authenticated end-points of a channel (e.g., as in IPsec; see below) Bindings that name a channel - MUST be cryptographically bound to the key exchange of the secure session - MUST be cryptographically bound to all potentially un- authenticated plaintext used for negotiation of the secure session (e.g., algorithm negotiations) and - users of channel bindings MUST exchange authenticated, integrity protected channel bindings data or signatures thereof (such exchanges MAY also be confidentiality protected) Additionally, the channel represented by the bindings MUST provide a cryptographically secure key exchange (and re-keying) and channel setup negotiation, and it MUST provide at least cryptographically secure data integrity protection services. Channel bindings data SHOULD NOT be constructed in such a way that their exchange requires confidentiality protection. N. Williams [Page 5] DRAFT Channel Bindings to Secure Channels Expires November 2004 No channel bindings described herein require confidentiality protected exchanges. The security of channel bindings depends on the security of: - the authentication and integrity protection technology used to protect the channel bindings exchanges at the application layers - the security of the channels identified by the channel bindings - the security of the channel bindings construction o Channel bindings to network addresses The GSS-API originally defined only channel bindings to network addresses. Such channel bindings, of course, are generally not cryptographically secure. For channel bindings to network addresses to be secure the application peers MUST be able to verify and ensure that network communications between them are secured and that there is no MITM - which generally means that the application peers MUST be able to interpret and authorize identities authenticated by the network and MUST be able to protect the methods by which they obtain the network addresses in the first place. In practice channel bindings to network addresses have mostly just caused trouble with Network Address Translation (NAT). 3. Authentication protocols and channel bindings Some authentication services provide for channel bindings, such as the GSS-API and some GSS-API mechanisms - others do not, such as SASL. Where suitable channel bindings facilities are not provided application protocol designers may include a separate, protected (where the authentication service provides message protection services) exchange of channel bindings material 3.1. The GSS-API and channel bindings The GSS-API provides for the use of channel bindings during initialization of GSS-API security contexts, though GSS-API mechanisms are not required to support this facility. This channel bindings facility is defined in detail in RFC2744. Unfortunately, the use of GSS-API channel bindings is generally not negotiated by GSS-API mechanisms, therefore GSS-API applications must agree a priori on the use of channel bindings or otherwise negotiate the use of channel bindings. N. Williams [Page 6] DRAFT Channel Bindings to Secure Channels Expires November 2004 Fortunately, it is possible to design GSS-API pseudo-mechanisms that simply wrap around existing mechanisms for the purpose of allowing applications to negotiate the use of channel bindings within their existing methods for negotiating GSS-API mechanisms. For example, NFSv4 [RFC3530] provides its own GSS-API mechanism negotiation, as does the MOUNT protocol for NFSv2/3 [RFC....]. [NOTE: This is an indirect reference to the Channel Conjunction Mechanism (CCM).] 3.2. SASL and channel bindings SASL does not provide for the use of channel bindings during initialization of SASL contexts. SASL applications MAY define their own exchange of integrity- protected channel bindings using established SASL integrity layers. Alternatively, SASL applications MAY use the GSS-* SASL mechanisms (which correspond to GSS-API mechanisms) to ensure the use of channel bindings through the GSS-API's facilities. 3.3. Kerberos V and channel bindings Kerberos V does not provide for use of channel bindings, thus the same general approach given above (post-authentication protected channel bindings exchange) applies to Kerberos V as well. However, Kerberos V AP client applications also MAY use the AP-REQ's Authenticator's "checksum" field to send a hash of channel bindings material to Kerberos V AP servers. Unfortunately, there is no slot in the AP-REP message for carrying the AP server's channel bindings (which justifies the statement that Kerberos V does not provide a channel bindings facility), so Kerberos V applications MUST establish a convention with regards to AP servers' handling of AP-REQ checksum data - and such applications have to trust the servers to respond with suitable error messages to AP-REQs bearing incorrect channel bindings. 4. Channel bindings to secure layers Not every secure session protocol or interface provides for secure channels, and not every secure session protocol provides data suitable for use as channel bindings. 4.1. Bindings to SSHv2 channels SSHv2 provides both, a secure channel and material (the SSHv2 "session ID") that is suitable for use as channel bindings. Thus it is RECOMMENDED that the SSHv2 "session ID" be used as the channel bindings for SSHv2. 4.2. Bindings to TLS channels N. Williams [Page 7] DRAFT Channel Bindings to Secure Channels Expires November 2004 TLS provides both, a secure channel and material (the TLS "finished" messages), that is suitable for use as channel bindings. Thus it is RECOMMENDED that the concatenation of the client's and server's "finished" messages, in that order, be used as the channel bindings for TLS. Note that the TLS "session ID," in spite of being named similarly to the SSHv2 session ID, is not suitable for use as channel bindings because it is assigned by the server, so a MITM could assign the same session ID on the client side as it gets from the server. 4.3. Bindings to IPsec IPsec does not provide a way to reliably name a channel regardless of what key exchange protocol is used. Therefore, the only reliable way to construct channel bindings to IPsec is to use the identities authenticated by the IPsec key exchange protocol for the given channel. New interfaces [IPSP-APIREQ] are required by which applications can create IPsec "channels." The basic idea is to use the interfaces described in [IPSP-APIREQ] to dynamically alter the SPD to reflect the requested bindings for the requested connections and then use the authenticated IDs as the identity of the channel. This approach does not name the channel directly, but no MITM can ensure that the authenticated IDs used as channel bindings match on both end-points unless the MITM has stolen or broken the IPsec credentials and/or authentication protocol. This is sufficient. 4.3.1. Interfaces for creating IPsec channels In order to build an IPsec channel some additional application programming interfaces are needed to: - indicate that an as yet unconnected channel is to be bound to IPsec IDs and - explicitly specify one, the other or both of those IDs - implicitly specify one, the other or both of those IDs (e.g., the ID corresponding to the current application program instance) - indirectly specify one, the other or both of those IDs (e.g., a hostname) and/or - discover the IPsec IDs to which a channel is bound N. Williams [Page 8] DRAFT Channel Bindings to Secure Channels Expires November 2004 For connection-less datagram transports the IDs to be used need to be specified/discovered on a per-datagram basis. See [IPSP-APIREQ]. 4.4. Bindings to other types of channels For secure session protocols that do not provide material suitable for use as channel bindings such material SHOULD be constructed by concatenating the octets from the messages exchanged during the initialization of a session in the chronological order in which they were exchanged and processed (which requires synchronous session initialization), or a strong hash thereof (such as SHA-1). Some secure session protocols do not provide a secure channel but which do provide per-message integrity or confidentiality protection services. It is up to the network layers that use such protocols to build channels from such services; applications MUST NOT delegate session cryptographic protection to network layers that do not provide a secure channel. Kerberos V, certain GSS-API and SASL mechanisms, all provide session cryptographic protection and the necessary key exchange, but they provide neither a channel nor material suitable for use as channel bindings. Thus the RECOMMENDED channel bindings for channels protected by Kerberos V consist of a SHA-1 hash of the concatenated octets of the AP-REQ and AP-REP messages, in that order (or, for user-to-user exchanges, the various messages exchanged, including the ticket request, ticket and AP messages, in the order in which they were generated and processed) used to initialize the channel's cryptographic protection. Similarly for channels protected by GSS-API security contexts the RECOMMENDED channel bindings consist of a SHA-1 hash of the concatenated octets of the context tokens exchanged to setup a GSS-API security context in the order in which they were generated and processed (i.e., starting with the initiator's initial context token followed by the acceptor's reply token, if any, followed by the initiator's reply token, if any, etc...). 5. Benefits of channel bindings to secure channels The use of channel bindings to delegate session cryptographic protection include: o Performance improvements by avoiding double protection in cases where IPsec is in use and applications provide their own secure channels. o Performance improvements by leveraging hardware-accelerated IPsec. N. Williams [Page 9] DRAFT Channel Bindings to Secure Channels Expires November 2004 o Performance improvements by allowing RDDP hardware offloading to be integrated with IPsec hardware acceleration. If protocols layered above RDDP use privacy protection then RDDP offload cannot be done, thus by using channel bindings to IPsec the privacy protection is moved to IPsec, which is layered below RDDP, so RDDP can address application protocol data that's in cleartext relative to the RDDP headers. o Latency improvements for applications that multiplex multiple users onto a single channel, such as NFS w/ RPCSEC_GSS. 6. Security considerations When delegating session protection from one layer to another, one will almost certainly be making some session security trade-offs, such as using weaker data encryption/authentication modes. Implementors and administrators SHOULD understand these trade-offs. Channel bindings cannot and MUST NOT be used without mutual authentication (of client/user/initiator and server/user/acceptor) and/or without integrity-protected, authenticated exchange of channel bindings material. Anonymous secure channels SHOULD NOT be used without authentication and corresponding use of channel bindings (to the anonymous secure channels) at higher network layers, or for any purposes other than opportunistic encryption, since such channels provide no authenticated protection on their own. The security of channel bindings depends on the security of the channels, the construction of the bindings and the security of the authentication and integrity protection used to exchange channel bindings. 7. References 7.1. Informative references [Needs references to NFSv2/3 use of RPCSEC_GSS, to NFSv4, to SCTP, and, possibly, to DNS, DNSSEC, TELNET, SPNEGO, SSHv2 gss keyex, and CCM.] [TELNET] J. Postel, J.K. Reynolds, RFC0854 (STD0008): "Telnet Protocol Specification," May 1993, Status: Standard. [DNS] P.V. Mockapetris, RFC1035 (STD0013): "Domain names - implementation and specification," November 1987, Status: Standard. [DNSSEC] N. Williams [Page 10] DRAFT Channel Bindings to Secure Channels Expires November 2004 B. Wellington, RFC3008: "Domain Name System Security (DNSSEC) Signing Authority," November 2000, Status: Proposed Standard. [RFC2203] M. Eisler, A. Chiu, L. Ling, RFC2203: "RPCSEC_GSS Protocol Specification," September 1997, Status: Proposed Standard. [RFC2623] M. Eisler, "NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5," June 1999, Status: Proposed Standard. [NFSv4] S. Shepler, et. al., RFC3530: "Network File System (NFS) version 4 Protocol," April 2003, Status: Proposed Standard. [SPNEGO] E. Baize, D. Pinkas, RFC2478: "The Simple and Protected GSS-API Negotiation Mechanism," December 1998, Status: Proposed Standard. [CCM] M. Eisler, N. Williams, Internet-Draft: "The Channel Conjunction Mechanism (CCM) for GSS," May 2003, Status: Internet-Draft. ... 7.2. Normative references [Needs references to RFC2119, RFC2026, the GSS-API (RFCs 2743 & 2744), SASL, SSHv2, IKEv2, IPsec, Kerberos V, ...] [RFC2026] S. Bradner, RFC2026: "The Internet Standard Process - Revision 3," October 1996, Obsoletes - RFC 1602, Status: Best Current Practice. [RFC2119] S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to Indicate Requirement Levels," March 1997, Status: Best Current Practice. [RFC2743] J. Linn, RFC2743: "Generic Security Service Application Program Interface Version 2, Update 1," January 2000, Status: Proposed Standard. [RFC2744] J. Wray, RFC2744: "Generic Security Service API Version 2 : C-bindings," January 2000, Status: Proposed Standard. [IPSP-APIREQ] W. Sommerfeld, draft-ietf-ipsp-ipsec-apireq-00: "Requirements for an IPsec API," June 2003, Status: Draft. N. Williams [Page 11] DRAFT Channel Bindings to Secure Channels Expires November 2004 ... 8. Acknowledgements The author would like to thank Mike Eisler for his work on the Channel Conjunction Mechanism I-D and for bringing the problem to a head, Sam Hartman for pointing out that channel bindings provide a general solution to the channel binding problem, Jeff Altman for his suggestion of using the TLS finished messages as the TLS channel bindings, as well as Bill Sommerfeld, Radia Perlman for their most helpful comments. 9. Author's Address Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 Email: nicolas.williams@sun.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. N. Williams [Page 12] -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 19 16:19:34 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11535 for ; Wed, 19 May 2004 16:19:33 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i4JKDFET023859 for ietf-cat-wg-out720680; Wed, 19 May 2004 13:13:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i4JKDANK023811 for ; Wed, 19 May 2004 13:13:11 -0700 (PDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i4JKCS6b014092; Wed, 19 May 2004 13:12:28 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i4JKCC4F010613; Wed, 19 May 2004 14:12:12 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i4JK9SDr804953; Wed, 19 May 2004 15:09:44 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i4JK9SZB804952; Wed, 19 May 2004 15:09:28 -0500 (CDT) Date: Wed, 19 May 2004 15:09:28 -0500 From: Nicolas Williams To: Internet-Drafts@ietf.org Cc: Jeffrey Altman , ietf-cat-wg@lists.Stanford.EDU Subject: draft-williams-gssapi-store-deleg-creds-00.txt Message-ID: <20040519200928.GZ101103@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk INTERNET-DRAFT Nicolas Williams Sun Microsystems September 2003 GSS-APIv2 Extension for Storing Delegated Credentials Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This draft expires on January 30th, 2004. Please send comments to the authors. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines a new function for the GSS-API which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. N. Williams [Page 1] DRAFT GSS_Store_cred() Expires March 2004 Table of Contents 1 Introduction 2 GSS_Store_cred() 2.1 C-Bindings for GSS_Store_cred() 3 Examples 4 Security Considerations 5 References 5.1 Normative References 6 Author's Address 1 Introduction The GSS-API [RFC2743] clearly assumes that credentials exist in an implicit store whence they can be acquired using GSS_Acquire_cred() and GSS_Add_cred() or through use of the default credential. Multiple credential stores may exist on a given host, but only one store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any given time. [NOTE: This assumption can be seen in sections 1.1.1.2 and 1.1.1.3 of RFC2743 as well as in section 3.5 of RFC2744. Note to the RFC editor: please remove this note before publication.] Applications may be able to change the credential store from which credentials can be acquired, either by changing user contexts (where the applications have the privilege to do so) or by other means (where a user may have multiple credential stores). Some GSS-API acceptor applications always change user contexts, after accepting a GSS-API security context and making appropriate authorization checks, to the user context corresponding to the initiator principal name or to a context requested by the initiator. The means by which credential stores are managed are generally beyond the scope of the GSS-API. In the case of delegated credential handles however, such credentials do not exist in the acceptor's credential store or in the credential stores of the user contexts to which the acceptor application might change - which is precisely the raison d'etre of credential delegation. But the GSS-API provides no mechanism by which delegated credential handles can be made available for acquisition through GSS_Acquire_cred()/GSS_Add_cred(). The GSS-API also does not provide any credential import/export interfaces like the GSS-API context import/export interfaces. Thus acceptors are limited to making only direct use of delegated credential handles and only with GSS_Init_sec_context(), GSS_Inquire_cred*() and GSS_Release_cred(). This limitation is particularly onerous on Unix systems where a call to exec() to N. Williams [Page 2] DRAFT GSS_Store_cred() Expires March 2004 replace the process image obliterates the delegated credentials handle. [NOTE: Delegated credentials are practically unusable on Unix implementations of Secure Shell (SSHv2) servers, except where there are extended interfaces for dealing with delegated credentials, which to date have always been mechanism-specific interfaces. Note to the RFC editor: please remove this note before publication.] In order to make delegated credentials generally as useful as credentials that can be acquired with GSS_Acquire_cred() and GSS_Add_cred() a primitive is needed which allows storing of credentials in the implicit credential store. This primitive we call "GSS_Store_cred()." [NOTE: Simon Wilkinson's patches to OpenSSH for GSS-API sport a simple internal interface for storing delegated credentials in users' credential store - this internal interface wraps around two mechanism specific internal interfaces for storing GSI and Kerberos V credentials. Simon's code shows that: a) a generic method is needed for making delegated credentials available for indirect use through acquisition (as opposed to just using the actual delegated cred handle) b) it is possible to design and implement such a generic method for storing delegated credentials. No new concepts are added to the GSS-API by this document, but the implicit existence of a credential store in the background is made explicit, and a deficiency of the GSS-API is corrected. Compare this to the GGF proposal which includes a credential import/export facility (like the existing context import/ export facility), but with an option to export as "environment variables," meaning something like "store these input creds in some new credential store and then tell me the name of that credential store through some output environment variable"[*]. Thus, the GGF export-cred-to-environment- variable proposal adds knowledge of environment variables to the GSS-API, which this proposal does not. Note that a credential import/export facility along the lines of the existing context import/export facility may be useful and complements the GSS_Store_cred() interface; in fact, with GSS_Store_cred() it should be possible to remove the 'option_req' input parameter and export-to-env-var features N. Williams [Page 3] DRAFT GSS_Store_cred() Expires March 2004 of the GGF's GSS_Export_cred() credential export proposal. [*] For the exact semantics see section 1.2, paragraph 6 of draft-engert-ggf-gss-extensions-00.txt One side effect of GSS_Store_cred(), however, is that it allows applications that can switch their current credential store to move credentials from one store to the other; this is a direct result of making it possible to store a credential given a GSS-API credential handle. Perhaps there should be some text allowing, or recommending, that implementations of GSS_Store_cred() allow only the storage of credentials acquired through credential delegation. Note to the RFC editor: please remove this note before publication.] 2 GSS_Store_cred() Inputs: o input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST -- NOT be GSS_C_NO_CREDENTIAL o cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, -- 2=ACCEPT-ONLY o desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID -- then store all the elements of the input_cred_handle, otherwise -- store only the element of the corresponding mechanism o overwrite_cred BOOLEAN, -- if TRUE replace any credential for the -- same principal in the credential store o default_cred BOOLEAN -- if TRUE make the stored credential -- available as the default credential (for acquisition with -- GSS_C_NO_NAME as the desired name or for use as -- GSS_C_NO_CREDENTIAL) Outputs: o major_status INTEGER, o minor_status INTEGER, o mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of -- mechanism OIDs for which credential elements were successfully -- stored o cred_usage_stored INTEGER -- like cred_usage, but indicates what -- kind of credential was stored (useful when the cred_usage input -- parameter is set to INITIATE-AND-ACCEPT) N. Williams [Page 4] DRAFT GSS_Store_cred() Expires March 2004 Return major_status codes: o GSS_S_COMPLETE indicates that the credentials were successfully stored. o GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials had expired or expired before they could be stored. o GSS_S_NO_CRED indicates that no input credentials were given. o GSS_S_UNAVAILABLE indicates that the credential store is not available. o GSS_S_DUPLICATE_ELEMENT indicates that an element of the input credential could not be stored because a credential for the same principal exists in the current credential store and the overwrite_cred input argument was FALSE. o GSS_S_FAILURE indicates that the credential could not be stored for some other reason. The minor status code may provide more information if a non-GSS_C_NULL_OID desired_mech_element was given. GSS_Store_cred() is used to store, in the current credential store, a given credential that has either been acquired from a different credential store or been accepted as a delegated credential. Specific mechanism elements of a credential can be stored one at a time by specifying a non-GSS_C_NULL_OID mechanism OID as the desired_mech_element input argument, in which case the minor status output SHOULD have a mechanism-specific value when the major status is not GSS_S_COMPLETE. The initiator, acceptor or both usages of the input credential may be stored as per the cred_usage input argument. The credential elements that were actually stored, when the major status is GSS_S_COMPLETE, are indicated through the cred_usage_stored and mech_elements_stored function outputs. If credentials already exist in the current store for the principal of the input_cred_handle, then those credentials are not replaced with the input credentials unless the overwrite_cred input argument is TRUE. Finally, if the current credential store has no default credential (that is, no credential that could be acquired for GSS_C_NO_NAME) or if the default_cred input argument is TRUE, and the input credential can be successfully stored, then the input credential will be available for acquisition with GSS_C_NO_NAME as the desired name input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(), GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and GSS_Accept_sec_context(). N. Williams [Page 5] DRAFT GSS_Store_cred() Expires March 2004 2.1 C-Bindings for GSS_Store_cred() The C-bindings for GSS_Store_cred() make use of types from and are designed based on the style of the GSS-APIv2 C-Bindings [RFC2744]. OM_uint32 gss_store_cred( OM_uint32 *minor_status, gss_cred_id_t input_cred, gss_cred_usage_t cred_usage, const gss_OID desired_mech, OM_uint32 overwrite_cred, OM_uint32 default_cred, gss_OID_set *elements_stored, gss_cred_usage_t *cred_usage_stored) The two boolean arguments, 'overwrite_cred' and 'default_cred' are typed as OM_uint32; 0 corresponds to FALSE, non-zero values correspond to TRUE. 3 Examples The intended usage of GSS_Store_cred() is to make delegated credentials available to child processes of GSS-API acceptor applications. Example pseudo-code: /* * * * <"requested_username" is a username derived from the initiator * name or explicitly requested by the initiator application.> */ ... if (authorize_gss_client(src_name, requested_username)) { /* * For Unix-type platforms this may mean calling setuid() and it * may or may not also mean setting/unsetting such environment * variables as KRB5CCNAME and what not. */ if (change_user_context(requested_username)) (void) gss_store_creds(&minor_status, deleg_cred, GSS_C_INITIATE, actual_mech, 0, 1, NULL, NULL); } else ... } else ... 4 Security Considerations N. Williams [Page 6] DRAFT GSS_Store_cred() Expires March 2004 Acceptor applications MUST only store delegated credentials into appropriate credential stores and only after proper authorization of the authenticated initiator principal to the requested service(s). Acceptor applications that have no use for delegated credentials MUST release them (such acceptor applications that use the GSS-API C-Bindings may simply provide a NULL value for the delegated_cred_handle argument to gss_accept_sec_context()). 5 References 5.1 Normative References [RFC2026] S. Bradner, RFC2026: "The Internet Standard Process - Revision 3," October 1996, Obsoletes - RFC 1602, Status: Best Current Practice. [RFC2119] S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to Indicate Requirement Levels," March 1997, Status: Best Current Practice. [RFC2743] J. Linn, RFC2743: "Generic Security Service Application Program Interface Version 2, Update 1," January 2000, Status: Proposed Standard. [RFC2744] J. Wray, RFC2744: "Generic Security Service API Version 2 : C-bindings," January 2000, Status: Proposed Standard. 6 Author's Address Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 Email: Nicolas.Williams@sun.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of N. Williams [Page 7] DRAFT GSS_Store_cred() Expires March 2004 developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. N. Williams [Page 8] -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 19 16:20:43 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11730 for ; Wed, 19 May 2004 16:20:40 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i4JKBPUT023638 for ietf-cat-wg-out720680; Wed, 19 May 2004 13:11:25 -0700 (PDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i4JKBJNK023622 for ; Wed, 19 May 2004 13:11:19 -0700 (PDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i4JKAPLr019903; Wed, 19 May 2004 13:10:25 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i4JKA9cE022097; Wed, 19 May 2004 14:10:09 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i4JK7fO5804941; Wed, 19 May 2004 15:07:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i4JK7fTe804940; Wed, 19 May 2004 15:07:41 -0500 (CDT) Date: Wed, 19 May 2004 15:07:41 -0500 From: Nicolas Williams To: Internet-Drafts@ietf.org Cc: Jeffrey Altman , ietf-cat-wg@lists.Stanford.EDU Subject: draft-williams-gssapi-stackable-pseudo-mechs-00.txt Message-ID: <20040519200741.GM488605@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Network Working Group Nicolas Williams INTERNET-DRAFT Sun Microsystems November 2004 Stackable Generic Security Service Pseudo-Mechanisms Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines and formalizes the concept of stackable pseudo- mechanisms for the Generic Security Service Application Programming Interface (GSS-API) and introduces a framework to support stackable pseudo-mechanisms and mechanism compositing. Stackable GSS-API pseudo-mechanisms allow for the composition of new mechanisms that combine features from multiple mechanisms. Stackable mechanisms that add support for Perfect Forward Security (PFS), data compression, additional authentication factors, etc... are facilitated by this document. Table of Contents 1. Introduction pg. 3 1.1. Glossary pg. 3 2. Issues with Mechanism Composition pg. 4 N. Williams [Page 1] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 3. Mechanism Composition pg. 5 3.1. Construction of Composed Mechanism OIDs pg. 5 3.2. Mechanism Composition Rules pg. 6 3.3. Interfacing with Composite Mechanisms pg. 6 3.4. Compatibility with the Basic GSS-API Interfaces pg. 7 3.5. Processing of Tokens for Composite Mechanisms pg. 7 4. New GSS-API Interfaces pg. 8 4.1. Mechanism Attributes and Attribute Sets pg. 8 4.1.1. Determination of Attribute Sets of Composite Mechs pg. 9 4.1.2. Initial Set of Known Mechanism Attributes pg. 9 4.1.3. Mechanism Attribute Sets of Existing Mechs pg. 11 4.2. New GSS-API Function Interfaces pg. 12 4.2.1. GSS_Indicate_mechs_by_mech_attrs() pg. 12 4.2.2. GSS_Inquire_mech_attrs_for_mech() pg. 13 4.2.3. GSS_Display_mech_attr() pg. 14 4.2.4. GSS_Compose_oid() pg. 15 4.2.5. GSS_Decompose_oid() pg. 15 4.2.6. GSS_Release_oid() pg. 16 4.2.7. GSS_Indicate_negotiable_mechs() pg. 16 4.2.8. GSS_Negotiate_mechs() pg. 17 4.3. New Major Status Values pg. 18 4.4. C-Bindings pg. 18 5. Negotiation of Composite Mechanisms pg. 19 5.1. Negotiation of Composite Mechanisms Through SPNEGO pg. 20 6. Requirements for Mechanism Designers pg. 20 7. IANA Considerations pg. 20 8. Security considerations pg. 20 9. References pg. 21 9.1. Informative references pg. 21 9.2. Normative references pg. 21 10. Author's Address pg. 21 N. Williams [Page 2] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1. Introduction Recent discussions within the IETF have shown the need for a refactoring of the features that GSS-API mechanisms may provide and a way to compose new mechanisms from smaller components. Mechanism features are more formally referred to as "mechanism attributes" below. The terms "feature" and mechanism attribute" are sometimes used interchangeably. One way to do this is to "stack" multiple mechanisms on top of each other such that the features of all of them are summed into a new, composite mechanism. One existing GSS-API mechanism, LIPKEY [LIPKEY], is essentially stacked over another, SPKM-3 [LIPKEY], although LIPKEY does not conform to the stackable pseduo-mechanism framework described herein. The first truly stackable pseudo-mechanism proposed, CCM [CCM] was for signalling the willingness of an initiator and/or acceptor to utilize channel bindings as well as to correctly implement channel bindings. Since then other similar mechanism compositing needs and ideas have come up, along with problems such as "what combinations are possible, useful, reasonable and secure?" Problems which we believe are solved herein. Therefore the time has come to define the concept of GSS-API mechanism compositing through the use of stackable pseudo-mechanisms. 1.1. Glossary Concrete GSS-API mechanism A mechanism which can be used standalone. Examples include: the Kerberos V mechanism [CFX], SPKM-1/2 [SPKM] and SPKM-3 [LIPKEY]. GSS-API Pseudo-mechanism A mechanism which uses other mechanisms in the construction of its context and/or per-message tokens and security contexts. SPNEGO is an example of this. N. Williams [Page 3] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 Stackable GSS-API pseudo-mechanism A mechanism which uses a single other mechanism in the construction of its tokens such that the OID of the composite result can be constructed by prepending the OID of the stackable pseudo-mechanism to the OID of the mechanism to be used by it. Mechanism-negotiation GSS-API pseudo-mechanism A GSS-API mechanism that negotiates the use of GSS-API mechanisms. SPNEGO [SPNEGO] is an example of this. 2. Issues with Mechanism Composition Interfacing with composite mechanisms through the existing GSS-API interfaces and the handling of composite mechanism tokens is straightforward enough and described in section 3. However, the concepts of stackable and composite mechanisms do give rise to several minor problems: - How to determine allowable combinations of mechanisms; - How to encode composite mechanism OIDs; - How to decompose the OID of a composite mechanism and process its tokens properly; - Application interfacing issues such as: - Whether and/or which composite mechanisms should be listed by GSS_Indicate_mechs(); - Whether and/or which composite mechanisms not listed by GSS_Indicate_mechs() may nonetheless be available for use by applications and how applications can detect their availability; - What additional interfaces should be provided to help applications select appropriate mechanisms; - Mechanism negotiation issues (related to the application interface issues listed above), such as: - Should applications advertise composite mechanisms in SPNEGO or other application-specific mechanism negotiation contexts? - Or should applications advertise concrete and stackable pseudo- mechanisms in SPNEGO or other application-specific mechanism negotiation contexts? N. Williams [Page 4] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 Section 3 addresses the OID composition, decomposition and encoding issues, as well as basic interfacing and token handling issues. Section 4 addresses the application interfacing issues. Section 5 addresses the mechanism negotiation issues. 3. Mechanism Composition Mechanism composition by stacking pseudo-mechanisms on a concrete mechanism is conceptually simple: join the OIDs of the several mechanisms in question and process GSS-API tokens and routine calls through the top-most pseudo-mechanism in a stack, which can then, if necessary, do the same with the remainder of the stack. Some stackable pseudo-mechanisms may do nothing more than perform transformations on application data (e.g., compression); such pseudo-mechanisms will generally chain the processing of tokens and routine calls to the mechanisms below them in the stack. Other stackable pseudo-mechanisms may utilize the mechanisms below them only during security context setup. For example, a stackable pseudo-mechanism could perform a Diffie-Hellman key exchange and authenticate it by binding a security context established with the mechanism stacked below it; such a mechanism would provide its own per-message tokens. 3.1. Construction of Composed Mechanism OIDs Composition of mechanism OIDs is simple: prepend the OID of one pseudo-mechanism to the OID of another mechanism (composite or otherwise), but there MUST always be at least one final mechanism OID and it MUST be useful standalone (i.e., it MUST NOT be a pseudo-mechanism). A composite mechanism OID forms, essentially, a stack. The encoding of composed mechanism OIDs is not quite the concatenation of the component OIDs' encodings, however. This is because the first two arcs of ASN.1 OIDs are encoded differently from subsequent arcs (the first two arcs have a limited namespace and are encoded as a single octet), so were composite mechanism OIDs to be encoded as the concatenation of the component OIDs the result would not decode as the concatenation of the component OIDs. To avoid this problem the first two arcs of each component of a composite mechanism OID, other than the leading component, will be encoded as other arcs would. Decomposition of mechanism OIDs is similar, with each pseudo- mechanism in the stack being able to determine the OID suffix from knowledge of its own OID(s), from the composite mechanism OID in its OID or OID SET arguments and from the the composite OID from the initial context token for a given context. N. Williams [Page 5] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 New pseudo-mechanisms MAY be allocated OIDs from the prefix given below as follows by assignment of a sub-string of OID arcs to be appended to this prefix. This prefix OID is: [1.3.6.1.5.5.11 appears to be available, registration w/ IANA TBD] All OID allocations below this OID MUST be for stackable pseudo- mechanisms and MUST consist of a single arc. This will make it possible to decompose the OIDs of composite mechanisms without necessarily knowing a priori the OIDs of the component stackable pseudo-mechanisms. 3.2. Mechanism Composition Rules All new stackable pseudo-mechanisms MUST specify the rules for determining whether they can stack above a given mechanism, composite or otherwise. Such rules may be based on specific mechanism attribute sets and/or specific OIDs (composite and otherwise) of mechanisms stacked below them. All stackable pseudo-mechanisms MUST have the following mechanism composition rule relating to unknown mechanism attributes: - composition with mechanisms supporting unknown mechanism attributes MUST NOT be permitted. This rule protects against compositions which cannot be considered today but which might nonetheless arise due to the introduction of new mechanisms and which might turn out to be insecure or otherwise undesirable. Mechanism composition rules for stackable pseudo-mechanisms MAY and SHOULD be updated as new GSS-API mechanism attributes and mechanisms sporting them are introduced. The specifications of mechanisms that introduce new mechanism attributes or which otherwise should not be combined with others in ways which would be permitted under existing rules SHOULD also update the mechanism composition rules of affected pseudo-mechanisms. 3.3. Interfacing with Composite Mechanisms The basic GSS-API [RFC2743] interfaces MUST NOT accept as input or provide as output the OID of any stackable pseudo-mechanism. Composite mechanisms MUST be treated as concrete mechanisms by the basic GSS-API interfaces [RFC2743]. Thus the way in which a composite mechanism is used by applications with the basic GSS-API (version 2, update 1) is straightforward, exactly as if composite mechanisms were normal GSS-API mechanisms. This is facilitated by the fact that in all cases where the GSS-API N. Williams [Page 6] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 implementation might need to know how to process or create a token it has the necessary contextual information, the mechanism OID, available and can decompose composite mechanism OIDs as necessary. For example, for initial GSS_Init_sec_context() calls the implementation knows the desired mechanism OID, and if it should be left unspecified, it can pick a default mechanism given the initiator credentials provided by the application (and if none are provided other default mechanism and credential selections can still be made). For subsequent calls to GSS_Init_sec_context() the implementation knows which mechanism to use from the given [partially established] security context. Similarly for GSS_Accept_sec_context, where on initial calls the mechanism OID can be determined from the given initial context token's framing. The manner in which GSS-API implementations and the various mechanisms and pseudo-mechanisms interface with one another is more interesting; it is also left as an excercise to implementors. 3.4. Compatibility with the Basic GSS-API Interfaces In order to preserve backwards compatibility with applications that use only the basic GSS-API interfaces (version 2, update 1), several restrictions are imposed on the use of composite and stackable pseduo-mechanisms with the basic GSS-API interfaces: o GSS_Indicate_mechs() MUST NOT indicate support for any stackable pseduo-mechanisms under any circumstance. o GSS_Indicate_mechs() MAY indicate support for some, all or none of the available composite mechanisms. o Which composite mechanisms, if any, are indicated through GSS_Indicate_mechs() SHOULD be configurable. o GSS_Acquire_cred() and GSS_Add_cred() MUST NOT create credentials for composite mechanisms not explicitly requested or, if GSS_C_NULL_OID is given as a desired for composite mechanisms not indicated by GSS_Indicate_mechs(). o GSS_Acquire_cred() and GSS_Add_cred() MUST NOT (and truly cannot) create credentials for stackable pseudo-mechanisms. 3.5. Processing of Tokens for Composite Mechanisms The initial context token for any mechanism, composite or otherwise, MUST be encapsulated as described in section 3.1 of rfc2743 [RFC2743], and the OID used in that framing MUST be that of the mechanism, but in the case of composite mechanisms this OID MUST be the OID of the leading component of the composite mechanism. Note that this has implications for multi-mechanism implementations of the GSS-API, namely that acceptors MUST route initial context N. Williams [Page 7] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 tokens to the appropriate mechanism and they MUST allow that mechanism to determine the composite mechanism OID (such as by allowing that mechanism's GSS_Accept_sec_context() to output the actual mechanism to the application. In all other cases the mechanism that produced a given token can be determined by the given security context. 4. New GSS-API Interfaces GSS-API applications face, today, the problem of how to select from multiple GSS-API mechanisms that may be available. This problem is likely to be exacerbated by the introduction of stackable. To address this problem we introduce a new concept: that of mechanism attributes. By allowing applications to query the set of attributes associated with individual mechanisms and to find out which mechanisms support a given set of attributes we allow applications to select mechanisms based on their attributes yet without having to hardcode mechanism OIDs. Section 4.1 describes the mechanism mechanism attributes concept. Sections 4.2.1, 4.2.2 and 4.2.3 describe three new interfaces that deal in mechanisms and attribute sets: - GSS_Indicate_mechs_by_attrs() - GSS_Inquire_attrs_for_mech() - GSS_Display_mech_attr() Additional utility functions for mechanism OID composition and decomposition are given in sections 4.2.4, 4.2.5 and 4.2.6. Finally, two utility functions, GSS_Indicate_negotiable_mechs() and GSS_Negotiate_mechs(), to aid applications in mechanism negotiation are described in sections 4.2.7 and 4.2.8. These two interfaces may be implemented entirely in terms of the other interfaces described herein. 4.1. Mechanism Attributes and Attribute Sets An abstraction for the features provided by pseudo-mechanisms is needed in order to facilitate the programmatic composition of mechanisms. Two data types are needed: one for individual mechanism attributes and one for mechanism attribute sets. To simplify the mechanism attributes interfaces we reuse the 'OID' and 'OID set' data types and model individual mechanism attribute types as OIDs. To this end we define an open namespace of mechanism attributes and assign them arcs off of this OID: N. Williams [Page 8] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 [1.3.6.1.5.5.12 appears to be available, registration w/ IANA TBD] 4.1.1. Determination of Attribute Sets of Composite Mechs Each mechanism, composite or otherwise, has a set of mechanism attributes that it supports as specified. The mechanism attribute set of a composite mechanism is to be determined by the top-most stackable pseudo-mechanism of the composite according to its own attribute set and that of the mechanism stacked directly below it. It may well be that some composite mechanisms' attribute sets consist of the union of those of their every component, however this need not be the case and should not be assumed. Every stackable pseudo-mechanism's specification MUST specify the rules for determining the mechanism attribute set of mechanisms composed by it. 4.1.2. Initial Set of Known Mechanism Attributes Mech Attr name OID Arc Arc name -------------- ------- -------- GSS_C_MA_MECH_CONCRETE (1) concrete-mech GSS_C_MA_MECH_STACKABLE (2) pseudo-mech GSS_C_MA_MECH_COMPOSITE (3) composite-mech GSS_C_MA_MECH_NEGO (4) mech-negotiation-mech GSS_C_MA_MECH_GLUE (5) mech-glue GSS_C_MA_NOT_MECH (6) not-mech GSS_C_MA_DEPRECATED (7) mech-deprecated GSS_C_MA_NOT_DFLT_MECH (8) mech-not-default GSS_C_MA_ITOK_NOT_FRAMED (9) initial-token-not-framed GSS_C_MA_AUTH_INIT (10) auth-init-princ GSS_C_MA_AUTH_TARG (11) auth-targ-princ GSS_C_MA_AUTH_INIT_INIT (12) auth-init-princ-initial GSS_C_MA_AUTH_TARG_INIT (13) auth-targ-princ-initial GSS_C_MA_AUTH_INIT_ANON (14) auth-init-princ-anon GSS_C_MA_AUTH_TARG_ANON (15) auth-targ-princ-anon GSS_C_MA_DELEG_CRED (16) deleg-cred GSS_C_MA_INTEG_PROT (17) integ-prot GSS_C_MA_CONF_PROT (18) conf-prot GSS_C_MA_PROT_READY (19) prot-ready GSS_C_MA_REPLAY_DET (20) replay-detection GSS_C_MA_OOS_DET (21) oos-detection GSS_C_MA_CBINDINGS (22) channel-bindings GSS_C_MA_CBINDINGS_BIDI (23) channel-bindings-bidirectional GSS_C_MA_CBINDINGS_NEGO (24) channel-bindings-negotiate GSS_C_MA_PFS (25) pfs GSS_C_MA_COMPRESS (26) compress (27..) N. Williams [Page 9] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 Mech Attr name Purpose -------------- ------- GSS_C_MA_MECH_CONCRETE Indicates that a mech is neither a pseudo- mechanism nor a composite mechanism. GSS_C_MA_MECH_STACKABLE Indicates that a mech is a pseudo-mechanism. GSS_C_MA_MECH_COMPOSITE Indicates that a mech is a composite mechanism. GSS_C_MA_MECH_NEGO Indicates that a mech negotiates other mechs (e.g., SPNEGO has this attribute). GSS_C_MA_MECH_GLUE Indicates that the OID is not for a mechanism but for the GSS-API itself. GSS_C_MA_NOT_MECH Indicates that the OID is known, yet also known not to be the OID of any GSS-API mechanism (or the GSS-API itself). GSS_C_MA_DEPRECATED Indicates that a mech (or its OID) is deprecated and MUST NOT be used as a default mechanism. GSS_C_MA_NOT_DFLT_MECH Indicates that a mech (or its OID) MUST NOT be used as a default mechanism. GSS_C_MA_ITOK_NOT_FRAMED Indicates that the given mechanism's initial context tokens are not properly framed as per-section 3.1 of rfc2743. GSS_C_MA_AUTH_INIT Indicates support for authentication of initiator to acceptor. GSS_C_MA_AUTH_TARG Indicates support for authentication of acceptor to initiator. GSS_C_MA_AUTH_INIT_INIT Indicates support for initial authentication of initiator to acceptor. GSS_C_MA_AUTH_TARG_INIT Indicates support for initial authentication of acceptor to initiator. GSS_C_MA_AUTH_INIT_ANON Indicates support for initiator anonymity. GSS_C_MA_AUTH_TARG_ANON Indicates support for acceptor anonymity. GSS_C_MA_DELEG_CRED Indicates support for credential delegation. GSS_C_MA_INTEG_PROT Indicates support for per-message integrity protection. GSS_C_MA_CONF_PROT Indicates support for per-message confidentiality protection. GSS_C_MA_PROT_READY Indicates support for per-message protection prior to full context establishment. N. Williams [Page 10] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 GSS_C_MA_REPLAY_DET Indicates support for replay detection. GSS_C_MA_OOS_DET Indicates support for out-of-sequence detection. GSS_C_MA_CBINDINGS Indicates support for channel bindings. GSS_C_MA_CBINDINGS_BIDI Indicates support for bidirectional channel bindings. GSS_C_MA_CBINDINGS_NEGO Indicates that the mech acts as a signal for application support for and willingness to use channel bindings. GSS_C_MA_PFS Indicates support for Perfect Forward Security. GSS_C_MA_COMPRESS Indicates support for compression of data inputs to GSS_Wrap(). 4.1.3. Mechanism Attribute Sets of Existing Mechs The Kerberos V mechanism [RFC1964] [CFX] provides the following mechanism attributes: GSS_C_MA_MECH_CONCRETE GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_PROT_READY (varies by initiator implementation) GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS The Kerberos V mechanism also has a deprecated OID which has the same mechanism attributes as above, and GSS_C_MA_DEPRECATED. [The mechanism attributes of the SPKM family of mechanisms will be provided in a separate document as SPKM is current being reviewed for possibly significant changes due to problems in its specifications.] The LIPKEY mechanism offers the following attributes: GSS_C_MA_MECH_CONCRETE (should be stackable, but does not compose) GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG (from SPKM-3) GSS_C_MA_AUTH_TARG_ANON (from SPKM-3) GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET (LIPKEY should also provide GSS_C_MA_CBINDINGS, but SPKM-3 N. Williams [Page 11] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 requires clarifications on this point.) The SPNEGO mechanism [SPNEGO] provides the following attribute: GSS_C_MA_MECH_NEGO All other mechanisms' attrivutes will be described elsewhere. 4.2. New GSS-API Function Interfaces Several new interfaces are given by which, for example, GSS-API applications may determine what features are provided by a given mechanism, what mechanisms provide what features and what compositions are legal. These new interfaces are all OPTIONAL. In order to preserve backwards compatibility with applications that do not use the new interfaces GSS_Indicate_mechs() MUST NOT indicate support for any stackable pseduo-mechanisms. GSS_Indicate_mechs() MAY indicate support for some, all or none of the available composite mechanisms; which composite mechanisms, if any, are indicated through GSS_Indicate_mechs() SHOULD be configurable. GSS_Acquire_cred() and GSS_Add_cred() MUST NOT create credentials for composite mechanisms not explicitly requested or, if no desired mechanism or mechanisms are given, for composite mechanisms not indicated by GSS_Indicate_mechs(). Applications SHOULD use GSS_Indicate_mechs_by_mech_attrs() instead of GSS_Indicate_mechs() wherever possible. Applications can use GSS_Indicate_mechs_by_mech_attrs() to determine what, if any, mechanisms provide a given set of features. GSS_Indicate_mechs_by_mech_attrs() can also be used to indicate (as in GSS_Indicate_mechs()) the set of available mechanisms of each type (concrete, mechanism negotiation pseudo-mechanism, stackable pseudo-mechanism and composite mechanisms). Applications may use GSS_Inquire_mech_attrs_for_mech() to test whether a given composite mechanism is available and the set of features that it offers. GSS_Negotiate_mechs() may be used to negotiate the use of mechanisms such that composite mechanisms need not be advertised but instead be implied by offering stackable pseudo-mechanisms. 4.2.1. GSS_Indicate_mechs_by_mech_attrs() Inputs: o desired_mech_attrs SET OF OBJECT IDENTIFIER -- set of GSS_C_MA_* -- OIDs that the mechanisms indicated in the mechs output parameter N. Williams [Page 12] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 -- MUST offer. o except_mech_attrs SET OF OBJECT IDENTIFIER -- set of GSS_C_MA_* -- OIDs that the mechanisms indicated in the mechs output parameter -- MUST NOT offer. Outputs: o major_status INTEGER, o minor_status INTEGER, o mechs SET OF OBJECT IDENTIFIER -- set of mechanisms that support -- the desired_mech_attrs but not the except_mech_attrs. Return major_status codes: o GSS_S_COMPLETE indicates success; the output mechs parameter MAY be the empty set (GSS_C_NO_OID_SET). o GSS_BAD_MECH_ATTR indicates that at least one mechanism attribute OID in desired_mech_attrs or except_mech_attrs is unknown to the implementation. o GSS_S_FAILURE indicates that the request failed for some other reason. GSS_Indicate_mechs_by_mech_attrs() returns the set of mechanism OIDs that offer at least the desired_mech_attrs but none of the except_mech_attrs. When desired_mech_attrs and except_mech_attrs are the empty set this function acts as a version of GSS_indicate_mechs() that outputs the set of all supported mechanisms of all types. By setting the desired_mechs input parameter to a set of a single GSS_C_MA_MECH* feature applications can obtain the list of all supported mechanisms of a given type (concrete, stackable, etc...). 4.2.2. GSS_Inquire_mech_attrs_for_mech() Inputs: o mech OBJECT IDENTIFIER -- mechanism OID Outputs: o major_status INTEGER, o minor_status INTEGER, o mech_attrs SET OF OBJECT IDENTIFIER -- set of mech_attrs OIDs -- (GSS_C_MA_*) N. Williams [Page 13] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 Return major_status codes: o GSS_S_COMPLETE indicates success; the output mech_attrs parameter MAY be the empty set (GSS_C_NO_OID_SET). o GSS_S_BAD_MECH indicates that the mechanism named by the mech parameter does not exist or that mech is GSS_C_NO_OID and no default mechanism could be determined. o GSS_S_FAILURE indicates that the request failed for some other reason. GSS_Inquire_mech_attrs_for_mech() indicates the set of mechanism attributes supported by a given mechanism. Because the mechanism attribute sets of composite mechanisms need not be the union of their components', when called to obtain the feature set of a composite mechanism GSS_Inquire_mech_attrs_for_mech() obtains it by querying the mechanism at the top of the stack. See section 4.1. 4.2.3. GSS_Display_mech_attr() Inputs: o mech_attr OBJECT IDENTIFIER -- mechanism attribute OID Outputs: o major_status INTEGER, o minor_status INTEGER, o name OCTET STRING, -- name of mechanism attribute (e.g., -- GSS_C_MA_*) o short_desc OCTET STRING, -- a short description of the mechanism -- attribute o long_desc OCTET STRING -- a longer description of the mechanism -- attribute Return major_status codes: o GSS_S_COMPLETE indicates success. o GSS_S_BAD_MECH_ATTR indicates that the mechanism attribute referenced by the mech_attr parameter is unknown to the implementation. o GSS_S_FAILURE indicates that the request failed for some other reason. N. Williams [Page 14] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 This function can be used to obtain human-readable descriptions of GSS-API mechanism attributes. 4.2.4. GSS_Compose_oid() Inputs: o mech1 OBJECT IDENTIFIER, -- mechanism OID o mech2 OBJECT IDENTIFIER -- mechanism OID Outputs: o major_status INTEGER, o minor_status INTEGER, o composite OBJECT IDENTIFIER -- OID composition of mech1 with -- mech2 ({mech1 mech2}) Return major_status codes: o GSS_S_COMPLETE indicates success. o GSS_S_BAD_MECH indicates that mech1 is not supported. o GSS_S_FAILURE indicates that the request failed for some other reason. The minor status will be specific to mech1 and may provide further information. 4.2.5. GSS_Decompose_oid() Inputs: o input_mech OBJECT IDENTIFIER, -- mechanism OID. o mechs SET OF OBJECT IDENTIFIER -- mechanism OIDs (if -- GSS_C_NULL_OID_SET defaults to the set of stackable -- pseudo-mechanism OIDs indicated by -- GSS_Indicate_mechs_by_mech_attrs()). Outputs: o major_status INTEGER, o minor_status INTEGER, o lead_mech OBJECT IDENTIFIER, -- leading stackable pseudo- -- mechanism OID. o trail_mech OBJECT IDENTIFIER -- input_mech with lead_mech removed -- from the front. N. Williams [Page 15] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 Return major_status codes: o GSS_S_COMPLETE indicates success. o GSS_S_BAD_MECH indicates that the input_mech could not be decomposed as no stackable pseudo-mechanism is available whose OID is a prefix of the input_mech. o GSS_S_FAILURE indicates that the request failed for some other reason. 4.2.6. GSS_Release_oid() The following text is adapted from the obsoleted rfc2078 [RFC2078]. Inputs: o oid OBJECT IDENTIFIER Outputs: o major_status INTEGER, o minor_status INTEGER Return major_status codes: o GSS_S_COMPLETE indicates successful completion o GSS_S_FAILURE indicates that the operation failed Allows the caller to release the storage associated with an OBJECT IDENTIFIER buffer allocated by another GSS-API call, specifically GSS_Compose_oid() and GSS_Decompose_oid(). This call's specific behavior depends on the language and programming environment within which a GSS-API implementation operates, and is therefore detailed within applicable bindings specifications; in particular, this call may be superfluous within bindings where memory management is automatic. 4.2.7. GSS_Indicate_negotiable_mechs() Inputs: o input_cred_handle CREDENTIAL HANDLE, -- credential handle to be -- used with GSS_Init_sec_context(); may be GSS_C_NO_CREDENTIAL. o peer_type_known BOOLEAN, -- indicates whether the peer is known -- to support or not supprot the stackable pseudo-mechanism -- framework. o peer_has_mech_stacking BOOLEAN -- indicates whether the peer -- supports the stackable pseudo-mechanism framework; ignore if N. Williams [Page 16] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 -- peer_type_known is FALSE. Outputs: o major_status INTEGER, o minor_status INTEGER, o offer_mechs SET OF OBJECT IDENTIFIER, -- mechanisms to offer. Return major_status codes: o GSS_S_COMPLETE indicates success. o GSS_S_NO_CREDENTIAL indicates that the caller's credentials are expired or, if input_cred_handle is GSS_C_NO_CREDENTIAL, that no credentials could be acquired for GSS_C_NO_NAME. o GSS_S_FAILURE indicates that the request failed for some other reason. This function produces a set of mechanism OIDs, optimized for space, that its caller should advertise to peers during mechanism negotiation. The output offer_mechs parameter will include all of the mechanisms for which the input_cred_handle has elements (as indicated by GSS_Inquire_cred()), but composite mechanisms will be included either implicitly or implicitly as per the following rules: - if peer_type_known is TRUE and peer_has_mech_stacking is FALSE then no composite mechanisms not indicated by GSS_Indicate_mechs() will be advertised, explictly or implicitly; - if peer_type_known is FALSE then all composite mechanisms indicated by GSS_Indicate_mechs() for which input_cred_handle has elements will be indicated in offer_mechs explicitly and all others may be indicated in offer_mechs implicitly, by including their component stackable pseduo-mechanism OIDs (see below); - if peer_type_known is TRUE and peer_has_mech_stacking is TRUE composite mechanisms will generally not be advertised explicitly, but will be advertised implicitly, by including their component stackable pseduo-mechanism OIDs (see below); no composite mechanisms will be advertised explicitly - if the input_cred_handle does not have elements for all of the possible composite mechanisms that could be constructed from the its elements' decomposed mechanisms, then all composite mechanisms for which the input_cred_handle does have elements will be advertised explicitly in offer_mechs. 4.2.8. GSS_Negotiate_mechs() N. Williams [Page 17] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 Inputs: o input_credential_handle CREDENTIAL HANDLE, -- mechanisms offered -- by the caller. o peer_mechs SET OF OBJECT IDENTIFIER -- mechanisms offered by -- the caller's peer. Outputs: o major_status INTEGER, o minor_status INTEGER, o mechs SET OF OBJECT IDENTIFIER -- mechanisms common to the -- caller's credentials and the caller's peer. Return major_status codes: o GSS_S_COMPLETE indicates success; the output mechs parameter MAY be the empty set (GSS_C_NO_OID_SET). o GSS_S_NO_CREDENTIAL indicates that the caller's credentials are expired or, if input_cred_handle is GSS_C_NO_CREDENTIAL, that no credentials could be acquired for GSS_C_NO_NAME. o GSS_S_FAILURE indicates that the request failed for some other reason. This function matches the mechanisms for which the caller has credentials with the mechanisms offered by the caller's peer and returns the set of mechanisms in common to both, accounting for any composite mechanisms offered by the peer implicitly. 4.3. New Major Status Values A single new major status code is added for GSS_Display_mech_attr(): GSS_S_BAD_MECH_ATTR roughly corresponding to GSS_S_BAD_MECH, but applicable to mechanism attribute OIDs, rather than to mechanism OIDs. For the C-bindings GSS_S_BAD_MECH_ATTR shall have a routine error number of 19 (this is shifted to the left by GSS_C_ROUTINE_ERROR_OFFSET). 4.4. C-Bindings #define GSS_S_BAD_MECH_ATTR (19ul << GSS_C_ROUTINE_ERROR_OFFSET) OM_uint32 gss_inquire_mechs_for_mech_attrs( N. Williams [Page 18] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 OM_uint32 *minor_status, const gss_OID_set desired_mech_attrs, gss_OID_set *mechs); OM_uint32 gss_inquire_mech_attrs_for_mech( OM_uint32 *minor_status, const gss_OID mech, gss_OID_set *mech_attrs); OM_uint32 gss_display_mech_attr( OM_uint32 *minor_status, const gss_OID mech_attr, gss_buffer_t name, gss_buffer_t short_desc, gss_buffer_t long_desc); OM_uint32 gss_compose_oid( OM_uint32 *minor_status, const gss_OID mech1, const gss_OID mech2, gss_OID *composite); OM_uint32 gss_decompose_oid( OM_uint32 *minor_status, const gss_OID input_mech, const gss_OID_set mechs, gss_OID *lead_mech, gss_OID *trail_mech); OM_uint32 gss_release_oid( OM_uint32 *minor_status, gss_OID *oid); OM_uint32 GSS_Indicate_negotiable_mechs( OM_uint32 *minor_status, const gss_cred_id_t input_cred_handle, OM_uint32 peer_type_known, OM_uint32 peer_has_mech_stacking, gss_OID_set *offer_mechs); OM_uint32 gss_negotiate_mechs( OM_uint32 *minor_status, const gss_cred_id_t input_cred_handle, const gss_OID_set peer_mechs, const gss_OID_set *mechs); 5. Negotiation of Composite Mechanisms Where GSS-API implementations do not support the stackable mechanism framework interfaces applications may only negotiate explicitly from a set of concrete and composite mechanism OIDs as indicated by GSS_Indicate_mechs() and for which suitable credentials are available. GSS_Indicate_mechs(), as described in section 3.4, MUST N. Williams [Page 19] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 NOT indicate support for individual stackable pseudo-mechanisms, so there will not be any composite mechanisms implied but not explicitly offered in the mechanism negotiation. Applications that support the stackable mechanism framework SHOULD use GSS_Indicate_negotiable_mechs() to construct the set of mechanism OIDs to offer to their peers. GSS_Indicate_negotiable_mechs() optimizes for bandwidth consumption by using decomposed OIDs instead of composed OIDs, where possible. See section 4.2.7. Peers that support the stackable mechanism framework interfaces SHOULD use GSS_Negotiate_mechs() to select a mechanism as that routine accounts for composite mechanisms implicit in the mechanism offers. 5.1. Negotiation of Composite Mechanisms Through SPNEGO SPNEGO applications MUST advertise either the set of mechanism OIDs for which they have suitable credentials or the set of mechanism OIDs produced by calling GSS_Indicate_negotiable_mechs() with the available credentials and the peer_type_known parameter as FALSE. 6. Requirements for Mechanism Designers Stackable pseudo-mechanisms specifications MUST: - list the set of GSS-API mechanism attributes associated with them - list their initial mechanism composition rules - specify a mechanism for updating their mechanism composition rules All other mechanism specifications MUST: - list the set of GSS-API mechanism attributes associated with them 7. IANA Considerations The namsepace of programming language symbols with names beginning with GSS_C_MA_* is reserved for allocation by the IANA. Allocation of arcs in the namespace of OIDs relative to the base mechanism attribute OID specified in section 4 is reserved to the IANA. Allocation of arcs in the namespace of OIDs relative to the base stackable pseduo-mechanism OID specified in section 3 is reserved to the IANA. 8. Security considerations Some composite mechanisms may well not be secure. The mechanism composition rules of pseudo-mechanisms (including the default N. Williams [Page 20] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 composition rule given in section 3 for unknown mechanism attributes) should be used to prevent the use of unsafe composite mechanisms. Designers of pseudo-mechanisms should study the possible combinations of their mechanisms with others and design mechanism composition rules accordingly. Similarly, pseudo-mechanism designers MUST specify, and implementors MUST implement, composite mechanism attribute set determination rules appropriate to the subject pseduo-mechanism, as described in section 4.1.1. Failure to do so may lead to inappropriate composite mechanisms being deemed permissible by programmatic application of flawed mechanism composition rules or to by their application with incorrect mechanism attribute sets. 9. References 9.1. Informative references [?] ... 9.2. Normative references [RFC2026] S. Bradner, RFC2026: "The Internet Standard Process - Revision 3," October 1996, Obsoletes - RFC 1602, Status: Best Current Practice. [RFC2119] S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to Indicate Requirement Levels," March 1997, Status: Best Current Practice. [RFC2743] J. Linn, RFC2743: "Generic Security Service Application Program Interface Version 2, Update 1," January 2000, Status: Proposed Standard. [RFC2744] J. Wray, RFC2744: "Generic Security Service API Version 2 : C-bindings," January 2000, Status: Proposed Standard. [MUST add references to LIPKEY, SPKM, the Kerberos V mechanism, SPNEGO, CCM, etc...] ... 10. Author's Address Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 N. Williams [Page 21] DRAFT Stackable GSS-API Pseudo-Mechs Expires November 2004 Email: nicolas.williams@sun.com Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. N. Williams [Page 22] -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 20 10:50:22 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21593 for ; Thu, 20 May 2004 10:50:21 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i4KEitWA013250 for ietf-cat-wg-out720680; Thu, 20 May 2004 07:44:55 -0700 (PDT) Received: from serrano.cc.columbia.edu (IDENT:cu41754@serrano.cc.columbia.edu [128.59.59.142]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i4KEioNK013241 for ; Thu, 20 May 2004 07:44:51 -0700 (PDT) Received: from columbia.edu (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i4KEilZn029466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 May 2004 10:44:47 -0400 (EDT) Message-ID: <40ACC45F.4070508@columbia.edu> Date: Thu, 20 May 2004 10:44:47 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Internet-Drafts@ietf.org CC: Nicolas Williams , ietf-cat-wg@lists.Stanford.EDU Subject: Re: draft-williams-gssapi-store-deleg-creds-01.txt References: <20040519200928.GZ101103@binky.central.sun.com> In-Reply-To: <20040519200928.GZ101103@binky.central.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050902030600010702020204" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms050902030600010702020204 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit INTERNET-DRAFT Nicolas Williams Sun Microsystems September 2003 GSS-APIv2 Extension for Storing Delegated Credentials Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This draft expires on January 30th, 2004. Please send comments to the authors. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines a new function for the GSS-API which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. N. Williams [Page 1] DRAFT GSS_Store_cred() Expires March 2004 Table of Contents 1 Introduction 2 GSS_Store_cred() 2.1 C-Bindings for GSS_Store_cred() 3 Examples 4 Security Considerations 5 References 5.1 Normative References 6 Author's Address 1 Introduction The GSS-API [RFC2743] clearly assumes that credentials exist in an implicit store whence they can be acquired using GSS_Acquire_cred() and GSS_Add_cred() or through use of the default credential. Multiple credential stores may exist on a given host, but only one store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any given time. [NOTE: This assumption can be seen in sections 1.1.1.2 and 1.1.1.3 of RFC2743 as well as in section 3.5 of RFC2744. Note to the RFC editor: please remove this note before publication.] Applications may be able to change the credential store from which credentials can be acquired, either by changing user contexts (where the applications have the privilege to do so) or by other means (where a user may have multiple credential stores). Some GSS-API acceptor applications always change user contexts, after accepting a GSS-API security context and making appropriate authorization checks, to the user context corresponding to the initiator principal name or to a context requested by the initiator. The means by which credential stores are managed are generally beyond the scope of the GSS-API. In the case of delegated credential handles however, such credentials do not exist in the acceptor's credential store or in the credential stores of the user contexts to which the acceptor application might change - which is precisely the raison d'etre of credential delegation. But the GSS-API provides no mechanism by which delegated credential handles can be made available for acquisition through GSS_Acquire_cred()/GSS_Add_cred(). The GSS-API also does not provide any credential import/export interfaces like the GSS-API context import/export interfaces. Thus acceptors are limited to making only direct use of delegated credential handles and only with GSS_Init_sec_context(), GSS_Inquire_cred*() and GSS_Release_cred(). This limitation is particularly onerous on Unix systems where a call to exec() to N. Williams [Page 2] DRAFT GSS_Store_cred() Expires March 2004 replace the process image obliterates the delegated credentials handle. [NOTE: Delegated credentials are practically unusable on Unix implementations of Secure Shell (SSHv2) servers, except where there are extended interfaces for dealing with delegated credentials, which to date have always been mechanism-specific interfaces. Note to the RFC editor: please remove this note before publication.] In order to make delegated credentials generally as useful as credentials that can be acquired with GSS_Acquire_cred() and GSS_Add_cred() a primitive is needed which allows storing of credentials in the implicit credential store. This primitive we call "GSS_Store_cred()." [NOTE: Simon Wilkinson's patches to OpenSSH for GSS-API sport a simple internal interface for storing delegated credentials in users' credential store - this internal interface wraps around two mechanism specific internal interfaces for storing GSI and Kerberos V credentials. Simon's code shows that: a) a generic method is needed for making delegated credentials available for indirect use through acquisition (as opposed to just using the actual delegated cred handle) b) it is possible to design and implement such a generic method for storing delegated credentials. No new concepts are added to the GSS-API by this document, but the implicit existence of a credential store in the background is made explicit, and a deficiency of the GSS-API is corrected. Compare this to the GGF proposal which includes a credential import/export facility (like the existing context import/ export facility), but with an option to export as "environment variables," meaning something like "store these input creds in some new credential store and then tell me the name of that credential store through some output environment variable"[*]. Thus, the GGF export-cred-to-environment- variable proposal adds knowledge of environment variables to the GSS-API, which this proposal does not. Note that a credential import/export facility along the lines of the existing context import/export facility may be useful and complements the GSS_Store_cred() interface; in fact, with GSS_Store_cred() it should be possible to remove the 'option_req' input parameter and export-to-env-var features N. Williams [Page 3] DRAFT GSS_Store_cred() Expires March 2004 of the GGF's GSS_Export_cred() credential export proposal. [*] For the exact semantics see section 1.2, paragraph 6 of draft-engert-ggf-gss-extensions-00.txt One side effect of GSS_Store_cred(), however, is that it allows applications that can switch their current credential store to move credentials from one store to the other; this is a direct result of making it possible to store a credential given a GSS-API credential handle. Perhaps there should be some text allowing, or recommending, that implementations of GSS_Store_cred() allow only the storage of credentials acquired through credential delegation. Note to the RFC editor: please remove this note before publication.] 2 GSS_Store_cred() Inputs: o input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST -- NOT be GSS_C_NO_CREDENTIAL o cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, -- 2=ACCEPT-ONLY o desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID -- then store all the elements of the input_cred_handle, otherwise -- store only the element of the corresponding mechanism o overwrite_cred BOOLEAN, -- if TRUE replace any credential for the -- same principal in the credential store o default_cred BOOLEAN -- if TRUE make the stored credential -- available as the default credential (for acquisition with -- GSS_C_NO_NAME as the desired name or for use as -- GSS_C_NO_CREDENTIAL) Outputs: o major_status INTEGER, o minor_status INTEGER, o mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of -- mechanism OIDs for which credential elements were successfully -- stored o cred_usage_stored INTEGER -- like cred_usage, but indicates what -- kind of credential was stored (useful when the cred_usage input -- parameter is set to INITIATE-AND-ACCEPT) N. Williams [Page 4] DRAFT GSS_Store_cred() Expires March 2004 Return major_status codes: o GSS_S_COMPLETE indicates that the credentials were successfully stored. o GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials had expired or expired before they could be stored. o GSS_S_NO_CRED indicates that no input credentials were given. o GSS_S_UNAVAILABLE indicates that the credential store is not available. o GSS_S_DUPLICATE_ELEMENT indicates that an element of the input credential could not be stored because a credential for the same principal exists in the current credential store and the overwrite_cred input argument was FALSE. o GSS_S_FAILURE indicates that the credential could not be stored for some other reason. The minor status code may provide more information if a non-GSS_C_NULL_OID desired_mech_element was given. GSS_Store_cred() is used to store, in the current credential store, a given credential that has either been acquired from a different credential store or been accepted as a delegated credential. Specific mechanism elements of a credential can be stored one at a time by specifying a non-GSS_C_NULL_OID mechanism OID as the desired_mech_element input argument, in which case the minor status output SHOULD have a mechanism-specific value when the major status is not GSS_S_COMPLETE. The initiator, acceptor or both usages of the input credential may be stored as per the cred_usage input argument. The credential elements that were actually stored, when the major status is GSS_S_COMPLETE, are indicated through the cred_usage_stored and mech_elements_stored function outputs. If credentials already exist in the current store for the principal of the input_cred_handle, then those credentials are not replaced with the input credentials unless the overwrite_cred input argument is TRUE. Finally, if the current credential store has no default credential (that is, no credential that could be acquired for GSS_C_NO_NAME) or if the default_cred input argument is TRUE, and the input credential can be successfully stored, then the input credential will be available for acquisition with GSS_C_NO_NAME as the desired name input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(), GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and GSS_Accept_sec_context(). N. Williams [Page 5] DRAFT GSS_Store_cred() Expires March 2004 2.1 C-Bindings for GSS_Store_cred() The C-bindings for GSS_Store_cred() make use of types from and are designed based on the style of the GSS-APIv2 C-Bindings [RFC2744]. OM_uint32 gss_store_cred( OM_uint32 *minor_status, gss_cred_id_t input_cred, gss_cred_usage_t cred_usage, const gss_OID desired_mech, OM_uint32 overwrite_cred, OM_uint32 default_cred, gss_OID_set *elements_stored, gss_cred_usage_t *cred_usage_stored) The two boolean arguments, 'overwrite_cred' and 'default_cred' are typed as OM_uint32; 0 corresponds to FALSE, non-zero values correspond to TRUE. 3 Examples The intended usage of GSS_Store_cred() is to make delegated credentials available to child processes of GSS-API acceptor applications. Example pseudo-code: /* * * * <"requested_username" is a username derived from the initiator * name or explicitly requested by the initiator application.> */ ... if (authorize_gss_client(src_name, requested_username)) { /* * For Unix-type platforms this may mean calling setuid() and it * may or may not also mean setting/unsetting such environment * variables as KRB5CCNAME and what not. */ if (change_user_context(requested_username)) (void) gss_store_creds(&minor_status, deleg_cred, GSS_C_INITIATE, actual_mech, 0, 1, NULL, NULL); } else ... } else ... 4 Security Considerations N. Williams [Page 6] DRAFT GSS_Store_cred() Expires March 2004 Acceptor applications MUST only store delegated credentials into appropriate credential stores and only after proper authorization of the authenticated initiator principal to the requested service(s). Acceptor applications that have no use for delegated credentials MUST release them (such acceptor applications that use the GSS-API C-Bindings may simply provide a NULL value for the delegated_cred_handle argument to gss_accept_sec_context()). 5 References 5.1 Normative References [RFC2026] S. Bradner, RFC2026: "The Internet Standard Process - Revision 3," October 1996, Obsoletes - RFC 1602, Status: Best Current Practice. [RFC2119] S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to Indicate Requirement Levels," March 1997, Status: Best Current Practice. [RFC2743] J. Linn, RFC2743: "Generic Security Service Application Program Interface Version 2, Update 1," January 2000, Status: Proposed Standard. [RFC2744] J. Wray, RFC2744: "Generic Security Service API Version 2 : C-bindings," January 2000, Status: Proposed Standard. 6 Author's Address Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 Email: Nicolas.Williams@sun.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of N. Williams [Page 7] DRAFT GSS_Store_cred() Expires March 2004 developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. N. Williams [Page 8] --------------ms050902030600010702020204 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJOzCC AvgwggJhoAMCAQICAwwjmjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDE2MDIxODM0WhcNMDUwNDE2MDIxODM0 WjBGMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRq YWx0bWFuQGNvbHVtYmlhLmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKyS 7eWrak81hbARkTT+lqX+uujXLK3tDmCn/6IQH9tDKYtf5A8/llZJdPYHUA9p1FH9hwk23iGY scSkJq84FJenlWKOOqOsT6BlueWsrlKuseJCdMf9uhN28p+UnZvrcVhcLLTYfRvQT9OUw/k3 h4TzNdyAXbBJ3LnL1ySbFRaNVkq7cW/2ircAWpcyqHH4ZKstdSLbo6axsDHWRZL8yHUsI1Gz esRSYQf2aUeUqvmGbEKEKFwbfqgfLwlBLiv1Lqib/++J3s5g3syhqWe3T8tUffmhdibUdX2W umT2uiWl/WGEBvc1+o5k0T2JqWMNR9VgzPyk8P+iZRHl76Yb49ECAwEAAaNUMFIwDgYDVR0P AQH/BAQDAgP4MBEGCWCGSAGG+EIBAQQEAwIFoDAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVt YmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGXYUcZvaLEqctXUsgt0 fUMFXukM3E5fpLBkk3+BbcY457WQE38ZM1AOvcYOHqB1xhJCxP1U0pSJu2Xfe9Z1M2mU4C4V 2w4sDcWkZteM9EW7VYbXzSCKCw0TKKp3Wl9TFIWFdiFwPvhOzhXUonGTdYbOvRuAXQuJdNQW O4v2sQg1MIIC+DCCAmGgAwIBAgIDDCOaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA0MTYwMjE4MzRaFw0wNTA0 MTYwMjE4MzRaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG 9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArJLt5atqTzWFsBGRNP6Wpf666Ncsre0OYKf/ohAf20Mpi1/kDz+WVkl09gdQD2nU Uf2HCTbeIZixxKQmrzgUl6eVYo46o6xPoGW55ayuUq6x4kJ0x/26E3byn5Sdm+txWFwstNh9 G9BP05TD+TeHhPM13IBdsEncucvXJJsVFo1WSrtxb/aKtwBalzKocfhkqy11ItujprGwMdZF kvzIdSwjUbN6xFJhB/ZpR5Sq+YZsQoQoXBt+qB8vCUEuK/UuqJv/74nezmDezKGpZ7dPy1R9 +aF2JtR1fZa6ZPa6JaX9YYQG9zX6jmTRPYmpYw1H1WDM/KTw/6JlEeXvphvj0QIDAQABo1Qw UjAOBgNVHQ8BAf8EBAMCA/gwEQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdEQQYMBaBFGphbHRt YW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZdhRxm9o sSpy1dSyC3R9QwVe6QzcTl+ksGSTf4FtxjjntZATfxkzUA69xg4eoHXGEkLE/VTSlIm7Zd97 1nUzaZTgLhXbDiwNxaRm14z0RbtVhtfNIIoLDRMoqndaX1MUhYV2IXA++E7OFdSicZN1hs69 G4BdC4l01BY7i/axCDUwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwwjmjAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NDA1MjAxNDQ0NDdaMCMGCSqGSIb3DQEJBDEWBBTd7l2D3QmdjF4ZVPF+AtCtq+6GVjBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDCOaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwwj mjANBgkqhkiG9w0BAQEFAASCAQAs5I8aI35t0a+n21el4ZxSIvmMI12pAEnK0z1seSNLytCY ZsTX5yOCl1Ud7qW37A2/WtJIX83wOAxnTwvW2S17rk1/4P2pkuZA6MG2bU8JOL1hGfaHy0pw 9KgVn93nN9ukMwUq/vPLXbfU8lzyT9rCyxLlgPsF2H3e7ELZgblYssMHNxcCP4jLia80qtV4 KTqaOHK8JxxerMsKQSQHaxf91Q7saUZZ+zY+r6GkGB6Gh2aVUvm8k/G2eKAT/9f0rLeWt0j2 NJDtL1Oj1++aIJAPskUkVYaezol/M8JHcJf1PgpUT40sRGMTjuZDNTwlClg2TrRr3OCC7CJ9 baZski05AAAAAAAA --------------ms050902030600010702020204-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 20 11:31:48 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24042 for ; Thu, 20 May 2004 11:31:47 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i4KFTca5021750 for ietf-cat-wg-out720680; Thu, 20 May 2004 08:29:38 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i4KFTZNK021743 for ; Thu, 20 May 2004 08:29:36 -0700 (PDT) Received: from columbia.edu (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i4KFTVXb004849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 May 2004 11:29:31 -0400 (EDT) Message-ID: <40ACCEDA.6030508@columbia.edu> Date: Thu, 20 May 2004 11:29:30 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams CC: Dinara Suleymanova , ietf-cat-wg@lists.Stanford.EDU Subject: Re: draft-williams-gssapi-store-deleg-creds-00.txt References: <20040519200928.GZ101103@binky.central.sun.com> <6.1.0.6.2.20040520104018.01ccd690@odin.ietf.org> <20040520152246.GF488605@binky.central.sun.com> In-Reply-To: <20040520152246.GF488605@binky.central.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010003090708060603080706" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms010003090708060603080706 Content-Type: multipart/alternative; boundary="------------010703070009020004010206" This is a multi-part message in MIME format. --------------010703070009020004010206 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Nicolas Williams wrote: >On Thu, May 20, 2004 at 10:41:25AM -0400, Dinara Suleymanova wrote: > > >>Have you already had this I-D before? I found that it was expired in April. >>If you had an expired I-D, please correct the version to a -01 and resubmit. >>If you have any questions please contact me. >> >> > >Ooops, sorry, I meant to make it -00... -01 was the result of my >private versioning... > > Nico: You are supposed to be on vacation. :-) Dinara is correct. The -00 version of this draft was published and announced to Internet-Drafts on 9/8/2003. The resubmission must be -01. Jeffrey Altman --------------010703070009020004010206 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Nicolas Williams wrote:
On Thu, May 20, 2004 at 10:41:25AM -0400, Dinara Suleymanova wrote:
  
Have you already had this I-D before? I found that it was expired in April.
If you had an expired I-D, please correct the version to a -01 and resubmit.
If you have any questions please contact me.
    

Ooops, sorry, I meant to make it -00...  -01 was the result of my
private versioning...

Nico:

You are supposed to be on vacation.  :-)

Dinara is correct.  The -00 version of this draft was published and announced to Internet-Drafts on 9/8/2003.
The resubmission must be -01.

Jeffrey Altman



--------------010703070009020004010206-- --------------ms010003090708060603080706 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJOzCC AvgwggJhoAMCAQICAwwjmjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDE2MDIxODM0WhcNMDUwNDE2MDIxODM0 WjBGMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRq YWx0bWFuQGNvbHVtYmlhLmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKyS 7eWrak81hbARkTT+lqX+uujXLK3tDmCn/6IQH9tDKYtf5A8/llZJdPYHUA9p1FH9hwk23iGY scSkJq84FJenlWKOOqOsT6BlueWsrlKuseJCdMf9uhN28p+UnZvrcVhcLLTYfRvQT9OUw/k3 h4TzNdyAXbBJ3LnL1ySbFRaNVkq7cW/2ircAWpcyqHH4ZKstdSLbo6axsDHWRZL8yHUsI1Gz esRSYQf2aUeUqvmGbEKEKFwbfqgfLwlBLiv1Lqib/++J3s5g3syhqWe3T8tUffmhdibUdX2W umT2uiWl/WGEBvc1+o5k0T2JqWMNR9VgzPyk8P+iZRHl76Yb49ECAwEAAaNUMFIwDgYDVR0P AQH/BAQDAgP4MBEGCWCGSAGG+EIBAQQEAwIFoDAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVt YmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGXYUcZvaLEqctXUsgt0 fUMFXukM3E5fpLBkk3+BbcY457WQE38ZM1AOvcYOHqB1xhJCxP1U0pSJu2Xfe9Z1M2mU4C4V 2w4sDcWkZteM9EW7VYbXzSCKCw0TKKp3Wl9TFIWFdiFwPvhOzhXUonGTdYbOvRuAXQuJdNQW O4v2sQg1MIIC+DCCAmGgAwIBAgIDDCOaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA0MTYwMjE4MzRaFw0wNTA0 MTYwMjE4MzRaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG 9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArJLt5atqTzWFsBGRNP6Wpf666Ncsre0OYKf/ohAf20Mpi1/kDz+WVkl09gdQD2nU Uf2HCTbeIZixxKQmrzgUl6eVYo46o6xPoGW55ayuUq6x4kJ0x/26E3byn5Sdm+txWFwstNh9 G9BP05TD+TeHhPM13IBdsEncucvXJJsVFo1WSrtxb/aKtwBalzKocfhkqy11ItujprGwMdZF kvzIdSwjUbN6xFJhB/ZpR5Sq+YZsQoQoXBt+qB8vCUEuK/UuqJv/74nezmDezKGpZ7dPy1R9 +aF2JtR1fZa6ZPa6JaX9YYQG9zX6jmTRPYmpYw1H1WDM/KTw/6JlEeXvphvj0QIDAQABo1Qw UjAOBgNVHQ8BAf8EBAMCA/gwEQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdEQQYMBaBFGphbHRt YW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZdhRxm9o sSpy1dSyC3R9QwVe6QzcTl+ksGSTf4FtxjjntZATfxkzUA69xg4eoHXGEkLE/VTSlIm7Zd97 1nUzaZTgLhXbDiwNxaRm14z0RbtVhtfNIIoLDRMoqndaX1MUhYV2IXA++E7OFdSicZN1hs69 G4BdC4l01BY7i/axCDUwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwwjmjAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NDA1MjAxNTI5MzBaMCMGCSqGSIb3DQEJBDEWBBSYX1/rdzYD+eaMezG0VPfc5BFsNjBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDCOaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwwj mjANBgkqhkiG9w0BAQEFAASCAQAGnb+IgBzq/w9MMbpORC6GDnnd+vwO/b5RZidIfYzkpKuv 5mzDh3mkMjk0GkB4Vhrcv1pia9ah7O52ury7eUZLSPImpDiObZnLQoTfOrsOn44srhWCFJAQ h6R/k2ix2mJs9XsRRsmHOIxmabwgIpG9WTdYQ371i/+WLBtkzJU0BztBhZvTk2lsWyv8SG0h k/tjygaYoizwjFnSDQksfjTlJh8/pPkIbq/c/Pu1YPAZELLZk/L8u0FEHACGflsnwrzEl8Ll iPKVtVvK7uTUOBz9fRyQhjz7aT+eFC7ndXvcTmwoX33pmgpBVDsfmqyZkCUWYmzGQQZ0laT9 LNf7qAdtAAAAAAAA --------------ms010003090708060603080706-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 20 11:32:10 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24088 for ; Thu, 20 May 2004 11:32:10 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i4KFPUWu020865 for ietf-cat-wg-out720680; Thu, 20 May 2004 08:25:30 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i4KFPPNK020852 for ; Thu, 20 May 2004 08:25:26 -0700 (PDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i4KFNoMP028238; Thu, 20 May 2004 09:23:50 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i4KFP34F021258; Thu, 20 May 2004 09:25:03 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i4KFMmCb805905; Thu, 20 May 2004 10:23:03 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i4KFMlXM805904; Thu, 20 May 2004 10:22:47 -0500 (CDT) Date: Thu, 20 May 2004 10:22:47 -0500 From: Nicolas Williams To: Dinara Suleymanova Cc: Jeffrey Altman , ietf-cat-wg@lists.Stanford.EDU Subject: Re: draft-williams-gssapi-store-deleg-creds-00.txt Message-ID: <20040520152246.GF488605@binky.central.sun.com> References: <20040519200928.GZ101103@binky.central.sun.com> <6.1.0.6.2.20040520104018.01ccd690@odin.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.0.6.2.20040520104018.01ccd690@odin.ietf.org> User-Agent: Mutt/1.4.1i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Thu, May 20, 2004 at 10:41:25AM -0400, Dinara Suleymanova wrote: > Have you already had this I-D before? I found that it was expired in April. > If you had an expired I-D, please correct the version to a -01 and resubmit. > If you have any questions please contact me. Ooops, sorry, I meant to make it -00... -01 was the result of my private versioning... > Thanks. > > Dinara > > At 04:09 PM 5/19/2004, Nicolas Williams wrote: > > >INTERNET-DRAFT Nicolas Williams > > Sun Microsystems > > September 2003 > > > > > > > > GSS-APIv2 Extension for Storing Delegated Credentials > > > > > > > > > > > >Status of this Memo > > > > This document is an Internet-Draft and is in full conformance with > > all provisions of Section 10 of RFC2026 [RFC2026]. > > > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF), its areas, and its working groups. Note that > > other groups may also distribute working documents as Internet- > > Drafts. > > > > Internet-Drafts are draft documents valid for a maximum of six months > > and may be updated, replaced, or obsoleted by other documents at any > > time. It is inappropriate to use Internet- Drafts as reference > > material or to cite them other than as "work in progress." > > > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/ietf/1id-abstracts.txt > > > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html. > > > > This draft expires on January 30th, 2004. Please send comments to > > the authors. > > > > > >Copyright Notice > > > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > > >Abstract > > > > This document defines a new function for the GSS-API which allows > > applications to store delegated (and other) credentials in the > > implicit GSS-API credential store. This is needed for GSS-API > > applications to use delegated credentials as they would use other > > credentials. > > > >Conventions used in this document > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in [RFC2119]. > > > >N. Williams [Page 1] > > > >DRAFT GSS_Store_cred() Expires March 2004 > > > > > >Table of Contents > > > > 1 Introduction > > 2 GSS_Store_cred() > > 2.1 C-Bindings for GSS_Store_cred() > > 3 Examples > > 4 Security Considerations > > 5 References > > 5.1 Normative References > > 6 Author's Address > > > >1 Introduction > > > > The GSS-API [RFC2743] clearly assumes that credentials exist in an > > implicit store whence they can be acquired using GSS_Acquire_cred() > > and GSS_Add_cred() or through use of the default credential. > > Multiple credential stores may exist on a given host, but only one > > store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any > > given time. > > > > [NOTE: This assumption can be seen in sections 1.1.1.2 and 1.1.1.3 > > of RFC2743 as well as in section 3.5 of RFC2744. > > > > Note to the RFC editor: please remove this note before > > publication.] > > > > Applications may be able to change the credential store from which > > credentials can be acquired, either by changing user contexts (where > > the applications have the privilege to do so) or by other means > > (where a user may have multiple credential stores). > > > > Some GSS-API acceptor applications always change user contexts, after > > accepting a GSS-API security context and making appropriate > > authorization checks, to the user context corresponding to the > > initiator principal name or to a context requested by the initiator. > > The means by which credential stores are managed are generally beyond > > the scope of the GSS-API. > > > > In the case of delegated credential handles however, such credentials > > do not exist in the acceptor's credential store or in the credential > > stores of the user contexts to which the acceptor application might > > change - which is precisely the raison d'etre of credential > > delegation. But the GSS-API provides no mechanism by which delegated > > credential handles can be made available for acquisition through > > GSS_Acquire_cred()/GSS_Add_cred(). The GSS-API also does not provide > > any credential import/export interfaces like the GSS-API context > > import/export interfaces. > > > > Thus acceptors are limited to making only direct use of delegated > > credential handles and only with GSS_Init_sec_context(), > > GSS_Inquire_cred*() and GSS_Release_cred(). This limitation is > > particularly onerous on Unix systems where a call to exec() to > > > >N. Williams [Page 2] > > > >DRAFT GSS_Store_cred() Expires March 2004 > > > > replace the process image obliterates the delegated credentials > > handle. > > > > [NOTE: Delegated credentials are practically unusable on Unix > > implementations of Secure Shell (SSHv2) servers, except where > > there are extended interfaces for dealing with delegated > > credentials, which to date have always been > > mechanism-specific interfaces. > > > > Note to the RFC editor: please remove this note before > > publication.] > > > > In order to make delegated credentials generally as useful as > > credentials that can be acquired with GSS_Acquire_cred() and > > GSS_Add_cred() a primitive is needed which allows storing of > > credentials in the implicit credential store. This primitive we call > > "GSS_Store_cred()." > > > > [NOTE: Simon Wilkinson's patches to OpenSSH for GSS-API sport a > > simple internal interface for storing delegated credentials > > in users' credential store - this internal interface wraps > > around two mechanism specific internal interfaces for storing > > GSI and Kerberos V credentials. > > > > Simon's code shows that: > > > > a) a generic method is needed for making delegated > > credentials available for indirect use through acquisition > > (as opposed to just using the actual delegated cred > > handle) > > > > b) it is possible to design and implement such a generic > > method for storing delegated credentials. > > > > No new concepts are added to the GSS-API by this document, > > but the implicit existence of a credential store in the > > background is made explicit, and a deficiency of the GSS-API > > is corrected. > > > > Compare this to the GGF proposal which includes a credential > > import/export facility (like the existing context import/ > > export facility), but with an option to export as > > "environment variables," meaning something like "store these > > input creds in some new credential store and then tell me the > > name of that credential store through some output environment > > variable"[*]. Thus, the GGF export-cred-to-environment- > > variable proposal adds knowledge of environment variables to > > the GSS-API, which this proposal does not. Note that a > > credential import/export facility along the lines of the > > existing context import/export facility may be useful and > > complements the GSS_Store_cred() interface; in fact, with > > GSS_Store_cred() it should be possible to remove the > > 'option_req' input parameter and export-to-env-var features > > > >N. Williams [Page 3] > > > >DRAFT GSS_Store_cred() Expires March 2004 > > > > of the GGF's GSS_Export_cred() credential export proposal. > > > > [*] For the exact semantics see section 1.2, paragraph 6 of > > draft-engert-ggf-gss-extensions-00.txt > > > > One side effect of GSS_Store_cred(), however, is that it > > allows applications that can switch their current credential > > store to move credentials from one store to the other; this > > is a direct result of making it possible to store a > > credential given a GSS-API credential handle. Perhaps there > > should be some text allowing, or recommending, that > > implementations of GSS_Store_cred() allow only the storage of > > credentials acquired through credential delegation. > > > > Note to the RFC editor: please remove this note before > > publication.] > > > >2 GSS_Store_cred() > > > > Inputs: > > > > o input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST > > -- NOT be GSS_C_NO_CREDENTIAL > > > > o cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, > > -- 2=ACCEPT-ONLY > > > > o desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID > > -- then store all the elements of the input_cred_handle, otherwise > > -- store only the element of the corresponding mechanism > > > > o overwrite_cred BOOLEAN, -- if TRUE replace any credential for the > > -- same principal in the credential store > > > > o default_cred BOOLEAN -- if TRUE make the stored credential > > -- available as the default credential (for acquisition with > > -- GSS_C_NO_NAME as the desired name or for use as > > -- GSS_C_NO_CREDENTIAL) > > > > Outputs: > > > > o major_status INTEGER, > > > > o minor_status INTEGER, > > > > o mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of > > -- mechanism OIDs for which credential elements were successfully > > -- stored > > > > o cred_usage_stored INTEGER -- like cred_usage, but indicates what > > -- kind of credential was stored (useful when the cred_usage input > > -- parameter is set to INITIATE-AND-ACCEPT) > > > > > >N. Williams [Page 4] > > > >DRAFT GSS_Store_cred() Expires March 2004 > > > > Return major_status codes: > > > > o GSS_S_COMPLETE indicates that the credentials were successfully > > stored. > > > > o GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials > > had expired or expired before they could be stored. > > > > o GSS_S_NO_CRED indicates that no input credentials were given. > > > > o GSS_S_UNAVAILABLE indicates that the credential store is not > > available. > > > > o GSS_S_DUPLICATE_ELEMENT indicates that an element of the input > > credential could not be stored because a credential for the same > > principal exists in the current credential store and the > > overwrite_cred input argument was FALSE. > > > > o GSS_S_FAILURE indicates that the credential could not be stored > > for some other reason. The minor status code may provide more > > information if a non-GSS_C_NULL_OID desired_mech_element was given. > > > > GSS_Store_cred() is used to store, in the current credential store, a > > given credential that has either been acquired from a different > > credential store or been accepted as a delegated credential. > > > > Specific mechanism elements of a credential can be stored one at a > > time by specifying a non-GSS_C_NULL_OID mechanism OID as the > > desired_mech_element input argument, in which case the minor status > > output SHOULD have a mechanism-specific value when the major status > > is not GSS_S_COMPLETE. > > > > The initiator, acceptor or both usages of the input credential may be > > stored as per the cred_usage input argument. > > > > The credential elements that were actually stored, when the major > > status is GSS_S_COMPLETE, are indicated through the cred_usage_stored > > and mech_elements_stored function outputs. > > > > If credentials already exist in the current store for the principal > > of the input_cred_handle, then those credentials are not replaced > > with the input credentials unless the overwrite_cred input argument > > is TRUE. > > > > Finally, if the current credential store has no default credential > > (that is, no credential that could be acquired for GSS_C_NO_NAME) or > > if the default_cred input argument is TRUE, and the input credential > > can be successfully stored, then the input credential will be > > available for acquisition with GSS_C_NO_NAME as the desired name > > input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as > > GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(), > > GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and > > GSS_Accept_sec_context(). > > > >N. Williams [Page 5] > > > >DRAFT GSS_Store_cred() Expires March 2004 > > > > > >2.1 C-Bindings for GSS_Store_cred() > > > > The C-bindings for GSS_Store_cred() make use of types from and are > > designed based on the style of the GSS-APIv2 C-Bindings [RFC2744]. > > > > OM_uint32 gss_store_cred( > > OM_uint32 *minor_status, > > gss_cred_id_t input_cred, > > gss_cred_usage_t cred_usage, > > const gss_OID desired_mech, > > OM_uint32 overwrite_cred, > > OM_uint32 default_cred, > > gss_OID_set *elements_stored, > > gss_cred_usage_t *cred_usage_stored) > > > > The two boolean arguments, 'overwrite_cred' and 'default_cred' are > > typed as OM_uint32; 0 corresponds to FALSE, non-zero values > > correspond to TRUE. > > > >3 Examples > > > > The intended usage of GSS_Store_cred() is to make delegated > > credentials available to child processes of GSS-API acceptor > > applications. Example pseudo-code: > > > > /* > > * > * initiator name (hereafter, "src_name") and a delegated credential > > * handle (hereafter "deleg_cred").> > > * > > * <"requested_username" is a username derived from the initiator > > * name or explicitly requested by the initiator application.> > > */ > > ... > > > > if (authorize_gss_client(src_name, requested_username)) { > > /* > > * For Unix-type platforms this may mean calling setuid() and it > > * may or may not also mean setting/unsetting such environment > > * variables as KRB5CCNAME and what not. > > */ > > if (change_user_context(requested_username)) > > (void) gss_store_creds(&minor_status, deleg_cred, > > GSS_C_INITIATE, actual_mech, > > 0, 1, NULL, NULL); > > } > > else ... > > } > > else ... > > > >4 Security Considerations > > > > > >N. Williams [Page 6] > > > >DRAFT GSS_Store_cred() Expires March 2004 > > > > Acceptor applications MUST only store delegated credentials into > > appropriate credential stores and only after proper authorization of > > the authenticated initiator principal to the requested service(s). > > > > Acceptor applications that have no use for delegated credentials MUST > > release them (such acceptor applications that use the GSS-API > > C-Bindings may simply provide a NULL value for the > > delegated_cred_handle argument to gss_accept_sec_context()). > > > >5 References > > > >5.1 Normative References > > > > [RFC2026] > > S. Bradner, RFC2026: "The Internet Standard Process - Revision > > 3," October 1996, Obsoletes - RFC 1602, Status: Best Current > > Practice. > > > > [RFC2119] > > S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to > > Indicate Requirement Levels," March 1997, Status: Best Current > > Practice. > > > > [RFC2743] > > J. Linn, RFC2743: "Generic Security Service Application Program > > Interface Version 2, Update 1," January 2000, Status: Proposed > > Standard. > > > > [RFC2744] > > J. Wray, RFC2744: "Generic Security Service API Version 2 : > > C-bindings," January 2000, Status: Proposed Standard. > > > >6 Author's Address > > > > Nicolas Williams > > Sun Microsystems > > 5300 Riata Trace Ct > > Austin, TX 78727 > > Email: Nicolas.Williams@sun.com > > > >Full Copyright Statement > > > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > > > This document and translations of it may be copied and furnished to > > others, and derivative works that comment on or otherwise explain it > > or assist in its implementation may be prepared, copied, published > > and distributed, in whole or in part, without restriction of any > > kind, provided that the above copyright notice and this paragraph are > > included on all such copies and derivative works. However, this > > document itself may not be modified in any way, such as by removing > > the copyright notice or references to the Internet Society or other > > Internet organizations, except as needed for the purpose of > > > >N. Williams [Page 7] > > > >DRAFT GSS_Store_cred() Expires March 2004 > > > > developing Internet standards in which case the procedures for > > copyrights defined in the Internet Standards process must be > > followed, or as required to translate it into languages other than > > English. > > > > The limited permissions granted above are perpetual and will not be > > revoked by the Internet Society or its successors or assigns. > > > > This document and the information contained herein is provided on an > > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > >Acknowledgement > > > > Funding for the RFC Editor function is currently provided by the > > Internet Society. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >N. Williams [Page 8] > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 20 11:47:22 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25791 for ; Thu, 20 May 2004 11:47:21 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i4KFfY49023318 for ietf-cat-wg-out720680; Thu, 20 May 2004 08:41:34 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i4KFfVNK023311 for ; Thu, 20 May 2004 08:41:32 -0700 (PDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i4KFe1MP006613; Thu, 20 May 2004 09:40:01 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i4KFfE4F028682; Thu, 20 May 2004 09:41:14 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i4KFcxRJ805930; Thu, 20 May 2004 10:39:14 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i4KFcx9u805929; Thu, 20 May 2004 10:38:59 -0500 (CDT) Date: Thu, 20 May 2004 10:38:59 -0500 From: Nicolas Williams To: Jeffrey Altman Cc: Dinara Suleymanova , ietf-cat-wg@lists.Stanford.EDU Subject: Re: draft-williams-gssapi-store-deleg-creds-00.txt Message-ID: <20040520153859.GI488605@binky.central.sun.com> References: <20040519200928.GZ101103@binky.central.sun.com> <6.1.0.6.2.20040520104018.01ccd690@odin.ietf.org> <20040520152246.GF488605@binky.central.sun.com> <40ACCEDA.6030508@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40ACCEDA.6030508@columbia.edu> User-Agent: Mutt/1.4.1i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Thu, May 20, 2004 at 11:29:30AM -0400, Jeffrey Altman wrote: > Nicolas Williams wrote: > >On Thu, May 20, 2004 at 10:41:25AM -0400, Dinara Suleymanova wrote: > >Ooops, sorry, I meant to make it -00... -01 was the result of my > >private versioning... > > Nico: > > You are supposed to be on vacation. :-) Right, which is why I'm all confused! My plane leaves in the afternoon, and I gave in to temptation... > Dinara is correct. The -00 version of this draft was published and > announced to Internet-Drafts on 9/8/2003. > The resubmission must be -01. Which I see you've done. Thanks! Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Sat May 22 06:41:46 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27352 for ; Sat, 22 May 2004 06:41:46 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i4MAaNKc003665 for ietf-cat-wg-out720680; Sat, 22 May 2004 03:36:23 -0700 (PDT) Received: from rmk027.org ([203.199.214.66]) by lists.Stanford.EDU (8.12.10/8.12.10) with SMTP id i4MAaJNL003660 for ; Sat, 22 May 2004 03:36:21 -0700 (PDT) Date: Sat, 22 May 2004 15:56:39 +0530 To: "Ietf-cat-wg" From: "Jlinn" Subject: [Possible Virus] New changes Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------xxrzajviwlmubfprxhzu" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk ----------xxrzajviwlmubfprxhzu Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------xxrzajviwlmubfprxhzu Content-Type: application/octet-stream; name="You_will_answer_to_me.vbs" Content-Disposition: attachment; filename="You_will_answer_to_me.vbs" Content-Transfer-Encoding: base64 ----------xxrzajviwlmubfprxhzu-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon May 24 14:32:31 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22283 for ; Mon, 24 May 2004 14:32:31 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i4OISBfY028479 for ietf-cat-wg-out720680; Mon, 24 May 2004 11:28:11 -0700 (PDT) Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i4OIS6NK028449 for ; Mon, 24 May 2004 11:28:07 -0700 (PDT) Received: from [192.168.1.11] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i4OIS4cE009254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 May 2004 14:28:05 -0400 (EDT) Message-ID: <40B23EB7.4040700@columbia.edu> Date: Mon, 24 May 2004 14:28:07 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ Housley , "Steven M. Bellovin" CC: ietf-cat-wg@lists.Stanford.EDU Subject: Request to create KITTEN (daughter of CAT) Working Group within the IETF Security Area References: <20040519160128.A3CC57B44@berkshire.research.att.com> <6.1.0.6.2.20040519172253.02c664f0@mail.binhost.com> In-Reply-To: <6.1.0.6.2.20040519172253.02c664f0@mail.binhost.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010303090907050209030406" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms010303090907050209030406 Content-Type: multipart/alternative; boundary="------------070503080106010007000203" This is a multi-part message in MIME format. --------------070503080106010007000203 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Russ and Steve: During the years since the Security Area's Common Authentication Technology working group closed its doors there has been significant new experience gained by those designing applications which utilize GSSAPI v2 update 1 and the GSSAPI v2 C Language Bindings. This experience has demonstrated several areas within the existing RFCs (2743 and 2744) which are less than well-defined and/or lacking in functionality. Attempts to address these deficiencies have resulted in discussions taking place in many inappropriate forums. Some attempts have occurred within existing IETF working groups which have rejected the work as being outside the existing charter. Other attempts have been pursued by third party organizations such as Global Grid Forum which have chosen to extend IETF standards on their own due to an inability to find a forum within IETF to pursue their work. The discussions on the IETF-CAT mailing list over the last several months have been quite contentious not to mention fun to read. The fruits of these discussions are the following: * There are a number of interested parties who would like to produce an new and improved GSSAPI specification be created to address issues related to credentials management; thread safety; channel binding usability (as discussed at IETF Minneapolis SAAG); C Language usage; ABI stability; mechanism specific extensibility; and support for mechanisms which do not provide a single canonical name. * There is an apparent consensus that the existing GSSAPI v2 RFCs should be revised to include improved language to clarify areas which have resulted in confusion for GSS mechanism implementors and application developers. There should be new text describing the lack of thread safety in GSSAPI v2 as well as descriptions of how to support IPv6 in the existing channel bindings. However, these revisions must not change the specification in any way which would affect backward interoperability with either existing implementations of GSSAPI v2 or even GSSAPI v1. * There is an apparent consensus that a new GSSAPI v3 specification be created to support the extended functionality that is required. * There is rough consensus that work should proceed to develop new forms of non-address based channel bindings which may be used to bind GSS to TLS, IPSec, SSH, and other cryptographic channels. * There are also proposals that a new mechansism for negotiating and properly using channel bindings (CCM) should be defined and that SPNEGO (RFC 2748) be updated to correct flaws in its design and specification. The current participants of the IETF-CAT mailing list believe the time is right to form the Common Authentication Technology Next Generation working group (aka Kitten) to address these work areas. As such we would like permission from the IESG to form the working group at San Diego or if necessary to hold a BOF to discuss the need for the working group and the scope of its charter. What follows is a proposed charter for the Kitten Working Group. Proposed Charter The Generic Security Services API [RFC 2743, RFC 2744] provides an API for applications to set up security contexts and to use these contexts for per-message protection services. The Common Authentication Technology Next Generation Working Group (Kitten) will work on standardizing extensions and improvements to the GSSAPI that the IETF believes are necessary based on experience using GSSAPI over the last 10 years. Extensions may be published as separate drafts or included in a GSSAPI version 3. While version 2 of the GSSAPI may be clarified, no backward incompatible changes will be made to this version of the API. This working group is chartered to revise the GSSAPI v2 RFCs for the purpose of clarifying areas of ambiguity: * Use of channel bindings * Thread safety restrictions * C Language utilization o use of const o utilization of gss types by the application o gss name space o improve recommendations for implementation specific types (e.g., use pointers to incomplete structs) * Guidelines for GSS-API mechanism designers * Guidelines for GSS-API application protocol designers This working group is chartered to specify a non-backward compatible GSSAPI v3 to support the following extensions: * Clarify the portable use of channel bindings and better specify channel bindings in a language-independent manner. * Specify thread safety extensions to allow multi-threaded applications to use GSSAPI * Definitions of channel bindings for TLS, IPSec, SSH and other cryptographic channels based on work started in the NFSV4 working group. * Defined a GSSAPI extension to allow applications to store credentials. Discussions to be started based upon: o draft-williams-gss-store-deleg-creds-xx.txt * Extensions to solve problems posed by the Global Grid Forum's GSSAPI extensions document. * Extensions to deal with mechanism-specific extensibility in a multi-mechanism environment. * Extend GSSAPI to support mechanisms that do not have a single canonical name for each authentication identity. * Extensions to support stackable GSSAPI mechanisms. This working group is chartered to perform the following GSSAPI mechanism specification work: * Specify a GSSAPI v2/v3 Channel Conjunction Mechanism * Revise RFC 2748 (SPNEGO) to correct problems that make the specification unimplementable and to document the problems found in widely-deployed attempts to implement this spec. End of Proposed Charter The participants of the IETF-CAT mailing list realize the quantity of work which we desire to undertake is quite ambitious in scope. This is simply an indication of how much work has accumulated over the last few years since the CAT working group disbanded. We believe that we can accomplish the stated work items in 18 months. Milestones * Clarifications to GSSAPIv2 (six months to IESG) Informational [editor: Jeffrey Altman] * The Channel Conjunction Mechanism (CCM) for the GSSAPI (six months to IESG) Proposed Standard [editors: Nicolas Williams/Mike Eisler] * On the Use of Channel Bindings to Secure Channels (six months to IESG) Proposed Standard [editor: Nicolas Williams] draft-ietf-nfsv4-channel-bindings-01.txt * GSSAPIv3 (18 months to IESG) Proposed Standard [editor: to be determined] * Stackable Generic Security Service Pseudo-mechanisms Proposed Standard or to be folded into GSSAPIv3 [editor: Nicolas Williams] draft-williams-gssapi-stackable-pseudo-mechs-00.txt * GSS-APIv2 Extension for Storing Delegated Credentials Proposed Standard or to be folded into GSSAPIv3 [editor: Nicolas Williams] * draft-williams-gssapi-store-deleg-creds-00.txt SPNEGO (RFC 2478) Revisions (18 months to IESG) Proposed Standard [editor: to be determined] End of Milestones Chairperson The proposed chairperson for the Kitten WG is Jeffrey Altman. Mailing List The current mailing list for discussions is ietf-cat-wg@lists.stanford.edu. Due to the facts that no one at Stanford is actively involved in the discussions and the mailing list software is quite old, the working group when formed will switch to a new mailing list. Sincerely, Jeffrey Altman (for the participants of the ietf-cat-wg mailing list) --------------070503080106010007000203 Content-Type: text/html; charset=windows-1251 Content-Transfer-Encoding: 8bit Russ and Steve:

During the years since the Security Area's Common Authentication Technology working group closed its doors there has been significant new experience gained by those designing applications which utilize GSSAPI v2 update 1 and the GSSAPI v2 C Language Bindings.  This experience has demonstrated several areas within the existing RFCs (2743 and 2744) which are less than well-defined and/or lacking in functionality.

Attempts to address these deficiencies have resulted in discussions taking place in many inappropriate forums.  Some attempts have occurred within existing IETF working groups which have rejected the work as being outside the existing charter.  Other attempts have been pursued by third party organizations such as Global Grid Forum which have chosen to extend IETF standards on their own due to an inability to find a forum within IETF to pursue their work.

The discussions on the IETF-CAT mailing list over the last several months have been quite contentious not to mention fun to read.  The fruits of these discussions are the following:
  • There are a number of interested parties who would like to produce an new and improved GSSAPI specification be created to address issues related to credentials management; thread safety; channel binding usability (as discussed at IETF Minneapolis SAAG); C Language usage; ABI stability; mechanism specific extensibility; and support for mechanisms which do not provide a single canonical name.
  • There is an apparent consensus that the existing GSSAPI v2 RFCs should be revised to include improved language to clarify areas which have resulted in confusion for GSS mechanism implementors and application developers.  There should be new text describing the lack of thread safety in GSSAPI v2 as well as descriptions of how to support IPv6 in the existing channel bindings.  However, these revisions must not change the specification in any way which would affect backward interoperability with either existing implementations of GSSAPI v2 or even GSSAPI v1.
  • There is an apparent consensus that a new GSSAPI v3 specification be created to support the extended functionality that is required.
  • There is rough consensus that work should proceed to develop new forms of non-address based channel bindings which may be used to bind GSS to TLS, IPSec, SSH, and other cryptographic channels.
  • There are also proposals that a new mechansism for negotiating and properly using channel bindings (CCM) should be defined and that SPNEGO (RFC 2748) be updated to correct flaws in its design and specification.
The current participants of the IETF-CAT mailing list believe the time is right to form the Common Authentication Technology Next Generation working group (aka Kitten) to address these work areas.  As such we would like permission from the IESG to form the working group at San Diego or if necessary to hold a BOF to discuss the need for the working group and the scope of its charter.  What follows is a proposed charter for the Kitten Working Group.

Proposed Charter

The Generic Security Services API [RFC 2743, RFC 2744] provides an API for applications to set up security contexts and to use these contexts for per-message protection services.  The Common Authentication Technology Next Generation Working Group (Kitten) will work on standardizing extensions  and improvements to the GSSAPI that the IETF believes are necessary based on experience using GSSAPI over the last 10 years.  Extensions may be published as separate drafts or included in a GSSAPI version 3.  While version 2 of the GSSAPI may be clarified, no backward incompatible changes will be made to this version of the API.

This working group is chartered to revise the GSSAPI v2 RFCs for the purpose of clarifying areas of ambiguity:
  • Use of channel bindings
  • Thread safety restrictions
  • C Language utilization
    • use of const
    • utilization of gss types by the application
    • gss name space
    • improve recommendations for implementation specific types (e.g., use pointers to incomplete structs)
  • Guidelines for GSS-API mechanism designers
  • Guidelines for GSS-API application protocol designers
This working group is chartered to specify a non-backward compatible GSSAPI v3 to support the following extensions:
  • Clarify the portable use of channel bindings and better specify channel bindings in a language-independent manner.
  • Specify thread safety extensions to allow multi-threaded applications to use GSSAPI
  • Definitions of channel bindings for TLS, IPSec, SSH and other cryptographic  channels based on work started in the NFSV4 working  group.
  • Defined a GSSAPI extension to allow applications to store credentials.  Discussions to be started based upon:
    • draft-williams-gss-store-deleg-creds-xx.txt
  • Extensions to solve problems posed by the Global Grid Forum's GSSAPI extensions document.
  • Extensions to deal with mechanism-specific extensibility in a multi-mechanism environment.
  • Extend GSSAPI to support mechanisms that do not have a single canonical name for each authentication identity.
  • Extensions to support stackable GSSAPI mechanisms.

This working group is chartered to perform the following GSSAPI mechanism specification work:
  • Specify a GSSAPI v2/v3 Channel Conjunction Mechanism
  • Revise RFC 2748 (SPNEGO) to correct problems that make the specification unimplementable and to document the problems found in widely-deployed attempts to implement this spec.
End of Proposed Charter


The participants of the IETF-CAT mailing list realize the quantity of work which we desire to undertake is quite ambitious in scope. This is simply an indication of how much work has accumulated over the last few years since the CAT working group disbanded.  We believe that we can accomplish the stated work items in 18 months.

Milestones
  • Clarifications to GSSAPIv2 (six months to IESG)
    Informational
    [editor: Jeffrey Altman]
  • The Channel Conjunction Mechanism (CCM) for the GSSAPI (six months to IESG)
    Proposed Standard
    [editors: Nicolas Williams/Mike Eisler]
  • On the Use of Channel Bindings to Secure Channels (six months to IESG)
    Proposed Standard
    [editor: Nicolas Williams]
    draft-ietf-nfsv4-channel-bindings-01.txt
  • GSSAPIv3 (18 months to IESG)
    Proposed Standard
    [editor: to be determined]
  • Stackable Generic Security Service Pseudo-mechanisms
    Proposed Standard or to be folded into GSSAPIv3
    [editor: Nicolas Williams]
    draft-williams-gssapi-stackable-pseudo-mechs-00.txt
  • GSS-APIv2 Extension for Storing Delegated Credentials
    • Proposed Standard or to be folded into GSSAPIv3
    [editor: Nicolas Williams]
    draft-williams-gssapi-store-deleg-creds-00.txt
  • SPNEGO (RFC 2478) Revisions (18 months to IESG)
    Proposed Standard
    [editor: to be determined]

End of Milestones

Chairperson
The proposed chairperson for the Kitten WG is Jeffrey Altman.

Mailing List
The current mailing list for discussions is ietf-cat-wg@lists.stanford.edu.
Due to the facts that no one at Stanford is actively involved in the
discussions and the mailing list software is quite old, the working group
when formed will switch to a new mailing list.


Sincerely,

Jeffrey Altman (for the participants of the ietf-cat-wg mailing list)

--------------070503080106010007000203-- --------------ms010303090907050209030406 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJOzCC AvgwggJhoAMCAQICAwwjmjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDE2MDIxODM0WhcNMDUwNDE2MDIxODM0 WjBGMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRq YWx0bWFuQGNvbHVtYmlhLmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKyS 7eWrak81hbARkTT+lqX+uujXLK3tDmCn/6IQH9tDKYtf5A8/llZJdPYHUA9p1FH9hwk23iGY scSkJq84FJenlWKOOqOsT6BlueWsrlKuseJCdMf9uhN28p+UnZvrcVhcLLTYfRvQT9OUw/k3 h4TzNdyAXbBJ3LnL1ySbFRaNVkq7cW/2ircAWpcyqHH4ZKstdSLbo6axsDHWRZL8yHUsI1Gz esRSYQf2aUeUqvmGbEKEKFwbfqgfLwlBLiv1Lqib/++J3s5g3syhqWe3T8tUffmhdibUdX2W umT2uiWl/WGEBvc1+o5k0T2JqWMNR9VgzPyk8P+iZRHl76Yb49ECAwEAAaNUMFIwDgYDVR0P AQH/BAQDAgP4MBEGCWCGSAGG+EIBAQQEAwIFoDAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVt YmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGXYUcZvaLEqctXUsgt0 fUMFXukM3E5fpLBkk3+BbcY457WQE38ZM1AOvcYOHqB1xhJCxP1U0pSJu2Xfe9Z1M2mU4C4V 2w4sDcWkZteM9EW7VYbXzSCKCw0TKKp3Wl9TFIWFdiFwPvhOzhXUonGTdYbOvRuAXQuJdNQW O4v2sQg1MIIC+DCCAmGgAwIBAgIDDCOaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA0MTYwMjE4MzRaFw0wNTA0 MTYwMjE4MzRaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG 9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArJLt5atqTzWFsBGRNP6Wpf666Ncsre0OYKf/ohAf20Mpi1/kDz+WVkl09gdQD2nU Uf2HCTbeIZixxKQmrzgUl6eVYo46o6xPoGW55ayuUq6x4kJ0x/26E3byn5Sdm+txWFwstNh9 G9BP05TD+TeHhPM13IBdsEncucvXJJsVFo1WSrtxb/aKtwBalzKocfhkqy11ItujprGwMdZF kvzIdSwjUbN6xFJhB/ZpR5Sq+YZsQoQoXBt+qB8vCUEuK/UuqJv/74nezmDezKGpZ7dPy1R9 +aF2JtR1fZa6ZPa6JaX9YYQG9zX6jmTRPYmpYw1H1WDM/KTw/6JlEeXvphvj0QIDAQABo1Qw UjAOBgNVHQ8BAf8EBAMCA/gwEQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdEQQYMBaBFGphbHRt YW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZdhRxm9o sSpy1dSyC3R9QwVe6QzcTl+ksGSTf4FtxjjntZATfxkzUA69xg4eoHXGEkLE/VTSlIm7Zd97 1nUzaZTgLhXbDiwNxaRm14z0RbtVhtfNIIoLDRMoqndaX1MUhYV2IXA++E7OFdSicZN1hs69 G4BdC4l01BY7i/axCDUwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwwjmjAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NDA1MjQxODI4MDdaMCMGCSqGSIb3DQEJBDEWBBQhAW90aYaNVOotVEDdhTJE6xaVfjBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDCOaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwwj mjANBgkqhkiG9w0BAQEFAASCAQBL4JSKXbhKHaUFc8xb5eFeRiJT5oTiBCZp4W0RPUcfkhyx HVCRjrhZn9um9fNXpiuhP+sDbokxXc/PB3w/YDBV3tqJ+ePzBJeTETXK+p52/I2CLhcwogXe NVKeyTSsjN9ZfjL9HSOAgzfuYbTu/qEmAGdRaog1wGu8VCbSqsZw1bzD/Y3Fy1X/WjXOaX0j mRRWKXVs6wae3CW/axUl0EWjdFQGd2rzEho2IOtrRDxY8E061ZIQeI+jsgKEYm1a2h7CHxsp l9OdBWnBdXjee6f7k7rB5dehbVqjD1YYLw2KPYNgoDVc96w/NGaUzRiKEOvC00q+O1xtnwrK 61Df2iIKAAAAAAAA --------------ms010303090907050209030406-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 27 18:46:08 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02229 for ; Thu, 27 May 2004 18:46:07 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i4RMSBkr017596 for ietf-cat-wg-out720680; Thu, 27 May 2004 15:28:11 -0700 (PDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i4RMS6NK017504 for ; Thu, 27 May 2004 15:28:07 -0700 (PDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i4RMRTw2018585; Thu, 27 May 2004 15:27:29 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i4RMRDcE023068; Thu, 27 May 2004 16:27:13 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i4RMOqQd808833; Thu, 27 May 2004 17:25:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i4RMOpSE808832; Thu, 27 May 2004 17:24:51 -0500 (CDT) Date: Thu, 27 May 2004 17:24:51 -0500 From: Nicolas Williams To: Internet-Drafts@ietf.org Cc: Jeffrey Altman , ietf-cat-wg@lists.Stanford.EDU Subject: draft-williams-gssapi-cred-store-00.txt Message-ID: <20040527222451.GI101103@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk INTERNET-DRAFT Nicolas Williams Sun Microsystems November 2004 GSS-APIv2 Extension for Storing Delegated Credentials Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The details of Generic Security Service (GSS) credential store management vary by platform and even by GSS mechanism. Credential store management is an interesting concept that requires exploration. This document defines a small extension to the GSS-API for GSS-API credential store management. While exploration of the credential store management problem is the goal of this document, implementation of these interfaces is not discounted nor discouraged. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. N. Williams [Page 1] DRAFT GSS Credential Store API Expires November 2004 Table of Contents 1. Introduction pg. 3 2. GSS_Make_cred_store() pg. 3 3. GSS_Get_current_cred_store() pg. 3 4. GSS_Set_current_cred_store() pg. 4 5. GSS_Inquire_cred_store() pg. 5 6. GSS_Display_cred_store() pg. 5 7. C-Bindings pg. 5 8. Examples pg. 5 9. Security Considerations pg. 5 10. Acknowledgements pg. 5 11. References pg. 5 11.1. Informative References pg. 5 11.2. Normative References pg. 5 12. Author's Address pg. 6 N. Williams [Page 2] DRAFT GSS Credential Store API Expires November 2004 1. Introduction [Text needed on what is a "credential store" and what is a "current credential store,: and their relation to the callers' current execution context.] [Also add text about how this stuff imports concepts such as "process," which does not augur well for interface genericity.] [See [gss_store_cred].] 2. GSS_Make_cred_store() Inputs: o inheritance SET OF ENUMERATED, -- Specifies the desired -- inheritance rule for this store. Possible values include: -- -- o none (this process only) -- o default -- o spawn -- o fork -- o exec o sharing ENUMERATED, -- Specifies the desired degree of sharing -- of this store with other processes or threads. Possible values -- include: -- -- o none -- o default -- o allThreadsInSameProcess -- o allProcessesInSameSession -- o allProcessesForSameUser -- o allProcesses Outputs: o major_status INTEGER, o minor_status INTEGER, o cred_store_handle CREDENTIAL STORE HANDLE Return status codes: ... 3. GSS_Get_current_cred_store() Inputs: N. Williams [Page 3] DRAFT GSS Credential Store API Expires November 2004 o Outputs: o major_status INTEGER, o minor_status INTEGER, o cred_store_handle CREDENTIAL STORE HANDLE Return status codes: o GSS_S_COMPLETE indicates that there is a credential store or that one can be created, when GSS_Store_cred() is called, for the current execution context of the caller. o GSS_S_UNAVAILABLE indicates that no credential store exists for the current execution context of the caller. o GSS_S_FAILURE indicates that an unspecified failure has occurred. This function returns a credential store handle that refers to the credential store from which credentials would be acquired given the current execution context of the caller. Credential store handles may not remain accessible when the caller switches the user of the execution context. 4. GSS_Set_current_cred_store() Inputs: o cred_store_handle CREDENTIAL STORE HANDLE, Outputs: o major_status INTEGER, o minor_status INTEGER Return status codes: o GSS_S_COMPLETE indicates that the given credential store will be used by subsequent GSS-API credential acquisition or storage made in the same execution context as that of the caller to GSS_Set_current_cred_store(). If the given store handle is GSS_C_NO_STORE then either a default or new (which is a platform-specific matter) credential store will be created and set as the current credential store. o GSS_S_BAD_STORE indicates that the given credential store handle is not recognized or refers to a credential store that no longer exists or is otherwise corrupt. N. Williams [Page 4] DRAFT GSS Credential Store API Expires November 2004 o GSS_S_UNAVAILABLE indicates that the current credential store for the current execution context could not be set, possibly due to lack of resources. o GSS_S_FAILURE indicates that a generic failure has occurred. This function changes the credential store for the current execution context. Calls to this function MAY have platform-specific side effects (e.g., setting environment variables, setting a process' "pag," etc...), but an implementation of it MUST NOT change the user context of the application, a restriction applicable only on multi-user platforms. The current credential store may change or become unavailable when the caller switches the user of the execution context. 5. GSS_Inquire_cred_store() [Inquire a cred store for inheritance and sharing levels, supported mechanisms.] 6. GSS_Display_cred_store() [Display a credential store. A generic equivalent of MIT's klist(1).] 7. C-Bindings [...] 8. Examples [...] 9. Security Considerations 10. Acknowledgements [...] 11. References 11.1. Informative References [gss_store_cred] N. Williams, draft-williams-gssapi-store-deleg-creds-00: "GSS-APIv2 Extension for Storing Delegated Credentials," September 2003, Status: Internet-Draft. 11.2. Normative References N. Williams [Page 5] DRAFT GSS Credential Store API Expires November 2004 [RFC2026] S. Bradner, RFC2026: "The Internet Standard Process - Revision 3," October 1996, Obsoletes - RFC 1602, Status: Best Current Practice. [RFC2119] S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to Indicate Requirement Levels," March 1997, Status: Best Current Practice. [RFC2743] J. Linn, RFC2743: "Generic Security Service Application Program Interface Version 2, Update 1," January 2000, Status: Proposed Standard. [RFC2744] J. Wray, RFC2744: "Generic Security Service API Version 2 : C-bindings," January 2000, Status: Proposed Standard. 12. Author's Address Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 Email: Nicolas.Williams@sun.com Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF N. Williams [Page 6] DRAFT GSS Credential Store API Expires November 2004 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. N. Williams [Page 7] -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu