From owner-ietf-sasl Thu May 4 23:00:34 2000
Received: (from majordomo@localhost)
by ns.secondary.com (8.9.3/8.9.3) id XAA19692
for ietf-sasl-bks; Thu, 4 May 2000 23:00:34 -0700 (PDT)
Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160])
by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA19687;
Thu, 4 May 2000 23:00:31 -0700 (PDT)
From: zxmmnnuv1l1l@www0101111111101tototo.to
Received: from tot-ta.proxy.aol.com (tot-ta.proxy.aol.com [152.163.205.1])
by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
with ESMTP id CAA21665;
Fri, 5 May 2000 02:05:12 -0400 (EDT)
Received: from mx.boston.juno.com (98CEB529.ipt.aol.com [152.206.181.41])
by tot-ta.proxy.aol.com (8.10.0/8.10.0) with SMTP id e45655S22747;
Fri, 5 May 2000 02:05:06 -0400 (EDT)
Subject: Open Today....
Date: Thu, 4 May 2000 02:08:23
Message-Id: <589.123649.161622@mx.boston.juno.com>
X-Apparently-From: WeiH888@aol.com
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
For more information email us:
zxmmnnuv1l1l@www0101111111101tototo.to
Reduce your international phone bill by over 50%. Join our
easy-to-use callback service today for free.
No monthly minimums, surcharges or set-up fees apply, just low
flat rates 24 hours, everyday.
Visit our website: http://hometown.aol.com/gotelcom/ and enter to
win $500 in FREE phone calls, or email us for more info:
zxmmnnuv1l1l@www0101111111101tototo.to
Check out our low rates below. Complete listing of rates for
all countries available on our website. Prices are per minute in
USD.
To get the rates add cost of country you are calling FROM to cost
of country you are calling TO.
Algeria 0.27
Argentina 0.36
Argentina Buenos Aires 0.18
Australia 0.10
Austria 0.11
Bahamas 0.15
Bahrain 0.42
Bangladesh 0.63
Belgium 0.10
Brazil 0.27
Brazil Rio de Jan. 0.20
Brazil Sao Paulo 0.20
Canada 0.08
Chile 0.15
China 0.27
Colombia 0.25
Cyprus 0.23
Denmark 0.10
Djibouti 0.74
Egypt 0.59
Finland 0.10
France 0.08
Georgia 0.46
Germany 0.08
Ghana 0.36
Greece 0.20
Hong Kong 0.10
Hungary 0.26
India 0.60
Indonesia 0.33
Indonesia Jakarta 0.20
Iran 0.62
Ireland 0.10
Israel 0.13
Italy 0.11
Japan 0.10
Jordan 0.51
Kazakhstan 0.36
Kenya 0.74
Kuwait 0.54
Lebanon 0.55
Liberia 0.38
Libya 0.27
Malaysia 0.20
Malta 0.17
Mauritania 0.58
Mexico 0.18
Morocco 0.46
Netherlands 0.07
New Zealand 0.09
Nigeria 0.70
Norway 0.08
Oman 0.53
Pakistan 0.69
Philippines 0.29
Poland 0.28
Qatar 0.53
Romania 0.35
Russia 0.39
Russia Moscow 0.18
Russia St. Petersburg 0.20
Saudi Arabia 0.61
Singapore Rep. 0.15
Somalia 0.60
South Africa 0.35
South Africa Johannesburg0.22
South Korea 0.12
Spain 0.13
Sri Lanka 0.64
Sudan 0.39
Sweden 0.08
Switzerland 0.10
Syria 0.57
Taiwan 0.11
Tajikistan 0.47
Thailand 0.35
Tunisia 0.40
Turkey 0.39
Turkmenistan 0.46
Ukraine 0.29
United Arab Emirates 0.35
United Kingdom 0.07
USA 0.05
Venezuela 0.33
Yemen 0.74
- Rates apply 24 hrs/day, 7 days per week
- NO sign-up fees, NO monthly fees, and NO surcharges
- You DO NOT have to SWITCH your current provider
- Ideal for Home and Business use
- Callback service is available to/from anywhere in the world.
Contact us for more information and complete rate table at:
Email: zxmmnnuv1l1l@www0101111111101tototo.to
http://hometown.aol.com/gotelcom/
If you would like to be removed from our list, please reply to:
zxmmnnuv1l1l@www0101111111101tototo.to with the word "remove" in
the subject line.
From owner-ietf-sasl Tue May 16 19:54:41 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id TAA17217
for ietf-sasl-bks; Tue, 16 May 2000 19:54:41 -0700 (PDT)
Received: from seed.pacific.net.sg (seed.pacific.net.sg [203.120.90.77])
by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA17210
for ; Tue, 16 May 2000 19:54:39 -0700 (PDT)
Received: from pop2.pacific.net.sg (pop2.pacific.net.sg [203.120.90.86])
by seed.pacific.net.sg with ESMTP
id LAA15987 for ; Wed, 17 May 2000 11:01:11 +0800 (SGT)
Received: from oedipus.pacific.net.sg (oedipus.pacific.net.sg [203.120.89.95])
by pop2.pacific.net.sg with ESMTP
id LAA14912 for ; Wed, 17 May 2000 11:01:06 +0800 (SGT)
Date: Wed, 17 May 2000 11:01:05 +0800 (SGT)
From: Hor Pui Ling
To: ietf-sasl@imc.org
Subject: cyrus-sasl in bsdi4.0
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Hi,
I'm trying to install cyrus-sasl-1.5.15 and sendmail-8.10.1 with smtp auth
feature in an bsdi 4.0 machine but having problems to get it works.
Tried to run the sample program and got the below response, seems like it
can't find the sasl libraries.
./sample-client
Waiting for mechanism list from server...
^C
./sample-server
Generating client mechanism list...
Sending list of 0 mechanism(s)
S:
Waiting for client mechanism...
C:
got ''
lt-sample-server: Starting SASL negotiation: no mechanism available
I installed the cyrus-sasl witn ./configure, make and make install in
/usr/local as the prefix dir. There is a soft link of /usr/lib/sasl to
/usr/local/lib/sasl.
When I run sendmail, the error message in /var/log/maillog is
SASL error: listmech=0, num=0
and in /var/log/messages displayed
unable to dlopen /usr/lib/sasl/libcrammd5.so: File
not found
unable to dlopen /usr/lib/sasl/libdigestmd5.so:
File not found
unable to dlopen /usr/lib/sasl/libanonymous.so:
File not found
unable to dlopen /usr/lib/sasl/libplain.so: File
not found
All the files above do exist.
And, I noticed there is a warning message when I configure cyrus-sasl as
below:
*** Warning: This library needs some functionality provided by -lresolv.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
Please advise what could be wrong. Any helps would be appreciated. TIA.
Regards,
PL
From owner-ietf-sasl Tue May 16 20:19:55 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19926
for ietf-sasl-bks; Tue, 16 May 2000 20:19:55 -0700 (PDT)
Received: from smtp3.andrew.cmu.edu (SMTP3.ANDREW.CMU.EDU [128.2.10.83])
by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA19922
for ; Tue, 16 May 2000 20:19:53 -0700 (PDT)
Received: from catch22.andrew.cmu.edu (LEG-DSL.REM.CMU.EDU [128.2.84.68])
by smtp3.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id XAA01878;
Tue, 16 May 2000 23:26:18 -0400 (EDT)
Date: Tue, 16 May 2000 23:26:17 -0400 (EDT)
Message-Id: <200005170326.XAA01878@smtp3.andrew.cmu.edu>
From: Larry Greenfield
X-Mailer: BatIMail version 3.2
To: ietf-sasl@imc.org
Cc: Hor Pui Ling
In-reply-to:
Subject: Re: cyrus-sasl in bsdi4.0
References:
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
The cyrus-sasl mailing list is at cyrus-sasl@lists.andrew.cmu.edu;
join by sending mail to majordomo@lists.andrew.cmu.edu with the body
"subscribe cyrus-sasl".
In brief, dlopen()'ing on BSDI is broken; you can ask on cyrus-sasl if
anyone has managed to overcome this problem. You may want to contact
BSDI and see if they have a bugfix.
Larry
Date: Wed, 17 May 2000 11:01:05 +0800 (SGT)
From: Hor Pui Ling
Hi,
I'm trying to install cyrus-sasl-1.5.15 and sendmail-8.10.1 with smtp auth
feature in an bsdi 4.0 machine but having problems to get it works.
Tried to run the sample program and got the below response, seems like it
can't find the sasl libraries.
./sample-client
Waiting for mechanism list from server...
^C
./sample-server
Generating client mechanism list...
Sending list of 0 mechanism(s)
S:
Waiting for client mechanism...
C:
got ''
lt-sample-server: Starting SASL negotiation: no mechanism available
I installed the cyrus-sasl witn ./configure, make and make install in
/usr/local as the prefix dir. There is a soft link of /usr/lib/sasl to
/usr/local/lib/sasl.
When I run sendmail, the error message in /var/log/maillog is
SASL error: listmech=0, num=0
and in /var/log/messages displayed
unable to dlopen /usr/lib/sasl/libcrammd5.so: File
not found
unable to dlopen /usr/lib/sasl/libdigestmd5.so:
File not found
unable to dlopen /usr/lib/sasl/libanonymous.so:
File not found
unable to dlopen /usr/lib/sasl/libplain.so: File
not found
All the files above do exist.
And, I noticed there is a warning message when I configure cyrus-sasl as
below:
*** Warning: This library needs some functionality provided by -lresolv.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
Please advise what could be wrong. Any helps would be appreciated. TIA.
Regards,
PL
From owner-ietf-sasl Thu May 25 03:27:50 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id DAA02261
for ietf-sasl-bks; Thu, 25 May 2000 03:27:50 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02256
for ; Thu, 25 May 2000 03:27:48 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02849;
Thu, 25 May 2000 06:34:57 -0400 (EDT)
Message-Id: <200005251034.GAA02849@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-cat-wg@lists.stanford.edu, ietf-sasl@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-cat-sasl-gssapi-01.txt
Date: Thu, 25 May 2000 06:34:56 -0400
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Authentication Technology Working Group of the IETF.
Title : SASL GSSAPI mechanisms
Author(s) : J. Myers
Filename : draft-ietf-cat-sasl-gssapi-01.txt
Pages : 12
Date : 24-May-00
The Simple Authentication and Security Layer [SASL] is a method for
adding authentication support to connection-based protocols. This
document describes the method for using the Generic Security Service
Application Program Interface [GSSAPI] in the Simple Authentication
and Security Layer [SASL].
This document amends section 7.2 of RFC 2222 [SASL], the definition
of the 'GSSAPI' SASL mechanism.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-cat-sasl-gssapi-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-cat-sasl-gssapi-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-cat-sasl-gssapi-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000524104302.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-sasl-gssapi-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-sasl-gssapi-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000524104302.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ietf-sasl Thu May 25 13:05:31 2000
Received: (from majordomo@localhost)
by ns.secondary.com (8.9.3/8.9.3) id NAA18929
for ietf-sasl-bks; Thu, 25 May 2000 13:05:31 -0700 (PDT)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18925
for ; Thu, 25 May 2000 13:05:30 -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 e4PK8UN26779
for ; Thu, 25 May 2000 13:08:30 -0700 (PDT)
Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com
(Netscape Messaging Server 4.15) with ESMTP id FV4TGF00.LCS;
Thu, 25 May 2000 13:12:15 -0700
Message-ID: <392D8915.4FAB0482@netscape.com>
Date: Thu, 25 May 2000 13:12:05 -0700
From: jgmyers@netscape.com (John Myers)
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cat-ietf-wg@lists.stanford.edu, ietf-sasl@imc.org
Subject: SASL GSSAPI draft
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8FB55F21D83018E244084A7A"
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
This is a cryptographically signed message in MIME format.
--------------ms8FB55F21D83018E244084A7A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Following a between-meetings conversation in Adelaide, I have published
a new SASL GSSAPI draft. The main change from the previous draft is
that there is now an algorithm for determining the SASL mechanism name
for an arbitrary GSSAPI mechanism. The generated names are extremely
ugly, but there is really nothing else that will work.
This draft maintains the SHOULD NOT directive against using SPNEGO
underneath SASL. When the previous draft was published, this raised an
objection, but the objection was nontechnical and failed to address or
consider the interoperability and security problems which led to the
SHOULD NOT directive.
Work that remains to be done on the draft:
1. Need to add a directive to the "IANA Considerations" section which
reassigns ownership of the GSS-SPNEGO mechanism to the IESG, changes the
specification to that document, and changes its intended usage to
"LIMITED USE".
2. Need to add an example stating that the SASL mechanism name of SPKM-1
is GSS-K7XIDASOK7XIDASO
3. Need examples of some SASL negotiations.
4. Need to rewrite parts of the sample program in Appendix A. The
current program trades too much readability for brevity. It also needs
to recognize the OIDs for Kerberos V5 and SPNEGO and map them to their
special-case SASL mechanism names.
--------------ms8FB55F21D83018E244084A7A
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BlkwggMMMIICdaADAgECAgIQOjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ
BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u
bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0
IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05OTEyMTQwMDMxMTNaFw0wMDA2MTEwMDMxMTNa
MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh
BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz
MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
pX1zWvGAZgDcMU3cID5cDySLcRzNT1eSwrBtUr42rYUra0h9yNeM5/1sTQ/w/dxCCD9uYYfq
gIvDsbp37fH08MGDVHFStxvDDfkHApXjfQZeO/cocO/Is1RiNqh8rFab8IsyX7+enxrHA114
4MYJtJE39ykWfxys94/Raw4UfhMCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud
DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB
AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3
DQEBBAUAA4GBAFqbshBJHm+e8x8AZKU0v1WL01ws4lmvbNezMn/E6sgWW5F6vxH1JxceBlTI
FgYmhlxCi7EUluFtL2P9ebVb1J2zfxNAgfmAGg4s9abErf1Zn3X/7kQgH8bO10QjLh7XjYpk
I2z49gVR9IY/t0HE5qK5DEDamUyodBAivlTyq9W0MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG
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
QXV0aG9yaXR5AgIQOjAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTAwMDUyNTIwMTIwNlowIwYJKoZIhvcNAQkEMRYEFDAfQoGaindP
j1GvZ8XULzJL3FIzMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCSqGSIb3DQEBAQUABIGARVVhPRLPBhNpSiCS9uqUgKVYvN7dpJclF6o/4U90UeAV
/JqmRX7gMtByhDFRtIh2eNhygPzt49h2aVF0aRmerFmTVanYvRAjEUe+7TTItrv7k5tMgTTM
z1lYRQ0LUXj3gufPW7ehQRjLS7Oa7WcCdEXL+jhouuXUzui6reHOjGI=
--------------ms8FB55F21D83018E244084A7A--
From owner-ietf-sasl Thu May 25 13:55:30 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA19517
for ietf-sasl-bks; Thu, 25 May 2000 13:55:30 -0700 (PDT)
Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161])
by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA19513
for ; Thu, 25 May 2000 13:55:28 -0700 (PDT)
Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38])
by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e4PL2Nt11325;
Thu, 25 May 2000 17:02:23 -0400 (EDT)
Message-Id: <200005252102.e4PL2Nt11325@ginger.cmf.nrl.navy.mil>
To: jgmyers@netscape.com (John Myers)
cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org
Subject: Re: SASL GSSAPI draft
In-reply-to: Your message of "Thu, 25 May 2000 13:18:41 PDT."
<392D8AA1.C2183AB0@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: Thu, 25 May 2000 17:02:22 -0400
From: Ken Hornstein
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
>This draft maintains the SHOULD NOT directive against using SPNEGO
>underneath SASL. When the previous draft was published, this raised an
>objection, but the objection was nontechnical and failed to address or
>consider the interoperability and security problems which led to the
>SHOULD NOT directive.
I think I might have missed that discussion (or did it take place on
ietf-sasl?).
I'd hate to ask you to reiterate all of that discussion again, so if
you could please point me to a mailing list archive and an approximate
time frame that the discussion about not using SPNEGO in SASL took
place, I'll go away quitely :-)
--Ken
From owner-ietf-sasl Thu May 25 14:33:03 2000
Received: (from majordomo@localhost)
by ns.secondary.com (8.9.3/8.9.3) id OAA19985
for ietf-sasl-bks; Thu, 25 May 2000 14:33:03 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19981
for ; Thu, 25 May 2000 14:33:02 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
by netscape.com (8.8.5/8.8.5) with ESMTP id OAA00614
for ; Thu, 25 May 2000 14:32:55 -0700 (PDT)
Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com
(Netscape Messaging Server 4.15) with ESMTP id FV4XIC00.77A;
Thu, 25 May 2000 14:39:48 -0700
Message-ID: <392D9D9E.97CBB770@netscape.com>
Date: Thu, 25 May 2000 14:39:42 -0700
From: jgmyers@netscape.com (John Myers)
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ken Hornstein
CC: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org
Subject: Re: SASL GSSAPI draft
References: <200005252102.e4PL2Nt11325@ginger.cmf.nrl.navy.mil>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms73D66CC669AA43C95B91162D"
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
This is a cryptographically signed message in MIME format.
--------------ms73D66CC669AA43C95B91162D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ken Hornstein wrote:
> I think I might have missed that discussion (or did it take place on
> ietf-sasl?).
There was some discussion around March/April 1999 on the CAT mailing
list. I wouldn't say those discussions resolved the issue. Please feel
free to bring up concerns you have with my recently posted draft.
> I'd hate to ask you to reiterate all of that discussion again, so if
> you could please point me to a mailing list archive and an approximate
> time frame that the discussion about not using SPNEGO in SASL took
> place, I'll go away quitely :-)
The reasoning is laid out in section 4 of my recently posted draft.
There is a SHOULD NOT directive and a MUST directive in that section.
--------------ms73D66CC669AA43C95B91162D
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BlkwggMMMIICdaADAgECAgIQOjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ
BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u
bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0
IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05OTEyMTQwMDMxMTNaFw0wMDA2MTEwMDMxMTNa
MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh
BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz
MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
pX1zWvGAZgDcMU3cID5cDySLcRzNT1eSwrBtUr42rYUra0h9yNeM5/1sTQ/w/dxCCD9uYYfq
gIvDsbp37fH08MGDVHFStxvDDfkHApXjfQZeO/cocO/Is1RiNqh8rFab8IsyX7+enxrHA114
4MYJtJE39ykWfxys94/Raw4UfhMCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud
DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB
AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3
DQEBBAUAA4GBAFqbshBJHm+e8x8AZKU0v1WL01ws4lmvbNezMn/E6sgWW5F6vxH1JxceBlTI
FgYmhlxCi7EUluFtL2P9ebVb1J2zfxNAgfmAGg4s9abErf1Zn3X/7kQgH8bO10QjLh7XjYpk
I2z49gVR9IY/t0HE5qK5DEDamUyodBAivlTyq9W0MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG
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
QXV0aG9yaXR5AgIQOjAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTAwMDUyNTIxMzk0M1owIwYJKoZIhvcNAQkEMRYEFMM3zwJ2FpLv
NWkRecO0wBenSTNWMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCSqGSIb3DQEBAQUABIGACZvGKbwQC8vVVov1pCFKji2nIq81WNgh0Q6orFc8JGmb
oQ/MAiOnxsFGZla4Hjb0F866c9KbDDsScVv+GWX8kSiwGJrtc7TtcCTk1sXjUfbW1LGPSxUL
f6GrNrBub5PoSky3onkdKeumRs6NaxaV3UBcOfpijw1ecKcqI3hFtnI=
--------------ms73D66CC669AA43C95B91162D--
From owner-ietf-sasl Mon May 29 20:29:02 2000
Received: (from majordomo@localhost)
by ns.secondary.com (8.9.3/8.9.3) id UAA04546
for ietf-sasl-bks; Mon, 29 May 2000 20:29:02 -0700 (PDT)
Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161])
by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA04536
for ; Mon, 29 May 2000 20:29:00 -0700 (PDT)
Received: from pendragon.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 e4U3aDt00689;
Mon, 29 May 2000 23:36:13 -0400 (EDT)
Message-Id: <200005300336.e4U3aDt00689@ginger.cmf.nrl.navy.mil>
To: jgmyers@netscape.com (John Myers)
cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org
Subject: Re: SASL GSSAPI draft
In-reply-to: Your message of "Thu, 25 May 2000 14:39:42 PDT."
<392D9D9E.97CBB770@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, 29 May 2000 23:36:12 -0400
From: Ken Hornstein
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
>> I think I might have missed that discussion (or did it take place on
>> ietf-sasl?).
>
>There was some discussion around March/April 1999 on the CAT mailing
>list. I wouldn't say those discussions resolved the issue. Please feel
>free to bring up concerns you have with my recently posted draft.
Okay, I saw only a message from Bill Ricker asking about SPNEGO,
posting by you, and Paul Leach's reply.
>> I'd hate to ask you to reiterate all of that discussion again, so if
>> you could please point me to a mailing list archive and an approximate
>> time frame that the discussion about not using SPNEGO in SASL took
>> place, I'll go away quitely :-)
>
>The reasoning is laid out in section 4 of my recently posted draft.
>There is a SHOULD NOT directive and a MUST directive in that section.
Okay, I reread this section. I take it you mean this:
A client which supports, for example, the Kerberos V5 GSSAPI
mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL
mechanism will not interoperate with a server which supports the
Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL
mechanism.
This might be right, but for the wrong reason. 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 (well, let me rephrase that
... you could certainly write a SPNEGO implementation that would
fail to interoperate with a vanilla Kerberos 5 GSSAPI implementation,
but you would have to work at it :-).) 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).
As for this:
If a client's policy is to first prefer GSSAPI mechanism X, then
non-GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server
supports mechanisms Y and Z but not X, then if the client attempts to
negotiate mechanism X by using the "GSS-SPNEGO" SASL mechanism, it
may end up using mechanism Z when it should have used mechanism Y.
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).
I'm really torn here. I can't see the harm in duplicating the SASL
negotiation with SPNEGO, and SPNEGO negotiation _is_ protected without
having to do any extra work ... but the SASL negotiation really is
better suited to piecemeal upgrade, which makes me think it's a better
choice (but I'm not completely convinced).
--Ken
From owner-ietf-sasl Tue May 30 05:53:30 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id FAA05355
for ietf-sasl-bks; Tue, 30 May 2000 05:53:30 -0700 (PDT)
Received: from karon.dynas.se (karon.dynas.se [192.71.43.4])
by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA05351
for ; Tue, 30 May 2000 05:53:28 -0700 (PDT)
Received: (qmail 16214 invoked from network); 30 May 2000 13:01:07 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10)
by karon.sto.dynas.se with SMTP; 30 May 2000 13:01:07 -0000
Received: (qmail 18270 invoked from network); 30 May 2000 13:01:21 -0000
Received: from dhcp02.ua.dynas.se (10.131.2.152)
by spirit.dynas.se with SMTP; 30 May 2000 13:01:21 -0000
Date: Tue, 30 May 2000 15:00:19 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom
To: ietf-sasl@imc.org
Subject: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
In-Reply-To:
Message-ID:
X-X-Sender: magnus@[172.16.1.10]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
FYI. Comments and feedback is welcome and solicited.
-- Magnus
Magnus Nystrom Email: magnus@rsasecurity.com
RSA Security
Newsgroups: local.ietf-announce-list
X-Sender:
Message-ID: <200005231035.GAA29268@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-zuccherato-9798-3-sasl-00.txt
X-Orig-Date: Tue, 23 May 2000 06:35:02 -0400
Date: Tue, 23 May 2000 11:43:20 GMT
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : ISO/IEC 9798-3 Authentication SASL Mechanism
Author(s) : R. Zuccherato, M. Nystrom
Filename : draft-zuccherato-9798-3-sasl-00.txt
Pages : 14
Date : 22-May-00
This document defines a SASL [RFC2222] authentication mechanism based
on ISO/IEC 9798-3 [ISO3] and FIPS PUB 196 [FIPS] entity
authentication. This mechanism only provides authentication using
X.509 certificates [X509]. It has no effect on the protocol
encodings and does not provide integrity or confidentiality services.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zuccherato-9798-3-sasl-00.txt
From owner-ietf-sasl Tue May 30 06:48:26 2000
Received: (from majordomo@localhost)
by ns.secondary.com (8.9.3/8.9.3) id GAA06340
for ietf-sasl-bks; Tue, 30 May 2000 06:48:26 -0700 (PDT)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129])
by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA06336
for ; Tue, 30 May 2000 06:48:24 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com
via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 May 2000 13:51: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 JAA19376;
Tue, 30 May 2000 09:52:18 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0)
id ; Tue, 30 May 2000 09:52:33 -0400
Message-ID:
From: "Linn, John"
To: "'Ken Hornstein'" , jgmyers@netscape.com
Cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org
Subject: RE: SASL GSSAPI draft
Date: Tue, 30 May 2000 09:52:25 -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-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Ken wrote, excerpting:
> >
> >The reasoning is laid out in section 4 of my recently posted draft.
> >There is a SHOULD NOT directive and a MUST directive in that section.
>
> Okay, I reread this section. I take it you mean this:
>
> A client which supports, for example, the Kerberos V5 GSSAPI
> mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL
> mechanism will not interoperate with a server which supports the
> Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL
> mechanism.
>
> This might be right, but for the wrong reason. 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 (well, let me rephrase that
> ... you could certainly write a SPNEGO implementation that would
> fail to interoperate with a vanilla Kerberos 5 GSSAPI implementation,
> but you would have to work at it :-).) 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).
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.
>
> As for this:
>
> If a client's policy is to first prefer GSSAPI mechanism X, then
> non-GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server
> supports mechanisms Y and Z but not X, then if the client
> attempts to
> negotiate mechanism X by using the "GSS-SPNEGO" SASL mechanism, it
> may end up using mechanism Z when it should have used mechanism Y.
>
> 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).
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.
--jl
From owner-ietf-sasl Thu May 4 23:00:34 2000
Received: (from majordomo@localhost)
by ns.secondary.com (8.9.3/8.9.3) id XAA19692
for ietf-sasl-bks; Thu, 4 May 2000 23:00:34 -0700 (PDT)
Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160])
by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA19687;
Thu, 4 May 2000 23:00:31 -0700 (PDT)
From: zxmmnnuv1l1l@www0101111111101tototo.to
Received: from tot-ta.proxy.aol.com (tot-ta.proxy.aol.com [152.163.205.1])
by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
with ESMTP id CAA21665;
Fri, 5 May 2000 02:05:12 -0400 (EDT)
Received: from mx.boston.juno.com (98CEB529.ipt.aol.com [152.206.181.41])
by tot-ta.proxy.aol.com (8.10.0/8.10.0) with SMTP id e45655S22747;
Fri, 5 May 2000 02:05:06 -0400 (EDT)
Subject: Open Today....
Date: Thu, 4 May 2000 02:08:23
Message-Id: <589.123649.161622@mx.boston.juno.com>
X-Apparently-From: WeiH888@aol.com
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
For more information email us:
zxmmnnuv1l1l@www0101111111101tototo.to
Reduce your international phone bill by over 50%. Join our
easy-to-use callback service today for free.
No monthly minimums, surcharges or set-up fees apply, just low
flat rates 24 hours, everyday.
Visit our website: http://hometown.aol.com/gotelcom/ and enter to
win $500 in FREE phone calls, or email us for more info:
zxmmnnuv1l1l@www0101111111101tototo.to
Check out our low rates below. Complete listing of rates for
all countries available on our website. Prices are per minute in
USD.
To get the rates add cost of country you are calling FROM to cost
of country you are calling TO.
Algeria 0.27
Argentina 0.36
Argentina Buenos Aires 0.18
Australia 0.10
Austria 0.11
Bahamas 0.15
Bahrain 0.42
Bangladesh 0.63
Belgium 0.10
Brazil 0.27
Brazil Rio de Jan. 0.20
Brazil Sao Paulo 0.20
Canada 0.08
Chile 0.15
China 0.27
Colombia 0.25
Cyprus 0.23
Denmark 0.10
Djibouti 0.74
Egypt 0.59
Finland 0.10
France 0.08
Georgia 0.46
Germany 0.08
Ghana 0.36
Greece 0.20
Hong Kong 0.10
Hungary 0.26
India 0.60
Indonesia 0.33
Indonesia Jakarta 0.20
Iran 0.62
Ireland 0.10
Israel 0.13
Italy 0.11
Japan 0.10
Jordan 0.51
Kazakhstan 0.36
Kenya 0.74
Kuwait 0.54
Lebanon 0.55
Liberia 0.38
Libya 0.27
Malaysia 0.20
Malta 0.17
Mauritania 0.58
Mexico 0.18
Morocco 0.46
Netherlands 0.07
New Zealand 0.09
Nigeria 0.70
Norway 0.08
Oman 0.53
Pakistan 0.69
Philippines 0.29
Poland 0.28
Qatar 0.53
Romania 0.35
Russia 0.39
Russia Moscow 0.18
Russia St. Petersburg 0.20
Saudi Arabia 0.61
Singapore Rep. 0.15
Somalia 0.60
South Africa 0.35
South Africa Johannesburg0.22
South Korea 0.12
Spain 0.13
Sri Lanka 0.64
Sudan 0.39
Sweden 0.08
Switzerland 0.10
Syria 0.57
Taiwan 0.11
Tajikistan 0.47
Thailand 0.35
Tunisia 0.40
Turkey 0.39
Turkmenistan 0.46
Ukraine 0.29
United Arab Emirates 0.35
United Kingdom 0.07
USA 0.05
Venezuela 0.33
Yemen 0.74
- Rates apply 24 hrs/day, 7 days per week
- NO sign-up fees, NO monthly fees, and NO surcharges
- You DO NOT have to SWITCH your current provider
- Ideal for Home and Business use
- Callback service is available to/from anywhere in the world.
Contact us for more information and complete rate table at:
Email: zxmmnnuv1l1l@www0101111111101tototo.to
http://hometown.aol.com/gotelcom/
If you would like to be removed from our list, please reply to:
zxmmnnuv1l1l@www0101111111101tototo.to with the word "remove" in
the subject line.
From owner-ietf-sasl Tue May 16 19:54:41 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id TAA17217
for ietf-sasl-bks; Tue, 16 May 2000 19:54:41 -0700 (PDT)
Received: from seed.pacific.net.sg (seed.pacific.net.sg [203.120.90.77])
by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA17210
for ; Tue, 16 May 2000 19:54:39 -0700 (PDT)
Received: from pop2.pacific.net.sg (pop2.pacific.net.sg [203.120.90.86])
by seed.pacific.net.sg with ESMTP
id LAA15987 for ; Wed, 17 May 2000 11:01:11 +0800 (SGT)
Received: from oedipus.pacific.net.sg (oedipus.pacific.net.sg [203.120.89.95])
by pop2.pacific.net.sg with ESMTP
id LAA14912 for ; Wed, 17 May 2000 11:01:06 +0800 (SGT)
Date: Wed, 17 May 2000 11:01:05 +0800 (SGT)
From: Hor Pui Ling
To: ietf-sasl@imc.org
Subject: cyrus-sasl in bsdi4.0
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Hi,
I'm trying to install cyrus-sasl-1.5.15 and sendmail-8.10.1 with smtp auth
feature in an bsdi 4.0 machine but having problems to get it works.
Tried to run the sample program and got the below response, seems like it
can't find the sasl libraries.
./sample-client
Waiting for mechanism list from server...
^C
./sample-server
Generating client mechanism list...
Sending list of 0 mechanism(s)
S:
Waiting for client mechanism...
C:
got ''
lt-sample-server: Starting SASL negotiation: no mechanism available
I installed the cyrus-sasl witn ./configure, make and make install in
/usr/local as the prefix dir. There is a soft link of /usr/lib/sasl to
/usr/local/lib/sasl.
When I run sendmail, the error message in /var/log/maillog is
SASL error: listmech=0, num=0
and in /var/log/messages displayed
unable to dlopen /usr/lib/sasl/libcrammd5.so: File
not found
unable to dlopen /usr/lib/sasl/libdigestmd5.so:
File not found
unable to dlopen /usr/lib/sasl/libanonymous.so:
File not found
unable to dlopen /usr/lib/sasl/libplain.so: File
not found
All the files above do exist.
And, I noticed there is a warning message when I configure cyrus-sasl as
below:
*** Warning: This library needs some functionality provided by -lresolv.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
Please advise what could be wrong. Any helps would be appreciated. TIA.
Regards,
PL
From owner-ietf-sasl Tue May 16 20:19:55 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19926
for ietf-sasl-bks; Tue, 16 May 2000 20:19:55 -0700 (PDT)
Received: from smtp3.andrew.cmu.edu (SMTP3.ANDREW.CMU.EDU [128.2.10.83])
by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA19922
for ; Tue, 16 May 2000 20:19:53 -0700 (PDT)
Received: from catch22.andrew.cmu.edu (LEG-DSL.REM.CMU.EDU [128.2.84.68])
by smtp3.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id XAA01878;
Tue, 16 May 2000 23:26:18 -0400 (EDT)
Date: Tue, 16 May 2000 23:26:17 -0400 (EDT)
Message-Id: <200005170326.XAA01878@smtp3.andrew.cmu.edu>
From: Larry Greenfield
X-Mailer: BatIMail version 3.2
To: ietf-sasl@imc.org
Cc: Hor Pui Ling
In-reply-to:
Subject: Re: cyrus-sasl in bsdi4.0
References:
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
The cyrus-sasl mailing list is at cyrus-sasl@lists.andrew.cmu.edu;
join by sending mail to majordomo@lists.andrew.cmu.edu with the body
"subscribe cyrus-sasl".
In brief, dlopen()'ing on BSDI is broken; you can ask on cyrus-sasl if
anyone has managed to overcome this problem. You may want to contact
BSDI and see if they have a bugfix.
Larry
Date: Wed, 17 May 2000 11:01:05 +0800 (SGT)
From: Hor Pui Ling
Hi,
I'm trying to install cyrus-sasl-1.5.15 and sendmail-8.10.1 with smtp auth
feature in an bsdi 4.0 machine but having problems to get it works.
Tried to run the sample program and got the below response, seems like it
can't find the sasl libraries.
./sample-client
Waiting for mechanism list from server...
^C
./sample-server
Generating client mechanism list...
Sending list of 0 mechanism(s)
S:
Waiting for client mechanism...
C:
got ''
lt-sample-server: Starting SASL negotiation: no mechanism available
I installed the cyrus-sasl witn ./configure, make and make install in
/usr/local as the prefix dir. There is a soft link of /usr/lib/sasl to
/usr/local/lib/sasl.
When I run sendmail, the error message in /var/log/maillog is
SASL error: listmech=0, num=0
and in /var/log/messages displayed
unable to dlopen /usr/lib/sasl/libcrammd5.so: File
not found
unable to dlopen /usr/lib/sasl/libdigestmd5.so:
File not found
unable to dlopen /usr/lib/sasl/libanonymous.so:
File not found
unable to dlopen /usr/lib/sasl/libplain.so: File
not found
All the files above do exist.
And, I noticed there is a warning message when I configure cyrus-sasl as
below:
*** Warning: This library needs some functionality provided by -lresolv.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
Please advise what could be wrong. Any helps would be appreciated. TIA.
Regards,
PL
From owner-ietf-sasl Thu May 25 03:27:50 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id DAA02261
for ietf-sasl-bks; Thu, 25 May 2000 03:27:50 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02256
for ; Thu, 25 May 2000 03:27:48 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02849;
Thu, 25 May 2000 06:34:57 -0400 (EDT)
Message-Id: <200005251034.GAA02849@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-cat-wg@lists.stanford.edu, ietf-sasl@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-cat-sasl-gssapi-01.txt
Date: Thu, 25 May 2000 06:34:56 -0400
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Authentication Technology Working Group of the IETF.
Title : SASL GSSAPI mechanisms
Author(s) : J. Myers
Filename : draft-ietf-cat-sasl-gssapi-01.txt
Pages : 12
Date : 24-May-00
The Simple Authentication and Security Layer [SASL] is a method for
adding authentication support to connection-based protocols. This
document describes the method for using the Generic Security Service
Application Program Interface [GSSAPI] in the Simple Authentication
and Security Layer [SASL].
This document amends section 7.2 of RFC 2222 [SASL], the definition
of the 'GSSAPI' SASL mechanism.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-cat-sasl-gssapi-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-cat-sasl-gssapi-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-cat-sasl-gssapi-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000524104302.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-sasl-gssapi-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-sasl-gssapi-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000524104302.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ietf-sasl Thu May 25 13:05:31 2000
Received: (from majordomo@localhost)
by ns.secondary.com (8.9.3/8.9.3) id NAA18929
for ietf-sasl-bks; Thu, 25 May 2000 13:05:31 -0700 (PDT)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18925
for ; Thu, 25 May 2000 13:05:30 -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 e4PK8UN26779
for ; Thu, 25 May 2000 13:08:30 -0700 (PDT)
Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com
(Netscape Messaging Server 4.15) with ESMTP id FV4TGF00.LCS;
Thu, 25 May 2000 13:12:15 -0700
Message-ID: <392D8915.4FAB0482@netscape.com>
Date: Thu, 25 May 2000 13:12:05 -0700
From: jgmyers@netscape.com (John Myers)
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cat-ietf-wg@lists.stanford.edu, ietf-sasl@imc.org
Subject: SASL GSSAPI draft
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8FB55F21D83018E244084A7A"
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
This is a cryptographically signed message in MIME format.
--------------ms8FB55F21D83018E244084A7A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Following a between-meetings conversation in Adelaide, I have published
a new SASL GSSAPI draft. The main change from the previous draft is
that there is now an algorithm for determining the SASL mechanism name
for an arbitrary GSSAPI mechanism. The generated names are extremely
ugly, but there is really nothing else that will work.
This draft maintains the SHOULD NOT directive against using SPNEGO
underneath SASL. When the previous draft was published, this raised an
objection, but the objection was nontechnical and failed to address or
consider the interoperability and security problems which led to the
SHOULD NOT directive.
Work that remains to be done on the draft:
1. Need to add a directive to the "IANA Considerations" section which
reassigns ownership of the GSS-SPNEGO mechanism to the IESG, changes the
specification to that document, and changes its intended usage to
"LIMITED USE".
2. Need to add an example stating that the SASL mechanism name of SPKM-1
is GSS-K7XIDASOK7XIDASO
3. Need examples of some SASL negotiations.
4. Need to rewrite parts of the sample program in Appendix A. The
current program trades too much readability for brevity. It also needs
to recognize the OIDs for Kerberos V5 and SPNEGO and map them to their
special-case SASL mechanism names.
--------------ms8FB55F21D83018E244084A7A
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BlkwggMMMIICdaADAgECAgIQOjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ
BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u
bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0
IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05OTEyMTQwMDMxMTNaFw0wMDA2MTEwMDMxMTNa
MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh
BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz
MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
pX1zWvGAZgDcMU3cID5cDySLcRzNT1eSwrBtUr42rYUra0h9yNeM5/1sTQ/w/dxCCD9uYYfq
gIvDsbp37fH08MGDVHFStxvDDfkHApXjfQZeO/cocO/Is1RiNqh8rFab8IsyX7+enxrHA114
4MYJtJE39ykWfxys94/Raw4UfhMCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud
DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB
AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3
DQEBBAUAA4GBAFqbshBJHm+e8x8AZKU0v1WL01ws4lmvbNezMn/E6sgWW5F6vxH1JxceBlTI
FgYmhlxCi7EUluFtL2P9ebVb1J2zfxNAgfmAGg4s9abErf1Zn3X/7kQgH8bO10QjLh7XjYpk
I2z49gVR9IY/t0HE5qK5DEDamUyodBAivlTyq9W0MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG
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
QXV0aG9yaXR5AgIQOjAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTAwMDUyNTIwMTIwNlowIwYJKoZIhvcNAQkEMRYEFDAfQoGaindP
j1GvZ8XULzJL3FIzMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCSqGSIb3DQEBAQUABIGARVVhPRLPBhNpSiCS9uqUgKVYvN7dpJclF6o/4U90UeAV
/JqmRX7gMtByhDFRtIh2eNhygPzt49h2aVF0aRmerFmTVanYvRAjEUe+7TTItrv7k5tMgTTM
z1lYRQ0LUXj3gufPW7ehQRjLS7Oa7WcCdEXL+jhouuXUzui6reHOjGI=
--------------ms8FB55F21D83018E244084A7A--
From owner-ietf-sasl Thu May 25 13:55:30 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA19517
for ietf-sasl-bks; Thu, 25 May 2000 13:55:30 -0700 (PDT)
Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161])
by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA19513
for ; Thu, 25 May 2000 13:55:28 -0700 (PDT)
Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38])
by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e4PL2Nt11325;
Thu, 25 May 2000 17:02:23 -0400 (EDT)
Message-Id: <200005252102.e4PL2Nt11325@ginger.cmf.nrl.navy.mil>
To: jgmyers@netscape.com (John Myers)
cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org
Subject: Re: SASL GSSAPI draft
In-reply-to: Your message of "Thu, 25 May 2000 13:18:41 PDT."
<392D8AA1.C2183AB0@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: Thu, 25 May 2000 17:02:22 -0400
From: Ken Hornstein
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
>This draft maintains the SHOULD NOT directive against using SPNEGO
>underneath SASL. When the previous draft was published, this raised an
>objection, but the objection was nontechnical and failed to address or
>consider the interoperability and security problems which led to the
>SHOULD NOT directive.
I think I might have missed that discussion (or did it take place on
ietf-sasl?).
I'd hate to ask you to reiterate all of that discussion again, so if
you could please point me to a mailing list archive and an approximate
time frame that the discussion about not using SPNEGO in SASL took
place, I'll go away quitely :-)
--Ken
From owner-ietf-sasl Thu May 25 14:33:03 2000
Received: (from majordomo@localhost)
by ns.secondary.com (8.9.3/8.9.3) id OAA19985
for ietf-sasl-bks; Thu, 25 May 2000 14:33:03 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19981
for ; Thu, 25 May 2000 14:33:02 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
by netscape.com (8.8.5/8.8.5) with ESMTP id OAA00614
for ; Thu, 25 May 2000 14:32:55 -0700 (PDT)
Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com
(Netscape Messaging Server 4.15) with ESMTP id FV4XIC00.77A;
Thu, 25 May 2000 14:39:48 -0700
Message-ID: <392D9D9E.97CBB770@netscape.com>
Date: Thu, 25 May 2000 14:39:42 -0700
From: jgmyers@netscape.com (John Myers)
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ken Hornstein
CC: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org
Subject: Re: SASL GSSAPI draft
References: <200005252102.e4PL2Nt11325@ginger.cmf.nrl.navy.mil>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms73D66CC669AA43C95B91162D"
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
This is a cryptographically signed message in MIME format.
--------------ms73D66CC669AA43C95B91162D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ken Hornstein wrote:
> I think I might have missed that discussion (or did it take place on
> ietf-sasl?).
There was some discussion around March/April 1999 on the CAT mailing
list. I wouldn't say those discussions resolved the issue. Please feel
free to bring up concerns you have with my recently posted draft.
> I'd hate to ask you to reiterate all of that discussion again, so if
> you could please point me to a mailing list archive and an approximate
> time frame that the discussion about not using SPNEGO in SASL took
> place, I'll go away quitely :-)
The reasoning is laid out in section 4 of my recently posted draft.
There is a SHOULD NOT directive and a MUST directive in that section.
--------------ms73D66CC669AA43C95B91162D
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BlkwggMMMIICdaADAgECAgIQOjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ
BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u
bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0
IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05OTEyMTQwMDMxMTNaFw0wMDA2MTEwMDMxMTNa
MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh
BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz
MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
pX1zWvGAZgDcMU3cID5cDySLcRzNT1eSwrBtUr42rYUra0h9yNeM5/1sTQ/w/dxCCD9uYYfq
gIvDsbp37fH08MGDVHFStxvDDfkHApXjfQZeO/cocO/Is1RiNqh8rFab8IsyX7+enxrHA114
4MYJtJE39ykWfxys94/Raw4UfhMCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud
DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB
AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3
DQEBBAUAA4GBAFqbshBJHm+e8x8AZKU0v1WL01ws4lmvbNezMn/E6sgWW5F6vxH1JxceBlTI
FgYmhlxCi7EUluFtL2P9ebVb1J2zfxNAgfmAGg4s9abErf1Zn3X/7kQgH8bO10QjLh7XjYpk
I2z49gVR9IY/t0HE5qK5DEDamUyodBAivlTyq9W0MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG
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
QXV0aG9yaXR5AgIQOjAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTAwMDUyNTIxMzk0M1owIwYJKoZIhvcNAQkEMRYEFMM3zwJ2FpLv
NWkRecO0wBenSTNWMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCSqGSIb3DQEBAQUABIGACZvGKbwQC8vVVov1pCFKji2nIq81WNgh0Q6orFc8JGmb
oQ/MAiOnxsFGZla4Hjb0F866c9KbDDsScVv+GWX8kSiwGJrtc7TtcCTk1sXjUfbW1LGPSxUL
f6GrNrBub5PoSky3onkdKeumRs6NaxaV3UBcOfpijw1ecKcqI3hFtnI=
--------------ms73D66CC669AA43C95B91162D--
From owner-ietf-sasl Mon May 29 20:29:02 2000
Received: (from majordomo@localhost)
by ns.secondary.com (8.9.3/8.9.3) id UAA04546
for ietf-sasl-bks; Mon, 29 May 2000 20:29:02 -0700 (PDT)
Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161])
by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA04536
for ; Mon, 29 May 2000 20:29:00 -0700 (PDT)
Received: from pendragon.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 e4U3aDt00689;
Mon, 29 May 2000 23:36:13 -0400 (EDT)
Message-Id: <200005300336.e4U3aDt00689@ginger.cmf.nrl.navy.mil>
To: jgmyers@netscape.com (John Myers)
cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org
Subject: Re: SASL GSSAPI draft
In-reply-to: Your message of "Thu, 25 May 2000 14:39:42 PDT."
<392D9D9E.97CBB770@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, 29 May 2000 23:36:12 -0400
From: Ken Hornstein
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
>> I think I might have missed that discussion (or did it take place on
>> ietf-sasl?).
>
>There was some discussion around March/April 1999 on the CAT mailing
>list. I wouldn't say those discussions resolved the issue. Please feel
>free to bring up concerns you have with my recently posted draft.
Okay, I saw only a message from Bill Ricker asking about SPNEGO,
posting by you, and Paul Leach's reply.
>> I'd hate to ask you to reiterate all of that discussion again, so if
>> you could please point me to a mailing list archive and an approximate
>> time frame that the discussion about not using SPNEGO in SASL took
>> place, I'll go away quitely :-)
>
>The reasoning is laid out in section 4 of my recently posted draft.
>There is a SHOULD NOT directive and a MUST directive in that section.
Okay, I reread this section. I take it you mean this:
A client which supports, for example, the Kerberos V5 GSSAPI
mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL
mechanism will not interoperate with a server which supports the
Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL
mechanism.
This might be right, but for the wrong reason. 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 (well, let me rephrase that
... you could certainly write a SPNEGO implementation that would
fail to interoperate with a vanilla Kerberos 5 GSSAPI implementation,
but you would have to work at it :-).) 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).
As for this:
If a client's policy is to first prefer GSSAPI mechanism X, then
non-GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server
supports mechanisms Y and Z but not X, then if the client attempts to
negotiate mechanism X by using the "GSS-SPNEGO" SASL mechanism, it
may end up using mechanism Z when it should have used mechanism Y.
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).
I'm really torn here. I can't see the harm in duplicating the SASL
negotiation with SPNEGO, and SPNEGO negotiation _is_ protected without
having to do any extra work ... but the SASL negotiation really is
better suited to piecemeal upgrade, which makes me think it's a better
choice (but I'm not completely convinced).
--Ken
From owner-ietf-sasl Tue May 30 05:53:30 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id FAA05355
for ietf-sasl-bks; Tue, 30 May 2000 05:53:30 -0700 (PDT)
Received: from karon.dynas.se (karon.dynas.se [192.71.43.4])
by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA05351
for ; Tue, 30 May 2000 05:53:28 -0700 (PDT)
Received: (qmail 16214 invoked from network); 30 May 2000 13:01:07 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10)
by karon.sto.dynas.se with SMTP; 30 May 2000 13:01:07 -0000
Received: (qmail 18270 invoked from network); 30 May 2000 13:01:21 -0000
Received: from dhcp02.ua.dynas.se (10.131.2.152)
by spirit.dynas.se with SMTP; 30 May 2000 13:01:21 -0000
Date: Tue, 30 May 2000 15:00:19 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom
To: ietf-sasl@imc.org
Subject: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
In-Reply-To:
Message-ID:
X-X-Sender: magnus@[172.16.1.10]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
FYI. Comments and feedback is welcome and solicited.
-- Magnus
Magnus Nystrom Email: magnus@rsasecurity.com
RSA Security
Newsgroups: local.ietf-announce-list
X-Sender:
Message-ID: <200005231035.GAA29268@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-zuccherato-9798-3-sasl-00.txt
X-Orig-Date: Tue, 23 May 2000 06:35:02 -0400
Date: Tue, 23 May 2000 11:43:20 GMT
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : ISO/IEC 9798-3 Authentication SASL Mechanism
Author(s) : R. Zuccherato, M. Nystrom
Filename : draft-zuccherato-9798-3-sasl-00.txt
Pages : 14
Date : 22-May-00
This document defines a SASL [RFC2222] authentication mechanism based
on ISO/IEC 9798-3 [ISO3] and FIPS PUB 196 [FIPS] entity
authentication. This mechanism only provides authentication using
X.509 certificates [X509]. It has no effect on the protocol
encodings and does not provide integrity or confidentiality services.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zuccherato-9798-3-sasl-00.txt
From owner-ietf-sasl Tue May 30 06:48:26 2000
Received: (from majordomo@localhost)
by ns.secondary.com (8.9.3/8.9.3) id GAA06340
for ietf-sasl-bks; Tue, 30 May 2000 06:48:26 -0700 (PDT)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129])
by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA06336
for ; Tue, 30 May 2000 06:48:24 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com
via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 May 2000 13:51: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 JAA19376;
Tue, 30 May 2000 09:52:18 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0)
id ; Tue, 30 May 2000 09:52:33 -0400
Message-ID:
From: "Linn, John"
To: "'Ken Hornstein'" , jgmyers@netscape.com
Cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org
Subject: RE: SASL GSSAPI draft
Date: Tue, 30 May 2000 09:52:25 -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-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Ken wrote, excerpting:
> >
> >The reasoning is laid out in section 4 of my recently posted draft.
> >There is a SHOULD NOT directive and a MUST directive in that section.
>
> Okay, I reread this section. I take it you mean this:
>
> A client which supports, for example, the Kerberos V5 GSSAPI
> mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL
> mechanism will not interoperate with a server which supports the
> Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL
> mechanism.
>
> This might be right, but for the wrong reason. 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 (well, let me rephrase that
> ... you could certainly write a SPNEGO implementation that would
> fail to interoperate with a vanilla Kerberos 5 GSSAPI implementation,
> but you would have to work at it :-).) 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).
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.
>
> As for this:
>
> If a client's policy is to first prefer GSSAPI mechanism X, then
> non-GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server
> supports mechanisms Y and Z but not X, then if the client
> attempts to
> negotiate mechanism X by using the "GSS-SPNEGO" SASL mechanism, it
> may end up using mechanism Z when it should have used mechanism Y.
>
> 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).
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.
--jl
Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA06340 for ietf-sasl-bks; Tue, 30 May 2000 06:48:26 -0700 (PDT)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA06336 for ; Tue, 30 May 2000 06:48:24 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 May 2000 13:51: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 JAA19376; Tue, 30 May 2000 09:52:18 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Tue, 30 May 2000 09:52:33 -0400
Message-ID:
From: "Linn, John"
To: "'Ken Hornstein'" , jgmyers@netscape.com
Cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org
Subject: RE: SASL GSSAPI draft
Date: Tue, 30 May 2000 09:52:25 -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-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Ken wrote, excerpting:
> >
> >The reasoning is laid out in section 4 of my recently posted draft.
> >There is a SHOULD NOT directive and a MUST directive in that section.
>
> Okay, I reread this section. I take it you mean this:
>
> A client which supports, for example, the Kerberos V5 GSSAPI
> mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL
> mechanism will not interoperate with a server which supports the
> Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL
> mechanism.
>
> This might be right, but for the wrong reason. 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 (well, let me rephrase that
> ... you could certainly write a SPNEGO implementation that would
> fail to interoperate with a vanilla Kerberos 5 GSSAPI implementation,
> but you would have to work at it :-).) 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).
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.
>
> As for this:
>
> If a client's policy is to first prefer GSSAPI mechanism X, then
> non-GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server
> supports mechanisms Y and Z but not X, then if the client
> attempts to
> negotiate mechanism X by using the "GSS-SPNEGO" SASL mechanism, it
> may end up using mechanism Z when it should have used mechanism Y.
>
> 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).
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.
--jl
Received: by ns.secondary.com (8.9.3/8.9.3) id FAA05355 for ietf-sasl-bks; Tue, 30 May 2000 05:53:30 -0700 (PDT)
Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA05351 for ; Tue, 30 May 2000 05:53:28 -0700 (PDT)
Received: (qmail 16214 invoked from network); 30 May 2000 13:01:07 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 30 May 2000 13:01:07 -0000
Received: (qmail 18270 invoked from network); 30 May 2000 13:01:21 -0000
Received: from dhcp02.ua.dynas.se (10.131.2.152) by spirit.dynas.se with SMTP; 30 May 2000 13:01:21 -0000
Date: Tue, 30 May 2000 15:00:19 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom
To: ietf-sasl@imc.org
Subject: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
In-Reply-To:
Message-ID:
X-X-Sender: magnus@[172.16.1.10]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
FYI. Comments and feedback is welcome and solicited.
-- Magnus
Magnus Nystrom Email: magnus@rsasecurity.com
RSA Security
Newsgroups: local.ietf-announce-list
X-Sender:
Message-ID: <200005231035.GAA29268@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-zuccherato-9798-3-sasl-00.txt
X-Orig-Date: Tue, 23 May 2000 06:35:02 -0400
Date: Tue, 23 May 2000 11:43:20 GMT
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : ISO/IEC 9798-3 Authentication SASL Mechanism
Author(s) : R. Zuccherato, M. Nystrom
Filename : draft-zuccherato-9798-3-sasl-00.txt
Pages : 14
Date : 22-May-00
This document defines a SASL [RFC2222] authentication mechanism based
on ISO/IEC 9798-3 [ISO3] and FIPS PUB 196 [FIPS] entity
authentication. This mechanism only provides authentication using
X.509 certificates [X509]. It has no effect on the protocol
encodings and does not provide integrity or confidentiality services.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zuccherato-9798-3-sasl-00.txt
Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA04546 for ietf-sasl-bks; Mon, 29 May 2000 20:29:02 -0700 (PDT)
Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA04536 for ; Mon, 29 May 2000 20:29:00 -0700 (PDT)
Received: from pendragon.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 e4U3aDt00689; Mon, 29 May 2000 23:36:13 -0400 (EDT)
Message-Id: <200005300336.e4U3aDt00689@ginger.cmf.nrl.navy.mil>
To: jgmyers@netscape.com (John Myers)
cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org
Subject: Re: SASL GSSAPI draft
In-reply-to: Your message of "Thu, 25 May 2000 14:39:42 PDT." <392D9D9E.97CBB770@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, 29 May 2000 23:36:12 -0400
From: Ken Hornstein
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
>> I think I might have missed that discussion (or did it take place on
>> ietf-sasl?).
>
>There was some discussion around March/April 1999 on the CAT mailing
>list. I wouldn't say those discussions resolved the issue. Please feel
>free to bring up concerns you have with my recently posted draft.
Okay, I saw only a message from Bill Ricker asking about SPNEGO,
posting by you, and Paul Leach's reply.
>> I'd hate to ask you to reiterate all of that discussion again, so if
>> you could please point me to a mailing list archive and an approximate
>> time frame that the discussion about not using SPNEGO in SASL took
>> place, I'll go away quitely :-)
>
>The reasoning is laid out in section 4 of my recently posted draft.
>There is a SHOULD NOT directive and a MUST directive in that section.
Okay, I reread this section. I take it you mean this:
A client which supports, for example, the Kerberos V5 GSSAPI
mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL
mechanism will not interoperate with a server which supports the
Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL
mechanism.
This might be right, but for the wrong reason. 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 (well, let me rephrase that
... you could certainly write a SPNEGO implementation that would
fail to interoperate with a vanilla Kerberos 5 GSSAPI implementation,
but you would have to work at it :-).) 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).
As for this:
If a client's policy is to first prefer GSSAPI mechanism X, then
non-GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server
supports mechanisms Y and Z but not X, then if the client attempts to
negotiate mechanism X by using the "GSS-SPNEGO" SASL mechanism, it
may end up using mechanism Z when it should have used mechanism Y.
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).
I'm really torn here. I can't see the harm in duplicating the SASL
negotiation with SPNEGO, and SPNEGO negotiation _is_ protected without
having to do any extra work ... but the SASL negotiation really is
better suited to piecemeal upgrade, which makes me think it's a better
choice (but I'm not completely convinced).
--Ken
Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA19985 for ietf-sasl-bks; Thu, 25 May 2000 14:33:03 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19981 for ; Thu, 25 May 2000 14:33:02 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA00614 for ; Thu, 25 May 2000 14:32:55 -0700 (PDT)
Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FV4XIC00.77A; Thu, 25 May 2000 14:39:48 -0700
Message-ID: <392D9D9E.97CBB770@netscape.com>
Date: Thu, 25 May 2000 14:39:42 -0700
From: jgmyers@netscape.com (John Myers)
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ken Hornstein
CC: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org
Subject: Re: SASL GSSAPI draft
References: <200005252102.e4PL2Nt11325@ginger.cmf.nrl.navy.mil>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms73D66CC669AA43C95B91162D"
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
This is a cryptographically signed message in MIME format.
--------------ms73D66CC669AA43C95B91162D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ken Hornstein wrote:
> I think I might have missed that discussion (or did it take place on
> ietf-sasl?).
There was some discussion around March/April 1999 on the CAT mailing
list. I wouldn't say those discussions resolved the issue. Please feel
free to bring up concerns you have with my recently posted draft.
> I'd hate to ask you to reiterate all of that discussion again, so if
> you could please point me to a mailing list archive and an approximate
> time frame that the discussion about not using SPNEGO in SASL took
> place, I'll go away quitely :-)
The reasoning is laid out in section 4 of my recently posted draft.
There is a SHOULD NOT directive and a MUST directive in that section.
--------------ms73D66CC669AA43C95B91162D
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BlkwggMMMIICdaADAgECAgIQOjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ
BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u
bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0
IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05OTEyMTQwMDMxMTNaFw0wMDA2MTEwMDMxMTNa
MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh
BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz
MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
pX1zWvGAZgDcMU3cID5cDySLcRzNT1eSwrBtUr42rYUra0h9yNeM5/1sTQ/w/dxCCD9uYYfq
gIvDsbp37fH08MGDVHFStxvDDfkHApXjfQZeO/cocO/Is1RiNqh8rFab8IsyX7+enxrHA114
4MYJtJE39ykWfxys94/Raw4UfhMCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud
DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB
AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3
DQEBBAUAA4GBAFqbshBJHm+e8x8AZKU0v1WL01ws4lmvbNezMn/E6sgWW5F6vxH1JxceBlTI
FgYmhlxCi7EUluFtL2P9ebVb1J2zfxNAgfmAGg4s9abErf1Zn3X/7kQgH8bO10QjLh7XjYpk
I2z49gVR9IY/t0HE5qK5DEDamUyodBAivlTyq9W0MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG
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
QXV0aG9yaXR5AgIQOjAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTAwMDUyNTIxMzk0M1owIwYJKoZIhvcNAQkEMRYEFMM3zwJ2FpLv
NWkRecO0wBenSTNWMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCSqGSIb3DQEBAQUABIGACZvGKbwQC8vVVov1pCFKji2nIq81WNgh0Q6orFc8JGmb
oQ/MAiOnxsFGZla4Hjb0F866c9KbDDsScVv+GWX8kSiwGJrtc7TtcCTk1sXjUfbW1LGPSxUL
f6GrNrBub5PoSky3onkdKeumRs6NaxaV3UBcOfpijw1ecKcqI3hFtnI=
--------------ms73D66CC669AA43C95B91162D--
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA19517 for ietf-sasl-bks; Thu, 25 May 2000 13:55:30 -0700 (PDT)
Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA19513 for ; Thu, 25 May 2000 13:55:28 -0700 (PDT)
Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e4PL2Nt11325; Thu, 25 May 2000 17:02:23 -0400 (EDT)
Message-Id: <200005252102.e4PL2Nt11325@ginger.cmf.nrl.navy.mil>
To: jgmyers@netscape.com (John Myers)
cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org
Subject: Re: SASL GSSAPI draft
In-reply-to: Your message of "Thu, 25 May 2000 13:18:41 PDT." <392D8AA1.C2183AB0@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: Thu, 25 May 2000 17:02:22 -0400
From: Ken Hornstein
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
>This draft maintains the SHOULD NOT directive against using SPNEGO
>underneath SASL. When the previous draft was published, this raised an
>objection, but the objection was nontechnical and failed to address or
>consider the interoperability and security problems which led to the
>SHOULD NOT directive.
I think I might have missed that discussion (or did it take place on
ietf-sasl?).
I'd hate to ask you to reiterate all of that discussion again, so if
you could please point me to a mailing list archive and an approximate
time frame that the discussion about not using SPNEGO in SASL took
place, I'll go away quitely :-)
--Ken
Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA18929 for ietf-sasl-bks; Thu, 25 May 2000 13:05:31 -0700 (PDT)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18925 for ; Thu, 25 May 2000 13:05:30 -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 e4PK8UN26779 for ; Thu, 25 May 2000 13:08:30 -0700 (PDT)
Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FV4TGF00.LCS; Thu, 25 May 2000 13:12:15 -0700
Message-ID: <392D8915.4FAB0482@netscape.com>
Date: Thu, 25 May 2000 13:12:05 -0700
From: jgmyers@netscape.com (John Myers)
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cat-ietf-wg@lists.stanford.edu, ietf-sasl@imc.org
Subject: SASL GSSAPI draft
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8FB55F21D83018E244084A7A"
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
This is a cryptographically signed message in MIME format.
--------------ms8FB55F21D83018E244084A7A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Following a between-meetings conversation in Adelaide, I have published
a new SASL GSSAPI draft. The main change from the previous draft is
that there is now an algorithm for determining the SASL mechanism name
for an arbitrary GSSAPI mechanism. The generated names are extremely
ugly, but there is really nothing else that will work.
This draft maintains the SHOULD NOT directive against using SPNEGO
underneath SASL. When the previous draft was published, this raised an
objection, but the objection was nontechnical and failed to address or
consider the interoperability and security problems which led to the
SHOULD NOT directive.
Work that remains to be done on the draft:
1. Need to add a directive to the "IANA Considerations" section which
reassigns ownership of the GSS-SPNEGO mechanism to the IESG, changes the
specification to that document, and changes its intended usage to
"LIMITED USE".
2. Need to add an example stating that the SASL mechanism name of SPKM-1
is GSS-K7XIDASOK7XIDASO
3. Need examples of some SASL negotiations.
4. Need to rewrite parts of the sample program in Appendix A. The
current program trades too much readability for brevity. It also needs
to recognize the OIDs for Kerberos V5 and SPNEGO and map them to their
special-case SASL mechanism names.
--------------ms8FB55F21D83018E244084A7A
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BlkwggMMMIICdaADAgECAgIQOjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ
BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u
bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0
IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05OTEyMTQwMDMxMTNaFw0wMDA2MTEwMDMxMTNa
MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh
BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz
MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
pX1zWvGAZgDcMU3cID5cDySLcRzNT1eSwrBtUr42rYUra0h9yNeM5/1sTQ/w/dxCCD9uYYfq
gIvDsbp37fH08MGDVHFStxvDDfkHApXjfQZeO/cocO/Is1RiNqh8rFab8IsyX7+enxrHA114
4MYJtJE39ykWfxys94/Raw4UfhMCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud
DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB
AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3
DQEBBAUAA4GBAFqbshBJHm+e8x8AZKU0v1WL01ws4lmvbNezMn/E6sgWW5F6vxH1JxceBlTI
FgYmhlxCi7EUluFtL2P9ebVb1J2zfxNAgfmAGg4s9abErf1Zn3X/7kQgH8bO10QjLh7XjYpk
I2z49gVR9IY/t0HE5qK5DEDamUyodBAivlTyq9W0MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG
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
QXV0aG9yaXR5AgIQOjAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTAwMDUyNTIwMTIwNlowIwYJKoZIhvcNAQkEMRYEFDAfQoGaindP
j1GvZ8XULzJL3FIzMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCSqGSIb3DQEBAQUABIGARVVhPRLPBhNpSiCS9uqUgKVYvN7dpJclF6o/4U90UeAV
/JqmRX7gMtByhDFRtIh2eNhygPzt49h2aVF0aRmerFmTVanYvRAjEUe+7TTItrv7k5tMgTTM
z1lYRQ0LUXj3gufPW7ehQRjLS7Oa7WcCdEXL+jhouuXUzui6reHOjGI=
--------------ms8FB55F21D83018E244084A7A--
Received: by ns.secondary.com (8.9.3/8.9.3) id DAA02261 for ietf-sasl-bks; Thu, 25 May 2000 03:27:50 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02256 for ; Thu, 25 May 2000 03:27:48 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02849; Thu, 25 May 2000 06:34:57 -0400 (EDT)
Message-Id: <200005251034.GAA02849@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-cat-wg@lists.stanford.edu, ietf-sasl@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-cat-sasl-gssapi-01.txt
Date: Thu, 25 May 2000 06:34:56 -0400
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Authentication Technology Working Group of the IETF.
Title : SASL GSSAPI mechanisms
Author(s) : J. Myers
Filename : draft-ietf-cat-sasl-gssapi-01.txt
Pages : 12
Date : 24-May-00
The Simple Authentication and Security Layer [SASL] is a method for
adding authentication support to connection-based protocols. This
document describes the method for using the Generic Security Service
Application Program Interface [GSSAPI] in the Simple Authentication
and Security Layer [SASL].
This document amends section 7.2 of RFC 2222 [SASL], the definition
of the 'GSSAPI' SASL mechanism.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-cat-sasl-gssapi-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-cat-sasl-gssapi-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-cat-sasl-gssapi-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000524104302.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-sasl-gssapi-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-sasl-gssapi-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000524104302.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19926 for ietf-sasl-bks; Tue, 16 May 2000 20:19:55 -0700 (PDT)
Received: from smtp3.andrew.cmu.edu (SMTP3.ANDREW.CMU.EDU [128.2.10.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA19922 for ; Tue, 16 May 2000 20:19:53 -0700 (PDT)
Received: from catch22.andrew.cmu.edu (LEG-DSL.REM.CMU.EDU [128.2.84.68]) by smtp3.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id XAA01878; Tue, 16 May 2000 23:26:18 -0400 (EDT)
Date: Tue, 16 May 2000 23:26:17 -0400 (EDT)
Message-Id: <200005170326.XAA01878@smtp3.andrew.cmu.edu>
From: Larry Greenfield
X-Mailer: BatIMail version 3.2
To: ietf-sasl@imc.org
Cc: Hor Pui Ling
In-reply-to:
Subject: Re: cyrus-sasl in bsdi4.0
References:
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
The cyrus-sasl mailing list is at cyrus-sasl@lists.andrew.cmu.edu;
join by sending mail to majordomo@lists.andrew.cmu.edu with the body
"subscribe cyrus-sasl".
In brief, dlopen()'ing on BSDI is broken; you can ask on cyrus-sasl if
anyone has managed to overcome this problem. You may want to contact
BSDI and see if they have a bugfix.
Larry
Date: Wed, 17 May 2000 11:01:05 +0800 (SGT)
From: Hor Pui Ling
Hi,
I'm trying to install cyrus-sasl-1.5.15 and sendmail-8.10.1 with smtp auth
feature in an bsdi 4.0 machine but having problems to get it works.
Tried to run the sample program and got the below response, seems like it
can't find the sasl libraries.
./sample-client
Waiting for mechanism list from server...
^C
./sample-server
Generating client mechanism list...
Sending list of 0 mechanism(s)
S:
Waiting for client mechanism...
C:
got ''
lt-sample-server: Starting SASL negotiation: no mechanism available
I installed the cyrus-sasl witn ./configure, make and make install in
/usr/local as the prefix dir. There is a soft link of /usr/lib/sasl to
/usr/local/lib/sasl.
When I run sendmail, the error message in /var/log/maillog is
SASL error: listmech=0, num=0
and in /var/log/messages displayed
unable to dlopen /usr/lib/sasl/libcrammd5.so: File
not found
unable to dlopen /usr/lib/sasl/libdigestmd5.so:
File not found
unable to dlopen /usr/lib/sasl/libanonymous.so:
File not found
unable to dlopen /usr/lib/sasl/libplain.so: File
not found
All the files above do exist.
And, I noticed there is a warning message when I configure cyrus-sasl as
below:
*** Warning: This library needs some functionality provided by -lresolv.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
Please advise what could be wrong. Any helps would be appreciated. TIA.
Regards,
PL
Received: by ns.secondary.com (8.9.3/8.9.3) id TAA17217 for ietf-sasl-bks; Tue, 16 May 2000 19:54:41 -0700 (PDT)
Received: from seed.pacific.net.sg (seed.pacific.net.sg [203.120.90.77]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA17210 for ; Tue, 16 May 2000 19:54:39 -0700 (PDT)
Received: from pop2.pacific.net.sg (pop2.pacific.net.sg [203.120.90.86]) by seed.pacific.net.sg with ESMTP id LAA15987 for ; Wed, 17 May 2000 11:01:11 +0800 (SGT)
Received: from oedipus.pacific.net.sg (oedipus.pacific.net.sg [203.120.89.95]) by pop2.pacific.net.sg with ESMTP id LAA14912 for ; Wed, 17 May 2000 11:01:06 +0800 (SGT)
Date: Wed, 17 May 2000 11:01:05 +0800 (SGT)
From: Hor Pui Ling
To: ietf-sasl@imc.org
Subject: cyrus-sasl in bsdi4.0
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Hi,
I'm trying to install cyrus-sasl-1.5.15 and sendmail-8.10.1 with smtp auth
feature in an bsdi 4.0 machine but having problems to get it works.
Tried to run the sample program and got the below response, seems like it
can't find the sasl libraries.
./sample-client
Waiting for mechanism list from server...
^C
./sample-server
Generating client mechanism list...
Sending list of 0 mechanism(s)
S:
Waiting for client mechanism...
C:
got ''
lt-sample-server: Starting SASL negotiation: no mechanism available
I installed the cyrus-sasl witn ./configure, make and make install in
/usr/local as the prefix dir. There is a soft link of /usr/lib/sasl to
/usr/local/lib/sasl.
When I run sendmail, the error message in /var/log/maillog is
SASL error: listmech=0, num=0
and in /var/log/messages displayed
unable to dlopen /usr/lib/sasl/libcrammd5.so: File
not found
unable to dlopen /usr/lib/sasl/libdigestmd5.so:
File not found
unable to dlopen /usr/lib/sasl/libanonymous.so:
File not found
unable to dlopen /usr/lib/sasl/libplain.so: File
not found
All the files above do exist.
And, I noticed there is a warning message when I configure cyrus-sasl as
below:
*** Warning: This library needs some functionality provided by -lresolv.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
Please advise what could be wrong. Any helps would be appreciated. TIA.
Regards,
PL
Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA19692 for ietf-sasl-bks; Thu, 4 May 2000 23:00:34 -0700 (PDT)
Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA19687; Thu, 4 May 2000 23:00:31 -0700 (PDT)
From: zxmmnnuv1l1l@www0101111111101tototo.to
Received: from tot-ta.proxy.aol.com (tot-ta.proxy.aol.com [152.163.205.1]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id CAA21665; Fri, 5 May 2000 02:05:12 -0400 (EDT)
Received: from mx.boston.juno.com (98CEB529.ipt.aol.com [152.206.181.41]) by tot-ta.proxy.aol.com (8.10.0/8.10.0) with SMTP id e45655S22747; Fri, 5 May 2000 02:05:06 -0400 (EDT)
Subject: Open Today....
Date: Thu, 4 May 2000 02:08:23
Message-Id: <589.123649.161622@mx.boston.juno.com>
X-Apparently-From: WeiH888@aol.com
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
For more information email us:
zxmmnnuv1l1l@www0101111111101tototo.to
Reduce your international phone bill by over 50%. Join our
easy-to-use callback service today for free.
No monthly minimums, surcharges or set-up fees apply, just low
flat rates 24 hours, everyday.
Visit our website: http://hometown.aol.com/gotelcom/ and enter to
win $500 in FREE phone calls, or email us for more info:
zxmmnnuv1l1l@www0101111111101tototo.to
Check out our low rates below. Complete listing of rates for
all countries available on our website. Prices are per minute in
USD.
To get the rates add cost of country you are calling FROM to cost
of country you are calling TO.
Algeria 0.27
Argentina 0.36
Argentina Buenos Aires 0.18
Australia 0.10
Austria 0.11
Bahamas 0.15
Bahrain 0.42
Bangladesh 0.63
Belgium 0.10
Brazil 0.27
Brazil Rio de Jan. 0.20
Brazil Sao Paulo 0.20
Canada 0.08
Chile 0.15
China 0.27
Colombia 0.25
Cyprus 0.23
Denmark 0.10
Djibouti 0.74
Egypt 0.59
Finland 0.10
France 0.08
Georgia 0.46
Germany 0.08
Ghana 0.36
Greece 0.20
Hong Kong 0.10
Hungary 0.26
India 0.60
Indonesia 0.33
Indonesia Jakarta 0.20
Iran 0.62
Ireland 0.10
Israel 0.13
Italy 0.11
Japan 0.10
Jordan 0.51
Kazakhstan 0.36
Kenya 0.74
Kuwait 0.54
Lebanon 0.55
Liberia 0.38
Libya 0.27
Malaysia 0.20
Malta 0.17
Mauritania 0.58
Mexico 0.18
Morocco 0.46
Netherlands 0.07
New Zealand 0.09
Nigeria 0.70
Norway 0.08
Oman 0.53
Pakistan 0.69
Philippines 0.29
Poland 0.28
Qatar 0.53
Romania 0.35
Russia 0.39
Russia Moscow 0.18
Russia St. Petersburg 0.20
Saudi Arabia 0.61
Singapore Rep. 0.15
Somalia 0.60
South Africa 0.35
South Africa Johannesburg0.22
South Korea 0.12
Spain 0.13
Sri Lanka 0.64
Sudan 0.39
Sweden 0.08
Switzerland 0.10
Syria 0.57
Taiwan 0.11
Tajikistan 0.47
Thailand 0.35
Tunisia 0.40
Turkey 0.39
Turkmenistan 0.46
Ukraine 0.29
United Arab Emirates 0.35
United Kingdom 0.07
USA 0.05
Venezuela 0.33
Yemen 0.74
- Rates apply 24 hrs/day, 7 days per week
- NO sign-up fees, NO monthly fees, and NO surcharges
- You DO NOT have to SWITCH your current provider
- Ideal for Home and Business use
- Callback service is available to/from anywhere in the world.
Contact us for more information and complete rate table at:
Email: zxmmnnuv1l1l@www0101111111101tototo.to
http://hometown.aol.com/gotelcom/
If you would like to be removed from our list, please reply to:
zxmmnnuv1l1l@www0101111111101tototo.to with the word "remove" in
the subject line.