From owner-ietf-cat-wg@lists.Stanford.EDU Fri Jun 2 23:06:23 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21091 for ; Fri, 2 Jun 2000 23:06:22 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id TAA26695 for ietf-cat-wg-out720680; Fri, 2 Jun 2000 19:03:54 -0700 (PDT) Received: from dcl.mit.edu (DCL.MIT.EDU [18.172.1.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id TAA26689 for ; Fri, 2 Jun 2000 19:03:51 -0700 (PDT) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id WAA03140; Fri, 2 Jun 2000 22:03:49 -0400 (EDT) Date: Fri, 2 Jun 2000 22:03:49 -0400 (EDT) Message-Id: <200006030203.WAA03140@dcl.mit.edu> From: Ken Raeburn To: bcn@isi.edu Cc: krb-protocol@mit.edu, ietf-cat-wg@lists.Stanford.EDU Subject: kerberos-revisions: krb_priv and initialization vectors Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk The RFC1510 description of KRB_PRIV provides for the possibility of using a non-default IVEC -- which "might come from the last block of the ciphertext from the previous KRB_PRIV message" but is not required to -- at the application's request when encrypting KRB_PRIV messages. The kerberos-revisions draft says no such thing. The descriptions of the cryptosystems generally indicate the IVEC that "must" be used if another one isn't specified, which implies that KRB_PRIV *must* use the default IVEC always. Is this an intentional new restriction? Relating to this-- * The 3des-kd definition gives "ciphertext" as the encryption output plus the hash value. The "glossary of terms" defines ciphertext as the output of encryption. Either we need to use a different term, or define it so as to make it clear that more than simple encrypted bits may be included. * Since the "ciphertext", when it includes a checksum, may not be a multiple of the basic encryption algorithm's block size, it can't be divided into full-sized blocks. So "last block of the ciphertext" isn't a very precisely defined term anyways at this point. I would take it to mean the last octets, but implicit in that is the notion that you're counting "blocks" from the end, not the beginning. Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jun 6 12:33:10 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13828 for ; Tue, 6 Jun 2000 12:33:07 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA18725 for ietf-cat-wg-out720680; Tue, 6 Jun 2000 08:58:03 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id IAA18718 for ; Tue, 6 Jun 2000 08:58:00 -0700 (PDT) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13195 for ; Tue, 6 Jun 2000 08:57:59 -0700 (PDT) Received: from elephant.West.Sun.COM (elephant.West.Sun.COM [129.153.12.10]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA28017 for ; Tue, 6 Jun 2000 08:57:56 -0700 (PDT) Received: from elvira.west.sun.com (elvira [129.153.12.13]) by elephant.West.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id IAA27360 for ; Tue, 6 Jun 2000 08:56:31 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.west.sun.com by elvira.west.sun.com (PMDF V6.0-24 #43970) id <0FVQ00901PO279@elvira.west.sun.com> for ietf-cat-wg@lists.Stanford.EDU; Tue, 06 Jun 2000 08:57:38 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by elvira.west.sun.com (PMDF V6.0-24 #43970) with ESMTPA id <0FVQ0040FPNX19@elvira.west.sun.com>; Tue, 06 Jun 2000 08:57:38 -0700 (PDT) Date: Mon, 05 Jun 2000 21:51:30 -0700 From: Chris Newman Subject: RE: SASL GSSAPI draft In-reply-to: To: "Linn, John" , "'Ken Hornstein'" , jgmyers@netscape.com Cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Message-id: <850698.3169230690@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit Content-disposition: inline Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit --On Tuesday, May 30, 2000 9:52 -0400 "Linn, John" wrote: > It's certainly true that an SPNEGO token won't be usefully processable by > a target which doesn't support SPNEGO. If, however, a GSS implementation > can support GSS_MECH_A and GSS_MECH_B negotiated under SPNEGO, and that > GSS implementation is being used with SASL, it may not be too much > incremental effort to make GSS_MECH_A and GSS_MECH_B also available for > negotiation at the SASL level. There's a security vs. interoperability > tradeoff, since the SPNEGO negotiation is protected but the SASL > negotiation isn't. I'd suggest recommending, not discouraging, support > for SPNEGO for use where available and appropriate, but also recommending > configurable support to allow negotiation of individual GSS mechanisms at > the SASL level. Some problems with recommending SPNEGO in SASL: There are standards-compliant email servers deployed which only support Kerberos 5 (GSSAPI SASL) and don't support SPNEGO. Any email server which only advertises GSS-SPNEGO (not yet standardized) and not GSSAPI (standards track) for Kerberos 5 support is hostile both to the installed base of standards-compliant servers and to the deployment of Kerberos 5. If admins encounter an interop problem when trying to upgrade security, the first thing they usually do is back out the security upgrade. We don't want that to happen. I suspect the protection provided by SPNEGO will be irrelevant to most SASL-based protocols in practice because they'll get integrity protection from either TLS or IPsec prior to the SASL negotiation if they want it at all. So it just doesn't seem to be worth the extra round trip(s), IMHO. > If an application client (and its associated SASL and/or SPNEGO client) > supports policy-driven mechanism negotiation, the preferred set might (1) > span both GSS and non-GSS SASL mechanisms or (2) might be GSS mechanisms > only, with non-GSS SASL mechanisms to be invoked only as a fallback if > none of the GSS mechanisms are available. If (1), the client is most > easily served by performing the negotiation (and exposing the individual > GSS mechanisms) at the SASL level. Given the prospect of (2), however, > it'd be good to be able to negotiate among the available GSS mechanisms > in an SPNEGO-protected manner. I'm very uncomfortable with options in security protocols. Every option can double the complexity of a security analysis of the software. I suspect that any benefit gained by making SPNEGO an option will be outweighed by the cost of a security analysis of both codepaths and the interaction between various security polices and SPNEGO/SASL mechanism lists. - Chris -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jun 6 19:27:23 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20548 for ; Tue, 6 Jun 2000 19:27:21 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA13387 for ietf-cat-wg-out720680; Tue, 6 Jun 2000 15:57:47 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id PAA13382 for ; Tue, 6 Jun 2000 15:57:45 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e56MnuO13657 for ; Tue, 6 Jun 2000 15:49:56 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVR93C00.HR0; Tue, 6 Jun 2000 15:57:12 -0700 Message-ID: <393D812E.8D123B88@netscape.com> Date: Tue, 06 Jun 2000 15:54:38 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <200005300336.e4U3aDt00689@ginger.cmf.nrl.navy.mil> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7A4108F79C32C4FD17956951" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms7A4108F79C32C4FD17956951 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ken Hornstein wrote: > Okay, I saw only a message from Bill Ricker asking about SPNEGO, > posting by you, and Paul Leach's reply. I recall some other exchange when I first published a draft, but haven't located it. It doesn't much matter, we're having a good discussion about this now. > Having said that .... I > think that a client that sent a SPNEGO token to a SPNEGO-unaware > server would fail. I have been thinking for a while on how to > migrate to clients & servers supporting SPNEGO, and I haven't come > up with any good ideas yet (if I'm missing something obvious, then > please let me know). I don't think you can make this work and maintain SPNEGO's security requirement to protect the negotiation of mechanism. A man in the middle could make it appear to each side that the other does not support SPNEGO, thus forcing a downgrade to the weakest mechanism. If you are willing to take this risk, forgoing this property of SPNEGO, then the propsal to negoitate the mechanism directly through SASL instead of through SPNEGO is simpler. > This presumes that the app will have to have special-case code to > determine which mechanisms exist and to apply policy information > to the mechanism list; I'm not sure how you'll do that without > giving the app knowledge of each mechanism, which would kinda defeat > part of the purpose of GSSAPI. I have a hard time imaging this done > in practice (it seems that you can give SPNEGO some policy constraints, > but it doesn't give you the ability to do the ordering you want). Typically, a SASL library has both policy constrants and a mechanism preference ordering. Usually the preferences are ordered from strongest mechanism to weakest, but sometimes the cost of obtaining a credential affects this. For example, if the SASL library has a Kerberos credential available, it may want to use Kerberos over any mechanism that will need to prompt the user. --------------ms7A4108F79C32C4FD17956951 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwNjIyNTQzOVowIwYJKoZIhvcNAQkEMRYEFJFTsgpttt09 IoHjQ4t45VWOxQMlMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAYrx0vJLB5W0xTTs+3FYOyFqRMCSV8E/yQ15mr+XPU6XL F5ykhvMhCH2fIlKoSFrkdLzFCUKSg1hB/Ll26ZA/+ufPiViWbWE5CVDcm0K80vitFaB87wkN fhnUFr7ooXmIS2H8H7GpIMe4hhQlzWTyBigKVJ5BgSYAPDUoCJVgi6w= --------------ms7A4108F79C32C4FD17956951-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jun 6 19:53:48 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20785 for ; Tue, 6 Jun 2000 19:53:47 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA14812 for ietf-cat-wg-out720680; Tue, 6 Jun 2000 16:21:57 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id QAA14804 for ; Tue, 6 Jun 2000 16:21:55 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e56NHPw08709 for ; Tue, 6 Jun 2000 16:17:25 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVRA7O00.CTM; Tue, 6 Jun 2000 16:21:24 -0700 Message-ID: <393D876B.5DC135F2@netscape.com> Date: Tue, 06 Jun 2000 16:21:15 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Linn John" CC: "'Ken Hornstein'" , ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms44C1D113AC5AE39E0F921503" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms44C1D113AC5AE39E0F921503 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Linn, John" wrote: > There's a security vs. interoperability tradeoff, since the > SPNEGO negotiation is protected but the SASL negotiation isn't. The design criterion I've used in preparing the draft is that one should not trade away interoperability unless there exists a requirement in a site's security policy which is incompatible with that interoperability. > I'd suggest > recommending, not discouraging, support for SPNEGO for use where available > and appropriate, but also recommending configurable support to allow > negotiation of individual GSS mechanisms at the SASL level. The applicable requirement in the current draft is: In any case, there is no down-negotiation security consideration with using the strongest mechanism and set of options the implementation supports, so for interoperability that mechanism and set of options MUST be negotiable without using the "GSS-SPNEGO" mechanism. > If an application client (and its associated SASL and/or SPNEGO client) > supports policy-driven mechanism negotiation, the preferred set might (1) > span both GSS and non-GSS SASL mechanisms or (2) might be GSS mechanisms > only, with non-GSS SASL mechanisms to be invoked only as a fallback if none > of the GSS mechanisms are available. If (1), the client is most easily > served by performing the negotiation (and exposing the individual GSS > mechanisms) at the SASL level. Given the prospect of (2), however, it'd be > good to be able to negotiate among the available GSS mechanisms in an > SPNEGO-protected manner. If your security policy allows the negotiation of a weak mechanism outside of SPNEGO, then what benefit are you gaining from SPNEGO? An active attacker can make it appear that SPNEGO is not suppported by the other side, removing all benefit of SPNEGO over SASL mechainsm negotiation. This is why I discourage rather than encourage SPNEGO underneath SASL. Unless you have a security policy of allowing certain mechanisms only when their negotiation has been protected, the SPNEGO negotiation protection doesn't buy you anything. This particular security policy is explicitly mentioned in the draft as a reason to violate the SHOULD NOT directive against SPNEGO under SASL. --------------ms44C1D113AC5AE39E0F921503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwNjIzMjExNlowIwYJKoZIhvcNAQkEMRYEFNVm9y3JzG4m ZTtkVAIIRPY2eYc6MCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAmk9WHFo4eyYhkQ4ETuGpyANwwAcjbnn052pPoH0Ou4zD 4hFNvNZN9BSIjHnMMeMW4ZpkCeJQEAP9GFMpS3rIzZeoQXjQtRDUlOYvQbecH7rg9mDTybY+ q/3ASKEJM6yvcdChQQYg+Y29iCV2/J/r9pMhtdd4yTiLAHeQf+ITPwU= --------------ms44C1D113AC5AE39E0F921503-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Jun 8 12:52:19 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11889 for ; Thu, 8 Jun 2000 12:52:18 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA28604 for ietf-cat-wg-out720680; Thu, 8 Jun 2000 09:15:48 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id JAA28599 for ; Thu, 8 Jun 2000 09:15:46 -0700 (PDT) From: zainprov@swbell.net Received: from mta5.rcsntx.swbell.net by MIT.EDU with SMTP id AB02689; Thu, 8 Jun 00 12:15:34 EDT Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00DYUFPE39@mta5.rcsntx.swbell.net> for cat-ietf@mit.edu; Thu, 8 Jun 2000 11:14:38 -0500 (CDT) Date: Thu, 08 Jun 2000 11:14:38 -0500 (CDT) Date-Warning: Date header was inserted by mta5.rcsntx.swbell.net Subject: Shocking LOSE 10-100lbs. DESTINY To: cat-ietf@mit.edu Message-Id: <0FVU00D2JFSC39@mta5.rcsntx.swbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Jun 8 14:22:35 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13428 for ; Thu, 8 Jun 2000 14:22:34 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA00741 for ietf-cat-wg-out720680; Thu, 8 Jun 2000 09:54:40 -0700 (PDT) Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id JAA00728 for ; Thu, 8 Jun 2000 09:54:37 -0700 (PDT) From: zainprov@swbell.net Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00BPOEVXLQ@mta5.rcsntx.swbell.net> for ietf-cat-wg@lists.stanford.edu; Thu, 8 Jun 2000 11:05:58 -0500 (CDT) Date: Thu, 08 Jun 2000 11:05:58 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net Subject: Shocking LOSE 10-100lbs. DESTINY To: ietf-cat-wg@lists.Stanford.EDU Message-id: <0FVU00BF3FDWLQ@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Jun 8 14:50:14 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14045 for ; Thu, 8 Jun 2000 14:50:13 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA06167 for ietf-cat-wg-out720680; Thu, 8 Jun 2000 11:14:07 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA06150 for ; Thu, 8 Jun 2000 11:14:03 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA19990; Thu, 8 Jun 2000 11:14:02 -0700 (PDT) Message-Id: <200006081814.LAA19990@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2847 on LIPKEY Cc: rfc-ed@isi.edu, ietf-cat-wg@lists.Stanford.EDU Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 08 Jun 2000 11:14:02 -0700 From: RFC Editor Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2847 Title: LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM Author(s): M. Eisler Status: Standards Track Date: June 2000 Mailbox: mre@zambeel.com Pages: 22 Characters: 50045 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-cat-lipkey-03.txt URL: ftp://ftp.isi.edu/in-notes/rfc2847.txt This memorandum describes a method whereby one can use GSS-API [RFC2078] to supply a secure channel between a client and server, authenticating the client with a password, and a server with a public key certificate. As such, it is analogous to the common low infrastructure usage of the Transport Layer Security (TLS) protocol [RFC2246]. The method leverages the existing Simple Public Key Mechanism (SPKM) [RFC2025], and is specified as a separate GSS-API mechanism (LIPKEY) layered above SPKM. This document is a product of the Common Authentication Technology Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000608111128.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2847 --OtherAccess Content-Type: Message/External-body; name="rfc2847.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000608111128.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Jun 8 16:06:23 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15647 for ; Thu, 8 Jun 2000 16:06:22 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA09831 for ietf-cat-wg-out720680; Thu, 8 Jun 2000 12:43:26 -0700 (PDT) Received: from smtp-outgoing.amazon.com (smtp-outgoing.amazon.com [209.191.164.156]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA09826 for ; Thu, 8 Jun 2000 12:43:24 -0700 (PDT) Received: from mail-proxy-2.amazon.com (mail-proxy-2.amazon.com [10.16.42.202]) by smtp-outgoing.amazon.com (Postfix) with ESMTP id 456E465F; Thu, 8 Jun 2000 12:43:24 -0700 (PDT) Received: by mail-proxy-2.amazon.com id MAA09585; Thu, 8 Jun 2000 12:43:23 -0700 (PDT) Message-ID: <393FF694.4EEB1D21@amazon.com> Date: Thu, 08 Jun 2000 12:40:04 -0700 From: David Margrave Organization: Amazon.com, Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Myers Cc: Linn John , "'Ken Hornstein'" , ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <393D876B.5DC135F2@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit John Myers wrote: > > This is why I discourage rather than encourage SPNEGO underneath SASL. > Unless you have a security policy of allowing certain mechanisms only > when their negotiation has been protected, the SPNEGO negotiation > protection doesn't buy you anything. This particular security policy is > explicitly mentioned in the draft as a reason to violate the SHOULD NOT > directive against SPNEGO under SASL. As long as major applications, like say LDAP or IMAP for example, are in love with SASL (Honestly, do you blame them? Good grief, look at the prototype for gss_init_sec_context() some time!), don't you think it's worthwhile to at least go to the effort to add a modicum of real security to it? I mean, the only SASL mech worth a darn security-wise at the moment is GSS-API. I struggled with this for a while, then realized that if both sides really want a secure connection, then can simply decide they're only going to support one SASL mech (GSS KRB5), and that SASL+GSS is simply GSS (real security) with a few extra bytes of cruft (SASL) in front of the GSS token. Everybody is happy, everybody wins. So I would think that an SPNEGO SASL mech would be a good thing, because well-designed implementations of application protocols could be configured to only support one SASL mech (SPNEGO), so that we get real negotiation of a security protocol (SPNEGO) with a few extra bytes of cruft (SASL) wrapped around it. Its the cases where you'd say "I'll support SPNEGO and cleartext passwords as my SASL mechs", and the man-in-the-middle says "Okay, lets do cleartext passwords" that you would want to avoid by policy configuration. I believe that the best we can hope for is that SASL and SPNEGO(GSS) toolkits will play nice together so that SASL (which isn't going away) will support SPNEGO as an available option in the vast majority of implementations. Dave -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Sun Jun 11 16:39:50 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09442 for ; Sun, 11 Jun 2000 16:39:49 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA16146 for ietf-cat-wg-out720680; Sun, 11 Jun 2000 13:10:55 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA16141 for ; Sun, 11 Jun 2000 13:10:53 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5BK2uO27255 for ; Sun, 11 Jun 2000 13:02:57 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FW0AP900.VMG; Sun, 11 Jun 2000 13:10:21 -0700 Message-ID: <3943F14C.DD447F74@netscape.com> Date: Sun, 11 Jun 2000 13:06:39 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU CC: ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <393D876B.5DC135F2@netscape.com> <393FF694.4EEB1D21@amazon.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms21CF901E3143C20952D5E60F" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms21CF901E3143C20952D5E60F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Margrave wrote: > As long as major applications, like say LDAP or IMAP for example, are in love > with SASL [...] don't you think it's worthwhile to at least > go to the effort to add a modicum of real security to it? I mean, the only > SASL mech worth a darn security-wise at the moment is GSS-API. Personally, I think DIGEST-MD5 [RFC 2831] has an acceptable level of security. One cannot simply "add security" by throwing in cryptographic protocols wherever they are convenient. One has to form a threat model, devise security policies to address the modeled threats, and evaluate an implementation of those policies as a whole against said threats. To claim that SPNEGO adds "a modicum of real security" to SASL, one must show how the combination implements security policies to thwart which classes of threats. > I struggled > with this for a while, then realized that if both sides really want a secure > connection, then can simply decide they're only going to support one > SASL mech (GSS KRB5), and that SASL+GSS is simply GSS (real security) with a few > extra bytes of cruft (SASL) in front of the GSS token. Everybody is happy, > everybody wins. If both sides are configured to only support GSS KRB5, then what threat does the addition of SPNEGO protect against? > So I would think that an SPNEGO SASL mech would be a good thing, because > well-designed implementations of application protocols could be configured to > only support one SASL mech (SPNEGO), so that we get real negotiation of a > security protocol (SPNEGO) with a few extra bytes of cruft (SASL) wrapped around > it. Please address how a client supporting only Kerberos V5 underneath SPNEGO underneath SASL would interoperate with a server supporting only Kerberos V5 underneath SASL. --------------ms21CF901E3143C20952D5E60F Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxMTIxMDYzOVowIwYJKoZIhvcNAQkEMRYEFECGK2rIFaYz gUHEOxvvx5s335cgMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAu2Hn9VULwy420FZcuKsI6apbxImmNNecnjWzQ0stEBlWp0u6xfEv9PrpBOGz1S/1 aCfp1UkE+VRJf+AuX+p/oE0m2mUwn1e0TopGpW1cBOAQ6f6bGapmY1Hnt1B4eEcIpY6KHiN6 lbb3mtpU1qEC301cAKrznisXJrRWAPLi478= --------------ms21CF901E3143C20952D5E60F-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jun 12 00:42:14 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14028 for ; Mon, 12 Jun 2000 00:42:14 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id VAA23990 for ietf-cat-wg-out720680; Sun, 11 Jun 2000 21:07:49 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id VAA23985 for ; Sun, 11 Jun 2000 21:07:47 -0700 (PDT) Received: from cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.5.3]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e5C47hh14236; Mon, 12 Jun 2000 00:07:43 -0400 (EDT) Message-Id: <200006120407.e5C47hh14236@ginger.cmf.nrl.navy.mil> To: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft In-reply-to: Your message of "Sun, 11 Jun 2000 13:06:39 PDT." <3943F14C.DD447F74@netscape.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 12 Jun 2000 00:07:42 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >> So I would think that an SPNEGO SASL mech would be a good thing, because >> well-designed implementations of application protocols could be configured to >> only support one SASL mech (SPNEGO), so that we get real negotiation of a >> security protocol (SPNEGO) with a few extra bytes of cruft (SASL) wrapped around >> it. > >Please address how a client supporting only Kerberos V5 underneath >SPNEGO underneath SASL would interoperate with a server supporting only >Kerberos V5 underneath SASL. You keep bringing up these mythical "only Kerberos V5 underneath SPNEGO" implementations. Even if you're doing SPNEGO, you still have to parse V5 GSSAPI tokens; I can't really imagine a reason why you would not be able to handle a V5 GSSAPI token exchange without SPNEGO. I don't think this is a legitimate reason for recommending against the use of SPNEGO. I am still undecided on this issue; maybe it is right to not recommend the use of SPNEGO with SASL, but I don't think this is a valid reason. --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jun 12 13:54:13 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07856 for ; Mon, 12 Jun 2000 13:54:12 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA09427 for ietf-cat-wg-out720680; Mon, 12 Jun 2000 10:23:12 -0700 (PDT) Received: from smtp3.andrew.cmu.edu (SMTP3.ANDREW.CMU.EDU [128.2.10.83]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id KAA09422 for ; Mon, 12 Jun 2000 10:23:09 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp3.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id NAA23410; Mon, 12 Jun 2000 13:23:04 -0400 (EDT) Date: Mon, 12 Jun 2000 13:23:04 -0400 (EDT) Message-Id: <200006121723.NAA23410@smtp3.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Cc: Ken Hornstein In-reply-to: <200006120407.e5C47hh14236@ginger.cmf.nrl.navy.mil> Subject: Re: SASL GSSAPI draft References: <200006120407.e5C47hh14236@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Date: Mon, 12 Jun 2000 00:07:42 -0400 From: Ken Hornstein [...] You keep bringing up these mythical "only Kerberos V5 underneath SPNEGO" implementations. Even if you're doing SPNEGO, you still have to parse V5 GSSAPI tokens; I can't really imagine a reason why you would not be able to handle a V5 GSSAPI token exchange without SPNEGO. I don't think this is a legitimate reason for recommending against the use of SPNEGO. If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition to SPNEGO, no additional security is obtained via SPNEGO (the active attacks that SPNEGO prevents are just circumvented by removing SPNEGO from the capabilities line). Thus, it only makes sense to support SPNEGO/Krb5 if it is going to be used without advertising/allowing Krb5 without SPNEGO---which leads to the interoperability problems. Larry -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jun 12 18:08:46 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12122 for ; Mon, 12 Jun 2000 18:08:45 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA19322 for ietf-cat-wg-out720680; Mon, 12 Jun 2000 14:37:25 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA19315 for ; Mon, 12 Jun 2000 14:37:22 -0700 (PDT) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e5CLbHh21208; Mon, 12 Jun 2000 17:37:17 -0400 (EDT) Message-Id: <200006122137.e5CLbHh21208@ginger.cmf.nrl.navy.mil> To: ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Subject: Re: SASL GSSAPI draft In-reply-to: Your message of "Mon, 12 Jun 2000 13:23:04 EDT." <200006121723.NAA23410@smtp3.andrew.cmu.edu> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 12 Jun 2000 17:37:16 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > You keep bringing up these mythical "only Kerberos V5 underneath > SPNEGO" implementations. Even if you're doing SPNEGO, you still > have to parse V5 GSSAPI tokens; I can't really imagine a reason > why you would not be able to handle a V5 GSSAPI token exchange > without SPNEGO. I don't think this is a legitimate reason for > recommending against the use of SPNEGO. > >If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition >to SPNEGO, no additional security is obtained via SPNEGO (the active >attacks that SPNEGO prevents are just circumvented by removing SPNEGO >from the capabilities line). That's true, with the current draft. But if GSSAPI simply means, "any GSSAPI mechanism", then there's no reason a non-SPNEGO client can't interoperate with a SPNEGO-aware server, without any loss of security that I can tell (since there wouldn't be any negotiation in the non-SPNEGO case). I was under the impression that "the interoperability problem" was given as a reason not to use SPNEGO; that's the only reason why I'm saying I don't think it's a valid reason. --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jun 13 10:23:59 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09410 for ; Tue, 13 Jun 2000 10:23:58 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA08896 for ietf-cat-wg-out720680; Tue, 13 Jun 2000 06:59:20 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id GAA08891 for ; Tue, 13 Jun 2000 06:59:18 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 13 Jun 2000 13:54:31 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA10808; Tue, 13 Jun 2000 09:58:58 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Tue, 13 Jun 2000 09:59:13 -0400 Message-ID: From: "Linn, John" To: "'Ken Hornstein'" , ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Subject: RE: SASL GSSAPI draft Date: Tue, 13 Jun 2000 09:59:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Properly, I think, the interoperability concern applies to the case where GSS mechanisms are exposed for negotiation only via SPNEGO, and not also at the SASL level. If GSS mechanisms are exposed for negotiation at both the SPNEGO and SASL levels, this would provide the broadest degree of interoperability, supporting even those clients whose policies reject negotiation of any non-GSS SASL mechanisms and which demand to use SPNEGO as a protected means to select among the available GSS mechanisms. If it's plausible for a client to have such a policy, even though it's interacting with a server which may also have clients having other policies, interoperability would be best served by allowing negotiation at both levels. One argument against SPNEGO under SASL (additionally to SASL-level exposure of the same GSS mechanism set) is that it adds complexity which would be superfluous in some situations; the (apparently modest) incremental complexity might be justified by the fact that it enables a protected negotiation which would be usefully and additionally secure in other situations. Generally, wrt SPNEGO support under SASL, we've seen arguments for both positions. Rather than the present SHOULD NOT (albeit with listed exception), would this be a good candidate for compromise on a MAY? --jl > -----Original Message----- > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil] > Sent: Monday, June 12, 2000 5:37 PM > To: ietf-sasl@imc.org; ietf-cat-wg@lists.Stanford.EDU > Subject: Re: SASL GSSAPI draft > > > > You keep bringing up these mythical "only Kerberos V5 underneath > > SPNEGO" implementations. Even if you're doing SPNEGO, you still > > have to parse V5 GSSAPI tokens; I can't really imagine a reason > > why you would not be able to handle a V5 GSSAPI token exchange > > without SPNEGO. I don't think this is a legitimate reason for > > recommending against the use of SPNEGO. > > > >If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition > >to SPNEGO, no additional security is obtained via SPNEGO (the active > >attacks that SPNEGO prevents are just circumvented by removing SPNEGO > >from the capabilities line). > > That's true, with the current draft. But if GSSAPI simply means, "any > GSSAPI mechanism", then there's no reason a non-SPNEGO client can't > interoperate with a SPNEGO-aware server, without any loss of security > that I can tell (since there wouldn't be any negotiation in the > non-SPNEGO case). > > I was under the impression that "the interoperability > problem" was given > as a reason not to use SPNEGO; that's the only reason why I'm saying > I don't think it's a valid reason. > > --Ken > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jun 13 15:15:38 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19690 for ; Tue, 13 Jun 2000 15:15:37 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA17775 for ietf-cat-wg-out720680; Tue, 13 Jun 2000 11:52:01 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA17767 for ; Tue, 13 Jun 2000 11:51:58 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA15242; Tue, 13 Jun 2000 11:51:56 -0700 (PDT) Message-Id: <200006131851.LAA15242@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2853 on GSS-API Java Bindings Cc: rfc-ed@isi.edu, ietf-cat-wg@lists.Stanford.EDU Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 13 Jun 2000 11:51:56 -0700 From: RFC Editor Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2853 Title: Generic Security Service API Version 2 : Java Bindings Author(s): J. Kabat, M. Upadhyay Status: Standards Track Date: June 2000 Mailbox: jackk@valicert.com, mdu@eng.sun.com Pages: 97 Characters: 199512 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-cat-gssv2-javabind-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc2853.txt The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document specifies the Java bindings for GSS-API which is described at a language independent conceptual level in RFC 2743 [GSSAPIv2-UPDATE]. The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are The Simple Public-Key GSS-API Mechanism [SPKM] and The Kerberos Version 5 GSS-API Mechanism [KERBV5]. This document is a product of the Common Authentication Technology Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000613114940.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2853 --OtherAccess Content-Type: Message/External-body; name="rfc2853.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000613114940.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Jun 15 03:10:11 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24487 for ; Thu, 15 Jun 2000 03:10:10 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id XAA18381 for ietf-cat-wg-out720680; Wed, 14 Jun 2000 23:37:39 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id XAA18376 for ; Wed, 14 Jun 2000 23:37:37 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5F6Wvb08019 for ; Wed, 14 Jun 2000 23:32:58 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FW6NPU00.R18; Wed, 14 Jun 2000 23:37:06 -0700 Message-ID: <3948788D.62BADB48@netscape.com> Date: Wed, 14 Jun 2000 23:32:46 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <200005300336.e4U3aDt00689@ginger.cmf.nrl.navy.mil> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms49DFB204291C59317B913E32" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms49DFB204291C59317B913E32 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ken Hornstein wrote: > As I read RFC 2478, > you always deal with the OID of the underlying mechanism, so I > don't think it's possible to support, for example, Kerberos "under" > SPNEGO without just supporting Kerberos If a server supports Kerberos underneath SPNEGO but rejects Kerberos GSSAPI tokens not underneath SPNEGO, which requirement of RFC 2478 is that server violating? --------------ms49DFB204291C59317B913E32 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxNTA3MzI0NlowIwYJKoZIhvcNAQkEMRYEFAvLy+AgVmIp rC5DizLuBZHcLTotMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAyFvbeL5fVgm+qdg3i5XFVNXelmM+GcE4+tO/RlxeE8wHXAy5Co1IT0BDmNEUvVHw jsxPy2CxPdTqU8hHXANxRX8w3qOSyogqn7aqhg+Dc2c2MjvERdx2WjOiQUaXvZYk6m2TV0M9 GWfuFZc3s7kTNRSvQn0UjswPyzQBbeNDU8k= --------------ms49DFB204291C59317B913E32-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Jun 16 18:30:35 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26813 for ; Fri, 16 Jun 2000 18:30:33 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA13124 for ietf-cat-wg-out720680; Fri, 16 Jun 2000 14:59:09 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA13113 for ; Fri, 16 Jun 2000 14:59:05 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5GLowW06867 for ; Fri, 16 Jun 2000 14:50:58 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FW9P1M00.RW5; Fri, 16 Jun 2000 14:58:34 -0700 Message-ID: <394AA301.D623264@netscape.com> Date: Fri, 16 Jun 2000 14:58:25 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Subject: Re: SASL GSSAPI draft References: <3943F14C.DD447F74@netscape.com> <200006120407.e5C47hh14236@ginger.cmf.nrl.navy.mil> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msEB93552D1CF51C9180CCE623" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------msEB93552D1CF51C9180CCE623 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit My apologies, I accidentally left the ietf-cat-wg list off the recipient list when I first sent this message: Ken Hornstein wrote: > You keep bringing up these mythical "only Kerberos V5 underneath > SPNEGO" implementations. Reportedly, the Microsoft Windows 2000 SSPI implementation only advertises the availability of the SPNEGO GSSAPI mechanism. A straightforward implementation of SASL on Windows 2000 would be unlikely to advertise or recognize GSSAPI SASL mechanisms other than the "GSS-SPNEGO" mechanism that was registered by Microsoft. > Even if you're doing SPNEGO, you still > have to parse V5 GSSAPI tokens; I can't really imagine a reason > why you would not be able to handle a V5 GSSAPI token exchange > without SPNEGO. Consider a SPNEGO client and a non-SPNEGO server. The server will be unable to parse the SPNEGO GSSAPI token that the client sends. > >If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition > >to SPNEGO, no additional security is obtained via SPNEGO (the active > >attacks that SPNEGO prevents are just circumvented by removing SPNEGO > >from the capabilities line). > > That's true, with the current draft. But if GSSAPI simply means, "any > GSSAPI mechanism", then there's no reason a non-SPNEGO client can't > interoperate with a SPNEGO-aware server, without any loss of security > that I can tell (since there wouldn't be any negotiation in the > non-SPNEGO case). If the "GSSAPI" SASL mechanism means "any GSSAPI mechanism," then a client which supports more than one GSSAPI mechanism doesn't know which one to send to the server. If a client supports both Kerberos V5 and SPKM-1 and sees the server advertising "GSSAPI", which one should it send? Surely you don't intend for an IMAP client to take two round trips per GSSAPI mechanism in order to find out the server only supports the last mechanism the client tried? What do you mean there wouldn't be any negotiation in the non-SPNEGO case? There's always negotiation in SASL. A man in the middle can always make it look like either side doesn't support SPNEGO, so my "no additional security is obtained" statement still applies. > I was under the impression that "the interoperability problem" was given > as a reason not to use SPNEGO; that's the only reason why I'm saying > I don't think it's a valid reason. I'm sorry, I don't understand. What is the reason you're saying you don't think "the interoperability problem" is a valid reason? --------------msEB93552D1CF51C9180CCE623 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxNjIxNTgyNlowIwYJKoZIhvcNAQkEMRYEFE+a6Q9ihQxB O+F6UJ8jdTqtj3TYMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAIxxg/ZeWaKZYQCD0GKZyUc3uTPdNH6m7OhkNn5roN4jY JUDRk6hjKptpJ0ANGk0H9Cb3uFif4QuVpPkH3SHF6mBOD36cY5BOXJrDE8DKXsQ5LTZrzPCP 1oszNNwWebfrhyIIERM2pIOgCEGZ+blhs2WIh4WKm4ZqLWGSsQLgbss= --------------msEB93552D1CF51C9180CCE623-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Jun 16 19:57:45 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28133 for ; Fri, 16 Jun 2000 19:57:40 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA16732 for ietf-cat-wg-out720680; Fri, 16 Jun 2000 16:35:22 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id QAA16727 for ; Fri, 16 Jun 2000 16:35:20 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5GNRDW18852 for ; Fri, 16 Jun 2000 16:27:13 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FW9TI100.4BV; Fri, 16 Jun 2000 16:34:49 -0700 Message-ID: <394AB984.B4A401B@netscape.com> Date: Fri, 16 Jun 2000 16:34:28 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Subject: Re: SASL GSSAPI draft References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD28D6A4382055AF44DF9B865" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------msD28D6A4382055AF44DF9B865 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Linn, John" wrote: > Properly, I think, the interoperability concern applies to the case where > GSS mechanisms are exposed for negotiation only via SPNEGO, and not also at > the SASL level. Agreed. There is also a problem case where the policy prefers a non-GSSAPI mechanism over a particular GSSAPI mechanism. One possible reasonable policy would be to first prefer Kerberos, then DIGEST-MD5, then GSS-API-Easy. If a server only supports DIGEST-MD5 and GSS-API-Easy, a client might through SPNEGO inadvertently use GSS-API-Easy instead of DIGEST-MD5. > If GSS mechanisms are exposed for negotiation at both the > SPNEGO and SASL levels, this would provide the broadest degree of > interoperability, supporting even those clients whose policies reject > negotiation of any non-GSS SASL mechanisms and which demand to use SPNEGO as > a protected means to select among the available GSS mechanisms. One issue is whether or not it is a reasonable policy for the server to only accept certain weaker GSS mechanisms when their use has been negotiated through SPNEGO. If it is a reasonable policy, then the draft's current MUST wording about advertising the strongest GSS mechanism at the SASL layer is sufficient. If it is not a reasonable policy, then the requirement needs to be strengthened to say that all of the GSS mechanisms supported inside SPNEGO MUST also be advertised at the SASL layer. For SPNEGO to be useful, a client must not only have the policies you state, but must additionally support and have access to credentials for at least two GSS mechanisms. Steve Hole, who has implemented both Kerberos and SPKM, reports that in his experience any given client or server only has access to infrastructure for one GSS mechanism. I won't claim that it will never happen, but the set of policies and circumstances for which SPNEGO under SASL is necessary is rarely practical. > One argument against SPNEGO under SASL (additionally to SASL-level > exposure of the same GSS mechanism set) is that it adds complexity which > would be superfluous in some situations; the (apparently modest) incremental > complexity might be justified by the fact that it enables a protected > negotiation which would be usefully and additionally secure in other > situations. The incremental complexity of implementing SPNEGO is not necessarily modest. The SASL implementation I am currently working on and the CMU Cyrus SASL library both allow for SASL mechanism plug-ins. It would be relatively straightforward to create a SASL mechanism plug-in implementing Kerberos--that plug-in could then be loaded into any product implemented using the library. To support Kerberos underneath SPNEGO, either the SASL library would have to implement both GSSAPI and SPNEGO or one would have to create a GSSAPI/SPNEGO SASL plug-in and then have Kerberos plug-in to the GSSAPI plug-in. > Generally, wrt SPNEGO support under SASL, we've seen arguments for both > positions. Rather than the present SHOULD NOT (albeit with listed > exception), would this be a good candidate for compromise on a MAY? I am extremely worried about offering two different ways to do the same thing. When a protocol offers multiple ways to do something, it is not uncommon for an implementation to only test one of them. Even if only one way is a MUST IMPLEMENT, that is not necessarily the way that gets tested. If an implementation botches the MUST way and gains wide deployment due to some some other way working, the protocol effectively ends up with two or more MUST IMPLEMENTS. (This is a form of the "be liberal considered harmful" argument.) This is why I wrote this as a SHOULD NOT requirement with a listed exception. I am trying to get implementors to think about their customer's security requirements and only take on the complexity and risk of noninteroperation if the security policy and set of circumstances require. If we change the SHOULD NOT to a MAY, how else can we minimize the risk of clients and servers which only work with SPNEGO due to implementation laziness or error? --------------msD28D6A4382055AF44DF9B865 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxNjIzMzQyOVowIwYJKoZIhvcNAQkEMRYEFGT8cS+9ZRsH E3rBzsldG2a09U6MMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGASRm4goDBlEYABRIS4f3sZ2hpDJdORlMR1vrOihSpMggv 3v3c/uCy7SneSyFdyeo2WdfI7ToT1pwt6xqQSfXehTK0EHeB1AXbd+puIfhMHsnNQ/gwfqkW SBeIiFmRjNSAgOxJRSGN+khFanFdjOnTfZBo3gMZPJXVtuN+LsEBDRk= --------------msD28D6A4382055AF44DF9B865-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Jun 16 23:43:18 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03033 for ; Fri, 16 Jun 2000 23:43:18 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id UAA19892 for ietf-cat-wg-out720680; Fri, 16 Jun 2000 20:15:01 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id UAA19883 for ; Fri, 16 Jun 2000 20:14:58 -0700 (PDT) Received: from cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.5.3]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e5H3Ec801945; Fri, 16 Jun 2000 23:14:39 -0400 (EDT) Message-Id: <200006170314.e5H3Ec801945@ginger.cmf.nrl.navy.mil> To: ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Subject: Re: SASL GSSAPI draft In-reply-to: Your message of "Fri, 16 Jun 2000 14:58:25 PDT." <394AA301.D623264@netscape.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 16 Jun 2000 23:14:38 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >> You keep bringing up these mythical "only Kerberos V5 underneath >> SPNEGO" implementations. > >Reportedly, the Microsoft Windows 2000 SSPI implementation only >advertises the availability of the SPNEGO GSSAPI mechanism. A >straightforward implementation of SASL on Windows 2000 would be unlikely >to advertise or recognize GSSAPI SASL mechanisms other than the >"GSS-SPNEGO" mechanism that was registered by Microsoft. Hm, back up here. Are we talking about advertisement at the SASL or GSSAPI level? I think I'm a bit confused, because I thought SSPI was roughly equivalant to GSSAPI. I will say that when I telnetted to the SMTP server on a coworkers Windows 2000 box, one of the SASL mechanisms it advertised was "GSSAPI", and I didn't see GSS-SPNEGO anywhere. Maybe that will change in the future. Everything I have seen from Microsoft has led me to believe that this server would accept a valid Kerberos 5 GSSAPI token (but I haven't actually tested it yet), _and_ it would accept a SPNEGO token. I actually thought that this interoperability has been tested by Microsoft, but I'd appreciate a correction. >> Even if you're doing SPNEGO, you still >> have to parse V5 GSSAPI tokens; I can't really imagine a reason >> why you would not be able to handle a V5 GSSAPI token exchange >> without SPNEGO. > >Consider a SPNEGO client and a non-SPNEGO server. The server will be >unable to parse the SPNEGO GSSAPI token that the client sends. I agree, this is a problem; I don't think I ever disagreed with that. >> That's true, with the current draft. But if GSSAPI simply means, "any >> GSSAPI mechanism", then there's no reason a non-SPNEGO client can't >> interoperate with a SPNEGO-aware server, without any loss of security >> that I can tell (since there wouldn't be any negotiation in the >> non-SPNEGO case). > >If the "GSSAPI" SASL mechanism means "any GSSAPI mechanism," then a >client which supports more than one GSSAPI mechanism doesn't know which >one to send to the server. No disagreement here. But ... it was my thinking that if you supported more than one mechanism, you'd really have to do SPNEGO (or your proposed draft). >What do you mean there wouldn't be any negotiation in the non-SPNEGO >case? There's always negotiation in SASL. A man in the middle can >always make it look like either side doesn't support SPNEGO, so my "no >additional security is obtained" statement still applies. My apologies; I should have been clearer. I meant, "there wouldn't be any _SPNEGO_ negotiation in the non-SPNEGO case" (e.g., a Kerberos 5 only GSSAPI implementation would only send a Kerberos 5 GSSAPI mechanism). But you're right; you still don't gain any security, because you can then simply remove GSSAPI from the supported mechanism line. My apologies. >> I was under the impression that "the interoperability problem" was given >> as a reason not to use SPNEGO; that's the only reason why I'm saying >> I don't think it's a valid reason. > >I'm sorry, I don't understand. What is the reason you're saying you >don't think "the interoperability problem" is a valid reason? It's been said a number of times that Kerberos 5-only GSSAPI implementations won't interoperate with GSSAPI implementations that support Kerberos 5 only under SPNEGO, and this is one of the reasons a seperate GSS-SPNEGO SASL mechanism is needed. It is my belief that there are no GSSAPI implementations that support SPNEGO which do not support GSS Kerberos 5, and furthermore there is no reason why you would ever _create_ such a GSSAPI implementation (number one: you'd lose interoperability with Kerberos 5 GSSAPI implementations on non-SASL protocols such as FTP). So I don't think that any such interoperability problem exists. (from another note) >If a server supports Kerberos underneath SPNEGO but rejects Kerberos >GSSAPI tokens not underneath SPNEGO, which requirement of RFC 2478 is >that server violating? None, as far as I can tell (that exists outside of the SPNEGO spec, as far as I can tell). But is there a reason why you would do such a thing? Please understand that I'm not raising an objection to your draft; I'm just trying to understand the reasoning better. --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jun 19 11:55:27 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11955 for ; Mon, 19 Jun 2000 11:55:26 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA02045 for ietf-cat-wg-out720680; Mon, 19 Jun 2000 08:13:21 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id IAA02039 for ; Mon, 19 Jun 2000 08:13:19 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 19 Jun 2000 15:08:25 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA09896 for ; Mon, 19 Jun 2000 11:12:52 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Mon, 19 Jun 2000 11:13:16 -0400 Message-ID: From: "Linn, John" To: "'CAT-WG List'" Subject: Status re CAT and Kerberos WGs Date: Mon, 19 Jun 2000 11:13:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > CAT-WG members: > > As discussed at the Adelaide IETF, a new working group is in the process > of being established under the chairpersonship of Doug Engert to pursue > further work on Kerberos documents, including those currently associated > with CAT. A charter is being prepared, and a meeting of the new Kerberos > WG is planned for the Pittsburgh IETF. That meeting will discuss the > charter, and probably also some of the active Kerberos drafts (e.g., > Kerberos-Revisions, PKINIT); I'll defer to Doug to define the agenda in > more detail. > > WRT non-Kerberos CAT work items, I'm pleased to note the recent > publication of LIPKEY (RFC-2847) and GSS Java Bindings (RFC-2853) as > Proposed Standards. I'm not aware of other active non-Kerberos CAT items > targeting the standards track and requiring meeting discussion, so am not > now planning to request an IETF agenda slot for CAT in Pittsburgh. If > anyone believes that such scheduling is needed, and wishes to lead > discussion on a particular topic, please make this known to the list or to > me directly within the next week. > > --jl -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jun 19 15:11:34 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20697 for ; Mon, 19 Jun 2000 15:11:29 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA07850 for ietf-cat-wg-out720680; Mon, 19 Jun 2000 11:38:33 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA07842 for ; Mon, 19 Jun 2000 11:38:31 -0700 (PDT) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e5JIcN820770; Mon, 19 Jun 2000 14:38:23 -0400 (EDT) Message-Id: <200006191838.e5JIcN820770@ginger.cmf.nrl.navy.mil> To: "Linn, John" cc: "'CAT-WG List'" Subject: Re: Status re CAT and Kerberos WGs In-reply-to: Your message of "Mon, 19 Jun 2000 11:13:10 EDT." X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 19 Jun 2000 14:38:21 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >> As discussed at the Adelaide IETF, a new working group is in the process >> of being established under the chairpersonship of Doug Engert to pursue >> further work on Kerberos documents, including those currently associated >> with CAT. A charter is being prepared, and a meeting of the new Kerberos >> WG is planned for the Pittsburgh IETF. That meeting will discuss the >> charter, and probably also some of the active Kerberos drafts (e.g., >> Kerberos-Revisions, PKINIT); I'll defer to Doug to define the agenda in >> more detail. Is there a mailing list set up for this WG already, or should we continue to use the CAT mailing list for this purpose? (Probably at least until Pittsburgh). --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jun 19 15:15:13 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20800 for ; Mon, 19 Jun 2000 15:15:11 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA08884 for ietf-cat-wg-out720680; Mon, 19 Jun 2000 11:51:35 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id LAA08875 for ; Mon, 19 Jun 2000 11:51:31 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 19 Jun 2000 18:46:37 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA25940; Mon, 19 Jun 2000 14:51:04 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Mon, 19 Jun 2000 14:51:28 -0400 Message-ID: From: "Linn, John" To: "'Ken Hornstein'" , "Linn, John" Cc: "'CAT-WG List'" Subject: RE: Status re CAT and Kerberos WGs Date: Mon, 19 Jun 2000 14:51:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk For now, continue using the CAT-WG list; when the new list is available and it's time to switch Kerberos discussion there, this will be announced on CAT-WG. --jl > -----Original Message----- > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil] > Sent: Monday, June 19, 2000 2:38 PM > To: Linn, John > Cc: 'CAT-WG List' > Subject: Re: Status re CAT and Kerberos WGs > > > >> As discussed at the Adelaide IETF, a new working group is > in the process > >> of being established under the chairpersonship of Doug > Engert to pursue > >> further work on Kerberos documents, including those > currently associated > >> with CAT. A charter is being prepared, and a meeting of > the new Kerberos > >> WG is planned for the Pittsburgh IETF. That meeting will > discuss the > >> charter, and probably also some of the active Kerberos > drafts (e.g., > >> Kerberos-Revisions, PKINIT); I'll defer to Doug to define > the agenda in > >> more detail. > > Is there a mailing list set up for this WG already, or should > we continue > to use the CAT mailing list for this purpose? (Probably at > least until > Pittsburgh). > > --Ken > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jun 19 20:17:44 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25998 for ; Mon, 19 Jun 2000 20:17:43 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA26805 for ietf-cat-wg-out720680; Mon, 19 Jun 2000 16:49:31 -0700 (PDT) Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.12.91]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id QAA26800 for ; Mon, 19 Jun 2000 16:49:29 -0700 (PDT) Received: from localhost (bbense@localhost) by shred.stanford.edu (8.10.0/8.10.0.PreAlpha1) with ESMTP id e5JNnIM18827; Mon, 19 Jun 2000 16:49:18 -0700 (PDT) Date: Mon, 19 Jun 2000 16:49:18 -0700 (PDT) From: "Booker C. Bense" To: "Linn, John" cc: "'Ken Hornstein'" , "'CAT-WG List'" Subject: RE: Status re CAT and Kerberos WGs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Mon, 19 Jun 2000, Linn, John wrote: > For now, continue using the CAT-WG list; when the new list is available and > it's time to switch Kerberos discussion there, this will be announced on > CAT-WG. - If there aren't already provisions made for hosting the new list, I'll gladly host that one in addition to the existing cat list. - Booker C. Bense > > --jl > > > -----Original Message----- > > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil] > > Sent: Monday, June 19, 2000 2:38 PM > > To: Linn, John > > Cc: 'CAT-WG List' > > Subject: Re: Status re CAT and Kerberos WGs > > > > > > >> As discussed at the Adelaide IETF, a new working group is > > in the process > > >> of being established under the chairpersonship of Doug > > Engert to pursue > > >> further work on Kerberos documents, including those > > currently associated > > >> with CAT. A charter is being prepared, and a meeting of > > the new Kerberos > > >> WG is planned for the Pittsburgh IETF. That meeting will > > discuss the > > >> charter, and probably also some of the active Kerberos > > drafts (e.g., > > >> Kerberos-Revisions, PKINIT); I'll defer to Doug to define > > the agenda in > > >> more detail. > > > > Is there a mailing list set up for this WG already, or should > > we continue > > to use the CAT mailing list for this purpose? (Probably at > > least until > > Pittsburgh). > > > > --Ken > > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jun 19 20:39:22 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26258 for ; Mon, 19 Jun 2000 20:39:21 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id RAA27744 for ietf-cat-wg-out720680; Mon, 19 Jun 2000 17:20:00 -0700 (PDT) Received: from perq.cac.washington.edu (perq.cac.washington.edu [140.142.110.198]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id RAA27739 for ; Mon, 19 Jun 2000 17:19:58 -0700 (PDT) Received: from localhost (rlmorgan@localhost) by perq.cac.washington.edu (8.9.3/8.9.3) with ESMTP id RAA20095 for ; Mon, 19 Jun 2000 17:20:11 -0700 X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Mon, 19 Jun 2000 17:20:11 -0700 (PDT) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: IETF CAT Working Group Subject: RE: Status re CAT and Kerberos WGs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > For now, continue using the CAT-WG list; when the new list is > available and it's time to switch Kerberos discussion there, this will > be announced on CAT-WG. Any reason not to use kerberos@mit.edu? Seems to me Kerberos discussion is spread across too many mailing lists already. - RL "Bob" -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jun 19 21:22:55 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26655 for ; Mon, 19 Jun 2000 21:22:54 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id RAA28484 for ietf-cat-wg-out720680; Mon, 19 Jun 2000 17:50:43 -0700 (PDT) Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id RAA28479 for ; Mon, 19 Jun 2000 17:50:41 -0700 (PDT) Received: from anl.gov (apollo.ctd.anl.gov [146.137.96.39]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id TAA03118; Mon, 19 Jun 2000 19:50:34 -0500 (CDT) Message-ID: <394EC004.93E5EDB3@anl.gov> Date: Mon, 19 Jun 2000 19:51:16 -0500 From: "Douglas E. Engert" Reply-To: deengert@anl.gov Organization: Argonne National Laboratory X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Booker C. Bense" CC: "Linn, John" , "'Ken Hornstein'" , "'CAT-WG List'" Subject: Re: Status re CAT and Kerberos WGs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit "Booker C. Bense" wrote: > > On Mon, 19 Jun 2000, Linn, John wrote: > > > For now, continue using the CAT-WG list; when the new list is available and > > it's time to switch Kerberos discussion there, this will be announced on > > CAT-WG. > > - If there aren't already provisions made for hosting the new list, > I'll gladly host that one in addition to the existing cat list. Thanks, but we have a site for the list. I have been waiting for the "official" announcement of the WG by the IETF, and to use their archive. > > - Booker C. Bense > > > > > --jl > > > > > -----Original Message----- > > > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil] > > > Sent: Monday, June 19, 2000 2:38 PM > > > To: Linn, John > > > Cc: 'CAT-WG List' > > > Subject: Re: Status re CAT and Kerberos WGs > > > > > > > > > >> As discussed at the Adelaide IETF, a new working group is > > > in the process > > > >> of being established under the chairpersonship of Doug > > > Engert to pursue > > > >> further work on Kerberos documents, including those > > > currently associated > > > >> with CAT. A charter is being prepared, and a meeting of > > > the new Kerberos > > > >> WG is planned for the Pittsburgh IETF. That meeting will > > > discuss the > > > >> charter, and probably also some of the active Kerberos > > > drafts (e.g., > > > >> Kerberos-Revisions, PKINIT); I'll defer to Doug to define > > > the agenda in > > > >> more detail. > > > > > > Is there a mailing list set up for this WG already, or should > > > we continue > > > to use the CAT mailing list for this purpose? (Probably at > > > least until > > > Pittsburgh). > > > > > > --Ken > > > > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > > This message was posted through the Stanford campus mailing list > > server. If you wish to unsubscribe from this mailing list, send the > > message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu > > > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jun 19 23:14:50 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29604 for ; Mon, 19 Jun 2000 23:14:49 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id TAA00900 for ietf-cat-wg-out720680; Mon, 19 Jun 2000 19:50:22 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id TAA00895 for ; Mon, 19 Jun 2000 19:50:20 -0700 (PDT) From: bench1@parsmail.com Received: from atv-ga3a-254.rasserver.net by MIT.EDU with SMTP id AA27560; Mon, 19 Jun 00 22:49:55 EDT Subject: your imaging supplies Date: Mon, 19 Jun 2000 07:11:43 Message-Id: <413.169108.601721@> Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk BENCHMARK SUPPLY 5334 LAKE VIEW CLUB ATLANTA GA 30338 ***LASER PRINTER TONER CARTRIDGES*** ***FAX AND COPIER TONER*** WE ACCEPT GOVERNMENT, SCHOOL & UNIVERSITY PURCHASE ORDERS JUST LEAVE YOUR PO # WITH CORRECT BILLING & SHIPPING ADDRESS CHECK OUT OUR NEW CARTRIDGE PRICES FOR THE FOLLOWING PRINTERS: APPLE LASER WRITER PRO 600 OR 16/600 $69 LASER WRITER SELECT 300,310.360 $69 LASER WRITER 300, 320 $54 LASER WRITER LS,NT,2NTX,2F,2G & 2SC $54 LASER WRITER 12/640 $79 HEWLETT PACKARD LASERJET SERIES 2,3 & 3D (95A) $49 LASERJET SERIES 2P AND 3P (75A) $54 LASERJET SERIES 3SI AND 4SI (91A) $75 LASERJET SERIES 4L AND 4P $49 LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A) $59 LASERJET SERIES 4000 HIGH YIELD (27X) $99 LASERJET SERIES 4V $95 LASERJET SERIES 5SI , 8000 $95 LASERJET SERIES 5L AND 6L $49 LASERJET SERIES 5P, 5MP, 6P, 6MP $59 LASERJET SERIES 5000 (29A) $135 LASERJET SERIES 1100 (92A) $49 LASERJET SERIES 2100 (96A) $84 LASERJET SERIES 8100 (82X) $145 HP LASERFAX LASERFAX 500, 700, FX1, $59 LASERFAX 5000, 7000, FX2, $59 LASERFAX FX3 $69 LASERFAX FX4 $79 LEXMARK OPTRA 4019, 4029 HIGH YIELD $135 OPTRA R, 4039, 4049 HIGH YIELD $135 OPTRA S 4059 HIGH YIELD $135 OPTRA E $59 OPTRA N $115 EPSON EPL-7000, 8000 $105 EPL-1000, 1500 $105 CANON LBP-430 $49 LBP-460, 465 $59 LBP-8 II $54 LBP-LX $54 LBP-MX $95 LBP-AX $49 LBP-EX $59 LBP-SX $49 LBP-BX $95 LBP-PX $49 LBP-WX $95 LBP-VX $59 CANON FAX L700 THRU L790 FX1 $59 CANONFAX L5000 L70000 FX2 $59 CANON COPIERS PC 20, 25 ETC.... $89 PC 3, 6RE, 7, 11 (A30) $69 PC 320 THRU 780 (E40) $89 NEC SERIES 2 LASER MODEL 90,95 $105 PLEASE NOTE: 2) WE DO NOT SEND OUT CATALOGS OR PRICE LISTS 3) WE DO NOT FAX QUOTES OR PRICE LISTS. 4) WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS 5) WE DO NOT CARRY: BROTHER-MINOLTA-KYOSERA-PANASONIC PRODUCTS 6) WE DO NOT CARRY: XEROX-FUJITSU-OKIDATA OR SHARP PRODUCTS 7) WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES 8) WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES 9) WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS ****OUR ORDER LINE IS 770-399-0953 **** ****OUR CUSTOMER SERVICE LINE IS 800-586-0540**** ****OUR E-MAIL REMOVAL AND COMPLAINT LINE IS 888-494-8597**** ****PLACE YOUR ORDER AS FOLLOWS**** : BY PHONE 770-399-0953 BY FAX: 770-698-9700 BY MAIL: BENCHMARK PRINT SUPPLY 5334 LAKE VIEW CLUB ATLANTA GA 30338 MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER: 1) YOUR PHONE NUMBER 2) COMPANY NAME 3) SHIPPING ADDRESS 4) YOUR NAME 5) ITEMS NEEDED WITH QUANTITIES 6) METHOD OF PAYMENT. (COD OR CREDIT CARD) 7) CREDIT CARD NUMBER WITH EXPIRATION DATE 1) WE SHIP UPS GROUND. ADD $4.5 FOR SHIPPING AND HANDLING. 2) COD CHECK ORDERS ADD $3.5 TO YOUR SHIPPING COST. 2) WE ACCEPT ALL MAJOR CREDIT CARD OR "COD" ORDERS. 3) OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS 4) OUR STANDARD MERCHANDISE REPLCAMENT POLICY IS NET 90 DAYS. NOTE NUMBER (1): PLEASE DO NOT CALL OUR ORDER LINE TO REMOVE YOUR E-MAIL ADDRESS OR COMPLAIN. OUR ORDER LINE IS NOT SETUP TO FORWARD YOUR E-MAIL ADDRESS REMOVAL REQUESTS OR PROCESS YOUR COMPLAINTS..IT WOULD BE A WASTED PHONE CALL.YOUR ADDRESS WOULD NOT BE REMOVED AND YOUR COMPLAINTS WOULD NOT BE HANDLED.PLEASE CALL OUR TOLL FREE E-MAIL REMOVAL AND COMPLAINT LINE TO DO THAT. NOTE NUMBER (2): OUR E-MAIL RETURN ADDRESS IS NOT SETUP TO ANSWER ANY QUESTIONS YOU MIGHT HAVE REGARDING OUR PRODUCTS. OUR E-MAIL RETURN ADDRESS IS ALSO NOT SETUP TO TAKE ANY ORDERS AT THIS TIME. PLEASE CALL THE ORDER LINE TO PLACE YOUR ORDER OR HAVE ANY QUESTIONS ANSWERED. OTHERWISE PLEASE CALL OUR CUSTOMER SERCICE LINE. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jun 20 00:49:39 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01639 for ; Tue, 20 Jun 2000 00:49:39 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id VAA03925 for ietf-cat-wg-out720680; Mon, 19 Jun 2000 21:25:50 -0700 (PDT) Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.12.91]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id VAA03920 for ; Mon, 19 Jun 2000 21:25:48 -0700 (PDT) Received: from localhost (bbense@localhost) by shred.stanford.edu (8.10.0/8.10.0.PreAlpha1) with ESMTP id e5K4PlQ19377; Mon, 19 Jun 2000 21:25:47 -0700 (PDT) Date: Mon, 19 Jun 2000 21:25:47 -0700 (PDT) From: "Booker C. Bense" To: "RL 'Bob' Morgan" cc: IETF CAT Working Group Subject: RE: Status re CAT and Kerberos WGs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Mon, 19 Jun 2000, RL 'Bob' Morgan wrote: > > > For now, continue using the CAT-WG list; when the new list is > > available and it's time to switch Kerberos discussion there, this will > > be announced on CAT-WG. > > Any reason not to use kerberos@mit.edu? Seems to me Kerberos discussion > is spread across too many mailing lists already. > - Well, kerberos@mit.edu gets used as a help/bug list for the MIT kerberos src more than a design list. Much as I hate to have "yet another place" to read about kerberos, I think the new WG does require it's own list. - Booker C. Bense -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jun 20 11:49:20 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26890 for ; Tue, 20 Jun 2000 11:49:18 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA10735 for ietf-cat-wg-out720680; Tue, 20 Jun 2000 08:14:02 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id IAA10724 for ; Tue, 20 Jun 2000 08:13:59 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 20 Jun 2000 15:09:04 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA15951 for ; Tue, 20 Jun 2000 11:13:29 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Tue, 20 Jun 2000 11:13:48 -0400 Message-ID: From: "Linn, John" To: "'CAT-WG List'" Subject: Constituency check re GSS-Java provider specification Date: Tue, 20 Jun 2000 11:13:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk CAT/Java fanciers: The current GSS-Java provider draft, draft-ietf-cat-gssv2-javabind-spi-02.txt, hasn't received much WG discussion since its release last October. I'd like to get a sense of the current level of constituency within CAT for pursuing standardization in this area. If you're sufficiently interested in this topic to become actively involved in discussion and progression of a provider specification, please make this fact known to the list. Thanks, regards, ... --jl -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Jun 23 08:19:47 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08055 for ; Fri, 23 Jun 2000 08:19:47 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id EAA27238 for ietf-cat-wg-out720680; Fri, 23 Jun 2000 04:58:42 -0700 (PDT) Received: from perq.cac.washington.edu (c986708-b.sttln1.wa.home.com [24.11.162.150]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id EAA27233 for ; Fri, 23 Jun 2000 04:58:39 -0700 (PDT) Received: from localhost (rlmorgan@localhost) by perq.cac.washington.edu (8.9.3/8.9.3) with ESMTP id EAA22447; Fri, 23 Jun 2000 04:58:53 -0700 X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Fri, 23 Jun 2000 04:58:51 -0700 (PDT) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: "Booker C. Bense" cc: IETF CAT Working Group Subject: RE: Status re CAT and Kerberos WGs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > > Any reason not to use kerberos@mit.edu? Seems to me Kerberos discussion > > is spread across too many mailing lists already. > > > > - Well, kerberos@mit.edu gets used as a help/bug list for the > MIT kerberos src more than a design list. Much as I hate to > have "yet another place" to read about kerberos, I think the > new WG does require it's own list. How about krb-protocol@mit.edu then? Seems like the right name, and almost all of its recent traffic has been cross-posted to ietf-cat-wg ... - RL "Bob" -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Jun 23 10:00:19 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10873 for ; Fri, 23 Jun 2000 10:00:19 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA28317 for ietf-cat-wg-out720680; Fri, 23 Jun 2000 06:32:36 -0700 (PDT) Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id GAA28312 for ; Fri, 23 Jun 2000 06:32:34 -0700 (PDT) Received: from anl.gov (apollo.ctd.anl.gov [146.137.96.39]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA06822 for ; Fri, 23 Jun 2000 08:32:34 -0500 (CDT) Message-ID: <3953671D.706D8196@anl.gov> Date: Fri, 23 Jun 2000 08:33:17 -0500 From: "Douglas E. Engert" Reply-To: deengert@anl.gov Organization: Argonne National Laboratory X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF CAT Working Group Subject: IETF Kerberos Working Group Mail List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit The Kerberos Working Group is in the process of being officially defined as an IETF working group. I was hoping to wait till this has occurred before announcing the new mail list. But it now appears time for the announcement. Mailing Lists: General Discussion:ietf-krb-wg@anl.gov To Subscribe: majordomo@anl.gov In Body: subscribe ietf-krb-wg your_email_address Archive: ftp://ftp.ietf.org/ietf-mail-archive/krb/ There is an archive, but not at the IETF as yet. This will bve implemented as part of the official announcement. You may subscribe to the list now, but at least of the the next week, if you send mail to the list, please copy the ietf-cat-wg@lists.Stanford.EDU so as to give others time to register. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu