From kitten-bounces@lists.ietf.org Fri Sep 3 12:41:59 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 03 Sep 2004 12:41:58 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 576921324F for ; Fri, 3 Sep 2004 12:41:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3H43-0002r9-QJ; Fri, 03 Sep 2004 12:37:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3Grp-0000VG-CI for kitten@megatron.ietf.org; Fri, 03 Sep 2004 12:24:49 -0400 Received: from brazilnut.cc.columbia.edu (IDENT:cu41754@brazilnut.cc.columbia.edu [128.59.59.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08998 for ; Fri, 3 Sep 2004 12:24:46 -0400 (EDT) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i83GOkwL021442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Sep 2004 12:24:47 -0400 (EDT) Message-ID: <41389B27.4000509@columbia.edu> Date: Fri, 03 Sep 2004 12:26:15 -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.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU, kitten@ietf.org X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Cc: Subject: [Kitten] IETF-60 Minutes for Kitten (Draft 1) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0824851503==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 24843 Lines: 540 This is a cryptographically signed message in MIME format. --===============0824851503== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030109000805080705060203" This is a cryptographically signed message in MIME format. --------------ms030109000805080705060203 Content-Type: multipart/mixed; boundary="------------060405000900020408010206" This is a multi-part message in MIME format. --------------060405000900020408010206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sorry for the delay. I will submit these minutes to proceedings at 4pm EDT. Jeffrey Altman --------------060405000900020408010206 Content-Type: text/plain; name="ietf60-kitten-minutes.txt" Content-Disposition: inline; filename="ietf60-kitten-minutes.txt" Content-Transfer-Encoding: 7bit ** IETF 60 - San Diego, CA ** Kitten BOF ** Mon, Aug 2, 2004 Chairs: Jeffrey Altman Scribe: Ken Hornstein Agenda: ------- * Introduction and Welcome [5 minutes] * Global Grid Forum GSS requirements [15 minutes] -Doug Engert * Channel bindings portability issues [2 minutes] -Sam Hartman * GSSAPI naming [10 minutes] -Sam Hartman * Need for cryptographic channel bindings and CCM [20 minutes] -Nicolas Williams * Stackable Psuedo Mechanisms [15 minutes] -Nicolas Williams * C# Bindings for GSSAPI [10 minutes] -J.K. * GSSAPI SPNEGO issues [10 minutes] -Wyllys Ingersol * Kitten Working Group Charter discussion Introduction: ------------- It has been four years since CAT closed, wide deployment has revealed RFCs 2743 and 2744 to be less well-defined that they could be. E.g.: Credentials management, thread safety, channel bindings, ABI stability, mechanism specific extensibility, support for mechanisms without a single canonical name. GSS-SPNEGO is flawed; it's not possible to create interoperable implementations. Channel bindings must be defined to support cryptographic channels such as TLS, IPSec, SSH and a new GSS mechanism to negotiate channel bindings must be defined. Language bindings for C# are desired. What this BOF is going to try to do is to present some of the problem spaces, and see if enough work is available/appropriate to form a WG. Global Grid Forum & GSS extensions developed as part of the GGF: Doug Engert, Argonne National Labs ---------------------------------------------------------------- GGF formed about 5-6 years ago (http://www.ggf.org) to standardize Grid Computing. Its members are from 400 Organizations/50 countries. The next meeting will be in Brussels. Characteristics of Grid Computing: * More than traditional client/server or distributed computing. * User-to-user, peer-to-peer authentication. * Users may start servers/services, and two-way delegation. The Globus GSI (http://www.globus.org) is a GSS-API implementation using TLS/SSL with X.509 certs. Delegation uses RFC-3820 "Internet X.509 PKI Proxy Certificate Profiles", similar to forwarded Kerberos tickets. The initiator and accepter use similar creds. Allows user-to-user and self-to-self authentication. (e.g., file transfer between two nodes, using a proxy cert) GSS-API Extensions GFD-E.024 http://www.ggf.org/documents/GWD-I-E/GFD-E.024.pdf http://www.ietf.org/internet-drafts/draft-engert-ggf-gss-extensions-01.txt Describe GSS extensions adopted by GGF. Details of extensions: * Credential import/export. * Delegation at any time/direction. * Credential extensions handling. * Setting of context options. * Credential import/export: * New APIs: gss_export_cred(), gss_import_cred() - Credentials to a buffer, for things like application saves/reloads. - Credentials could be saved for use by non-GSS-API apps. Applications must be able to accept multiple connections, and save/reload delegated creds not tied to process or thread. The APIs have been implemented for GSI and MIT Kerberos. An open question is how to export creds from within the GSSAPI. The GGF has open issues with Nico Williams' "Creds Store" document: + Needs more control by application over delegated creds. (Uses implicit cred store, but does not address explicit creds stores under application control) + Refers to GGF GSI extensions implying that the mech needs knowledge of environment + Uses Simon's OpenSSH mods as example, but they use KRB5CCNAME environment variable. (Nico Wiilliams pointed out at this point that OpenSSH is a bad example, and that OpenSSH does not need to use an environment variable to implement the necessary functionality.) * Delegation at any time: gss_init_delegation(), gss_accept_delegation() Allows credential delegatin after context establishment, may be different creds, delegation is in either direction. * Credential extensions handling: Get mechanism or OID-specific information from credentials. Possible uses: Certificate extensions/Kerberos authorization data. Use OID to avoid mechanism API calls. * Setting of context options: gss_set_context_option_call() Set options for context using an OID. E.g.: Limited delegation, Kerberos forwardable flag, what to do when context expires, set encryption options. Additional functional desired: * Token Framing for every token. * Levels of verbosity with gss_display_status(). * Need a simple authz frunction to access krb5_kuserok() or the gridmap file. Chair: The GGF have touched on issues that numerous people have discovered (e.g., credential handling, authorization issues). Perhaps given our experience, we can tackle broader problems with more comfort than we had in the past. Channel bindings portability issues: Sam Hartman ------------------------------------ GSS-API has concept called channel bindings. We want to be able to make an assertion that the channel you are communication over is the same one you authenticated across. GSS-API authors had the concept that you might want to bind to a crypto key you're using for encryption, but they didn't really follow through. In RFC 2743, GSSAPI split into language-independent and language-dependent sections. The language-independent portion treated channel bindings as an opaque blob, but it's the sort of thing that mechanisms want to peek into. The C-language bindings specified a IP address, and the format for the IP address. The revision to the base specification refers to the C-language bindings and says, "Look her to see how channel bindings work". obviously, this is odd. The language bindings defines a C structure, which is not a good presentation layer (other minor problems with channel bindings). GSSAPI naming: Sam Hartman ------------------------------ GSSAPI Naming works well for some apps, not so well for others. Authentication/Authorization: * Authentication generates assertions as input to authorizations * Authorization uses these assertions to make access decisions. GSS Authentication model: * GSSAPI asserts an authenticated name to both peers. All input forms of this name can be canonicalized to a single form which is binary comparable. Authorization with GSSAPI names: * Canonical forms can be placed on ACLs. Without authentication a peer can generate canonical forms. There is a need to be able to handle more complicated structures. You might want to do more complicated things (directories, groups). Difficulty of Canonical Forms: * Names change over time. * Some mechanisms have no canonical representations. (e.g., what is the canonical name out of an X.509 cert?) SubjectAltName creates problems for certificates. (e.g., what about email address? Does the GSSAPI not get access to that because it's not part of your DN?) * [Bob Morgan: Some cases it's desirable to have the authentication name have only short-term value] * [Bill Sommerfeld: I realized that if you looked at the X.509 extended key usage attribute as part of the principal name, the cert became a lot more understandable] Desire for new Authentication Assertions: * Membership in groups. * Liberty/SAML require more complex assertions * Keeping names the same as people move in organizations. * People that have done large Kerberos deployments don't want to look up authz data in directories, they want the info in tickets. [Doug Engert: line between groups and names isn't black & white] Possible solutions: * Name attributes * Extensions to gss_canonicalize_name() * Credential extensions. Need for cryptographic channel bindings and CCM: Nicolas Williams ------------------------------------------------ Channel bindings allow session protecction at one network layer to be delegated to session protection at another by proving there is no MITM in the lower layer. Why? Performance plus security. Concept first described in GSS-APIv2 (rfc2273/2274), but the specs were lacking. (This is really relevant for applications that already have transport security, e.g. hardware accelerated encryption) Formal Definition (rough; See I-D): * Mutual auth at app-layer * App-level end-points exchange integrity-protected proof of knowledge of "channel bindings" for lower layer, secure channel. * Channel bindings must cryptographically _name_ a channel. Examples: TLS, SSHv2 - Channel bindings for TLS: client & server finished messages - Channel bindings for SSHv2: session ID These are crypto bound to the initial TLS/SSHv2 key exchange. - TCP/SCTP/UDP/IPSec? It can be done. - NULL bindings? Better than AUTH_SYS for NFS. GSS-API & Channel Bindings. * RFC2743 talks about them, but provides little guidance. * RFC2744 provides C structure (and little guidance beyond network addresses) channel binding are _not_ negotiable - you either use them, or don't. To make GSS channel bindings useful: * Provide a generic structure for channel binding data * Provide guidance for several types of channel bindings * Provide for negotiation of channel bindings by adding a new stackable GSS mechanism. Benefits (Overview) * Avoid double encryption when possible (E.g., NFS over IPsec) If the lower layer authentication facilities satisfy application needs then there's no need for channel bindings but we expect IPsec w/user certs to be rare. * RDDP RDDP layers between the transport and the application to facilitate receiver zero-copy by addressing interesting buffers in app payloads and direction RNIC to DMA data to correct location. * IPSec channel TCP/SCTP connection protected with transport-mode SA's with same protection/authentication for duration of connection. New APIs needed to deal with IPsec channels. (e.g. draft-ietf-ipsec-apireq-00.txt) What about anonymous IPsec? Apps that provide for authentication may not care about IDs authentication by IPsec but it would be nice to leverage IPsec for encryption (think hardware encryption). Channel binding structure/constructor functions. draft-williams-gssapi-channel-bindings-00.txt (not yet published) Generalizes structures from RFC2374. CCM-BIND: GSS pseudo mechanism stacks atop concrete mechs, like Kerberos 5. draft-ietf-nfsv4-ccm-02.txt Properly handles channel bindings proof exchanges. Offering CCM signals willingness to use channel bindings. SASL w/Channel Bindings Use SASL GSS-API spec And use CCM-BIND, negotiate SASL mechs as usual. (Needs review from the SASL community) SPNEGO and channel bindings pretty much same as SASL (minor changes to SPNEGO) In designing GSS CCM, useful concept noted: generic stackable pseudo-mechs. Interfaces needed to make this work. Q&A: [David Black, EMC: IPsec channel bindings can get very "interesting", e.g. fiberchannel node names in IPsec endpoint names.] [Nico: We don't care what the channel bindings are at the IPsec layer.] [David: Not time for full discussion now, just wanted to bring up the issue that the idea of indirect cryptographic binding involves a lot of work.] Stackable Psuedo Mechanisms: Nicolas Williams ------------------------------------ Brief history: * 2000 - LIPKEY, basic-over-SPKM * Early 2003: CCM-BIND (I-D), first stackable GSS pseudo-mechanism. * 58th IETF: hallway discussion of mechanism resulted in need for abstraction. Glossary: * Concrete mechanism - Mech that can be used as-is. * Pseudo-mech: mech only useful without reference to a concrete mech (e.g., SPNEGO) stackable pseudo-mech: mechanism that can be stacked above or combined with a concrete mechanism. Introduction: GSS-API mechs exist for Kerberos 5, PKIX (SPKM), and others such as Microsoft's NTLMSSP, Sun's mech_dh. GSS pseudo-mechanisms exist today - SPNEGO. When developing new lightweight pseudo-mech for NFS we expanded on channel bindings and came up with CCM. Composite mechs have OID, just like any other mechanism. LIPKEY: Almost a stack (does equivalant of basic-over-SSL) Other idea for stackable pseudo-mechs: * Proper channel binding - CCM-BIND * PFS, Compression, basic-over-*, three party auth. Example: Perfect Forward Secrecy. Context tokens might contain tokens from lower mech, DH public parameters, and it's own per-message tokens. Not all mechanism stacks make sense (e.g., pfs, compress, krb5 is no good, but {compress, pfs, krb5} is okay. Complexity - how many valid composites, how to negotiate? GSS_indicate_mechs() - don't want to make stackable mechs available to apps. Solutions: * GSS_indicate_mechs() MUST not indicate stackable mechs and composite mechs (composite mechs okay if explicitly configured to do so). New APIs for stackable/composite mechs. Composite mech users know what features they want from them, but why should they know the OID of the composite mechs? Add API for inquiring mechs by attributes. These new APIs are all optional. Stackable pseudo-mechs should describe constraints on how they can be mixed with other mechs. Benefits of new APIs: * No need to hardcode mechanism OIDs anymore. e.g, SSHv2 MUST NOT use SPNEGO, but SPNEGO might get new OIDs. * Indicating mechs by attributes makes applications more general. Mechanism attributes: * concrete * stackable * composite * glue * other Depreciated (old krb5 mech OID), non-standard (GSI SSL mech) authenticates initiator, acceptor, other. See draft: draft-williams-gssapi-stackable-pseudo-mechs-00.txt C# Bindings for GSSAPI: J.K. Jaganathan ---------------------------------- Not able to get draft out in time. First version is just a description of MS's implementation of current GSS-API bindings. We are hoping that this will be the right forum. Interested in hearing from people who had experience with Java GSSAPI bindings. [Nico: If you're going to have bindings for SSPI's encrypt-in-place functionality, it would be nice to have that functionality in GSSAPI as well.] [Chair: Novell's Mono group has an alternate proposal for C# bindings based on the Java GSS-API bindings.] GSSAPI SPNEGO issues: Wyllys Ingersol ------------------------------------ Original SPNEGO draft implemented early on by MS. When Sun tried to implement it, discovered interop problems with MS implementation. Some problems are DER versus BER, explicit versus implicit tagging, mechlist MIC field, only implemented to cover initial list you send (should it also include flags, encoding of the sequence, concatenated OIDs), and more vagarities. (Those were all spec issues.) Implementation issues: Kerberos OID is wrong, off by one byte, which changes whole OID. Mechlist MIC field not valid for request, and server ignores mechlist MIC field completely. (Problem with server ignoring mechlist MIC is that since the sequence number is incremented on the client but the server does not, the sequence numbers don't match) Without using mechlist-MIC, you get SNEGO, not SPNEGO. We couldn't find a way of producing a implementation that followed the spec and interoperated with MS. Suggestions: * force all vendors to implement the spec correctly and have a flag day, but that won't likely work. * clarify the spec and get a new OID. [hartmans: Even if you have a new OID, you need to have a flag day] Proposed Charter Discussion: ------------------------------ Looking at moving two directions at once: informational draft with wisdom for gssapi v2, new draft describing gssapi v3. [Nico: The only thing that might break backwards compat is the naming work (no canonical names for some mechs).] Open mike for charter items: [Joe Saloway, Cisco: W.R.T channel bindings, might be worth investigating if we can get some commonality from SASL & EAP. In terms of naming, might need to update existing mechanisms to deal with new naming.] [Chair: agreed, naming is an open topic still.] [Sam Hartman: The SASL GSSAPI editor is very familiar with our work (couldn't be here today), it would be great if we could get someone from EAP here. W.r.t naming, if a mechanism has a home, the work could be done there (e.g., Kerberos in krb-wg), not sure if spkm has a home. if people want to drop things, my personal preference is to drop gssapiv2 clarifications.] [Nico: w.r.t. channel bindings, I don't think the concept is specific to gssapi, can be generalized to other things. GSSAPI just provides a slot for it, so it's a natural home for it.] [Bill Sommerfeld: There may be multiple working groups here (e.g., maybe channel bindings should be it's own WG). Maybe want broader community to work on channel bindings who may not be interested in 'const' in GSSAPI.] [Unknown: May want to check to see if termology w.r.t. channel bindings is same termology as EAP, not sure if it is.] [Sam Hartman: EAP has the same channel bindings problems even if they don't call it channel bindings.] [Joe Saloway: there are a couple of drafts that deal with things similar to stackable mechs in EAP.] [Nico: Similar things in Kerberos with preauth mechanisms.] [Sam Hartman: while it's good we're acknowledging all of this synergy, we do want to get done in a finite time, if we split off into multiple wg's it may prevent that.] [: "Specify thread safety extensions"? Has focus shifted from clarifying thread issues (like two threads calling gss_get_mic at the same time), to provide new APIs? What would the new APIs look like? I re-read the thread discussion on the list, but did not find discussion on any thread extensions.] [Chair: I do not believe we're discussing any new APIs.] [Nico: We're just talking about changes in semantics but some list members believe that's effectively a new API. The big issue is that if you write a threaded GSSAPI program, you lose portability.] [Ken Raeburn: Phrasing of this section of charter (clarification of gssapi v2) is poor; many times, if something is unclear, the answer is, "You just lose".] [Chair: Idea is similar to Kerberos clarifications: explanations of what apps might expect, and what we thought the spec meant.] [: fwiw, changing semantics to make threaded use work would be fine by me, but introducing new APIs for threading seem convoluted.] [Nico: GSSAPIv3 won't be radically different than v2; should have most of the same APIs. For v2, we could use a preprocessor macro to determine if the GSSAPI implementation is thread-safe or not.] [Russ Housley (IESG): First big question: Is there community support for this initiative? Some documents already have names behind them, which means that they have editors. Question asked: "Do people think that this work belongs in the IETF?" Looks like the consensus is that the answer is "yes".] --------------060405000900020408010206-- --------------ms030109000805080705060203 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDQwOTAzMTYyNjE1WjAjBgkqhkiG9w0BCQQxFgQUCpA0xltLLGNsewsoidxOh+StPUMw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAp2PEDPIvNe/QyeRLgGFUSiPQwjXc5bsawLetPSRk 2mRcdNdcsHTAVVhe77gxIVryDzZE3vEMVVPpC/njAqOZrd4VTXp0rN3XD5xN26pYwyXcoNeb pEwIYafIQxdHexng25B9lVbEvjgnbvxNd6OtR8ozjy7uvlsFF4qNmVCRBiYBZzzdYRqLMoK1 1AEzRx+opmSGfLrQtFp7Gt+nB+bOyUdx/U0kQm+KEe8BuK8NfftQxDqlAf//0pYi3yaF7qjO fCk7z2G4n0bLnLam74ZjkCzSWOthHcLVIROXflVgus/LEylk2QKYPCV608QEyldnQZXJPhQ+ z8xc5OuaKxFrIgAAAAAAAA== --------------ms030109000805080705060203-- --===============0824851503== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0824851503==-- From kitten-bounces@lists.ietf.org Wed Sep 8 14:38:15 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Wed, 08 Sep 2004 14:38:13 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id DF8D313711 for ; Wed, 8 Sep 2004 14:38:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C57Cz-0000NA-Ge; Wed, 08 Sep 2004 14:30:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C576N-00076j-Lo for kitten@megatron.ietf.org; Wed, 08 Sep 2004 14:23:27 -0400 Received: from serrano.cc.columbia.edu (IDENT:cu41754@serrano.cc.columbia.edu [128.59.59.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03731 for ; Wed, 8 Sep 2004 14:23:24 -0400 (EDT) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i88INLrc001577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 8 Sep 2004 14:23:23 -0400 (EDT) Message-ID: <413F4E7E.6050403@columbia.edu> Date: Wed, 08 Sep 2004 14:25:02 -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.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------070900040501030506080609" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Cc: Subject: [Kitten] Proposed Charter X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 5627 Lines: 161 This is a multi-part message in MIME format. --------------070900040501030506080609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Attached is the proposed charter as of the IETF 60 BOF. Now is the time to discuss on the list any changes we would like to make prior to submitting the Charter to the IESG for approval. Jeffrey Altman --------------070900040501030506080609 Content-Type: text/plain; name="charter.txt" Content-Disposition: inline; filename="charter.txt" Content-Transfer-Encoding: 7bit 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 core GSSAPI specification and language bindings 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: o Use of channel bindings o Thread safety restrictions o 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) o Guidelines for GSS-API mechanism designers o 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: o Clarify the portable use of channel bindings and better specify channel bindings in a language-independent manner. o Specify thread safety extensions to allow multi-threaded applications to use GSSAPI o Definitions of channel bindings for TLS, IPSec, SSH and other cryptographic channels based on work started in the NFSV4 working group. o 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 o Extensions to solve problems posed by the Global Grid Forum's GSSAPI extensions document. o Extensions to deal with mechanism-specific extensibility in a multi-mechanism environment. o Extend GSSAPI to support mechanisms that do not have a single canonical name for each authentication identity. o Extensions to support stackable GSSAPI mechanisms. This working group is chartered to perform the following GSSAPI mechanism specification work: o Specify a GSSAPI v2/v3 Channel Conjunction Mechanism o 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. This working group is chartered to perform the following new GSSAPI Language Binding specification work: o Specify a language binding for C# 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 Either: o Clarifications to GSSAPIv2 (six months to IESG) Informational [editor: TBD] Or: o Generic Security Service Application Program Interface Version 2, Update 2 (six months to IESG) Proposed Standard [editor: TBD] o Generic Security Service API Version 2 : C-bindings (six months to IESG) Proposed Standard [editor: TBD] End: o The Channel Conjunction Mechanism (CCM) for the GSSAPI (six months to IESG) Proposed Standard [editors: Nicolas Williams/Mike Eisler] o 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 o GSSAPIv3 (18 months to IESG) Proposed Standard [editor: to be determined] o 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 o 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 o GSSAPI Mechanisms without a Single Canonical Name (12 months to IESG) to be folded into GSSAPIv3 [editor: Sam Hartman] draft-hartman-gss-naming-00.txt o SPNEGO (RFC 2478) Revisions (18 months to IESG) Proposed Standard [editor: TBD] o C# Bindings for GSSAPI Proposed Standard [editor: Larry Zhu] End of Milestones MAILING LIST: The mailing list for discussions is kitten@lists.ietf.org Use the following web page to join: https://www1.ietf.org/mailman/listinfo/kitten --------------070900040501030506080609 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --------------070900040501030506080609-- From kitten-bounces@lists.ietf.org Wed Sep 8 15:21:04 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Wed, 08 Sep 2004 15:21:03 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 1CC4413711 for ; Wed, 8 Sep 2004 15:21:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C57t1-0001UD-Lv; Wed, 08 Sep 2004 15:13:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C57bm-0005wU-Fn for kitten@megatron.ietf.org; Wed, 08 Sep 2004 14:55:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05797 for ; Wed, 8 Sep 2004 14:55:52 -0400 (EDT) Received: from stratton-four-seventy-six.mit.edu ([18.187.6.221] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C57fT-0006th-AY for kitten@ietf.org; Wed, 08 Sep 2004 14:59:44 -0400 Received: by cz.mit.edu (Postfix, from userid 8042) id 863B4E004D; Wed, 8 Sep 2004 14:56:50 -0400 (EDT) To: Jeffrey Altman Subject: Re: [Kitten] Proposed Charter References: <413F4E7E.6050403@columbia.edu> From: Sam Hartman Date: Wed, 08 Sep 2004 14:56:50 -0400 In-Reply-To: <413F4E7E.6050403@columbia.edu> (Jeffrey Altman's message of "Wed, 08 Sep 2004 14:25:02 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 X-Mailman-Approved-At: Wed, 08 Sep 2004 15:13:42 -0400 Cc: kitten@ietf.org X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 261 Lines: 9 Several of us requested adding a PRF for gssapi as an extension. Nico has a draft to do this. There were no objections. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Sep 8 18:32:45 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Wed, 08 Sep 2004 18:32:44 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id F107A13711 for ; Wed, 8 Sep 2004 18:32:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5AvW-00033D-NU; Wed, 08 Sep 2004 18:28:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5AoT-0001bl-Qj for kitten@megatron.ietf.org; Wed, 08 Sep 2004 18:21:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28038 for ; Wed, 8 Sep 2004 18:21:10 -0400 (EDT) Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5AsB-0004aB-V6 for kitten@ietf.org; Wed, 08 Sep 2004 18:25:05 -0400 Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i88MLAMF025331; Wed, 8 Sep 2004 18:21:10 -0400 (EDT) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i88ML3qX000378 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 8 Sep 2004 18:21:09 -0400 (EDT) In-Reply-To: <413F4E7E.6050403@columbia.edu> References: <413F4E7E.6050403@columbia.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5ED38C2E-01E5-11D9-ABEA-000A95909EE2@mit.edu> From: Ken Raeburn Date: Wed, 8 Sep 2004 18:21:03 -0400 To: Jeffrey Altman X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Ken Raeburn Subject: Re: [Kitten] Proposed Charter X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 1498 Lines: 47 On Sep 8, 2004, at 14:25, Jeffrey Altman wrote: > o 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) Do we need to specify this level of detail, and by implication exclude any other issues that may come up? Would o C language utilization clarifications and recommendations (e.g., type utilization, name spaces) suffice? > This working group is chartered to specify a non-backward compatible > GSSAPI v3 to support the following extensions: I don't think this phrasing goes quite so far in prohibiting us from considering changes not explicitly listed.... > o Specify thread safety extensions to allow multi-threaded > applications > to use GSSAPI First, this probably belongs with "language bindings specification work". Second, as stated, this is not limited to the C bindings, correct? I don't recall if we ever discussed that point. > o Generic Security Service API Version 2 : C-bindings (six months to > IESG) ... Update 1? > o GSSAPI Mechanisms without a Single Canonical Name (12 months to > IESG) Perhaps "Unique" rather than "Single"? That might be redundant, but "without a single..." makes me think "zero", not "not precisely one". _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Sep 9 14:51:08 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Thu, 09 Sep 2004 14:51:07 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 8467613207 for ; Thu, 9 Sep 2004 14:51:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5TnF-0006S1-Ud; Thu, 09 Sep 2004 14:37:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Tjk-0005jQ-Di for kitten@megatron.ietf.org; Thu, 09 Sep 2004 14:33:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10534 for ; Thu, 9 Sep 2004 14:33:34 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.59.238] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5Tnd-0007xe-90 for kitten@ietf.org; Thu, 09 Sep 2004 14:37:38 -0400 Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i89IXOLh014890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 9 Sep 2004 14:33:31 -0400 (EDT) Message-ID: <4140A25A.7090904@columbia.edu> Date: Thu, 09 Sep 2004 14:35:06 -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.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org References: <413F4E7E.6050403@columbia.edu> <5ED38C2E-01E5-11D9-ABEA-000A95909EE2@mit.edu> In-Reply-To: <5ED38C2E-01E5-11D9-ABEA-000A95909EE2@mit.edu> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: Subject: Re: [Kitten] Proposed Charter X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 1514 Lines: 51 Ken Raeburn wrote: > On Sep 8, 2004, at 14:25, Jeffrey Altman wrote: > >> o 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) > > > Do we need to specify this level of detail, and by implication exclude > any other issues that may come up? Would I do not think that we need to specify this level of detail. I have replaced the detail with: > o C language utilization clarifications and recommendations (e.g., > type utilization, name spaces) >> o Specify thread safety extensions to allow multi-threaded applications >> to use GSSAPI > > > First, this probably belongs with "language bindings specification > work". Second, as stated, this is not limited to the C bindings, > correct? I don't recall if we ever discussed that point. I don't think we discussed this in detail. My assumption was that thread safety is language binding specific but that part of the problem was that there is a lack of expectations set by the base document. At the moment we do not have a separate section of work items for the Language Bindings vs the base document. Do we need to list the impact of the proposed extensions on the Language Bindings separately? Jeffrey Altman _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Sep 9 14:53:18 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Thu, 09 Sep 2004 14:53:17 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id D0B9313207 for ; Thu, 9 Sep 2004 14:53:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5U35-0001Gy-VJ; Thu, 09 Sep 2004 14:53:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5TnG-0006SB-G2 for kitten@megatron.ietf.org; Thu, 09 Sep 2004 14:37:14 -0400 Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10898 for ; Thu, 9 Sep 2004 14:37:12 -0400 (EDT) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i89IbAAa016069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 9 Sep 2004 14:37:11 -0400 (EDT) Message-ID: <4140A339.5070800@columbia.edu> Date: Thu, 09 Sep 2004 14:38:49 -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.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Cc: Subject: Proposed Charter (Draft #2) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0329734414==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 10676 Lines: 238 This is a cryptographically signed message in MIME format. --===============0329734414== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070703000405080804000906" This is a cryptographically signed message in MIME format. --------------ms070703000405080804000906 Content-Type: multipart/mixed; boundary="------------050400090501060107010405" This is a multi-part message in MIME format. --------------050400090501060107010405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Incorporating PRF and most of Ken Raeburn's comments. --------------050400090501060107010405 Content-Type: text/plain; name="charter.txt" Content-Disposition: inline; filename="charter.txt" Content-Transfer-Encoding: 7bit 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 core GSSAPI specification and language bindings 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: o Use of channel bindings o Thread safety restrictions o C language utilization clarifications and recommendations (e.g., type utilization, name spaces) o Guidelines for GSS-API mechanism designers o Guidelines for GSS-API application protocol designers This working group is chartered to specify a non-backward compatible GSSAPI v3 including support for the following extensions: o Clarify the portable use of channel bindings and better specify channel bindings in a language-independent manner. o Specify thread safety extensions to allow multi-threaded applications to use GSSAPI o Definitions of channel bindings for TLS, IPSec, SSH and other cryptographic channels based on work started in the NFSV4 working group. o Define a GSSAPI extension to allow applications to store credentials. Discussions to be started based upon: o draft-williams-gss-store-deleg-creds-xx.txt o Extensions to solve problems posed by the Global Grid Forum's GSSAPI extensions document. o Extensions to deal with mechanism-specific extensibility in a multi-mechanism environment. o Extend GSSAPI to support mechanisms that do not have a single canonical name for each authentication identity. o Extensions to support stackable GSSAPI mechanisms. o Define a Psuedo-Random Function for GSSAPI This working group is chartered to perform the following GSSAPI mechanism specification work: o Specify a GSSAPI v2/v3 Channel Conjunction Mechanism o 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. This working group is chartered to perform the following new GSSAPI Language Binding specification work: o Specify a language binding for C# 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 Either: o Clarifications to GSSAPIv2 (six months to IESG) Informational [editor: TBD] Or: o Generic Security Service Application Program Interface Version 2, Update 2 (six months to IESG) Proposed Standard [editor: TBD] o Generic Security Service API Version 2, Update 1 : C-bindings (six months to IESG) Proposed Standard [editor: TBD] End: o The Channel Conjunction Mechanism (CCM) for the GSSAPI (six months to IESG) Proposed Standard [editors: Nicolas Williams/Mike Eisler] o 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 o GSSAPIv3 (18 months to IESG) Proposed Standard [editor: to be determined] o 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 o 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 o GSSAPI Mechanisms without a Unique Canonical Name (12 months to IESG) to be folded into GSSAPIv3 [editor: Sam Hartman] draft-hartman-gss-naming-00.txt o SPNEGO (RFC 2478) Revisions (18 months to IESG) Proposed Standard [editor: TBD] o Pseudo-Random Function for GSSAPI to be folded into GSSAPIv3 [editor: Nicolas Williams] o C# Bindings for GSSAPI Proposed Standard [editor: Larry Zhu] End of Milestones MAILING LIST: The mailing list for discussions is kitten@lists.ietf.org Use the following web page to join: https://www1.ietf.org/mailman/listinfo/kitten --------------050400090501060107010405-- --------------ms070703000405080804000906 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDQwOTA5MTgzODQ5WjAjBgkqhkiG9w0BCQQxFgQUfE7PDWBRlv3rABHT7EMq5iNeOikw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEA2KGSkbMzedtbhn5XSdA/3erJysrTwFiIrcra7x4P X7MCLUCO5vZwy4Aqjoj1hCYM1E2abTOZB5yXjDZsoNYd8iMJOa18l3Jr4thrP2adXQ3sd7xf 8qsR74PN+9XH+4xTZVjoNBPvTMXjom4UthybMbOVr/wjgHMNmPLvr35UNTu9TyNdNGf8A3Q1 1Jb7ZamwN298Nz+nEifaEbZ16z2k2EAruVpJC/IWVYDp1+006o+ncsvDmgsfJqR5J1EqcaiN VVSd/7XwnlgHO1Y8o92TMU72/Y6gJcGIRKzwnlz8hLkGJClZKacLkGlVPECykfEkYjy7x8VE 8o6gSlz5KSq5swAAAAAAAA== --------------ms070703000405080804000906-- --===============0329734414== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0329734414==-- From kitten-bounces@lists.ietf.org Thu Sep 9 15:22:11 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Thu, 09 Sep 2004 15:22:08 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 875CA13207 for ; Thu, 9 Sep 2004 15:22:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5UNw-0006Av-Lb; Thu, 09 Sep 2004 15:15:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5UMt-0005Wo-DI for kitten@megatron.ietf.org; Thu, 09 Sep 2004 15:14:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13854 for ; Thu, 9 Sep 2004 15:14:01 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5UQn-0000DQ-4v for kitten@ietf.org; Thu, 09 Sep 2004 15:18:05 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i89JE053029604 for ; Thu, 9 Sep 2004 13:14:00 -0600 (MDT) 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 i89JDxja011028 for ; Thu, 9 Sep 2004 13:14:00 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i89JAwik025874; Thu, 9 Sep 2004 14:10:58 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i89JAvST025873; Thu, 9 Sep 2004 14:10:57 -0500 (CDT) Date: Thu, 9 Sep 2004 14:10:57 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20040909191056.GG1989@binky.central.sun.com> References: <4140A339.5070800@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4140A339.5070800@columbia.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: kitten@ietf.org, Mike Eisler Subject: Re: Proposed Charter (Draft #2) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 5975 Lines: 158 Are we taking the CCM document from the NFSv4 WG? Also, I'm not the editor of that one -- Mike Eisler is (I'm not sure if he's on this list either). My understanding was that we'd last call CCM in both WGs. Also, I take it the C# bindings are now part of KITTEN's charter? (I don't mind, mind you.) If so, Sun has some corrections to make to the Java bindings RFC (the error codes used by Sun's implementation don't agree with the ones in the RFC; it's easier to change the RFC than to fix the implementations and recompile the apps). Nico On Thu, Sep 09, 2004 at 02:38:49PM -0400, Jeffrey Altman wrote: > Incorporating PRF and most of Ken Raeburn's comments. > > 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 core GSSAPI specification and language > bindings 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: > o Use of channel bindings > o Thread safety restrictions > o C language utilization clarifications and recommendations > (e.g., type utilization, name spaces) > o Guidelines for GSS-API mechanism designers > o Guidelines for GSS-API application protocol designers > > This working group is chartered to specify a non-backward compatible > GSSAPI v3 including support for the following extensions: > o Clarify the portable use of channel bindings and better specify > channel bindings in a language-independent manner. > o Specify thread safety extensions to allow multi-threaded applications > to use GSSAPI > o Definitions of channel bindings for TLS, IPSec, SSH and other > cryptographic channels based on work started in the NFSV4 working > group. > o Define a GSSAPI extension to allow applications to store credentials. > Discussions to be started based upon: > o draft-williams-gss-store-deleg-creds-xx.txt > o Extensions to solve problems posed by the Global Grid Forum's GSSAPI > extensions document. > o Extensions to deal with mechanism-specific extensibility in a > multi-mechanism environment. > o Extend GSSAPI to support mechanisms that do not have a single > canonical name for each authentication identity. > o Extensions to support stackable GSSAPI mechanisms. > o Define a Psuedo-Random Function for GSSAPI > > This working group is chartered to perform the following GSSAPI mechanism > specification work: > > o Specify a GSSAPI v2/v3 Channel Conjunction Mechanism > o 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. > > This working group is chartered to perform the following new GSSAPI Language > Binding specification work: > > o Specify a language binding for C# > > 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 > Either: > o Clarifications to GSSAPIv2 (six months to IESG) > Informational > [editor: TBD] > Or: > o Generic Security Service Application Program Interface Version 2, Update 2 > (six months to IESG) > Proposed Standard > [editor: TBD] > o Generic Security Service API Version 2, Update 1 : C-bindings (six months to IESG) > Proposed Standard > [editor: TBD] > End: > o The Channel Conjunction Mechanism (CCM) for the GSSAPI (six months > to IESG) > Proposed Standard > [editors: Nicolas Williams/Mike Eisler] > o 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 > o GSSAPIv3 (18 months to IESG) > Proposed Standard > [editor: to be determined] > o 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 > o 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 > o GSSAPI Mechanisms without a Unique Canonical Name (12 months to IESG) > to be folded into GSSAPIv3 > [editor: Sam Hartman] > draft-hartman-gss-naming-00.txt > o SPNEGO (RFC 2478) Revisions (18 months to IESG) > Proposed Standard > [editor: TBD] > o Pseudo-Random Function for GSSAPI > to be folded into GSSAPIv3 > [editor: Nicolas Williams] > o C# Bindings for GSSAPI > Proposed Standard > [editor: Larry Zhu] > > End of Milestones > > > MAILING LIST: > The mailing list for discussions is > > kitten@lists.ietf.org > > Use the following web page to join: > > https://www1.ietf.org/mailman/listinfo/kitten > > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Sep 9 15:34:26 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Thu, 09 Sep 2004 15:34:24 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id B367513207 for ; Thu, 9 Sep 2004 15:34:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Udo-0006DA-2O; Thu, 09 Sep 2004 15:31:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5UWF-0002Xg-Bz for kitten@megatron.ietf.org; Thu, 09 Sep 2004 15:23:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15362 for ; Thu, 9 Sep 2004 15:23:41 -0400 (EDT) Received: from brazilnut.cc.columbia.edu ([128.59.59.203] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5Ua8-0000QW-HO for kitten@ietf.org; Thu, 09 Sep 2004 15:27:46 -0400 Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i89JNRWU004237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Sep 2004 15:23:29 -0400 (EDT) Message-ID: <4140AE15.6090804@columbia.edu> Date: Thu, 09 Sep 2004 15:25:09 -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.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams References: <4140A339.5070800@columbia.edu> <20040909191056.GG1989@binky.central.sun.com> In-Reply-To: <20040909191056.GG1989@binky.central.sun.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: kitten@ietf.org, Mike Eisler Subject: Re: Proposed Charter (Draft #2) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0390893167==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 6120 Lines: 117 This is a cryptographically signed message in MIME format. --===============0390893167== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030704010101090100000305" This is a cryptographically signed message in MIME format. --------------ms030704010101090100000305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > Are we taking the CCM document from the NFSv4 WG? Also, I'm not the > editor of that one -- Mike Eisler is (I'm not sure if he's on this list > either). I believe the decision should be made by the IESG. > Also, I take it the C# bindings are now part of KITTEN's charter? (I > don't mind, mind you.) If so, Sun has some corrections to make to the > Java bindings RFC (the error codes used by Sun's implementation don't > agree with the ones in the RFC; it's easier to change the RFC than to > fix the implementations and recompile the apps). I do not object to updating the Java Bindings as part of the Charter. Other comments? Jeffrey Altman --------------ms030704010101090100000305 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDQwOTA5MTkyNTA5WjAjBgkqhkiG9w0BCQQxFgQUla7H316zIf+R2AhnbytNVeDbBMkw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAhkIWASTPihPlBwwqYKJ2DjLTh99OIXbwtD+4zdDN 63l8zcAYiqtIwY6ekS3PAOEHlfE6tXr6Gl+ArALHNd5t8dxdZWyToX/mo7qEDf63W+SPB1MG f9xmjTYMBfwdqKgjZKLvUe4Q+jWcXFsF3383srhyFSlNiMaY4AIFJwLc8BPe7MMR+aJYfBsV 1CEX1oAuV3v/br+uwxgBmMm95z7f+teBZiWRBCQS/8HlpkmvKVUw6011Vde4Udf6QcWXiUlk Maxw6jmPDxfONOevR7xFzndY5KzAQAcxM3tMp1DiBtoGR6Qn8z8XiQqCPitlNrASVCCXLtYd wr3E3mJKpQ8DmgAAAAAAAA== --------------ms030704010101090100000305-- --===============0390893167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0390893167==-- From kitten-bounces@lists.ietf.org Thu Sep 9 15:36:58 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Thu, 09 Sep 2004 15:36:57 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 5427513207 for ; Thu, 9 Sep 2004 15:36:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5UfV-0006yS-1t; Thu, 09 Sep 2004 15:33:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5UYR-0003cU-9X for kitten@megatron.ietf.org; Thu, 09 Sep 2004 15:25:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15568 for ; Thu, 9 Sep 2004 15:25:57 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5UcJ-0000Tg-Mb for kitten@ietf.org; Thu, 09 Sep 2004 15:30:02 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i89JPs4d010739 for ; Thu, 9 Sep 2004 12:25:54 -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 i89JPrja017539 for ; Thu, 9 Sep 2004 13:25:54 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i89JMqum025897; Thu, 9 Sep 2004 14:22:52 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i89JMqMD025896; Thu, 9 Sep 2004 14:22:52 -0500 (CDT) Date: Thu, 9 Sep 2004 14:22:52 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20040909192252.GI1989@binky.central.sun.com> References: <4140A339.5070800@columbia.edu> <20040909191056.GG1989@binky.central.sun.com> <4140AE15.6090804@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4140AE15.6090804@columbia.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: kitten@ietf.org, Mike Eisler Subject: Re: Proposed Charter (Draft #2) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 913 Lines: 28 On Thu, Sep 09, 2004 at 03:25:09PM -0400, Jeffrey Altman wrote: > Nicolas Williams wrote: > > >Are we taking the CCM document from the NFSv4 WG? Also, I'm not the > >editor of that one -- Mike Eisler is (I'm not sure if he's on this list > >either). > > I believe the decision should be made by the IESG. Sure. > >Also, I take it the C# bindings are now part of KITTEN's charter? (I > >don't mind, mind you.) If so, Sun has some corrections to make to the > >Java bindings RFC (the error codes used by Sun's implementation don't > >agree with the ones in the RFC; it's easier to change the RFC than to > >fix the implementations and recompile the apps). > > I do not object to updating the Java Bindings as part of the Charter. > > Other comments? Still reviewing. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Sep 9 17:17:02 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Thu, 09 Sep 2004 17:17:01 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 5F51313207 for ; Thu, 9 Sep 2004 17:17:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5W63-0006m0-GJ; Thu, 09 Sep 2004 17:04:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5VTp-0001LA-Aw for kitten@megatron.ietf.org; Thu, 09 Sep 2004 16:25:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23283 for ; Thu, 9 Sep 2004 16:25:15 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5VXj-0002mh-Ga for kitten@ietf.org; Thu, 09 Sep 2004 16:29:20 -0400 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 i89KPE35013928 for ; Thu, 9 Sep 2004 13:25:14 -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 i89KPDjY016008 for ; Thu, 9 Sep 2004 14:25:14 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i89KMDjh026815; Thu, 9 Sep 2004 15:22:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i89KMD7i026814; Thu, 9 Sep 2004 15:22:13 -0500 (CDT) Date: Thu, 9 Sep 2004 15:22:13 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20040909202213.GJ1989@binky.central.sun.com> References: <4140A339.5070800@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4140A339.5070800@columbia.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: kitten@ietf.org Subject: Re: Proposed Charter (Draft #2) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 1129 Lines: 31 On Thu, Sep 09, 2004 at 02:38:49PM -0400, Jeffrey Altman wrote: > o Extend GSSAPI to support mechanisms that do not have a single > canonical name for each authentication identity. I'm not sure I like the way that this is phrased. We're trying to make it possible to do better than name-based authorization in portable GSS-API applications, which also happens to be something we'd want to do if we were to have mechanisms that lack a unique canonical name for each principal. I don't want a narrowly crafted item description here to constrain us unnecessarily. I propose: o Extend the GSS-API to support authorization by portable GSS applications while also supporting mechanisms that do not have a single canonical name for each authentication identity. Also, we should add an item for a domain-based name type. We've discussed this before elsewhere (in the SASL WG); I believe Sam is in favor and I'm pretty sure we can reach consensus on this item easily. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Sep 10 15:30:43 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 10 Sep 2004 15:30:37 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id B9F02131AC for ; Fri, 10 Sep 2004 15:30:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5r1m-0004Ab-GV; Fri, 10 Sep 2004 15:25:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5ql1-00022I-CD for kitten@megatron.ietf.org; Fri, 10 Sep 2004 15:08:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22977 for ; Fri, 10 Sep 2004 15:08:25 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.59.142] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5qp7-0005P0-QD for kitten@ietf.org; Fri, 10 Sep 2004 15:12:43 -0400 Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i8AJ8Jur000494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Sep 2004 15:08:23 -0400 (EDT) Message-ID: <4141FC0B.8000707@columbia.edu> Date: Fri, 10 Sep 2004 15:10:03 -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.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org References: <4140A339.5070800@columbia.edu> <20040909202213.GJ1989@binky.central.sun.com> In-Reply-To: <20040909202213.GJ1989@binky.central.sun.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Proposed Charter (Draft #2) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 723 Lines: 25 Nicolas Williams wrote: > > o Extend the GSS-API to support authorization by portable GSS > applications while also supporting mechanisms that do not have a > single canonical name for each authentication identity. This language is acceptable to me. Anyone else in favor of the change? > Also, we should add an item for a domain-based name type. We've > discussed this before elsewhere (in the SASL WG); I believe Sam is in > favor and I'm pretty sure we can reach consensus on this item easily. Can you summarize the discussion for this group? Thanks. Jeffrey Altman _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Sep 10 16:11:17 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 10 Sep 2004 16:11:16 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id B16D5131AC for ; Fri, 10 Sep 2004 16:11:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5rhR-0002UJ-IY; Fri, 10 Sep 2004 16:08:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5rRa-0002Ep-16 for kitten@megatron.ietf.org; Fri, 10 Sep 2004 15:52:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27467 for ; Fri, 10 Sep 2004 15:52:23 -0400 (EDT) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C5rVh-0006WR-8s for kitten@ietf.org; Fri, 10 Sep 2004 15:56:42 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa03899; 10 Sep 2004 15:52 EDT Date: Fri, 10 Sep 2004 15:52:05 -0400 From: Jeffrey Hutzelman To: Jeffrey Altman , kitten@ietf.org Message-ID: <128950000.1094845925@minbar.fac.cs.cmu.edu> In-Reply-To: <4141FC0B.8000707@columbia.edu> References: <4140A339.5070800@columbia.edu> <20040909202213.GJ1989@binky.central.sun.com> <4141FC0B.8000707@columbia.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Proposed Charter (Draft #2) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 550 Lines: 20 On Friday, September 10, 2004 15:10:03 -0400 Jeffrey Altman wrote: > Nicolas Williams wrote: >> >> o Extend the GSS-API to support authorization by portable GSS >> applications while also supporting mechanisms that do not have a >> single canonical name for each authentication identity. > > This language is acceptable to me. Anyone else in favor of the change? Works for me _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Sep 10 17:06:12 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 10 Sep 2004 17:06:11 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 74792131AC for ; Fri, 10 Sep 2004 17:06:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5riy-0003rm-8d; Fri, 10 Sep 2004 16:10:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5rcw-0008CE-Ew for kitten@megatron.ietf.org; Fri, 10 Sep 2004 16:04:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28522 for ; Fri, 10 Sep 2004 16:04:07 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5rh3-0006wb-2B for kitten@ietf.org; Fri, 10 Sep 2004 16:08:26 -0400 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 i8AK4735001411 for ; Fri, 10 Sep 2004 13:04:07 -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 i8AK46jY000529 for ; Fri, 10 Sep 2004 14:04:06 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i8AK14L1027301; Fri, 10 Sep 2004 15:01:04 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i8AK13In027300; Fri, 10 Sep 2004 15:01:03 -0500 (CDT) Date: Fri, 10 Sep 2004 15:01:03 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20040910200103.GG1989@binky.central.sun.com> References: <4140A339.5070800@columbia.edu> <20040909202213.GJ1989@binky.central.sun.com> <4141FC0B.8000707@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4141FC0B.8000707@columbia.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: kitten@ietf.org Subject: Re: Proposed Charter (Draft #2) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 1880 Lines: 53 On Fri, Sep 10, 2004 at 03:10:03PM -0400, Jeffrey Altman wrote: > Nicolas Williams wrote: > > > > o Extend the GSS-API to support authorization by portable GSS > > applications while also supporting mechanisms that do not have a > > single canonical name for each authentication identity. > > This language is acceptable to me. Anyone else in favor of the change? > > >Also, we should add an item for a domain-based name type. We've > >discussed this before elsewhere (in the SASL WG); I believe Sam is in > >favor and I'm pretty sure we can reach consensus on this item easily. > > Can you summarize the discussion for this group? When using LDAP w/ SASL w/ GSS* one is supposed to use ldap@ as the name of the server's principal (and hostbased service name type). This is not sufficient to authorize the server as a valid server for the directory that one is interested in. Consider a site that has three LDAP directories. Each directory will have one or more servers, all with ldap@ hostbased princ names. So how can a client authorize any one server to be a valid server for the directory that the client is interested in? How can one avoid redirection attacks? Deploying DNSSEC is one answer. Another is to put the name of the directory (a "domain name" if you wish) into the servers' principal names. We propose a new name type for this. We call this domain-based service principal names. Instances of domain-based service principal names containt three parts: a service name, a host name and a "domain" name. IIRC we had consensus in the SASL WG to proceed with domain-based names as SASL WG items (Sam?), but now that KITTEN WG has arrived I think KITTEN would be more appropriate. Cheers, Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Sep 10 17:21:57 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 10 Sep 2004 17:21:56 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id C5404131AC for ; Fri, 10 Sep 2004 17:21:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5scH-0006g9-7F; Fri, 10 Sep 2004 17:07:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5rj4-0003vL-58 for kitten@megatron.ietf.org; Fri, 10 Sep 2004 16:10:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29051 for ; Fri, 10 Sep 2004 16:10:27 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.59.238] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5rnA-00076t-UT for kitten@ietf.org; Fri, 10 Sep 2004 16:14:46 -0400 Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i8AKAJam018128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Sep 2004 16:10:24 -0400 (EDT) Message-ID: <41420A93.9080207@columbia.edu> Date: Fri, 10 Sep 2004 16:12:03 -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.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org References: <4140A339.5070800@columbia.edu> <20040909202213.GJ1989@binky.central.sun.com> <4141FC0B.8000707@columbia.edu> <20040910200103.GG1989@binky.central.sun.com> In-Reply-To: <20040910200103.GG1989@binky.central.sun.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: Subject: GSS Domain Service Names was Re: Proposed Charter (Draft #2) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 1692 Lines: 55 Thanks for the summary. A few questions to help me justify the additional work item: * Assuming we define the new GSS Service Name type within Kitten, what work must be done by SASL to allow them to be used? * What must be done by application protocols such as LDAP to allow them to be used? * What other application protocols are likely to use it? Thanks. Nicolas Williams wrote: > When using LDAP w/ SASL w/ GSS* one is supposed to use ldap@ as > the name of the server's principal (and hostbased service name type). > > This is not sufficient to authorize the server as a valid server for the > directory that one is interested in. > > Consider a site that has three LDAP directories. Each directory will > have one or more servers, all with ldap@ hostbased princ names. > > So how can a client authorize any one server to be a valid server for > the directory that the client is interested in? How can one avoid > redirection attacks? > > Deploying DNSSEC is one answer. > > Another is to put the name of the directory (a "domain name" if you > wish) into the servers' principal names. > > We propose a new name type for this. We call this domain-based service > principal names. > > Instances of domain-based service principal names containt three parts: > a service name, a host name and a "domain" name. > > IIRC we had consensus in the SASL WG to proceed with domain-based names > as SASL WG items (Sam?), but now that KITTEN WG has arrived I think > KITTEN would be more appropriate. > > Cheers, > > Nico _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Sep 10 17:44:15 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 10 Sep 2004 17:44:14 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 7232E131AC for ; Fri, 10 Sep 2004 17:44:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5t2N-0002Ej-Jw; Fri, 10 Sep 2004 17:34:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5sxQ-0000gO-1M for kitten@megatron.ietf.org; Fri, 10 Sep 2004 17:29:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10942 for ; Fri, 10 Sep 2004 17:29:21 -0400 (EDT) Received: from stratton-six-eighty-six.mit.edu ([18.187.7.175] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5t1Z-0002kd-5c for kitten@ietf.org; Fri, 10 Sep 2004 17:33:41 -0400 Received: by cz.mit.edu (Postfix, from userid 8042) id 972B8E004D; Fri, 10 Sep 2004 17:30:24 -0400 (EDT) To: Jeffrey Altman References: <4140A339.5070800@columbia.edu> <20040909202213.GJ1989@binky.central.sun.com> <4141FC0B.8000707@columbia.edu> <20040910200103.GG1989@binky.central.sun.com> <41420A93.9080207@columbia.edu> From: Sam Hartman Date: Fri, 10 Sep 2004 17:30:24 -0400 In-Reply-To: <41420A93.9080207@columbia.edu> (Jeffrey Altman's message of "Fri, 10 Sep 2004 16:12:03 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: kitten@ietf.org Subject: Re: GSS Domain Service Names was Re: Proposed Charter (Draft #2) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 810 Lines: 23 >>>>> "Jeffrey" == Jeffrey Altman writes: Jeffrey> Thanks for the summary. A few questions to help me Jeffrey> justify the additional work item: Jeffrey> * Assuming we define the new GSS Service Name type within Jeffrey> Kitten, what work must be done by SASL to allow them to Jeffrey> be used? We'd need to define rules for using it in our gssapi mechanism draft. I believe that's doable and I believe there is close to a consensus to do the work within the SASL group. I actually believe there is close to a consensus to do the entire thing including definition of the GSS name type within SASL if you decline it. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Sep 10 17:48:52 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 10 Sep 2004 17:48:51 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 6A789131AC for ; Fri, 10 Sep 2004 17:48:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5tDd-00054o-QC; Fri, 10 Sep 2004 17:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5t6A-00032z-Dk for kitten@megatron.ietf.org; Fri, 10 Sep 2004 17:38:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11487 for ; Fri, 10 Sep 2004 17:38:23 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5tAJ-0002uH-DV for kitten@ietf.org; Fri, 10 Sep 2004 17:42:43 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i8ALcO4d027860 for ; Fri, 10 Sep 2004 14:38:24 -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 i8ALcOjY015544 for ; Fri, 10 Sep 2004 15:38:24 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i8ALZN0x027361; Fri, 10 Sep 2004 16:35:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i8ALZN5r027360; Fri, 10 Sep 2004 16:35:23 -0500 (CDT) Date: Fri, 10 Sep 2004 16:35:23 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20040910213522.GK1989@binky.central.sun.com> References: <4140A339.5070800@columbia.edu> <20040909202213.GJ1989@binky.central.sun.com> <4141FC0B.8000707@columbia.edu> <20040910200103.GG1989@binky.central.sun.com> <41420A93.9080207@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41420A93.9080207@columbia.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: kitten@ietf.org Subject: Re: GSS Domain Service Names was Re: Proposed Charter (Draft #2) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 1182 Lines: 37 On Fri, Sep 10, 2004 at 04:12:03PM -0400, Jeffrey Altman wrote: > Thanks for the summary. > > A few questions to help me justify the additional work item: > > * Assuming we define the new GSS Service Name type within Kitten, what > work must be done by SASL to allow them to be used? Not much. Fortunately for SASL the Kerberos V mechanism makes it possible to detect support for a give peer name by trying GSS_Init_sec_context() without actually having to exchange any context tokens :) Clearly this is not likely to be true for other mechanisms. So users of the GSS-API have to know a priori what names (and name types) to use. See below. > * What must be done by application protocols such as LDAP to allow them > to be used? This may be more complicated. But at least we stop the rot. I figure that typically which type of name to use for acceptors in such apps will have to be a configurable option. > * What other application protocols are likely to use it? Things like kadmin, SMTP/SUBMIT, etc... come to mind. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Sep 10 17:55:10 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 10 Sep 2004 17:55:09 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id BF121131AC for ; Fri, 10 Sep 2004 17:55:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5tKo-0007MQ-5a; Fri, 10 Sep 2004 17:53:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5tJr-0006vl-Ex for kitten@megatron.ietf.org; Fri, 10 Sep 2004 17:52:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12205 for ; Fri, 10 Sep 2004 17:52:32 -0400 (EDT) Received: from stratton-six-eighty-six.mit.edu ([18.187.7.175] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5tNz-00037v-PD for kitten@ietf.org; Fri, 10 Sep 2004 17:56:52 -0400 Received: by cz.mit.edu (Postfix, from userid 8042) id D788FE004D; Fri, 10 Sep 2004 17:53:34 -0400 (EDT) To: Nicolas Williams References: <4140A339.5070800@columbia.edu> <20040909202213.GJ1989@binky.central.sun.com> <4141FC0B.8000707@columbia.edu> <20040910200103.GG1989@binky.central.sun.com> <41420A93.9080207@columbia.edu> <20040910213522.GK1989@binky.central.sun.com> From: Sam Hartman Date: Fri, 10 Sep 2004 17:53:34 -0400 In-Reply-To: <20040910213522.GK1989@binky.central.sun.com> (Nicolas Williams's message of "Fri, 10 Sep 2004 16:35:23 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: kitten@ietf.org Subject: Re: GSS Domain Service Names was Re: Proposed Charter (Draft #2) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 772 Lines: 25 >>>>> "Nicolas" == Nicolas Williams writes: >> * What must be done by application protocols such as LDAP to >> allow them to be used? Nicolas> This may be more complicated. But at least we stop the Nicolas> rot. Nicolas> I figure that typically which type of name to use for Nicolas> acceptors in such apps will have to be a configurable Nicolas> option. >> * What other application protocols are likely to use it? Nicolas> Things like kadmin, SMTP/SUBMIT, etc... come to mind. Basically anything that indirects name lookups through SRV should probably use this. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Sep 10 18:01:05 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 10 Sep 2004 18:01:05 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id D1A36131AC for ; Fri, 10 Sep 2004 18:01:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5tPq-0008SB-FZ; Fri, 10 Sep 2004 17:58:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5tL9-0007Q9-3G for kitten@megatron.ietf.org; Fri, 10 Sep 2004 17:53:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12296 for ; Fri, 10 Sep 2004 17:53:51 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5tPH-00039Z-21 for kitten@ietf.org; Fri, 10 Sep 2004 17:58:12 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i8ALrq35024488 for ; Fri, 10 Sep 2004 14:53:52 -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 i8ALrmJh016063 for ; Fri, 10 Sep 2004 15:53:51 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i8ALoli0027384; Fri, 10 Sep 2004 16:50:47 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i8ALol45027383; Fri, 10 Sep 2004 16:50:47 -0500 (CDT) Date: Fri, 10 Sep 2004 16:50:47 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20040910215047.GN1989@binky.central.sun.com> References: <4140A339.5070800@columbia.edu> <20040909202213.GJ1989@binky.central.sun.com> <4141FC0B.8000707@columbia.edu> <20040910200103.GG1989@binky.central.sun.com> <41420A93.9080207@columbia.edu> <20040910213522.GK1989@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: kitten@ietf.org Subject: Re: GSS Domain Service Names was Re: Proposed Charter (Draft #2) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: RO Content-Length: 316 Lines: 14 On Fri, Sep 10, 2004 at 05:53:34PM -0400, Sam Hartman wrote: > Basically anything that indirects name lookups through SRV should > probably use this. Excellent point. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Sep 14 13:13:41 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 14 Sep 2004 13:13:39 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 6D210131AC for ; Tue, 14 Sep 2004 13:13:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7Gfx-0005Q3-O0; Tue, 14 Sep 2004 13:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7GWV-0002z2-Ab for kitten@megatron.ietf.org; Tue, 14 Sep 2004 12:51:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24537 for ; Tue, 14 Sep 2004 12:51:16 -0400 (EDT) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7GbQ-00029A-O6 for kitten@ietf.org; Tue, 14 Sep 2004 12:56:26 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id SAA29788; Tue, 14 Sep 2004 18:50:39 +0200 (MESZ) From: Martin Rex Message-Id: <200409141650.SAA00416@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Tue, 14 Sep 2004 18:50:39 +0200 (MET DST) In-Reply-To: <20040910200103.GG1989@binky.central.sun.com> from "Nicolas Williams" at Sep 10, 4 03:01:03 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: Proposed Charter (Draft #2) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 1005 Lines: 28 Nicolas Williams wrote: > > When using LDAP w/ SASL w/ GSS* one is supposed to use ldap@ as > the name of the server's principal (and hostbased service name type). > > This is not sufficient to authorize the server as a valid server for the > directory that one is interested in. > > Consider a site that has three LDAP directories. Each directory will > have one or more servers, all with ldap@ hostbased princ names. > > So how can a client authorize any one server to be a valid server for > the directory that the client is interested in? How can one avoid > redirection attacks? The correct approach would be to use a directory and secure directory lookup to translate abstract service names into specific instances of a service (network address plus Kerberos principal name). As much as I dislike DCE, but they got this part right! -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Sep 14 13:30:57 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 14 Sep 2004 13:30:55 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 5A7FB131AC for ; Tue, 14 Sep 2004 13:30:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7GzO-0001HG-DB; Tue, 14 Sep 2004 13:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7GsD-0008OU-8U for kitten@megatron.ietf.org; Tue, 14 Sep 2004 13:13:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26433 for ; Tue, 14 Sep 2004 13:13:42 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7Gx8-0002dk-JY for kitten@ietf.org; Tue, 14 Sep 2004 13:18:52 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i8EHDf4d017946 for ; Tue, 14 Sep 2004 10:13:41 -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 i8EHDfjY014948 for ; Tue, 14 Sep 2004 11:13:41 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i8EHAZ5l001728; Tue, 14 Sep 2004 12:10:35 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i8EHAYL8001727; Tue, 14 Sep 2004 12:10:34 -0500 (CDT) Date: Tue, 14 Sep 2004 12:10:34 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20040914171034.GQ1989@binky.central.sun.com> References: <20040910200103.GG1989@binky.central.sun.com> <200409141650.SAA00416@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409141650.SAA00416@uw1048.wdf.sap.corp> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: kitten@ietf.org Subject: Re: Proposed Charter (Draft #2) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 1861 Lines: 47 On Tue, Sep 14, 2004 at 06:50:39PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > > > When using LDAP w/ SASL w/ GSS* one is supposed to use ldap@ as > > the name of the server's principal (and hostbased service name type). > > > > This is not sufficient to authorize the server as a valid server for the > > directory that one is interested in. > > > > Consider a site that has three LDAP directories. Each directory will > > have one or more servers, all with ldap@ hostbased princ names. > > > > So how can a client authorize any one server to be a valid server for > > the directory that the client is interested in? How can one avoid > > redirection attacks? > > The correct approach would be to use a directory and secure directory > lookup to translate abstract service names into specific > instances of a service (network address plus Kerberos principal name). That is a perfectly valid approach, though it has a bootstrapping issue. One approach is [much] simpler than the other though, requires less effort to specify, is nameservice/directory independent and so, taking all of this into account, much more likely to be interoperable. By the KISS principle, then, I think that the domain-based naming approach is worth following. Authorizing service principals to serve a given resource can be hard when that very resource is what you'd use to authorize the service principals in question. Yes, DNSSEC prevents DNS spoof attacks, which saves all apps that use SRV records to locate their servers from having to authorize the servers' service principals. But if we can avoid having to rely on secure nameservices, and we can do so with little effort, I think we should. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Sep 10 17:22:04 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 10 Sep 2004 17:22:03 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id E6E5D131AC for ; Fri, 10 Sep 2004 17:22:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5scl-0006o8-LT; Fri, 10 Sep 2004 17:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5rkj-0004xV-Rl for kitten@megatron.ietf.org; Fri, 10 Sep 2004 16:12:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29222 for ; Fri, 10 Sep 2004 16:12:11 -0400 (EDT) Received: from stratton-six-eighty-six.mit.edu ([18.187.7.175] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5ror-0007Aa-9W for kitten@ietf.org; Fri, 10 Sep 2004 16:16:30 -0400 Received: by cz.mit.edu (Postfix, from userid 8042) id 5D48016014E; Fri, 10 Sep 2004 16:13:13 -0400 (EDT) To: Jeffrey Altman References: <4140A339.5070800@columbia.edu> <20040909202213.GJ1989@binky.central.sun.com> <4141FC0B.8000707@columbia.edu> From: Sam Hartman Date: Fri, 10 Sep 2004 16:13:13 -0400 In-Reply-To: <4141FC0B.8000707@columbia.edu> (Jeffrey Altman's message of "Fri, 10 Sep 2004 15:10:03 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: kitten@ietf.org Subject: Re: Proposed Charter (Draft #2) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 556 Lines: 17 >>>>> "Jeffrey" == Jeffrey Altman writes: Jeffrey> Nicolas Williams wrote: >> o Extend the GSS-API to support authorization by portable GSS >> applications while also supporting mechanisms that do not have >> a single canonical name for each authentication identity. Jeffrey> This language is acceptable to me. Anyone else in favor Jeffrey> of the change? I like it. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Sep 10 18:27:49 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 10 Sep 2004 18:27:46 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 6CFF2131AC for ; Fri, 10 Sep 2004 18:27:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5tgB-0001ga-V3; Fri, 10 Sep 2004 18:15:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5tdx-0000Kc-7f for kitten@megatron.ietf.org; Fri, 10 Sep 2004 18:13:21 -0400 Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14289 for ; Fri, 10 Sep 2004 18:13:17 -0400 (EDT) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i8AMDHFG024895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Sep 2004 18:13:19 -0400 (EDT) Message-ID: <41422765.7010807@columbia.edu> Date: Fri, 10 Sep 2004 18:15:01 -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.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------080807070607010208070809" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Cc: Subject: Proposed Charter (Draft #3) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 6065 Lines: 167 This is a multi-part message in MIME format. --------------080807070607010208070809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit * incorporates proposed text change from Nico * incorporates new work item: domain service principal name any other comments? --------------080807070607010208070809 Content-Type: text/plain; name="charter.txt" Content-Disposition: inline; filename="charter.txt" Content-Transfer-Encoding: 7bit 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 core GSSAPI specification and language bindings 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: o Use of channel bindings o Thread safety restrictions o C language utilization clarifications and recommendations (e.g., type utilization, name spaces) o Guidelines for GSS-API mechanism designers o Guidelines for GSS-API application protocol designers This working group is chartered to specify a non-backward compatible GSSAPI v3 including support for the following extensions: o Clarify the portable use of channel bindings and better specify channel bindings in a language-independent manner. o Specify thread safety extensions to allow multi-threaded applications to use GSSAPI o Definitions of channel bindings for TLS, IPSec, SSH and other cryptographic channels based on work started in the NFSV4 working group. o Define a GSSAPI extension to allow applications to store credentials. Discussions to be started based upon: o draft-williams-gss-store-deleg-creds-xx.txt o Extensions to solve problems posed by the Global Grid Forum's GSSAPI extensions document. o Extensions to deal with mechanism-specific extensibility in a multi-mechanism environment. o Extend the GSS-API to support authorization by portable GSS applications while also supporting mechanisms that do not have a single canonical name for each authentication identity. o Specify a Domain-based GSS service principal name consisting of: service name, host name, and domain name for use by application services hosted across multiple servers. o Extensions to support stackable GSSAPI mechanisms. o Define a Psuedo-Random Function for GSSAPI This working group is chartered to perform the following GSSAPI mechanism specification work: o Specify a GSSAPI v2/v3 Channel Conjunction Mechanism o 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. o Update the GSSAPI Java Language Bindings to match actual implementation This working group is chartered to perform the following new GSSAPI Language Binding specification work: o Specify a language binding for C# 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 Either: o Clarifications to GSSAPIv2 (six months to IESG) Informational [editor: TBD] Or: o Generic Security Service Application Program Interface Version 2, Update 2 (six months to IESG) Proposed Standard [editor: TBD] o Generic Security Service API Version 2, Update 1 : C-bindings (six months to IESG) Proposed Standard [editor: TBD] End: o The Channel Conjunction Mechanism (CCM) for the GSSAPI (six months to IESG) Proposed Standard [editors: Mike Eisler/Nicolas Williams] draft-ietf-nfsv4-ccm-03.txt (Currently in NFSv4 Working Group - should it be moved?) o On the Use of Channel Bindings to Secure Channels (six months to IESG) Proposed Standard [editor: Nicolas Williams] draft-ietf-nfsv4-channel-bindings-02.txt (Currently in NFSv4 Working Group - should it be moved?) o GSSAPIv3 (18 months to IESG) Proposed Standard [editor: to be determined] o 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 o 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 o GSSAPI Mechanisms without a Unique Canonical Name (12 months to IESG) to be folded into GSSAPIv3 [editor: Sam Hartman] draft-hartman-gss-naming-00.txt o SPNEGO (RFC 2478) Revisions (18 months to IESG) Proposed Standard [editor: TBD] o Pseudo-Random Function for GSSAPI to be folded into GSSAPIv3 [editor: Nicolas Williams] o C# Bindings for GSSAPI Proposed Standard [editor: Larry Zhu] End of Milestones MAILING LIST: The mailing list for discussions is kitten@lists.ietf.org Use the following web page to join: https://www1.ietf.org/mailman/listinfo/kitten --------------080807070607010208070809 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --------------080807070607010208070809-- From kitten-bounces@lists.ietf.org Mon Sep 13 09:35:16 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 13 Sep 2004 09:35:14 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 38DD613230 for ; Mon, 13 Sep 2004 09:35:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6quS-00057G-TP; Mon, 13 Sep 2004 09:30:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6qs2-0004ag-1d for kitten@megatron.ietf.org; Mon, 13 Sep 2004 09:27:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28694 for ; Mon, 13 Sep 2004 09:27:48 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6qwi-0008Gx-Ju for kitten@ietf.org; Mon, 13 Sep 2004 09:32:42 -0400 Received: from jurassic.eng.sun.com ([129.146.85.105]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i8DDRh35001379; Mon, 13 Sep 2004 06:27:43 -0700 (PDT) Received: from [192.9.61.32] (punchin-wyllys.SFBay.Sun.COM [192.9.61.32]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i8DDRgSK456799; Mon, 13 Sep 2004 06:27:42 -0700 (PDT) Message-ID: <41459F79.8010107@sun.com> Date: Mon, 13 Sep 2004 09:24:09 -0400 From: Wyllys Ingersoll User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040630) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Altman References: <41422765.7010807@columbia.edu> In-Reply-To: <41422765.7010807@columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: Proposed Charter (Draft #3) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 6044 Lines: 166 I'm volunteering to edit the new SPNEGO document. -Wyllys Jeffrey Altman wrote: > * incorporates proposed text change from Nico > > * incorporates new work item: domain service principal name > > any other comments? > > >------------------------------------------------------------------------ > >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 core GSSAPI specification and language >bindings 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: > o Use of channel bindings > o Thread safety restrictions > o C language utilization clarifications and recommendations > (e.g., type utilization, name spaces) > o Guidelines for GSS-API mechanism designers > o Guidelines for GSS-API application protocol designers > >This working group is chartered to specify a non-backward compatible >GSSAPI v3 including support for the following extensions: > o Clarify the portable use of channel bindings and better specify > channel bindings in a language-independent manner. > o Specify thread safety extensions to allow multi-threaded applications > to use GSSAPI > o Definitions of channel bindings for TLS, IPSec, SSH and other > cryptographic channels based on work started in the NFSV4 working > group. > o Define a GSSAPI extension to allow applications to store credentials. > Discussions to be started based upon: > o draft-williams-gss-store-deleg-creds-xx.txt > o Extensions to solve problems posed by the Global Grid Forum's GSSAPI > extensions document. > o Extensions to deal with mechanism-specific extensibility in a > multi-mechanism environment. > o Extend the GSS-API to support authorization by portable GSS > applications while also supporting mechanisms that do not have a > single canonical name for each authentication identity. > o Specify a Domain-based GSS service principal name consisting of: > service name, host name, and domain name for use by application > services hosted across multiple servers. > o Extensions to support stackable GSSAPI mechanisms. > o Define a Psuedo-Random Function for GSSAPI > >This working group is chartered to perform the following GSSAPI mechanism >specification work: > > o Specify a GSSAPI v2/v3 Channel Conjunction Mechanism > o 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. > o Update the GSSAPI Java Language Bindings to match actual implementation > >This working group is chartered to perform the following new GSSAPI Language >Binding specification work: > > o Specify a language binding for C# > >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 >Either: > o Clarifications to GSSAPIv2 (six months to IESG) > Informational > [editor: TBD] >Or: > o Generic Security Service Application Program Interface Version 2, Update 2 > (six months to IESG) > Proposed Standard > [editor: TBD] > o Generic Security Service API Version 2, Update 1 : C-bindings (six months to IESG) > Proposed Standard > [editor: TBD] >End: > o The Channel Conjunction Mechanism (CCM) for the GSSAPI (six months > to IESG) > Proposed Standard > [editors: Mike Eisler/Nicolas Williams] > draft-ietf-nfsv4-ccm-03.txt > (Currently in NFSv4 Working Group - should it be moved?) > o On the Use of Channel Bindings to Secure Channels (six months to IESG) > Proposed Standard > [editor: Nicolas Williams] > draft-ietf-nfsv4-channel-bindings-02.txt > (Currently in NFSv4 Working Group - should it be moved?) > o GSSAPIv3 (18 months to IESG) > Proposed Standard > [editor: to be determined] > o 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 > o 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 > o GSSAPI Mechanisms without a Unique Canonical Name (12 months to IESG) > to be folded into GSSAPIv3 > [editor: Sam Hartman] > draft-hartman-gss-naming-00.txt > o SPNEGO (RFC 2478) Revisions (18 months to IESG) > Proposed Standard > [editor: TBD] > o Pseudo-Random Function for GSSAPI > to be folded into GSSAPIv3 > [editor: Nicolas Williams] > o C# Bindings for GSSAPI > Proposed Standard > [editor: Larry Zhu] > >End of Milestones > > >MAILING LIST: >The mailing list for discussions is > > kitten@lists.ietf.org > >Use the following web page to join: > > https://www1.ietf.org/mailman/listinfo/kitten > > > >------------------------------------------------------------------------ > >_______________________________________________ >Kitten mailing list >Kitten@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/kitten > > _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Sep 13 12:24:46 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 13 Sep 2004 12:24:45 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id AFE8813230 for ; Mon, 13 Sep 2004 12:24:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6tOK-0008LO-NI; Mon, 13 Sep 2004 12:09:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6tCn-0005Tm-94 for kitten@megatron.ietf.org; Mon, 13 Sep 2004 11:57:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11179 for ; Mon, 13 Sep 2004 11:57:22 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.206.20] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6tHV-00032O-CW for kitten@ietf.org; Mon, 13 Sep 2004 12:02:18 -0400 Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i8DFvJ5K005688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 13 Sep 2004 11:57:22 -0400 (EDT) Message-ID: <4145C3BA.1070802@columbia.edu> Date: Mon, 13 Sep 2004 11:58:50 -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.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org References: <41422765.7010807@columbia.edu> <41459F79.8010107@sun.com> In-Reply-To: <41459F79.8010107@sun.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Proposed Charter (Draft #3) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 599 Lines: 15 I have heard no objections to the contents of the proposed charter and I do not believe that there is consensus at this time to add additional working group items. In order to provide the IESG enough time to approve the group before IETF-61, I am going to submit the existing proposed charter for consideration. Additional items can be submitted as individual Internet-Drafts and can be considered by the Working Group if consensus is reached. Jeffrey Altman _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sat Sep 11 03:16:25 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Sat, 11 Sep 2004 03:16:24 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 05221131AC for ; Sat, 11 Sep 2004 03:16:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C625b-0005hO-7l; Sat, 11 Sep 2004 03:14:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C622E-00053I-SN for kitten@megatron.ietf.org; Sat, 11 Sep 2004 03:10:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28690 for ; Sat, 11 Sep 2004 03:10:57 -0400 (EDT) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C626S-0003Cr-3w for kitten@ietf.org; Sat, 11 Sep 2004 03:15:21 -0400 Received: (from lukeh@localhost) by au.padl.com (8.9.3/8.9.3) id RAA16219; Sat, 11 Sep 2004 17:10:22 +1000 (EST) From: Luke Howard Message-Id: <200409110710.RAA16219@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: kitten@ietf.org Date: Sat, 11 Sep 2004 17:10:21 +1000 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: tridge@samba.org Subject: GSS-API extensions for AEAD X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@PADL.COM List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 2304 Lines: 78 We need to support AEAD in GSS-API in order to interoperate with some vendor implementations of DCE RPC. I've extended our GSS-API implementation, which is based on Heimdal, to add the GSS_Unwrap_Ex() and GSS_Wrap_Ex() APIs. The C bindings are as follows: /* * GSS_Unwrap() with support for associated data. * * Notes: * * token_header_buffer contains the GSS-API token as * received from the peer * * associated_data_buffer contains the complete data * over which the checksum is to be verified; * * input_message_buffer contains the complete data to * be decrypted if confidentiality was requested; * * input_message_buffer value must point into the value * of associated_data_buffer (hence input_message_buffer * just specifies a span within associated_data_buffer). * * On returning GSS_S_COMPLETE, output_message_buffer * will contain input_message_buffer after unwrapping and; * * associated_data_buffer will have been authenticated * */ OM_uint32 gss_unwrap_ex(OM_uint32 *minor_status, const gss_ctx_id_t context_handle, const gss_buffer_t token_header_buffer, const gss_buffer_t associated_data_buffer, const gss_buffer_t input_message_buffer, gss_buffer_t output_message_buffer, int *conf_state, gss_qop_t *qop_state); /* * GSS_Wrap() with support for associated data. * * Notes: * * associated_data_buffer contains the complete data * over which the checksum is to be verified; * * input_message_buffer contains the data to be * encrypted if conf_req_flag == TRUE. * * On returning GSS_S_COMPLETE, output_token_buffer * will contain the GSS-API tokenheader, and; * * output_message_buffer will contain input_message_buffer * after wrapping (including any padding) */ OM_uint32 gss_wrap_ex(OM_uint32 *minor_status, const gss_ctx_id_t context_handle, int conf_req_flag, gss_qop_t qop_req, const gss_buffer_t associated_data_buffer, const gss_buffer_t input_message_buffer, int *conf_state, gss_buffer_t output_token_buffer, gss_buffer_t output_message_buffer); Any comments? Worth writing this up as an Internet Draft? -- Luke _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sat Sep 11 03:25:20 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Sat, 11 Sep 2004 03:25:19 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 694DB131AC for ; Sat, 11 Sep 2004 03:25:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C62AR-0007F7-NS; Sat, 11 Sep 2004 03:19:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C629p-00071J-EH for kitten@megatron.ietf.org; Sat, 11 Sep 2004 03:18:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28930 for ; Sat, 11 Sep 2004 03:18:47 -0400 (EDT) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C62E1-0003Hn-UO for kitten@ietf.org; Sat, 11 Sep 2004 03:23:11 -0400 Received: (from lukeh@localhost) by au.padl.com (8.9.3/8.9.3) id RAA16413; Sat, 11 Sep 2004 17:18:15 +1000 (EST) From: Luke Howard Message-Id: <200409110718.RAA16413@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: kitten@ietf.org Date: Sat, 11 Sep 2004 17:18:14 +1000 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tridge@samba.org Subject: Re: GSS-API extensions for AEAD X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@PADL.COM List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 616 Lines: 24 OK, so I made a few typos: > * token_header_buffer contains the GSS-API token as > * received from the peer token_header_buffer contains just the GSS-API token header; obviously this assumes an application message format that can identify the token header separately. This suited our application (DCE RPC) but may not suit all applications. > * associated_data_buffer contains the complete data > * over which the checksum is to be verified; s/verified/computed/ -- Luke _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sat Sep 11 04:43:07 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Sat, 11 Sep 2004 04:43:05 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 0374A131AC for ; Sat, 11 Sep 2004 04:43:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C63Te-0001Jt-N3; Sat, 11 Sep 2004 04:43:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C63QE-0000cn-SJ for kitten@megatron.ietf.org; Sat, 11 Sep 2004 04:39:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02886 for ; Sat, 11 Sep 2004 04:39:49 -0400 (EDT) Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C63US-0004ST-Tn for kitten@ietf.org; Sat, 11 Sep 2004 04:44:14 -0400 Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i8B8dl3s009089; Sat, 11 Sep 2004 04:39:48 -0400 (EDT) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i8B8dhYU021230 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 11 Sep 2004 04:39:44 -0400 (EDT) In-Reply-To: <200409110718.RAA16413@au.padl.com> References: <200409110718.RAA16413@au.padl.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1E3A12D3-03CE-11D9-ABEA-000A95909EE2@mit.edu> From: Ken Raeburn Date: Sat, 11 Sep 2004 04:39:38 -0400 To: lukeh@PADL.COM X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, tridge@samba.org Subject: Re: GSS-API extensions for AEAD X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 3426 Lines: 72 On Sep 11, 2004, at 03:18, Luke Howard wrote: >> * token_header_buffer contains the GSS-API token as >> * received from the peer > > token_header_buffer contains just the GSS-API token header; > obviously this assumes an application message format that > can identify the token header separately. This suited our > application (DCE RPC) but may not suit all applications. This would be an annoying new imposition, I think. Where a protocol currently sends one blob of data for GSS_Wrap, it has to effectively send two (which may be one blob plus an offset at which it gets split apart) for GSS_Wrap_Ex. That would also make it impossible to use a theoretical new Kerberos ASN.1 object KRB-PRIV-AND-SAFE (or a modified EncryptedData defined to incorporate associated data) that encapsulates AEAD at the Kerberos layer, if one were so inclined. And unless we make serious changes to GSS_Wrap, the mechanism is already going to have to implement the ability to figure out where the checksum or MAC or whatever is in a single data blob. Remember, too, that the associated data need not necessarily actually be sent on the wire. Forcing the application to reassemble the associated data and the encrypted data into one buffer seems wasteful. I'd prefer just using the one output buffer like GSS_Wrap does, and one additional input buffer to unwrap for the associated data. Additional stuff that needs to be considered if it's going to be written up: - Any relationship between this and the Wrap and MIC tokens, especially in degenerate AEAD cases where either associated data or encrypted data is empty. I.e., do we require that they be distinct (one not useful for fabricating another even if the application doesn't know what kind of message to expect), or can they be the same? - Do we allow a mechanism to not provide it? If it's required, GSSAPIv2 mechanisms won't be compliant with whatever this goes into (a v2 extension or v3) without updates, probably new OIDs, etc. If it's optional, do we need to know up front or is it a characteristic we find out after establishing the security context. (If we want updates, you may know I've already thought about AEAD for the Kerberos crypto spec, though I haven't written it all up so far.) - Or, is there some reasonable and general way we can specify automatic extension of v2 mechanisms (those that support confidentiality) to support this? Probably impossible unless we allow a Wrap_Ex token to look like a Wrap or MIC token that has somewhat different data in it. I wouldn't mind seeing it written up. But write up both the GSS-API description and the C binding, separately. Maybe in the same document, but the main part of the write-up should be independent of the C API. Not sure I agree with the need, though. For compatibility with some DCE RPC implementations (does this translate to anything more than "Microsoft SSPI"?), which evidently aren't actually using GSS-API? How about interoperability with other non-GSSAPI schemes too? :-) I'm willing to be convinced, but I don't want it to be that we just want to make existing protocol XYZ into a GSSAPIv3 protocol by defining GSSAPIv3 and A, B and C mechanisms such that they match what XYZ already does on the wire. Ken _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sat Sep 11 11:32:09 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Sat, 11 Sep 2004 11:32:08 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 9BA3F1382E for ; Sat, 11 Sep 2004 11:32:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C69s0-0005Xq-OG; Sat, 11 Sep 2004 11:32:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C69qZ-0005JC-4u for kitten@megatron.ietf.org; Sat, 11 Sep 2004 11:31:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23798 for ; Sat, 11 Sep 2004 11:31:24 -0400 (EDT) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C69uq-0002Lj-Pt for kitten@ietf.org; Sat, 11 Sep 2004 11:35:54 -0400 Received: (from lukeh@localhost) by au.padl.com (8.9.3/8.9.3) id BAA42979; Sun, 12 Sep 2004 01:30:46 +1000 (EST) From: Luke Howard Message-Id: <200409111530.BAA42979@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: raeburn@MIT.EDU References: <200409110718.RAA16413@au.padl.com> <1E3A12D3-03CE-11D9-ABEA-000A95909EE2@mit.edu> Date: Sun, 12 Sep 2004 01:30:45 +1000 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: kitten@ietf.org Subject: Re: GSS-API extensions for AEAD X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@PADL.COM List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 2270 Lines: 50 >I'd prefer just using the one output buffer like GSS_Wrap does, and one >additional input buffer to unwrap for the associated data. I should note that I added the separate token header argument to make things easier for the DCE library, which needs to place the GSS token header after the application data. However we can make this work just with GSS_Wrap() and, being unrelated to AEAD, I have no objection to removing the extra argument. >- Do we allow a mechanism to not provide it? If it's required, >GSSAPIv2 mechanisms won't be compliant with whatever this goes into (a >v2 extension or v3) without updates, probably new OIDs, etc. If it's >optional, do we need to know up front or is it a characteristic we find >out after establishing the security context. (If we want updates, you >may know I've already thought about AEAD for the Kerberos crypto spec, >though I haven't written it all up so far.) I think it is reasonable to allow AEAD to be optional and negotiated in some mechanism-specific way. That is how NTLM does it, and something similar could be done with the Kerberos mechanism. It also seems reasonable for a GSS_Wrap_Ex() token without additional associated data to be identical to a GSS_Wrap() token. Need to think about this some more though. If AEAD is optional then some way of conveying to the caller whether associated data was protected would be useful. >Not sure I agree with the need, though. For compatibility with some >DCE RPC implementations (does this translate to anything more than >"Microsoft SSPI"?), which evidently aren't actually using GSS-API? How >about interoperability with other non-GSSAPI schemes too? :-) I'm >willing to be convinced, but I don't want it to be that we just want to >make existing protocol XYZ into a GSSAPIv3 protocol by defining >GSSAPIv3 and A, B and C mechanisms such that they match what XYZ >already does on the wire. Understood. Ideally we can come up with something that is interoperable and elegant. At least if we can agree on a standard API then DCE can be treated as a special case by the mechanism implementation. -- Luke _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Sep 13 09:59:38 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 13 Sep 2004 09:59:37 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id EC9BC13230 for ; Mon, 13 Sep 2004 09:59:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6rCr-00086Y-Is; Mon, 13 Sep 2004 09:49:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6rBA-0007lf-PJ for kitten@megatron.ietf.org; Mon, 13 Sep 2004 09:47:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00308 for ; Mon, 13 Sep 2004 09:47:34 -0400 (EDT) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6rFr-0000Dl-Cr for kitten@ietf.org; Mon, 13 Sep 2004 09:52:28 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id PAA22868; Mon, 13 Sep 2004 15:41:15 +0200 (MESZ) From: Martin Rex Message-Id: <200409131341.PAA17084@uw1048.wdf.sap.corp> To: lukeh@PADL.COM Date: Mon, 13 Sep 2004 15:41:14 +0200 (MET DST) In-Reply-To: <200409110718.RAA16413@au.padl.com> from "Luke Howard" at Sep 11, 4 05:18:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, tridge@samba.org Subject: Re: GSS-API extensions for AEAD X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 451 Lines: 18 Luke, I'm a little confused about this proposal. Where exactly is the difference between your gss_wrap_ex(), gss_unwrap_ex() and the EXISTING gss_getmic() gss_verifymic()? As far as I remember, the GSS-API was originally designed by Engineers at Digital Equipment Coorporation (DEC) for use with DCE. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sat Sep 11 13:01:29 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Sat, 11 Sep 2004 13:01:29 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 3B73B1382E for ; Sat, 11 Sep 2004 13:01:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6BBX-00042P-Ga; Sat, 11 Sep 2004 12:57:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6BAe-0003me-KM for kitten@megatron.ietf.org; Sat, 11 Sep 2004 12:56:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27262 for ; Sat, 11 Sep 2004 12:56:13 -0400 (EDT) Received: from hotass-6.mit.edu ([18.101.1.48] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6BEx-0003VR-BL for kitten@ietf.org; Sat, 11 Sep 2004 13:00:44 -0400 Received: by cz.mit.edu (Postfix, from userid 8042) id C2AB1E004D; Sat, 11 Sep 2004 12:57:18 -0400 (EDT) To: lukeh@PADL.COM References: <200409110710.RAA16219@au.padl.com> From: Sam Hartman Date: Sat, 11 Sep 2004 12:57:18 -0400 In-Reply-To: <200409110710.RAA16219@au.padl.com> (Luke Howard's message of "Sat, 11 Sep 2004 17:10:21 +1000") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: kitten@ietf.org, tridge@samba.org Subject: Re: GSS-API extensions for AEAD X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 499 Lines: 19 So, you can't guarantee that a particular mechanism can support this. Remember all the trouble we had designing CFX. Remember also that CFX isn't even guaranteed to support this; it only happens to work for AES. I would feel very uncomfortable inshrining this in a standard. That said, I do completely understand the problem you're trying to solve. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sat Sep 11 17:30:16 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Sat, 11 Sep 2004 17:30:15 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id A68B51382E for ; Sat, 11 Sep 2004 17:30:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6FJQ-0003MM-RI; Sat, 11 Sep 2004 17:21:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6F9e-0000LU-8M for kitten@megatron.ietf.org; Sat, 11 Sep 2004 17:11:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10882 for ; Sat, 11 Sep 2004 17:11:28 -0400 (EDT) Received: from hotass-6.mit.edu ([18.101.1.48] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6FDz-0007ly-8J for kitten@ietf.org; Sat, 11 Sep 2004 17:16:00 -0400 Received: by cz.mit.edu (Postfix, from userid 8042) id A2699E004D; Sat, 11 Sep 2004 17:12:31 -0400 (EDT) To: lukeh@PADL.COM References: <200409110710.RAA16219@au.padl.com> From: Sam Hartman Date: Sat, 11 Sep 2004 17:12:31 -0400 In-Reply-To: (Sam Hartman's message of "Sat, 11 Sep 2004 12:57:18 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: kitten@ietf.org, tridge@samba.org Subject: Re: GSS-API extensions for AEAD X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 596 Lines: 17 >>>>> "Sam" == Sam Hartman writes: Sam> So, you can't guarantee that a particular mechanism can Sam> support this. Remember all the trouble we had designing CFX. Sam> Remember also that CFX isn't even guaranteed to support this; Sam> it only happens to work for AES. I'm still uncomfortable with this but wouldn't mind agreeing to consider the extension and specify if we believe it is a good idea after consideration. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sun Sep 12 03:34:13 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Sun, 12 Sep 2004 03:34:13 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 54C981382E for ; Sun, 12 Sep 2004 03:34:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6Orw-0003q7-2v; Sun, 12 Sep 2004 03:33:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6OmS-0002wZ-Cq for kitten@megatron.ietf.org; Sun, 12 Sep 2004 03:28:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28758 for ; Sun, 12 Sep 2004 03:28:10 -0400 (EDT) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6Oqs-0008QO-Jj for kitten@ietf.org; Sun, 12 Sep 2004 03:32:47 -0400 Received: (from lukeh@localhost) by au.padl.com (8.9.3/8.9.3) id RAA29873; Sun, 12 Sep 2004 17:27:29 +1000 (EST) From: Luke Howard Message-Id: <200409120727.RAA29873@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: hartmans@mit.edu References: <200409110710.RAA16219@au.padl.com> Date: Sun, 12 Sep 2004 17:27:27 +1000 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: kitten@ietf.org, tridge@samba.org Subject: Re: GSS-API extensions for AEAD X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@PADL.COM List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: RO Content-Length: 413 Lines: 17 >I would feel very uncomfortable inshrining this in a standard. > >That said, I do completely understand the problem you're trying to >solve. Well, no harm documenting it as an individual submission -- will be a little while until I have the spare cycles anyway. -- Luke _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sat Sep 11 14:01:46 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Sat, 11 Sep 2004 14:01:46 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id B29F51382E for ; Sat, 11 Sep 2004 14:01:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6CBU-0003Iz-AX; Sat, 11 Sep 2004 14:01:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6CAu-00032P-T5 for kitten@megatron.ietf.org; Sat, 11 Sep 2004 14:00:39 -0400 Received: from main.gmane.org ([80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00107 for ; Sat, 11 Sep 2004 14:00:31 -0400 (EDT) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C6CAo-0006VY-00 for ; Sat, 11 Sep 2004 20:00:30 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Sep 2004 20:00:30 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Sep 2004 20:00:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: kitten@ietf.org From: Simon Josefsson Date: Sat, 11 Sep 2004 19:56:29 +0200 Message-ID: References: <200409110710.RAA16219@au.padl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:6qeZFP5to8ftILFC8fceCs66rDY= Cc: Subject: Re: GSS-API extensions for AEAD X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 560 Lines: 23 Luke Howard writes: > Any comments? Worth writing this up as an Internet Draft? Yes, I believe so. Sam Hartman writes: > So, you can't guarantee that a particular mechanism can support this. I'm not sure I see how that is a problem. Mechanisms that do not support AEAD return an error. That approach works for mechanisms today, that don't implement the full API. Thanks, Simon _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Sep 13 13:46:27 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 13 Sep 2004 13:46:26 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 1AC7B13230 for ; Mon, 13 Sep 2004 13:46:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6un1-0000bJ-Ij; Mon, 13 Sep 2004 13:38:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6ucX-0007Kj-W4 for kitten@megatron.ietf.org; Mon, 13 Sep 2004 13:28:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18444 for ; Mon, 13 Sep 2004 13:28:04 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6uhG-0005CC-Bu for kitten@ietf.org; Mon, 13 Sep 2004 13:32:59 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i8DHS24d023854 for ; Mon, 13 Sep 2004 10:28:02 -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 i8DHS1jY017171 for ; Mon, 13 Sep 2004 11:28:02 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i8DHOuk6028423; Mon, 13 Sep 2004 12:24:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i8DHOukZ028422; Mon, 13 Sep 2004 12:24:56 -0500 (CDT) Date: Mon, 13 Sep 2004 12:24:56 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20040913172456.GB1989@binky.central.sun.com> References: <200409110710.RAA16219@au.padl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: kitten@ietf.org Subject: Re: GSS-API extensions for AEAD X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 985 Lines: 27 On Sat, Sep 11, 2004 at 07:56:29PM +0200, Simon Josefsson wrote: > Sam Hartman writes: > > > So, you can't guarantee that a particular mechanism can support this. > > I'm not sure I see how that is a problem. Mechanisms that do not > support AEAD return an error. That approach works for mechanisms > today, that don't implement the full API. I don't think it's a problem to have this extension, even though it would not be applicable to all mechanisms. That said I don't feel much sympathy for this proposal as, though there may be performance benefits to be had from it (encrypt-in-place) I prefer channel bindings to anonymous IPsec[1] as a way to improve performance. Perhaps CIFS will gain support for doing so and so the desire for this AEAD extensions to the GSS-API might go away, perhaps not. *shrug* Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Sep 13 15:15:25 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 13 Sep 2004 15:15:24 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id BD27C13230 for ; Mon, 13 Sep 2004 15:15:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6w9t-0006Td-NV; Mon, 13 Sep 2004 15:06:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6vxO-0006gz-Hy for kitten@megatron.ietf.org; Mon, 13 Sep 2004 14:53:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25568 for ; Mon, 13 Sep 2004 14:53:40 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6w28-0007Ck-2n for kitten@ietf.org; Mon, 13 Sep 2004 14:58:37 -0400 Received: by cz.mit.edu (Postfix, from userid 8042) id 4BBBE160079; Mon, 13 Sep 2004 14:54:46 -0400 (EDT) To: Nicolas Williams References: <200409110710.RAA16219@au.padl.com> <20040913172456.GB1989@binky.central.sun.com> From: Sam Hartman Date: Mon, 13 Sep 2004 14:54:46 -0400 In-Reply-To: <20040913172456.GB1989@binky.central.sun.com> (Nicolas Williams's message of "Mon, 13 Sep 2004 12:24:56 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: kitten@ietf.org, Simon Josefsson Subject: Re: GSS-API extensions for AEAD X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 901 Lines: 25 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Sat, Sep 11, 2004 at 07:56:29PM +0200, Simon Josefsson Nicolas> wrote: >> Sam Hartman writes: >> >> > So, you can't guarantee that a particular mechanism can >> support this. >> >> I'm not sure I see how that is a problem. Mechanisms that do >> not support AEAD return an error. That approach works for >> mechanisms today, that don't implement the full API. Nicolas> I don't think it's a problem to have this extension, even Nicolas> though it would not be applicable to all mechanisms. True. My concern is that people would want to use it with certain mechanisms (krb5) that don't actually support it. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Sep 13 23:40:47 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 13 Sep 2004 23:40:46 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 4C4DF13230 for ; Mon, 13 Sep 2004 23:40:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C74AU-0002fv-9q; Mon, 13 Sep 2004 23:39:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C746v-0001s8-CZ for kitten@megatron.ietf.org; Mon, 13 Sep 2004 23:36:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10817 for ; Mon, 13 Sep 2004 23:36:02 -0400 (EDT) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C74Bi-0003Gn-Sr for kitten@ietf.org; Mon, 13 Sep 2004 23:41:04 -0400 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id i8E3ZCqd066707; Tue, 14 Sep 2004 13:35:12 +1000 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id i8E3Z83d066705; Tue, 14 Sep 2004 13:35:08 +1000 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200409140335.i8E3Z83d066705@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: Nicolas.Williams@sun.com References: <200409110710.RAA16219@au.padl.com> <20040913172456.GB1989@binky.central.sun.com> Date: Tue, 14 Sep 2004 13:35:08 +1000 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: kitten@ietf.org, jas@extundo.com Subject: Re: GSS-API extensions for AEAD X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 698 Lines: 24 >That said I don't feel much sympathy for this proposal as, though there >may be performance benefits to be had from it (encrypt-in-place) I >prefer channel bindings to anonymous IPsec[1] as a way to improve >performance. Perhaps CIFS will gain support for doing so and so the >desire for this AEAD extensions to the GSS-API might go away, perhaps >not. *shrug* For the record, CIFS only uses GSS-API for authentication, so this proposal is unrelated. (CIFS does its own integrity protection and to my knowledge has no support for privacy.) -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Sep 13 23:40:22 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 13 Sep 2004 23:40:21 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 1490B13230 for ; Mon, 13 Sep 2004 23:40:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C74AT-0002fq-Vv; Mon, 13 Sep 2004 23:39:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7455-0001iR-Ql for kitten@megatron.ietf.org; Mon, 13 Sep 2004 23:34:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10770 for ; Mon, 13 Sep 2004 23:34:07 -0400 (EDT) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C749t-0003FW-Hb for kitten@ietf.org; Mon, 13 Sep 2004 23:39:10 -0400 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id i8E3XICQ066649; Tue, 14 Sep 2004 13:33:18 +1000 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id i8E3XIY2066648; Tue, 14 Sep 2004 13:33:18 +1000 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200409140333.i8E3XIY2066648@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: martin.rex@sap.com Date: Tue, 14 Sep 2004 13:33:18 +1000 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: kitten@ietf.org, tridge@samba.org Subject: Re: GSS-API extensions for AEAD X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 914 Lines: 29 >Where exactly is the difference between your gss_wrap_ex(), gss_unwrap_ex() >and the EXISTING gss_getmic() gss_verifymic()? gss_wrap_ex() can also encrypt some of the provided data while checksumming over the lot. >As far as I remember, the GSS-API was originally designed >by Engineers at Digital Equipment Coorporation (DEC) for use >with DCE. DCE provided GSS-API so that developers could add DCE security to non-DCE applications with a minimum of effort. However, RPC continued to use Kerberos natively for authentication. Some vendor implementations of DCE use GSS for RPC authentication in order to support multiple mechanisms and cryptosystems. Using GSS-API with Kerberos in this manner is not interoperable with Kerberos authentication in OSF DCE. -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Sep 14 13:04:23 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 14 Sep 2004 13:04:22 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 28A56131AC for ; Tue, 14 Sep 2004 13:04:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7GZY-0003uF-Tq; Tue, 14 Sep 2004 12:54:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7GCr-0006ki-65 for kitten@megatron.ietf.org; Tue, 14 Sep 2004 12:31:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22752 for ; Tue, 14 Sep 2004 12:30:58 -0400 (EDT) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7GHl-0001QD-Na for kitten@ietf.org; Tue, 14 Sep 2004 12:36:07 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id SAA12752; Tue, 14 Sep 2004 18:30:05 +0200 (MESZ) From: Martin Rex Message-Id: <200409141630.SAA00237@uw1048.wdf.sap.corp> To: lukeh@padl.com Date: Tue, 14 Sep 2004 18:30:04 +0200 (MET DST) In-Reply-To: <200409140333.i8E3XIY2066648@au.padl.com> from "Luke Howard" at Sep 14, 4 01:33:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, tridge@samba.org Subject: Re: GSS-API extensions for AEAD X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 1407 Lines: 41 Luke Howard wrote: > > gss_wrap_ex() can also encrypt some of the provided data while > checksumming over the lot. OK, I see. That is not possible with gss_getmic/gss_verifymic. > > >As far as I remember, the GSS-API was originally designed > >by Engineers at Digital Equipment Coorporation (DEC) for use > >with DCE. > > DCE provided GSS-API so that developers could add DCE security > to non-DCE applications with a minimum of effort. However, RPC > continued to use Kerberos natively for authentication. > > Some vendor implementations of DCE use GSS for RPC authentication > in order to support multiple mechanisms and cryptosystems. Using > GSS-API with Kerberos in this manner is not interoperable with > Kerberos authentication in OSF DCE. >From what I remeber one needs additional API calls to even get throught security context establishment with secure DCE RPC before being able to call things like gss_wrap_ex()/gss_unwrap_ex(). Microsoft has added the calls "CompleteAuthToken()" to their SSPI for that purpose, but there is no such call for GSS-API. Is that what Microsoft does via CompleteAuthToken() not necessary, or is/can the necessary information be supplied via ChannelBindings (Microsoft's SSPI doesn't have channel bindings)? -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Sep 14 19:52:09 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 14 Sep 2004 19:52:09 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 90177131AC for ; Tue, 14 Sep 2004 19:52:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7MwI-0000mz-Fp; Tue, 14 Sep 2004 19:42:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7MrY-00084i-7U for kitten@megatron.ietf.org; Tue, 14 Sep 2004 19:37:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04920 for ; Tue, 14 Sep 2004 19:37:25 -0400 (EDT) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7MwX-00046M-BY for kitten@ietf.org; Tue, 14 Sep 2004 19:42:38 -0400 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id i8ENahW0035854; Wed, 15 Sep 2004 09:36:43 +1000 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id i8ENagfm035853; Wed, 15 Sep 2004 09:36:42 +1000 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200409142336.i8ENagfm035853@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: martin.rex@sap.com Date: Wed, 15 Sep 2004 09:36:42 +1000 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: kitten@ietf.org, tridge@samba.org Subject: Re: GSS-API extensions for AEAD X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 795 Lines: 25 Hi Martin, >From what I remeber one needs additional API calls to even get >throught security context establishment with secure DCE RPC >before being able to call things like gss_wrap_ex()/gss_unwrap_ex(). > >Microsoft has added the calls "CompleteAuthToken()" to their SSPI >for that purpose, but there is no such call for GSS-API. Interesting, I hadn't seen this -- according to the Remarks in MSDN it is only called by the initiator. Perhaps this is because the RPC authentication trailer contains the number of padding bytes, and checksum is over the complete header including the authentication trailer (excepting the mechanism token). -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Sep 14 20:23:10 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 14 Sep 2004 20:23:09 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 605BC131AC for ; Tue, 14 Sep 2004 20:23:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7NVH-0008Qg-GP; Tue, 14 Sep 2004 20:18:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7NOf-0007Fy-O7 for kitten@megatron.ietf.org; Tue, 14 Sep 2004 20:11:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07167 for ; Tue, 14 Sep 2004 20:11:40 -0400 (EDT) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7NTe-0004jA-FX for kitten@ietf.org; Tue, 14 Sep 2004 20:16:52 -0400 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id i8F0Avpu037748; Wed, 15 Sep 2004 10:10:57 +1000 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id i8F0Avwk037747; Wed, 15 Sep 2004 10:10:57 +1000 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200409150010.i8F0Avwk037747@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: martin.rex@sap.com Date: Wed, 15 Sep 2004 10:10:57 +1000 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: kitten@ietf.org, tridge@samba.org Subject: Re: GSS-API extensions for AEAD X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 790 Lines: 23 >Interesting, I hadn't seen this -- according to the Remarks in MSDN >it is only called by the initiator. Perhaps this is because the RPC >authentication trailer contains the number of padding bytes, and >checksum is over the complete header including the authentication >trailer (excepting the mechanism token). Forget the above. It appears that CompleteSecurityContext() is called after both AcceptSecurityContext() and InitializeSecurityContext(). (Which is probably what Martin said in the first place.) Need to look into this more -- I've not found a need for this in our implementation which is interoperable with SSPI under DCE. -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten