From kitten-bounces@lists.ietf.org Sun Jul 09 12:29:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzcA7-0005KO-3T; Sun, 09 Jul 2006 12:29:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzcA6-0005KJ-5b for kitten@ietf.org; Sun, 09 Jul 2006 12:29:38 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzcA4-0002OM-UA for kitten@ietf.org; Sun, 09 Jul 2006 12:29:38 -0400 Received: from [192.168.1.240] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k69GSwwi005128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Jul 2006 12:29:18 -0400 (EDT) Message-ID: <44B12F04.10107@columbia.edu> Date: Sun, 09 Jul 2006 12:29:56 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Kerberos WG , SASL WG , Kitten X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Subject: Please participate in IETF66 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="===============1370903192==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1370903192== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090504060505020901020108" This is a cryptographically signed message in MIME format. --------------ms090504060505020901020108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit At IETF66 the Kerberos, Kitten and SASL Working Groups will be experimenting with a new means of incorporating remote participants into the meeting discussion. In order to ensure that the comments of remote participants as communicated via the Jabber Rooms will be seen by those physically present, the Jabber Room will be projected onto a second video screen. The Kerberos Working Group will be meeting on Monday, July 10th during the Morning Session (0900-1130 EDT) in Room 519A. The Kitten Working Group will be meeting on Monday, July 10th during the first Afternoon Session (1300-1500 EDT) in Room 519A. The SASL Working Group will be meeting on Monday, July 10th during the second Afternoon Session (1520-1720 EDT) in Room 519A. The Audio Stream for these three sessions can accessed via http://videolab.uoregon.edu/events/ietf/ietf667.m3u Use the following link to test your audio setup prior to the meetings: http://videolab.uoregon.edu/events/ietf/test.m3u The Jabber Room Server is "rooms.jabber.ietf.org". The room names are "krb-wg", "kitten" and "sasl". We look forward to your participation. Jeffrey Altman --------------ms090504060505020901020108 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJWTCC AwcwggJwoAMCAQICEDgwMdSemBfcGd6HY5Q4qrwwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRt YW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmFluisw/ NLjjXSHm0kgAgAMBknaWpJyDQlTpyzSswiSaDWINyEUzM/teBosk003zfyQdPONkWzclBRZ+ oGsYsAgxmyRe9tAJD7Jo6xp/6kCuF5nnaIyz91gWyuYZEeqQrfyFnWIfQu3fuoSeEIMLc9ac L9qhqnaTwCufH4v56CMftv6KFdf/k1CoLu/DL0ps5UOVwui+8iSWn3Qt6QfefDp9vbtBFPTV nZ7wGeewUJrO1LEC+x3gAOW+KxUcZMBax7tVygT5hDaQXm5lxUrlMQ/hLeWpv7LkVPD/ytoJ NCNzSnycrK4juG1CI12m5K1TNHZJ1uYjb7DUvMwOl6kQiQIDAQABozEwLzAfBgNVHREEGDAW gRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB ACNK1Xef6H2YL02xqVthcdQgFuF0bENE1u7gX/hegF1awGERhaIJmKGWau4OiAeHnlFqWysP EFzVrSb6L+TF9YHd/bP8WtxccOFnZ1L6oe7KOiyNfXGPZKj/i7Gti+MF4RM1ReZncTC1zMmZ DbFkVhL92vSgDGl4+6IwzjmQVK3sMIIDBzCCAnCgAwIBAgIQODAx1J6YF9wZ3odjlDiqvDAN BgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDYwNTI3MjIwMzMyWhcNMDcwNTI3MjIwMzMyWjBrMQ8wDQYDVQQEEwZBbHRt YW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMTSmVmZnJleSBFcmljIEFsdG1h bjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCYWW6KzD80uONdIebSSACAAwGSdpaknINCVOnLNKzCJJoNYg3I RTMz+14GiyTTTfN/JB0842RbNyUFFn6gaxiwCDGbJF720AkPsmjrGn/qQK4XmedojLP3WBbK 5hkR6pCt/IWdYh9C7d+6hJ4Qgwtz1pwv2qGqdpPAK58fi/noIx+2/ooV1/+TUKgu78MvSmzl Q5XC6L7yJJafdC3pB958On29u0EU9NWdnvAZ57BQms7UsQL7HeAA5b4rFRxkwFrHu1XKBPmE NpBebmXFSuUxD+Et5am/suRU8P/K2gk0I3NKfJysriO4bUIjXabkrVM0dknW5iNvsNS8zA6X qRCJAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAI0rVd5/ofZgvTbGpW2Fx1CAW4XRsQ0TW7uBf+F6A XVrAYRGFogmYoZZq7g6IB4eeUWpbKw8QXNWtJvov5MX1gd39s/xa3Fxw4WdnUvqh7so6LI19 cY9kqP+Lsa2L4wXhEzVF5mdxMLXMyZkNsWRWEv3a9KAMaXj7ojDOOZBUrewwggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECEDgwMdSemBfcGd6HY5Q4qrwwCQYFKw4DAhoFAKCCAcMw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNzA5MTYyOTU2 WjAjBgkqhkiG9w0BCQQxFgQUcJ7+DBHBqZuaWPAaZme7d47ygJMwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA4MDHUnpgX3Bneh2OUOKq8MIGHBgsqhkiG9w0B CRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA4MDHUnpgX3Bneh2OUOKq8MA0GCSqGSIb3DQEBAQUABIIBABRMggxMfBTfgln8WC8N0ENr oHbEoq8Ogab0nT+xXtiow5B+DTCxcf4KNqQQTytik3+SuCcxPyKXkbT6eESWpnkoqldVbJry PWlh0FxaL5o/CdKKjFdS41yO0jRUArQKY0bnQrZKzBBVYbGghxD4U8fJqc0ASIRHX+mLgxjQ QJ0ov1ZhNdmx75N3s8mM1MjFIJixejfMtYzv+G4z8nXBCnFvXroJ2WFVejUrsRTWMpZVz2At tyI/sw9XbkXLaNBqXTodVMeFWT6MQr9z38bNKzWh6JhnBn2gCIdg3pBn6Q9IyqL81ODgetEe eE5dequLwDiaJWdbTeWWox1QWBFRCwcAAAAAAAA= --------------ms090504060505020901020108-- --===============1370903192== 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 --===============1370903192==-- From kitten-bounces@lists.ietf.org Mon Jul 10 01:30:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzoM0-0004fr-EU; Mon, 10 Jul 2006 01:30:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzoLz-0004fm-D6 for kitten@ietf.org; Mon, 10 Jul 2006 01:30:43 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzoLw-0002uW-Rj for kitten@ietf.org; Mon, 10 Jul 2006 01:30:43 -0400 Received: from [18.100.0.78] (VPN-SEVENTY-EIGHT.MIT.EDU [18.100.0.78]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6A5Twg4029376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jul 2006 01:30:19 -0400 (EDT) Message-ID: <44B1C624.9070705@columbia.edu> Date: Sun, 09 Jul 2006 23:14:44 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Kitten , Kerberos WG X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: afbb91703506ab43c817903f0dd6f23d Cc: Subject: draft-ietf-kitten-gssapi-domain-based-names-02.txt - did not get published by the IETF Secretariat 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="===============2090281384==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============2090281384== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010907000003000304000606" This is a cryptographically signed message in MIME format. --------------ms010907000003000304000606 Content-Type: multipart/mixed; boundary="------------070708070702050809040102" This is a multi-part message in MIME format. --------------070708070702050809040102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The attached message from Nico Williams was sent to the Internet-Drafts@ietf.org mailbox prior to the cutoff date one minute after draft-ietf-kitten-krb5-gssapi-domain-based-names-02.txt which was published. The draft was neither published nor rejected. Due to this failure on the part of the IETF Secretariat a Working Group Last Call which I intended to announce tonight on both of these documents will be postponed until both documents are published. In the meantime, please find the time to review these documents. Thank you. Jeffrey Altman --------------070708070702050809040102 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message" Return-Path: Received: from bockwurst.cc.columbia.edu ([unix socket]) by bockwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Mon, 26 Jun 2006 07:40:32 -0400 X-Sieve: CMU Sieve 2.3 Received: from longan.cc.columbia.edu (longan.cc.columbia.edu [128.59.28.165]) by bockwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id k5QBeWlL024633 for ; Mon, 26 Jun 2006 07:40:32 -0400 Received: from nwkea-mail-4.sun.com (nwkea-mail-4.sun.com [192.18.42.26]) by longan.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k5QBeSgL005907 for ; Mon, 26 Jun 2006 07:40:31 -0400 (EDT) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5QBeRHE009365 for ; Mon, 26 Jun 2006 04:40:27 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k5QBeRhH011687 for ; Mon, 26 Jun 2006 05:40:27 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5QBeQTw003969; Mon, 26 Jun 2006 06:40:26 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5QBeQ76003968; Mon, 26 Jun 2006 06:40:26 -0500 (CDT) Date: Mon, 26 Jun 2006 06:40:26 -0500 From: Nicolas Williams To: Internet-Drafts@ietf.org, Jeffrey Altman Subject: draft-ietf-kitten-gssapi-domain-based-names-02.txt Message-ID: <20060626114026.GF1745@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Spam-Score: 1.668 (*) BLANK_LINES_70_80 X-Scanned-By: MIMEDefang 2.48 on 128.59.28.165 NETWORK WORKING GROUP N. Williams Internet-Draft Sun Expires: December 28, 2006 June 26, 2006 GSS-API Domain-Based Service Names and Name Type draft-ietf-kitten-gssapi-domain-based-names-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes domainname-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API). Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) instead of or in addition to a hostname. The primary purpose of domain-based service names is to provide a way to name clustered services after the domain which they service, thereby allowing their Williams Expires December 28, 2006 [Page 1] Internet-Draft GSS Domain Based Names June 2006 clients to authorize the service's servers based on authentication of their names. Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Name Type OID and Symbolic Name . . . . . . . . . . . . . . 5 4. Query and Display Syntaxes . . . . . . . . . . . . . . . . . 6 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Informative . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . 11 Williams Expires December 28, 2006 [Page 2] Internet-Draft GSS Domain Based Names June 2006 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Williams Expires December 28, 2006 [Page 3] Internet-Draft GSS Domain Based Names June 2006 2. Introduction The use of hostbased principal names for domain-wide services presents the problem of how to distinguish between an instance of a hostbased service that is authorized to respond for a domain and one that isn't. Consider LDAP. LDAP [RFC3377] with SASL [RFC2222] and the Kerberos V mechanism [RFC1964] for the GSS-API [RFC2743] uses a hostbased principal with a service name of "ldap", a reasonable approach, provided there is only one logical LDAP directory in a Kerberos realm's domain, and that all ldap servers in that realm serve that one LDAP directory. An network might have multiple, distinct LDAP services, but only one LDAP "name service"; if so then clients could not tell which LDAP service principals are authorized to serve which directory, not without assuming a secure method for finding LDAP servers (e.g., DNSSEC). This is a significant, and oft-unstated restriction on users of LDAP. Domain based names can eliminate this problem: the use of domain- based names should imply that the given host is a server for the official LDAP name service of the given domain. Notwithstanding the LDAP example the use of domain-based principal names for LDAP is not actually specified here and will be specified in a separate document. A domain-based name consists of three required elements: o a service name o a domain name o a hostname Williams Expires December 28, 2006 [Page 4] Internet-Draft GSS Domain Based Names June 2006 3. Name Type OID and Symbolic Name The new name type has an OID of [NOTE: OID assignment to be made with IANA.] {iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) gss- domain-based(5)} The recommended symbolic name for this GSS-API name type is "GSS_C_NT_DOMAINBASED_SERVICE". Williams Expires December 28, 2006 [Page 5] Internet-Draft GSS Domain Based Names June 2006 4. Query and Display Syntaxes There is a single name syntax for domain-based names. The syntax is: domain-based-name := | '@' '@' Note that for Internet domain names the trailing '.' is not and MUST NOT be included in the domain name (or hostname) parts of the display form GSS-API domain-based MNs. Williams Expires December 28, 2006 [Page 6] Internet-Draft GSS Domain Based Names June 2006 5. Examples o ldap@example.tld@ds1.example.tld o kadmin@example.tld@kdc1.example.tld Williams Expires December 28, 2006 [Page 7] Internet-Draft GSS Domain Based Names June 2006 6. Security Considerations Use of GSS-API domain-based names may not be negotiable by some GSS- API mechanisms, and some acceptors may not support GSS-API domain- based names. In such cases initiators are left to fallback on the use of hostbased names, in which case the initiators MUST also verify that the acceptor's hostbased name is authorized to provide the given service for the domain that the initiator had wanted. The above security consideration also applies to all GSS-API initiators who lack support for domain-based service names. Williams Expires December 28, 2006 [Page 8] Internet-Draft GSS Domain Based Names June 2006 7. References 7.1. Normative [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. 7.2. Informative [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996. [RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. Williams Expires December 28, 2006 [Page 9] Internet-Draft GSS Domain Based Names June 2006 Author's Address Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US Email: Nicolas.Williams@sun.com Williams Expires December 28, 2006 [Page 10] Internet-Draft GSS Domain Based Names June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Williams Expires December 28, 2006 [Page 11] --------------070708070702050809040102-- --------------ms010907000003000304000606 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJWTCC AwcwggJwoAMCAQICEDgwMdSemBfcGd6HY5Q4qrwwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRt YW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmFluisw/ NLjjXSHm0kgAgAMBknaWpJyDQlTpyzSswiSaDWINyEUzM/teBosk003zfyQdPONkWzclBRZ+ oGsYsAgxmyRe9tAJD7Jo6xp/6kCuF5nnaIyz91gWyuYZEeqQrfyFnWIfQu3fuoSeEIMLc9ac L9qhqnaTwCufH4v56CMftv6KFdf/k1CoLu/DL0ps5UOVwui+8iSWn3Qt6QfefDp9vbtBFPTV nZ7wGeewUJrO1LEC+x3gAOW+KxUcZMBax7tVygT5hDaQXm5lxUrlMQ/hLeWpv7LkVPD/ytoJ NCNzSnycrK4juG1CI12m5K1TNHZJ1uYjb7DUvMwOl6kQiQIDAQABozEwLzAfBgNVHREEGDAW gRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB ACNK1Xef6H2YL02xqVthcdQgFuF0bENE1u7gX/hegF1awGERhaIJmKGWau4OiAeHnlFqWysP EFzVrSb6L+TF9YHd/bP8WtxccOFnZ1L6oe7KOiyNfXGPZKj/i7Gti+MF4RM1ReZncTC1zMmZ DbFkVhL92vSgDGl4+6IwzjmQVK3sMIIDBzCCAnCgAwIBAgIQODAx1J6YF9wZ3odjlDiqvDAN BgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDYwNTI3MjIwMzMyWhcNMDcwNTI3MjIwMzMyWjBrMQ8wDQYDVQQEEwZBbHRt YW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMTSmVmZnJleSBFcmljIEFsdG1h bjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCYWW6KzD80uONdIebSSACAAwGSdpaknINCVOnLNKzCJJoNYg3I RTMz+14GiyTTTfN/JB0842RbNyUFFn6gaxiwCDGbJF720AkPsmjrGn/qQK4XmedojLP3WBbK 5hkR6pCt/IWdYh9C7d+6hJ4Qgwtz1pwv2qGqdpPAK58fi/noIx+2/ooV1/+TUKgu78MvSmzl Q5XC6L7yJJafdC3pB958On29u0EU9NWdnvAZ57BQms7UsQL7HeAA5b4rFRxkwFrHu1XKBPmE NpBebmXFSuUxD+Et5am/suRU8P/K2gk0I3NKfJysriO4bUIjXabkrVM0dknW5iNvsNS8zA6X qRCJAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAI0rVd5/ofZgvTbGpW2Fx1CAW4XRsQ0TW7uBf+F6A XVrAYRGFogmYoZZq7g6IB4eeUWpbKw8QXNWtJvov5MX1gd39s/xa3Fxw4WdnUvqh7so6LI19 cY9kqP+Lsa2L4wXhEzVF5mdxMLXMyZkNsWRWEv3a9KAMaXj7ojDOOZBUrewwggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECEDgwMdSemBfcGd6HY5Q4qrwwCQYFKw4DAhoFAKCCAcMw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNzEwMDMxNDQ0 WjAjBgkqhkiG9w0BCQQxFgQUu7ze2k244dbYwVShp2nyxxL7YSgwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA4MDHUnpgX3Bneh2OUOKq8MIGHBgsqhkiG9w0B CRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA4MDHUnpgX3Bneh2OUOKq8MA0GCSqGSIb3DQEBAQUABIIBAD0hc/OQ5B6KPRQ77s7/dW3V 6/N5xK0phVoACXpksvif5PgQYBvNyxtFkgYHj0R1llHByAL8wyUnhbNpBsCFmwwZjg7Ll7iO 6l5zGwgAJlnBlq1oGLXQANvRv8WSmZtkOx8O7nCvOJMIAkRKe++Jy5eW/Q/tbNcbEtEzf9ha kv71DpQfA3Offs+YoqHoElLrjlMrZ1xn7CrbX+CpHLM/AZoOCEXzcoUnVhCxdStWHCaCl++w s3xoU1JLNWD4RAndQ/Xv/9PB792rNlFKzA8NnipkvcxFRTaQFcliJK4akHAO5HMq51VsgMBJ G/0iJQMIzklFOaH9/oYfy13LVU7l4y4AAAAAAAA= --------------ms010907000003000304000606-- --===============2090281384== 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 --===============2090281384==-- From kitten-bounces@lists.ietf.org Mon Jul 10 01:56:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzokr-0004WU-Ho; Mon, 10 Jul 2006 01:56:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzokp-00047m-Tr for kitten@ietf.org; Mon, 10 Jul 2006 01:56:23 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzokm-0004mB-Le for kitten@ietf.org; Mon, 10 Jul 2006 01:56:21 -0400 Received: from [128.59.249.10] (vpn-128-59-249-10.vpn.columbia.edu [128.59.249.10]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6A5ti2h001184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jul 2006 01:56:08 -0400 (EDT) Message-ID: <44B1DF7D.7000209@columbia.edu> Date: Mon, 10 Jul 2006 01:02:53 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Kerberos WG , SASL WG , Kitten References: <44B12F04.10107@columbia.edu> In-Reply-To: <44B12F04.10107@columbia.edu> X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: Subject: Please participate in IETF66 [Corrected Jabber Server Info] 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="===============0785504932==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0785504932== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080608010200000403080709" This is a cryptographically signed message in MIME format. --------------ms080608010200000403080709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit At IETF66 the Kerberos, Kitten and SASL Working Groups will be experimenting with a new means of incorporating remote participants into the meeting discussion. In order to ensure that the comments of remote participants as communicated via the Jabber Rooms will be seen by those physically present, the Jabber Room will be projected onto a second video screen. The Kerberos Working Group will be meeting on Monday, July 10th during the Morning Session (0900-1130 EDT) in Room 519A. The Kitten Working Group will be meeting on Monday, July 10th during the first Afternoon Session (1300-1500 EDT) in Room 519A. The SASL Working Group will be meeting on Monday, July 10th during the second Afternoon Session (1520-1720 EDT) in Room 519A. The Audio Stream for these three sessions can accessed via http://videolab.uoregon.edu/events/ietf/ietf667.m3u Use the following link to test your audio setup prior to the meetings: http://videolab.uoregon.edu/events/ietf/test.m3u The Jabber Room Server is "jabber.ietf.org". The room names are "krb-wg", "kitten" and "sasl". We look forward to your participation. Jeffrey Altman --------------ms080608010200000403080709 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJWTCC AwcwggJwoAMCAQICEDgwMdSemBfcGd6HY5Q4qrwwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRt YW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmFluisw/ NLjjXSHm0kgAgAMBknaWpJyDQlTpyzSswiSaDWINyEUzM/teBosk003zfyQdPONkWzclBRZ+ oGsYsAgxmyRe9tAJD7Jo6xp/6kCuF5nnaIyz91gWyuYZEeqQrfyFnWIfQu3fuoSeEIMLc9ac L9qhqnaTwCufH4v56CMftv6KFdf/k1CoLu/DL0ps5UOVwui+8iSWn3Qt6QfefDp9vbtBFPTV nZ7wGeewUJrO1LEC+x3gAOW+KxUcZMBax7tVygT5hDaQXm5lxUrlMQ/hLeWpv7LkVPD/ytoJ NCNzSnycrK4juG1CI12m5K1TNHZJ1uYjb7DUvMwOl6kQiQIDAQABozEwLzAfBgNVHREEGDAW gRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB ACNK1Xef6H2YL02xqVthcdQgFuF0bENE1u7gX/hegF1awGERhaIJmKGWau4OiAeHnlFqWysP EFzVrSb6L+TF9YHd/bP8WtxccOFnZ1L6oe7KOiyNfXGPZKj/i7Gti+MF4RM1ReZncTC1zMmZ DbFkVhL92vSgDGl4+6IwzjmQVK3sMIIDBzCCAnCgAwIBAgIQODAx1J6YF9wZ3odjlDiqvDAN BgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDYwNTI3MjIwMzMyWhcNMDcwNTI3MjIwMzMyWjBrMQ8wDQYDVQQEEwZBbHRt YW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMTSmVmZnJleSBFcmljIEFsdG1h bjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCYWW6KzD80uONdIebSSACAAwGSdpaknINCVOnLNKzCJJoNYg3I RTMz+14GiyTTTfN/JB0842RbNyUFFn6gaxiwCDGbJF720AkPsmjrGn/qQK4XmedojLP3WBbK 5hkR6pCt/IWdYh9C7d+6hJ4Qgwtz1pwv2qGqdpPAK58fi/noIx+2/ooV1/+TUKgu78MvSmzl Q5XC6L7yJJafdC3pB958On29u0EU9NWdnvAZ57BQms7UsQL7HeAA5b4rFRxkwFrHu1XKBPmE NpBebmXFSuUxD+Et5am/suRU8P/K2gk0I3NKfJysriO4bUIjXabkrVM0dknW5iNvsNS8zA6X qRCJAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAI0rVd5/ofZgvTbGpW2Fx1CAW4XRsQ0TW7uBf+F6A XVrAYRGFogmYoZZq7g6IB4eeUWpbKw8QXNWtJvov5MX1gd39s/xa3Fxw4WdnUvqh7so6LI19 cY9kqP+Lsa2L4wXhEzVF5mdxMLXMyZkNsWRWEv3a9KAMaXj7ojDOOZBUrewwggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECEDgwMdSemBfcGd6HY5Q4qrwwCQYFKw4DAhoFAKCCAcMw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNzEwMDUwMjUz WjAjBgkqhkiG9w0BCQQxFgQU0bXU8dt7+tWgGmPX1x75gpyhGWEwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA4MDHUnpgX3Bneh2OUOKq8MIGHBgsqhkiG9w0B CRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA4MDHUnpgX3Bneh2OUOKq8MA0GCSqGSIb3DQEBAQUABIIBAIpHzPv8RVW0HbuMHsXEo/ah vLEdFs8dYq91+iSOJyxDa3Y2PhHlSUmqP5PhQ9Xpxfme6uNYSCA3NelQJqPRDG+hJYAKCekb ieKzx5aQ6U07JEKq/USIZRsHjtt8wW5h0BuwEUxcDOpdHCGEqD78+d0U+7ZtDG2thO37WydM p/l6HV3iddjQ43EuSNoWYvY9kR9AydIdh6GWHs6M2daUzyPF1DYfush8wCH87Hm0el0eu5/m emunr2/sYM9TaA8zoSWz+QyvlrzZPitYQBzpYgnF7l8ICOhZOOhtI8qmIpPyBJ6eHOqSO5oW BPdh9ldKaD2h3mAPm81m2uYFJOpRiNkAAAAAAAA= --------------ms080608010200000403080709-- --===============0785504932== 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 --===============0785504932==-- From kitten-bounces@lists.ietf.org Mon Jul 10 02:42:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzpTc-0007EK-PI; Mon, 10 Jul 2006 02:42:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzpTb-0007EF-Su for kitten@ietf.org; Mon, 10 Jul 2006 02:42:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzor3-0005OW-CE for kitten@ietf.org; Mon, 10 Jul 2006 02:02:49 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fzok2-0008Bg-TD for kitten@ietf.org; Mon, 10 Jul 2006 01:55:37 -0400 Received: from [128.59.249.10] (vpn-128-59-249-10.vpn.columbia.edu [128.59.249.10]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6A5rgQd001082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jul 2006 01:54:29 -0400 (EDT) Message-ID: <44B1DF7D.7000209@columbia.edu> Date: Mon, 10 Jul 2006 01:02:53 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Kerberos WG , SASL WG , Kitten References: <44B12F04.10107@columbia.edu> In-Reply-To: <44B12F04.10107@columbia.edu> X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -2.3 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: Subject: Please participate in IETF66 [Corrected Jabber Server Info] 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="===============0875356843==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0875356843== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080608010200000403080709" This is a cryptographically signed message in MIME format. --------------ms080608010200000403080709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit At IETF66 the Kerberos, Kitten and SASL Working Groups will be experimenting with a new means of incorporating remote participants into the meeting discussion. In order to ensure that the comments of remote participants as communicated via the Jabber Rooms will be seen by those physically present, the Jabber Room will be projected onto a second video screen. The Kerberos Working Group will be meeting on Monday, July 10th during the Morning Session (0900-1130 EDT) in Room 519A. The Kitten Working Group will be meeting on Monday, July 10th during the first Afternoon Session (1300-1500 EDT) in Room 519A. The SASL Working Group will be meeting on Monday, July 10th during the second Afternoon Session (1520-1720 EDT) in Room 519A. The Audio Stream for these three sessions can accessed via http://videolab.uoregon.edu/events/ietf/ietf667.m3u Use the following link to test your audio setup prior to the meetings: http://videolab.uoregon.edu/events/ietf/test.m3u The Jabber Room Server is "jabber.ietf.org". The room names are "krb-wg", "kitten" and "sasl". We look forward to your participation. Jeffrey Altman --------------ms080608010200000403080709 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJWTCC AwcwggJwoAMCAQICEDgwMdSemBfcGd6HY5Q4qrwwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRt YW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmFluisw/ NLjjXSHm0kgAgAMBknaWpJyDQlTpyzSswiSaDWINyEUzM/teBosk003zfyQdPONkWzclBRZ+ oGsYsAgxmyRe9tAJD7Jo6xp/6kCuF5nnaIyz91gWyuYZEeqQrfyFnWIfQu3fuoSeEIMLc9ac L9qhqnaTwCufH4v56CMftv6KFdf/k1CoLu/DL0ps5UOVwui+8iSWn3Qt6QfefDp9vbtBFPTV nZ7wGeewUJrO1LEC+x3gAOW+KxUcZMBax7tVygT5hDaQXm5lxUrlMQ/hLeWpv7LkVPD/ytoJ NCNzSnycrK4juG1CI12m5K1TNHZJ1uYjb7DUvMwOl6kQiQIDAQABozEwLzAfBgNVHREEGDAW gRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB ACNK1Xef6H2YL02xqVthcdQgFuF0bENE1u7gX/hegF1awGERhaIJmKGWau4OiAeHnlFqWysP EFzVrSb6L+TF9YHd/bP8WtxccOFnZ1L6oe7KOiyNfXGPZKj/i7Gti+MF4RM1ReZncTC1zMmZ DbFkVhL92vSgDGl4+6IwzjmQVK3sMIIDBzCCAnCgAwIBAgIQODAx1J6YF9wZ3odjlDiqvDAN BgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDYwNTI3MjIwMzMyWhcNMDcwNTI3MjIwMzMyWjBrMQ8wDQYDVQQEEwZBbHRt YW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMTSmVmZnJleSBFcmljIEFsdG1h bjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCYWW6KzD80uONdIebSSACAAwGSdpaknINCVOnLNKzCJJoNYg3I RTMz+14GiyTTTfN/JB0842RbNyUFFn6gaxiwCDGbJF720AkPsmjrGn/qQK4XmedojLP3WBbK 5hkR6pCt/IWdYh9C7d+6hJ4Qgwtz1pwv2qGqdpPAK58fi/noIx+2/ooV1/+TUKgu78MvSmzl Q5XC6L7yJJafdC3pB958On29u0EU9NWdnvAZ57BQms7UsQL7HeAA5b4rFRxkwFrHu1XKBPmE NpBebmXFSuUxD+Et5am/suRU8P/K2gk0I3NKfJysriO4bUIjXabkrVM0dknW5iNvsNS8zA6X qRCJAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAI0rVd5/ofZgvTbGpW2Fx1CAW4XRsQ0TW7uBf+F6A XVrAYRGFogmYoZZq7g6IB4eeUWpbKw8QXNWtJvov5MX1gd39s/xa3Fxw4WdnUvqh7so6LI19 cY9kqP+Lsa2L4wXhEzVF5mdxMLXMyZkNsWRWEv3a9KAMaXj7ojDOOZBUrewwggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECEDgwMdSemBfcGd6HY5Q4qrwwCQYFKw4DAhoFAKCCAcMw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNzEwMDUwMjUz WjAjBgkqhkiG9w0BCQQxFgQU0bXU8dt7+tWgGmPX1x75gpyhGWEwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA4MDHUnpgX3Bneh2OUOKq8MIGHBgsqhkiG9w0B CRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA4MDHUnpgX3Bneh2OUOKq8MA0GCSqGSIb3DQEBAQUABIIBAIpHzPv8RVW0HbuMHsXEo/ah vLEdFs8dYq91+iSOJyxDa3Y2PhHlSUmqP5PhQ9Xpxfme6uNYSCA3NelQJqPRDG+hJYAKCekb ieKzx5aQ6U07JEKq/USIZRsHjtt8wW5h0BuwEUxcDOpdHCGEqD78+d0U+7ZtDG2thO37WydM p/l6HV3iddjQ43EuSNoWYvY9kR9AydIdh6GWHs6M2daUzyPF1DYfush8wCH87Hm0el0eu5/m emunr2/sYM9TaA8zoSWz+QyvlrzZPitYQBzpYgnF7l8ICOhZOOhtI8qmIpPyBJ6eHOqSO5oW BPdh9ldKaD2h3mAPm81m2uYFJOpRiNkAAAAAAAA= --------------ms080608010200000403080709-- --===============0875356843== 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 --===============0875356843==-- From kitten-bounces@lists.ietf.org Mon Jul 10 03:10:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzpua-0008UH-Eb; Mon, 10 Jul 2006 03:10:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzpuZ-0008U8-Bd for kitten@ietf.org; Mon, 10 Jul 2006 03:10:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzor6-0005OW-2P for kitten@ietf.org; Mon, 10 Jul 2006 02:02:52 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FzogG-00087N-KH for kitten@ietf.org; Mon, 10 Jul 2006 01:51:44 -0400 Received: from [128.59.249.10] (vpn-128-59-249-10.vpn.columbia.edu [128.59.249.10]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6A5o05k000814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 10 Jul 2006 01:51:25 -0400 (EDT) Message-ID: <44B1DB89.3030702@columbia.edu> Date: Mon, 10 Jul 2006 00:46:01 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Kitten X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -2.0 (--) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Subject: IETF66 Agenda 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="===============0654759043==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0654759043== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090007010702000004000004" This is a cryptographically signed message in MIME format. --------------ms090007010702000004000004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The agenda is available from http://www3.ietf.org/proceedings/06jul/agenda/kitten.txt --------------ms090007010702000004000004 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJWTCC AwcwggJwoAMCAQICEDgwMdSemBfcGd6HY5Q4qrwwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRt YW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmFluisw/ NLjjXSHm0kgAgAMBknaWpJyDQlTpyzSswiSaDWINyEUzM/teBosk003zfyQdPONkWzclBRZ+ oGsYsAgxmyRe9tAJD7Jo6xp/6kCuF5nnaIyz91gWyuYZEeqQrfyFnWIfQu3fuoSeEIMLc9ac L9qhqnaTwCufH4v56CMftv6KFdf/k1CoLu/DL0ps5UOVwui+8iSWn3Qt6QfefDp9vbtBFPTV nZ7wGeewUJrO1LEC+x3gAOW+KxUcZMBax7tVygT5hDaQXm5lxUrlMQ/hLeWpv7LkVPD/ytoJ NCNzSnycrK4juG1CI12m5K1TNHZJ1uYjb7DUvMwOl6kQiQIDAQABozEwLzAfBgNVHREEGDAW gRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB ACNK1Xef6H2YL02xqVthcdQgFuF0bENE1u7gX/hegF1awGERhaIJmKGWau4OiAeHnlFqWysP EFzVrSb6L+TF9YHd/bP8WtxccOFnZ1L6oe7KOiyNfXGPZKj/i7Gti+MF4RM1ReZncTC1zMmZ DbFkVhL92vSgDGl4+6IwzjmQVK3sMIIDBzCCAnCgAwIBAgIQODAx1J6YF9wZ3odjlDiqvDAN BgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDYwNTI3MjIwMzMyWhcNMDcwNTI3MjIwMzMyWjBrMQ8wDQYDVQQEEwZBbHRt YW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMTSmVmZnJleSBFcmljIEFsdG1h bjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCYWW6KzD80uONdIebSSACAAwGSdpaknINCVOnLNKzCJJoNYg3I RTMz+14GiyTTTfN/JB0842RbNyUFFn6gaxiwCDGbJF720AkPsmjrGn/qQK4XmedojLP3WBbK 5hkR6pCt/IWdYh9C7d+6hJ4Qgwtz1pwv2qGqdpPAK58fi/noIx+2/ooV1/+TUKgu78MvSmzl Q5XC6L7yJJafdC3pB958On29u0EU9NWdnvAZ57BQms7UsQL7HeAA5b4rFRxkwFrHu1XKBPmE NpBebmXFSuUxD+Et5am/suRU8P/K2gk0I3NKfJysriO4bUIjXabkrVM0dknW5iNvsNS8zA6X qRCJAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAI0rVd5/ofZgvTbGpW2Fx1CAW4XRsQ0TW7uBf+F6A XVrAYRGFogmYoZZq7g6IB4eeUWpbKw8QXNWtJvov5MX1gd39s/xa3Fxw4WdnUvqh7so6LI19 cY9kqP+Lsa2L4wXhEzVF5mdxMLXMyZkNsWRWEv3a9KAMaXj7ojDOOZBUrewwggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECEDgwMdSemBfcGd6HY5Q4qrwwCQYFKw4DAhoFAKCCAcMw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNzEwMDQ0NjAx WjAjBgkqhkiG9w0BCQQxFgQUl5xoqVVOAbGb1FDLNFRA2bM1NsQwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA4MDHUnpgX3Bneh2OUOKq8MIGHBgsqhkiG9w0B CRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA4MDHUnpgX3Bneh2OUOKq8MA0GCSqGSIb3DQEBAQUABIIBAFvDxTUjqqcmCwwwBfTQ94pD XX2oszGc59+wwLGC8MIuKQL3oeUIodMmIw6Hr5DgXTNkT+e+tc9/MwA34PyhzX8S2hH+3AWl wIlURPXuYzGhvSwSsxy2/wuBk1+hslR1qls1hjfTtEoKMF27GVe3gg6HOKGBuqGzDqVq6Spe ex95FcKUOdH7vyZ/3lzPHH2HHZ2OUO9Zivw6UGMEs550YNxBI/rFxzKxPAdk+2afaQqwyScp aiHbYjOP3hHG7ezCEmc8s5e2FDPdnlIYA/H+PeevyainYnEuWHt4kyMshFOe/ZZ65h6ElNqW 2i9wBEQRlmHHy4EeI6MXdHpyn7XmC2gAAAAAAAA= --------------ms090007010702000004000004-- --===============0654759043== 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 --===============0654759043==-- From kitten-bounces@lists.ietf.org Mon Jul 10 16:59:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02qN-00044F-A4; Mon, 10 Jul 2006 16:59:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02qL-000449-G2 for kitten@ietf.org; Mon, 10 Jul 2006 16:59:01 -0400 Received: from maila.microsoft.com ([131.107.1.6] helo=mail1.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G02qK-0007HN-6D for kitten@ietf.org; Mon, 10 Jul 2006 16:59:01 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 13:58:59 -0700 Received: from tuk-hub-02.redmond.corp.microsoft.com ([157.54.70.28]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 13:58:59 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 13:58:58 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Mon, 10 Jul 2006 13:58:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jul 2006 13:58:57 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Exposing the client realms of the anonymous client thread-index: AcakY6lsRjlmIh/oQeet7A1QamnIRQ== From: "Liqiang\(Larry\) Zhu" To: , , X-OriginalArrivalTime: 10 Jul 2006 20:58:58.0702 (UTC) FILETIME=[A9F8F2E0:01C6A463] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: Exposing the client realms of the anonymous client 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: , Errors-To: kitten-bounces@lists.ietf.org In kitten, we have discussed this in detail, see the minutes for more information. please review the relevant text for this: GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to represent the anonymous identity. In addition, Section 2.1.1 of [RFC1964] defines the single string representation of a Kerberos principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME. For the anonymous principals, the name component within the exportable name as defined in Section 2.1.3 of [RFC1964] MUST signify the realm name according to Section 2.1.1 of [RFC1964]. In this specification only the client/initiator can be the anonymous identity. Portable initiators are RECOMMENDED to use default credentials whenever possible, and request anonymity only through the input anon_req_flag [RFC2743] to GSS_Init_Sec_Context(). Here is the diff out: > GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to 329,331d332 < Portable initiators are RECOMMENDED to use default credentials < whenever possible, and request anonymity only through the input < anon_req_flag to GSS_Init_Sec_Context(). 334,335c335 < < Zhu, et al. Expires December 5, 2006 [Page 6] --- > Zhu, et al. Expires December 3, 2006 [Page 6] 339a340,352 > represent the anonymous identity. In addition, Section 2.1.1 of > [RFC1964] defines the single string representation of a Kerberos > principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME. For > the anonymous principals, the name component within the exportable > name as defined in Section 2.1.3 of [RFC1964] MUST signify the realm > name according to Section 2.1.1 of [RFC1964]. In this specification > only the client/initiator can be the anonymous identity. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Jul 11 10:43:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0JSq-0002nk-A4; Tue, 11 Jul 2006 10:43:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0JSp-0002nP-PW for kitten@ietf.org; Tue, 11 Jul 2006 10:43:51 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0JSo-0005ic-Fb for kitten@ietf.org; Tue, 11 Jul 2006 10:43:51 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 771863BF64 for ; Tue, 11 Jul 2006 16:43:49 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19677-01-6 for ; Tue, 11 Jul 2006 16:43:49 +0200 (CEST) Received: from [132.219.30.183] (unknown [132.219.30.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id B6C9E3BE7E for ; Tue, 11 Jul 2006 16:43:48 +0200 (CEST) Message-ID: <44B3B92B.5000309@it.su.se> Date: Tue, 11 Jul 2006 16:43:55 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.662 tagged_above=-99 required=7 tests=[AWL=0.003, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: naming attributes 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: , Errors-To: kitten-bounces@lists.ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 During the wg yesterday I was asked to forward my comments regarding naming attributes to the list. As far as I understand the point of the naming api extension is to treat a name as an opaque extracting name attributes by attribute identifier. There are several obvious examples of objects which could be exposed by this api: X509 certs EKUs, SAML assertions, RDF graphs, LDAP entries etc. My problem is with the choice of OIDs as name attribute identifiers is that several of the obvious examples don't use OIDs as their native attribute identifiers. I would argue that using OIDs will only get us into a rat-hole of having to maintain mappings from OIDs to whatever the native name uses. Instead I would propose using a URN which both provides a structured and managed namespace aswell as including the OID namespace by reference. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEs7kr8Jx8FtbMZncRAlY0AJsGtSFGPnq7mtm4NRmX0LWYLX2wiwCfRld2 fJROBLmDPaiDQqS99w2YZWg= =X0q2 -----END PGP SIGNATURE----- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Jul 11 11:41:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0KMC-0005F6-Te; Tue, 11 Jul 2006 11:41:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0KMB-0005E3-Kf for kitten@ietf.org; Tue, 11 Jul 2006 11:41:03 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0KCl-0008Fk-Uy for kitten@ietf.org; Tue, 11 Jul 2006 11:31:21 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6BFVIiq018963 for ; Tue, 11 Jul 2006 08:31:19 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k6BFVI5m011760 for ; Tue, 11 Jul 2006 09:31:18 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k6BFVINE024206; Tue, 11 Jul 2006 10:31:18 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k6BFVHWS024205; Tue, 11 Jul 2006 10:31:17 -0500 (CDT) Date: Tue, 11 Jul 2006 10:31:17 -0500 From: Nicolas Williams To: Leif Johansson Message-ID: <20060711153117.GB21538@binky.Central.Sun.COM> Mail-Followup-To: Leif Johansson , kitten@ietf.org References: <44B3B92B.5000309@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B3B92B.5000309@it.su.se> User-Agent: Mutt/1.5.11 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: kitten@ietf.org Subject: Re: naming attributes 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: , Errors-To: kitten-bounces@lists.ietf.org On Tue, Jul 11, 2006 at 04:43:55PM +0200, Leif Johansson wrote: > During the wg yesterday I was asked to forward my comments regarding > naming attributes to the list. > > As far as I understand the point of the naming api extension is to > treat a name as an opaque extracting name attributes by attribute > identifier. There are several obvious examples of objects which could > be exposed by this api: X509 certs EKUs, SAML assertions, RDF graphs, > LDAP entries etc. > > My problem is with the choice of OIDs as name attribute identifiers > is that several of the obvious examples don't use OIDs as their > native attribute identifiers. I would argue that using OIDs will > only get us into a rat-hole of having to maintain mappings from > OIDs to whatever the native name uses. Instead I would propose > using a URN which both provides a structured and managed namespace > aswell as including the OID namespace by reference. OTOH there are several obvious examples that do use OIDs as their native attribute identifier (SANs, EKUs). What to do? The API being proposed is not a protocol, and its attribute identifiers aren't used on the wire as an inherent result of their use in the API (though where they map directly to actual uses on the wire specified in other protocols then their use in the API will relate to their use on the wire). So it doesn't really matter what these identifiers are. They could be anything, even octet strings, provided that we can reasonably manage a) the namespace of attribute identifiers, b) the mapping between specific instances of attribute identifiers and the things they map to. The GSS-API uses OIDs for other things, so it seemed natural to use those here. From an application developer's p.o.v. what matters is that the OIDs have symbolic names (GSS_C_...) so that application developers don't have to know the specific forms of these identifiers. So, from an API design p.o.v., as long as we have symbolic names for them then we shouldn't care whether we use OIDs or URNs or whatever. But I see no advantage to URNs over OIDs. There will be cases where the attribute identifiers in the API could map directly onto protocol-level identifiers, and there will be cases where they may not. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Jul 11 12:11:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Kp4-0000ve-9i; Tue, 11 Jul 2006 12:10:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Kp3-0000vZ-3G for kitten@ietf.org; Tue, 11 Jul 2006 12:10:53 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Kp1-00045W-Mm for kitten@ietf.org; Tue, 11 Jul 2006 12:10:53 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id SAA12437; Tue, 11 Jul 2006 18:10:37 +0200 (MESZ) From: Martin Rex Message-Id: <200607111610.SAA13514@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Tue, 11 Jul 2006 18:10:34 +0200 (MET DST) In-Reply-To: <20060711153117.GB21538@binky.Central.Sun.COM> from "Nicolas Williams" at Jul 11, 6 10:31:17 am 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: 538aad3a3c4f01d8b6a6477ca4248793 Cc: kitten@ietf.org Subject: Re: naming attributes 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: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > On Tue, Jul 11, 2006 at 04:43:55PM +0200, Leif Johansson wrote: > > As far as I understand the point of the naming api extension is to > > treat a name as an opaque extracting name attributes by attribute > > identifier. There are several obvious examples of objects which could > > be exposed by this api: X509 certs EKUs, SAML assertions, RDF graphs, > > LDAP entries etc. > > > > My problem is with the choice of OIDs as name attribute identifiers > > is that several of the obvious examples don't use OIDs as their > > native attribute identifiers. I would argue that using OIDs will > > only get us into a rat-hole of having to maintain mappings from > > OIDs to whatever the native name uses. Instead I would propose > > using a URN which both provides a structured and managed namespace > > aswell as including the OID namespace by reference. URN might be somewhat self-descriptive, OIDs are never self-descriptive. OTOH, OIDs are fairly small/short comparison of OIDs is foolproof and OIDs themselves do not have any I18N/L10N issues (attribute values may still have them). It should be fairly easy to assign OIDs for attribute identifiers that do not have them yet in the IETF GSS-API OID-space. However, independent of what one choses, I don't see a way to save application programmers from maintaining a mapping, because semantics and code to process particular attributes will have to be programmed, no matter what. btw. some of the attributes may not be single instances, but instead come in sets or sequences. How is the set/sequence traversed, and what about the ordering of a sequence (i.e. sets should be distinguishable from sequences at the API level). > > So, from an API design p.o.v., as long as we have symbolic names for > them then we shouldn't care whether we use OIDs or URNs or whatever. > > But I see no advantage to URNs over OIDs. There will be cases where the > attribute identifiers in the API could map directly onto protocol-level > identifiers, and there will be cases where they may not. The only conceivable advantage is the ease for vendors to come up with private extensions that are somewhat self-descriptive. It is likely a small Google-advantage if you need to find the spec. For the existing GSS-API architecture, OID-based tags are the more consistent fit, and I would prefer them. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Jul 11 13:05:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Lfj-0006Wk-Fx; Tue, 11 Jul 2006 13:05:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Lfi-0006VZ-6C for kitten@ietf.org; Tue, 11 Jul 2006 13:05:18 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Lfg-0007SM-NI for kitten@ietf.org; Tue, 11 Jul 2006 13:05:18 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id C80D93BE7E; Tue, 11 Jul 2006 19:05:15 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28618-01-38; Tue, 11 Jul 2006 19:05:15 +0200 (CEST) Received: from [132.219.15.185] (unknown [132.219.15.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 789DD3BE30; Tue, 11 Jul 2006 19:05:14 +0200 (CEST) Message-ID: <44B3DA52.6020303@it.su.se> Date: Tue, 11 Jul 2006 19:05:22 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: martin.rex@sap.com References: <200607111610.SAA13514@uw1048.wdf.sap.corp> In-Reply-To: <200607111610.SAA13514@uw1048.wdf.sap.corp> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.662 tagged_above=-99 required=7 tests=[AWL=0.003, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: kitten@ietf.org, Nicolas Williams Subject: Re: naming attributes 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: , Errors-To: kitten-bounces@lists.ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Rex wrote: > Nicolas Williams wrote: >> On Tue, Jul 11, 2006 at 04:43:55PM +0200, Leif Johansson wrote: >>> As far as I understand the point of the naming api extension is to >>> treat a name as an opaque extracting name attributes by attribute >>> identifier. There are several obvious examples of objects which could >>> be exposed by this api: X509 certs EKUs, SAML assertions, RDF graphs, >>> LDAP entries etc. >>> >>> My problem is with the choice of OIDs as name attribute identifiers >>> is that several of the obvious examples don't use OIDs as their >>> native attribute identifiers. I would argue that using OIDs will >>> only get us into a rat-hole of having to maintain mappings from >>> OIDs to whatever the native name uses. Instead I would propose >>> using a URN which both provides a structured and managed namespace >>> aswell as including the OID namespace by reference. > > URN might be somewhat self-descriptive, OIDs are never self-descriptive. > OTOH, OIDs are fairly small/short comparison of OIDs is foolproof and > OIDs themselves do not have any I18N/L10N issues (attribute values may still > have them). > > It should be fairly easy to assign OIDs for attribute identifiers that > do not have them yet in the IETF GSS-API OID-space. > > > However, independent of what one choses, I don't see a way to save > application programmers from maintaining a mapping, because semantics > and code to process particular attributes will have to be programmed, > no matter what. Not true. In the SAML-assertion wrapping case the api could use an underlying SAML-api which extracts attribute values based on URNs. No mappings there. > > btw. some of the attributes may not be single instances, but instead > come in sets or sequences. How is the set/sequence traversed, and > what about the ordering of a sequence (i.e. sets should be distinguishable > from sequences at the API level). > >> So, from an API design p.o.v., as long as we have symbolic names for >> them then we shouldn't care whether we use OIDs or URNs or whatever. >> >> But I see no advantage to URNs over OIDs. There will be cases where the >> attribute identifiers in the API could map directly onto protocol-level >> identifiers, and there will be cases where they may not. Note that URNs include OIDs by reference so using URNs don't preclude using OIDs. I guess what I am arguing for is both to include a larger namespace and thereby to avoid having to define attribute semantics in many cases. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEs9pS8Jx8FtbMZncRAgNWAJ42erXJubZ43H1P1yrFYkXUCSilXACeLbQA kHhjN9R8VCQoPfPxIVK08u4= =fqRo -----END PGP SIGNATURE----- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Jul 11 13:28:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0M2M-0005kF-UE; Tue, 11 Jul 2006 13:28:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0M2K-0005fv-UC for kitten@ietf.org; Tue, 11 Jul 2006 13:28:40 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0M2J-00013U-I6 for kitten@ietf.org; Tue, 11 Jul 2006 13:28:40 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA09903; Tue, 11 Jul 2006 19:28:27 +0200 (MESZ) From: Martin Rex Message-Id: <200607111728.TAA15755@uw1048.wdf.sap.corp> To: leifj@it.su.se (Leif Johansson) Date: Tue, 11 Jul 2006 19:28:25 +0200 (MET DST) In-Reply-To: <44B3DA52.6020303@it.su.se> from "Leif Johansson" at Jul 11, 6 07:05:22 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: naming attributes 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: , Errors-To: kitten-bounces@lists.ietf.org Leif Johansson wrote: > > > > > However, independent of what one choses, I don't see a way to save > > application programmers from maintaining a mapping, because semantics > > and code to process particular attributes will have to be programmed, > > no matter what. > > Not true. In the SAML-assertion wrapping case the api could use an > underlying SAML-api which extracts attribute values based on URNs. > No mappings there. I don't understand. We were discussing what the application caller above GSS-API will have to supply, and if the application caller cares at all about a particular attribute, it will have to implement semantics to interpret attribute values. Your descriptions sounds like an implementation detail how the GSS-API layer passes down the request for an attribute into an underlying SAML-api. What you seem to be calling for is the possibility to transfer native labeling and attribute values between a knowing application and a particular mechanism below GSS-API and not have to go through an additional abstraction layer (which would require mapping). Basically, you seen to be looking for a common API call rather than a real abstraction (which could, in theory, provide some level of portability/independence of the nature of the attribute). One requirement for a working abstraction would be that the attribute tags are all of the same type (OIDs would be best), and attribute values should have a compatible representation (i.e. octet string), canonical encoding and can be processed in an opaque fashion (equal or not equal in the octet string representation). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Jul 11 13:48:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0MLS-0001D7-Pb; Tue, 11 Jul 2006 13:48:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0MLS-0001Cv-A7 for kitten@ietf.org; Tue, 11 Jul 2006 13:48:26 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0MLQ-0003XY-Sa for kitten@ietf.org; Tue, 11 Jul 2006 13:48:26 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 738CE3BE2F; Tue, 11 Jul 2006 19:48:24 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31205-01-20; Tue, 11 Jul 2006 19:48:24 +0200 (CEST) Received: from [132.219.15.185] (unknown [132.219.15.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 3DA5D3BE2C; Tue, 11 Jul 2006 19:48:23 +0200 (CEST) Message-ID: <44B3E46E.5030301@it.su.se> Date: Tue, 11 Jul 2006 19:48:30 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: martin.rex@sap.com References: <200607111728.TAA15755@uw1048.wdf.sap.corp> In-Reply-To: <200607111728.TAA15755@uw1048.wdf.sap.corp> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.663 tagged_above=-99 required=7 tests=[AWL=0.002, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: naming attributes 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: , Errors-To: kitten-bounces@lists.ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Rex wrote: > Leif Johansson wrote: >>> However, independent of what one choses, I don't see a way to save >>> application programmers from maintaining a mapping, because semantics >>> and code to process particular attributes will have to be programmed, >>> no matter what. >> Not true. In the SAML-assertion wrapping case the api could use an >> underlying SAML-api which extracts attribute values based on URNs. >> No mappings there. > > I don't understand. > We were discussing what the application caller above GSS-API will > have to supply, and if the application caller cares at all about > a particular attribute, it will have to implement semantics to > interpret attribute values. True. > > Your descriptions sounds like an implementation detail how the > GSS-API layer passes down the request for an attribute into > an underlying SAML-api. > In several interesting cases I'm arguing that the GSS naming api could be a very light shim-layer to an underlying api, yes. I argue that adding the requirement to manage a potentially large attribute mapping table is something which would be nice to avoid. > What you seem to be calling for is the possibility to transfer native > labeling and attribute values between a knowing application and > a particular mechanism below GSS-API and not have to go through > an additional abstraction layer (which would require mapping). > I am hoping that the GSSAPI naming api won't have to redefine a large set of attributes which has been defined in several other forms already, including LDAP and SAML. > > Basically, you seen to be looking for a common API call rather > than a real abstraction (which could, in theory, provide some level > of portability/independence of the nature of the attribute). > One requirement for a working abstraction would be that the > attribute tags are all of the same type (OIDs would be best), > and attribute values should have a compatible representation > (i.e. octet string), canonical encoding and can be processed > in an opaque fashion (equal or not equal in the octet string > representation). > > > -Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEs+Ru8Jx8FtbMZncRAiSoAKCUlsfBOY3jGIhgcRt2s9ufB/iKcgCfUnCu NsSh1i/3gSdaKDatW1iaQJQ= =kSoe -----END PGP SIGNATURE----- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jul 12 13:34:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iba-0008VS-4r; Wed, 12 Jul 2006 13:34:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ibZ-0008VN-6M for kitten@ietf.org; Wed, 12 Jul 2006 13:34:33 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0ibX-0000Mb-BB for kitten@ietf.org; Wed, 12 Jul 2006 13:34:33 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6CHYRHL021638 for ; Wed, 12 Jul 2006 11:34:27 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k6CHVioY005358 for ; Wed, 12 Jul 2006 11:31:44 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k6CHYQJG025684; Wed, 12 Jul 2006 12:34:26 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k6CHYQrM025683; Wed, 12 Jul 2006 12:34:26 -0500 (CDT) Date: Wed, 12 Jul 2006 12:34:26 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060712173426.GM21538@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , leifj@it.su.se, kitten@ietf.org References: <20060711153117.GB21538@binky.Central.Sun.COM> <200607111610.SAA13514@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607111610.SAA13514@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.11 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: kitten@ietf.org Subject: Re: naming attributes 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: , Errors-To: kitten-bounces@lists.ietf.org On Tue, Jul 11, 2006 at 06:10:34PM +0200, Martin Rex wrote: > However, independent of what one choses, I don't see a way to save > application programmers from maintaining a mapping, because semantics > and code to process particular attributes will have to be programmed, > no matter what. Mappings would be done mostly in the mechanism/mechglue. E.g., you might have a name attribute corresponding to "MS PAC" that gives you that PAC payload, but also name attrs corresponding to individual items therein; the application would be responsible only for knowing the attr symbolic names and the encoding of the values. > btw. some of the attributes may not be single instances, but instead > come in sets or sequences. How is the set/sequence traversed, and > what about the ordering of a sequence (i.e. sets should be distinguishable > from sequences at the API level). The draft has GSS_Get_name_attribute() output a SET OF values; the proposed C bindings of it outputs one value per-call and a boolean/counter ('more') to indicate that it should be called again to retrieve additional values. > > So, from an API design p.o.v., as long as we have symbolic names for > > them then we shouldn't care whether we use OIDs or URNs or whatever. > > > > But I see no advantage to URNs over OIDs. There will be cases where the > > attribute identifiers in the API could map directly onto protocol-level > > identifiers, and there will be cases where they may not. > > The only conceivable advantage is the ease for vendors to come up with > private extensions that are somewhat self-descriptive. It is likely > a small Google-advantage if you need to find the spec. That might actually be useful. Perhaps we should ask SAML weenies about this. > For the existing GSS-API architecture, OID-based tags are the more > consistent fit, and I would prefer them. I agree, but we should consider the attribute self-description angle. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jul 12 13:40:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ih5-0000nL-3R; Wed, 12 Jul 2006 13:40:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ih3-0000kH-Qe for kitten@ietf.org; Wed, 12 Jul 2006 13:40:13 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0ih1-0000rX-Ne for kitten@ietf.org; Wed, 12 Jul 2006 13:40:13 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6CHeAuT001078 for ; Wed, 12 Jul 2006 10:40:10 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k6CHbS1H007509 for ; Wed, 12 Jul 2006 11:37:28 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k6CHeApc025698; Wed, 12 Jul 2006 12:40:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k6CHeAmU025697; Wed, 12 Jul 2006 12:40:10 -0500 (CDT) Date: Wed, 12 Jul 2006 12:40:10 -0500 From: Nicolas Williams To: Leif Johansson Message-ID: <20060712174010.GN21538@binky.Central.Sun.COM> Mail-Followup-To: Leif Johansson , martin.rex@sap.com, kitten@ietf.org References: <200607111610.SAA13514@uw1048.wdf.sap.corp> <44B3DA52.6020303@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B3DA52.6020303@it.su.se> User-Agent: Mutt/1.5.11 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: kitten@ietf.org Subject: Re: naming attributes 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: , Errors-To: kitten-bounces@lists.ietf.org On Tue, Jul 11, 2006 at 07:05:22PM +0200, Leif Johansson wrote: > Note that URNs include OIDs by reference so using URNs don't preclude > using OIDs. There's no real good reason for using OIDs other than that they're already used in the GSS-API so they are an easy fit. > I guess what I am arguing for is both to include a larger namespace and > thereby to avoid having to define attribute semantics in many cases. That's unconvicing to me, but Martin's point about attribute identifier self-description may be. Think of an attribute identifier that tells you, essentially, how to extract some element of a larger structure delivered/authenticated by a mechanism. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jul 12 15:40:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kZ1-0008VA-VG; Wed, 12 Jul 2006 15:40:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kZ1-0008V5-9B for kitten@ietf.org; Wed, 12 Jul 2006 15:40:03 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0kYz-0004M6-Vs for kitten@ietf.org; Wed, 12 Jul 2006 15:40:03 -0400 Received: from [132.219.7.235] (h07eb-net84db.lab.risq.net [132.219.7.235] (may be forged)) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6CJdr5X003051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jul 2006 15:39:57 -0400 (EDT) Message-ID: <44B5504B.7000304@columbia.edu> Date: Wed, 12 Jul 2006 15:40:59 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Kitten , saag@mit.edu, Sam Hartman , housley@vigilsec.com X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: Subject: IETF66 Summary of Kitten WG Meeting 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="===============0598128836==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0598128836== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000808010102080507010002" This is a cryptographically signed message in MIME format. --------------ms000808010102080507010002 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The Kitten working group met at IETF66 on Monday afternoon session I. The presentation materials are available at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 The Audio Stream is available at http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf66/ietf66-ch7-mon-afnoon.mp3.1 The Jabber Logs are available at: http://www.ietf.org/meetings/ietf-logs/kitten/2006-07-10.html =================================================================================== Document Status and Proposed Milestones --------------------------------------- Desired Enhancements to GSSAPI Version 3 Naming - draft-ietf-kitten-gss-naming-04.txt - Sent to IESG GSS-API Domain-Based Service Names - draft-ietf-kitten-gssapi-domain-based-names-04.txt - Ready for Working Group Last Call [Send to IESG - August 2006] GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism - draft-ietf-kitten-krb5-gssapi-domain-based-names-02.txt - Ready for Working Group Last Call [Send to IESG - August 2006] GSS-APIv2 Extension for Storing Delegated Credentials - draft-williams-gssapi-store-deleg-creds [Send to IESG - August 2006] Extended Generic Security Service Mechanism Inquiry APIs - draft-ietf-kitten-extended-mech-inquiry-02.txt - Ready for Working Group Last Call [Send to IESG - September 2006] Stackable Generic Security Service Pseudo-Mechanisms - draft-ietf-kitten-gssapi-stackable-pseudo-mechs-02.txt - Ready for Working Group Last Call [Send to IESG - September 2006] Clarifications and Extensions to the GSS-API for the Use of Channel Bindings - draft-ietf-kitten-gssapi-channel-bindings-02.txt - Ready for WGLC; blocked on draft-ietf-nfsv4-channel-bindings-04.txt [Send to IESG - September 2006] Namespace Considerations and Registries for GSS-API Extensions - draft-williams-gssapi-extensions-iana [Send to IESG - November 2006] GSS-API Naming Extensions - draft-ietf-kitten-gssapi-naming-exts-02.txt - active work item [Identify Open Issues - March 2007] GSS-API Internationalization - draft not published [Initial Draft March 2007] Guide to the GSS-APIv3 - draft-williams-gssapi-v3-guide-to [no milestone] Clarifications to GSS-API Version 2 Update 1 - not yet published [Send to IESG - before IETF67] Generic Security Service API Version 2 : Java Bindings Update - draft-ietf-kitten-rfc2853bis-01.txt - Next draft -02 Ready for Last Call??? [Send to IESG - October 2006] GSS_API V2: C# Bindings - draft-ietf-kitten-gssapi-csharp-bindings-00.txt [no milestone] ========================================================================= Proposed Charter Revision ------------------------- Revise the charter to include addressing internationalization issues. ========================================================================= Technical Discussion -------------------- * Discussed how Kerberos 5 Anonymous Names can interact with GSS export name and display name functions * Discussed draft-ietf-kitten-gssapi-naming-exts-02.txt. Requires much expert review. A significant open issue is whether or not OIDs should be used to identify "names" extracted from authorization attributes. * --------------ms000808010102080507010002 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJWTCC AwcwggJwoAMCAQICEDgwMdSemBfcGd6HY5Q4qrwwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRt YW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmFluisw/ NLjjXSHm0kgAgAMBknaWpJyDQlTpyzSswiSaDWINyEUzM/teBosk003zfyQdPONkWzclBRZ+ oGsYsAgxmyRe9tAJD7Jo6xp/6kCuF5nnaIyz91gWyuYZEeqQrfyFnWIfQu3fuoSeEIMLc9ac L9qhqnaTwCufH4v56CMftv6KFdf/k1CoLu/DL0ps5UOVwui+8iSWn3Qt6QfefDp9vbtBFPTV nZ7wGeewUJrO1LEC+x3gAOW+KxUcZMBax7tVygT5hDaQXm5lxUrlMQ/hLeWpv7LkVPD/ytoJ NCNzSnycrK4juG1CI12m5K1TNHZJ1uYjb7DUvMwOl6kQiQIDAQABozEwLzAfBgNVHREEGDAW gRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB ACNK1Xef6H2YL02xqVthcdQgFuF0bENE1u7gX/hegF1awGERhaIJmKGWau4OiAeHnlFqWysP EFzVrSb6L+TF9YHd/bP8WtxccOFnZ1L6oe7KOiyNfXGPZKj/i7Gti+MF4RM1ReZncTC1zMmZ DbFkVhL92vSgDGl4+6IwzjmQVK3sMIIDBzCCAnCgAwIBAgIQODAx1J6YF9wZ3odjlDiqvDAN BgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDYwNTI3MjIwMzMyWhcNMDcwNTI3MjIwMzMyWjBrMQ8wDQYDVQQEEwZBbHRt YW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMTSmVmZnJleSBFcmljIEFsdG1h bjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCYWW6KzD80uONdIebSSACAAwGSdpaknINCVOnLNKzCJJoNYg3I RTMz+14GiyTTTfN/JB0842RbNyUFFn6gaxiwCDGbJF720AkPsmjrGn/qQK4XmedojLP3WBbK 5hkR6pCt/IWdYh9C7d+6hJ4Qgwtz1pwv2qGqdpPAK58fi/noIx+2/ooV1/+TUKgu78MvSmzl Q5XC6L7yJJafdC3pB958On29u0EU9NWdnvAZ57BQms7UsQL7HeAA5b4rFRxkwFrHu1XKBPmE NpBebmXFSuUxD+Et5am/suRU8P/K2gk0I3NKfJysriO4bUIjXabkrVM0dknW5iNvsNS8zA6X qRCJAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAI0rVd5/ofZgvTbGpW2Fx1CAW4XRsQ0TW7uBf+F6A XVrAYRGFogmYoZZq7g6IB4eeUWpbKw8QXNWtJvov5MX1gd39s/xa3Fxw4WdnUvqh7so6LI19 cY9kqP+Lsa2L4wXhEzVF5mdxMLXMyZkNsWRWEv3a9KAMaXj7ojDOOZBUrewwggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECEDgwMdSemBfcGd6HY5Q4qrwwCQYFKw4DAhoFAKCCAcMw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNzEyMTk0MDU5 WjAjBgkqhkiG9w0BCQQxFgQUI0nbnpe5psJvalSooVg8/g2L64AwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA4MDHUnpgX3Bneh2OUOKq8MIGHBgsqhkiG9w0B CRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA4MDHUnpgX3Bneh2OUOKq8MA0GCSqGSIb3DQEBAQUABIIBAArn1CyBKzBkbV7TDNUWYEwC TvQ3dHptROtRxevSIhLJtJiwezvyK00C/7a+ATnkDH6wWdjyqOBlYQTGeyjRHzpiv/P22Myx 4wcNH0kk9LHo0IFG3/Yjq63RI0NojHbgVi9Q1Ssa9maiS7UyXPXsYyzyMo00ogq1RAnDw1xG /WQotGmVR2tWF4Ywd5S0gI/K2i0yb/eOJnLRusCYEriIdtfICaInKlD5/6mpVRwLPcONeNCR Fq4p7FwWQjusE9zbNgQYBcpf4Xu8NQyT8Zuc4XNOBcC4+K8qKBk4PtDktABFHfhsvCs+zIFr weMMSjs2el1ktSNM4WywRLvsabxl5YwAAAAAAAA= --------------ms000808010102080507010002-- --===============0598128836== 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 --===============0598128836==-- From kitten-bounces@lists.ietf.org Fri Jul 28 15:59:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6YUy-0006To-L3; Fri, 28 Jul 2006 15:59:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6YUo-0005mp-B4; Fri, 28 Jul 2006 15:59:42 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6YUn-0007IP-2h; Fri, 28 Jul 2006 15:59:42 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6SJo1p0023411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jul 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G6YLR-0003z5-Kl; Fri, 28 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 28 Jul 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: kitten@lists.ietf.org Subject: I-D ACTION:draft-ietf-kitten-gssapi-domain-based-names-02.txt 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: , Errors-To: kitten-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : GSS-API Domain-Based Service Names and Name Type Author(s) : N. Williams Filename : draft-ietf-kitten-gssapi-domain-based-names-02.txt Pages : 11 Date : 2006-7-28 This document describes domainname-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API). Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) instead of or in addition to a hostname. The primary purpose of domain-based service names is to provide a way to name clustered services after the domain which they service, thereby allowing their clients to authorize the service's servers based on authentication of their names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-domain-based-names-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-kitten-gssapi-domain-based-names-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-gssapi-domain-based-names-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-28105835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-gssapi-domain-based-names-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-domain-based-names-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-28105835.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From kitten-bounces@lists.ietf.org Sat Jul 29 16:40:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6vbd-0004vt-45; Sat, 29 Jul 2006 16:40:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6vbc-0004vo-N6 for kitten@ietf.org; Sat, 29 Jul 2006 16:40:16 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6vbb-0003pw-H3 for kitten@ietf.org; Sat, 29 Jul 2006 16:40:16 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B41D0E007D; Sat, 29 Jul 2006 16:40:57 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org, ietf-pkix@imc.org Date: Sat, 29 Jul 2006 16:40:57 -0400 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.2 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: Request to review draft-adamson-rfc2847-bis 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: , Errors-To: kitten-bounces@lists.ietf.org Hi, folks. There is a request to replace the SPKM3 and LIPKI gssapi mechanisms I've recieved. I would appreciate it if people familiar with GSS-API or PKIX could take a look at this draft and send me comments by August 14, 2006. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten