Subject: SASL GSSAPI draft

From: [email-masked] (John Myers)
Date: Thu, 25 May 2000 13:12:05 -0700

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.

---

From: "Linn, John" <[email-masked]>
Date: Tue, 30 May 2000 09:52:25 -0400

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: "Linn, John" <[email-masked]>
To: "'Ken Hornstein'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: SASL GSSAPI draft 
Date: Tue, 30 May 2000 09:52:25 -0400
Sender: [email-masked]

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

Date: Tue, 30 May 2000 15:00:19 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom <[email-masked]>
To: [email-masked]
Subject: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

FYI. Comments and feedback is welcome and solicited.

-- Magnus
Magnus Nystrom		Email: [email-masked]
RSA Security

Newsgroups: local.ietf-announce-list
X-Sender: <[email-masked]>
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: [email-masked]
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

To: [email-masked] (John Myers)
cc: [email-masked], [email-masked]
Subject: Re: SASL GSSAPI draft 
Date: Mon, 29 May 2000 23:36:12 -0400
From: Ken Hornstein <[email-masked]>
Sender: [email-masked]

>> 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

Date: Thu, 25 May 2000 14:39:42 -0700
From: [email-masked] (John Myers)
To: Ken Hornstein <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: SASL GSSAPI draft
Sender: [email-masked]

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

--------------ms73D66CC669AA43C95B91162D--

To: [email-masked] (John Myers)
cc: [email-masked], [email-masked]
Subject: Re: SASL GSSAPI draft 
Date: Thu, 25 May 2000 17:02:22 -0400
From: Ken Hornstein <[email-masked]>
Sender: [email-masked]

>consider the interoperability and security problems which led to the

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

Date: Thu, 25 May 2000 13:12:05 -0700
From: [email-masked] (John Myers)
To: [email-masked], [email-masked]
Subject: SASL GSSAPI draft
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms8FB55F21D83018E244084A7A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

--------------ms8FB55F21D83018E244084A7A--

To: IETF-Announce: ;
Cc: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-cat-sasl-gssapi-01.txt
Date: Thu, 25 May 2000 06:34:56 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 16 May 2000 23:26:17 -0400 (EDT)
From: Larry Greenfield <[email-masked]>
To: [email-masked]
Cc: Hor Pui Ling <[email-masked]>
Subject: Re: cyrus-sasl in bsdi4.0
Sender: [email-masked]

The cyrus-sasl mailing list is at [email-masked];
join by sending mail to [email-masked] 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 <[email-masked]>

   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

Date: Wed, 17 May 2000 11:01:05 +0800 (SGT)
From: Hor Pui Ling <[email-masked]>
To: [email-masked]
Subject: cyrus-sasl in bsdi4.0
Sender: [email-masked]

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: [email-masked]
Subject: Open Today....
Date: Thu, 4 May 2000 02:08:23
Sender: [email-masked]

For more information email us: 
[email-masked]

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: 
[email-masked]

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: [email-masked]
http://hometown.aol.com/gotelcom/

If you would like to be removed from our list, please reply to: 
[email-masked] with the word "remove" in 
the subject line.