On 3/13/24 06:48, Yoann Gini wrote:

I'm looking for a way to "route" Kerberos requests incoming to a single
IP to different backend depending on the requested realms.

I don't have a direct answer to your question.

But I thought that you could host multiple Kerberos realm databases on
the same server and that the client + server would mostly transparently
work with this.

With this in mind I would wonder if it's possible to have a (set of)
front end systems replicate from multiple back end systems as a common
point of access.

I could easily be wrong.

NeedMoreCOFFEE



--
Grant. . . .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: [email protected]

Here with Kerberos, I'm wondering how we can achieve something
equivalent, using a shared IP for multiple Kerberos realms and having
the incoming requests routed to the appropriate backend by some kind of >inspection.

I think that is certainly _possible_, but I don't believe there is
anything that does that today. You'd have to parse the Kerberos message
(which is ASN.1 and there are plenty of things that can handle that)
and extract out the realm of the server principal and route the message appropriately. One thing that leaps out at me is that by default a lot
of Kerberos messages default to UDP transport so that might be a bit
trickier to proxy them (but not impossible).

--Ken

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: [email protected]

On 13. Mar 2024, at 12:48, Yoann Gini <[email protected]> wrote:

Which allow us to have end to end TLS communication between our customers and their tenant. Which is mandatory for our mTLS. But without consuming one public IP per tenant to keep cost under control.

Here with Kerberos, I'm wondering how we can achieve something equivalent, using a shared IP for multiple Kerberos realms and having the incoming requests routed to the appropriate backend by some kind of inspection.

Set it up with a publicly routable IPv6 network, with one IP per tenant. You’re not going to run out of a /64 anytime soon, so the cost should stay constant.

-Marco

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: [email protected]

One thing that leaps out at me is that by default a lot of Kerberos
messages default to UDP transport so that might be a bit trickier to
proxy them (but not impossible).

Yes, that's another aspect of the issue, our expectations so far are on >support for TCP only clients. Since it's for mobile users that we are
looking to have this support, it shouldn't be an issue.

I would caution you that I think that is something you're going to have
to grapple with much sooner than you think.

A long time ago we had developed a small Kerberos proxy that forwarded
on Kerberos messages by prepending the source IP address/port to the
UDP message (our KDC at the time was modified to recognize this
and sent the prepended bytes back to the proxy so it could send it to
the correct originator).

--Ken

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: [email protected]

A long time ago we had developed a small Kerberos proxy that forwarded
on Kerberos messages by prepending the source IP address/port to the
UDP message (our KDC at the time was modified to recognize this and
sent the prepended bytes back to the proxy so it could send it to the
correct originator).

OK, did you had to support iOS and macOS endpoint on that context?
(we are looking for Kerberos support for them, to use with Apple SSO
Kerberos features)

This WAY predated iOS! (the proxy was for the Kerberos 4 protocol) But
I can say with certainty that the MacOS X Kerberos libraries (based on
Heimdal) will default to UDP in many cases. And on MacOS X you can run
into a case where you might be using a different Kerberos implementation
than the operating system libraries.

--Ken

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: [email protected] (Yoann Gini)
Copy: [email protected] ([email protected])

[MS-KKDCP]: Kerberos Key Distribution Center (KDC) Proxy Protoco
https learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kkdcp/5bcebb8d-b747-4ee5-9453-428aec1c5c38?source=recommendations

1 Introduction
The Kerberos Key Distribution Center (KDC) Proxy Protocol (KKDCP) is used by an HTTP-based KKDCP server and KKDCP client to relay the Kerberos Network Authentication Service (V5) protocol [RFC4120] and Kerberos change password [RFC3244] messages between
a Kerberos client and a KDC.
Note Throughout the remainder of this specification the Kerberos Network Authentication Service (V5) protocol will be referred to simply as Kerberos V5. Kerberos Network Authentication Service (V5) protocol [RFC4120] and Kerberos change password [
RFC3244] messages will be referred to simply as Kerberos messages.
Sections 1.5, 1.8, 1.9, 2, and 3 of this specification are normative. All other sections and examples in this specification are informative.

2.1 Transport
Messages are transported by using HTTP POST as specified in [RFC2616]. These messages are sent via Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) by default. The URI uses the virtual directory /KdcProxy unless otherwise configured. The
body of the HTTP message contains the KDC_PROXY_MESSAGE (section 2.2.2).
KDC proxy messages are defined using Abstract Syntax Notation One (ASN.1), as specified in [X680], and encoded using Distinguished Encoding Rules (DER), as specified in [X690] section 10.

2.2 Message Syntax
KKDCP does not alter the syntax of any Kerberos messages.

2.2.2 KDC_PROXY_MESSAGE
This structure is a KDC proxy message that contains the Kerberos message to be proxied and optional information for DC location at the KKDCP server.

KDC-PROXY-MESSAGE::= SEQUENCE {
kerb-message [0] OCTET STRING,
target-domain [1] KERB-REALM OPTIONAL,
dclocator-hint [2] INTEGER OPTIONAL
}
kerb-message: A Kerberos message, including the 4 octet length value specified in [RFC4120] section 7.2.2 in network byte order.
target-domain: An optional KerberosString ([RFC4120] section 5.2.1) that represents the realm to which the Kerberos message is sent, which is required for client messages and is not used in server messages. This value is not case-sensitive.
dclocator-hint: An optional Flags ([MS-NRPC] section 3.5.4.3.1) which contains additional data to be used to find a domain controller for the Kerberos message.


5.1 Security Considerations for Implementers
Because KKDCP is typically used in the Internet, messages are only protected when HTTPS is used, and the KKDCP server's certificate is valid. When using HTTP, the KKDCP client is sending clear text Kerberos messages, which are vulnerable to attacks
discussed in Kerberos V5 ([RFC4120] section 10), unless FAST [RFC6113] is used.

When the KKDCP server relays messages from Internet KKDCP clients to the KDC, it opens unauthenticated access to the KDC from the Internet, unless TLS client authentication is required. KKDCP servers can also provide some level of protection by only
relaying valid Kerberos messages, and by throttling messages. KKDCP servers open KDCs to the Internet, exposing them to denial-of-service attacks (using Kerberos messages) that were previously only possible via other authentication protocols, such as
NTLM.


-----Original Message-----
From: Kerberos <[email protected]> On Behalf Of Ken Hornstein via Kerberos
Sent: Wednesday, March 13, 2024 12:22 PM
To: Yoann Gini <[email protected]>
Cc: [email protected]
Subject: Re: Looking for a "Kerberos Router"?

[You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Looking at Apple documentation I see the support for something I had
never heard of: Kerberos Key Distribution Center Proxy.

Looks like a solution to encapsulate Kerberos requests into an HTTPS.

Any experience on this here?

I personally have not used that, but I know that MIT Kerberos supports that (as far as I can tell, that protocol exists just because firewall people are dumb, but that's neither here nor there). That contains a wrapper ASN.1 structure which has the
target realm in it so you could use that for routing (although the target domain is listed as an optional element to the KDC_PROXY_MESSAGE so that suggests to me you can't rely on it). So you're still going to have to write code to parse an ASN.1
structure to do backend routing.

It does occur to me that maybe if you have different KDC hostnames but the same IP address you could use TLS SNI or hostname routing which you indicated you already use and maybe that would be simpler? That presumes the client implementations set the
SNI field (I see that it does send a "Host" header, and it looks like MIT Kerberos does set the SNI hostname).

--Ken
________________________________________________
Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If
you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you
are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: [email protected]

Looking at Apple documentation I see the support for something I had
never heard of: Kerberos Key Distribution Center Proxy.

Looks like a solution to encapsulate Kerberos requests into an HTTPS.

Any experience on this here?

I personally have not used that, but I know that MIT Kerberos supports
that (as far as I can tell, that protocol exists just because firewall
people are dumb, but that's neither here nor there). That contains
a wrapper ASN.1 structure which has the target realm in it so you
could use that for routing (although the target domain is listed as an
optional element to the KDC_PROXY_MESSAGE so that suggests to me you
can't rely on it). So you're still going to have to write code to parse
an ASN.1 structure to do backend routing.

It does occur to me that maybe if you have different KDC hostnames but
the same IP address you could use TLS SNI or hostname routing which
you indicated you already use and maybe that would be simpler? That
presumes the client implementations set the SNI field (I see that it
does send a "Host" header, and it looks like MIT Kerberos does set the
SNI hostname).

--Ken

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: [email protected] (Ken Hornstein)
To: [email protected] (Yoann Gini)
Copy: [email protected] ([email protected])

See RFC 4559 and related 
MS support keep via https
Quest Vintela and others field kit that supports this
IBM and SiteMider have guidance and support





On Wednesday, March 13, 2024, 9:56 AM, Brent Kimberley via Kerberos <[email protected]> wrote:

[MS-KKDCP]: Kerberos Key Distribution Center (KDC) Proxy Protoco
https learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kkdcp/5bcebb8d-b747-4ee5-9453-428aec1c5c38?source=recommendations

1 Introduction
The Kerberos Key Distribution Center (KDC) Proxy Protocol (KKDCP) is used by an HTTP-based KKDCP server and KKDCP client to relay the Kerberos Network Authentication Service (V5) protocol [RFC4120] and Kerberos change password [RFC3244] messages between
a Kerberos client and a KDC.
Note  Throughout the remainder of this specification the Kerberos Network Authentication Service (V5) protocol will be referred to simply as Kerberos V5. Kerberos Network Authentication Service (V5) protocol [RFC4120] and Kerberos change password [
RFC3244] messages will be referred to simply as Kerberos messages.
Sections 1.5, 1.8, 1.9, 2, and 3 of this specification are normative. All other sections and examples in this specification are informative.

2.1 Transport
Messages are transported by using HTTP POST as specified in [RFC2616]. These messages are sent via Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) by default. The URI uses the virtual directory /KdcProxy unless otherwise configured. The
body of the HTTP message contains the KDC_PROXY_MESSAGE (section 2.2.2).
KDC proxy messages are defined using Abstract Syntax Notation One (ASN.1), as specified in [X680], and encoded using Distinguished Encoding Rules (DER), as specified in [X690] section 10.

2.2 Message Syntax
KKDCP does not alter the syntax of any Kerberos messages.

2.2.2 KDC_PROXY_MESSAGE
This structure is a KDC proxy message that contains the Kerberos message to be proxied and optional information for DC location at the KKDCP server.

KDC-PROXY-MESSAGE::= SEQUENCE {
    kerb-message          [0] OCTET STRING,
    target-domain          [1] KERB-REALM OPTIONAL,
    dclocator-hint        [2] INTEGER OPTIONAL
}
kerb-message: A Kerberos message, including the 4 octet length value specified in [RFC4120] section 7.2.2 in network byte order.
target-domain: An optional KerberosString ([RFC4120] section 5.2.1) that represents the realm to which the Kerberos message is sent, which is required for client messages and is not used in server messages. This value is not case-sensitive.
dclocator-hint: An optional Flags ([MS-NRPC] section 3.5.4.3.1) which contains additional data to be used to find a domain controller for the Kerberos message.


5.1 Security Considerations for Implementers
Because KKDCP is typically used in the Internet, messages are only protected when HTTPS is used, and the KKDCP server's certificate is valid. When using HTTP, the KKDCP client is sending clear text Kerberos messages, which are vulnerable to attacks
discussed in Kerberos V5 ([RFC4120] section 10), unless FAST [RFC6113] is used.

When the KKDCP server relays messages from Internet KKDCP clients to the KDC, it opens unauthenticated access to the KDC from the Internet, unless TLS client authentication is required. KKDCP servers can also provide some level of protection by only
relaying valid Kerberos messages, and by throttling messages. KKDCP servers open KDCs to the Internet, exposing them to denial-of-service attacks (using Kerberos messages) that were previously only possible via other authentication protocols, such as
NTLM.


-----Original Message-----
From: Kerberos <[email protected]> On Behalf Of Ken Hornstein via Kerberos
Sent: Wednesday, March 13, 2024 12:22 PM
To: Yoann Gini <[email protected]>
Cc: [email protected]
Subject: Re: Looking for a "Kerberos Router"?

[You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Looking at Apple documentation I see the support for something I had
never heard of: Kerberos Key Distribution Center Proxy.

Looks like a solution to encapsulate Kerberos requests into an HTTPS.

Any experience on this here?

I personally have not used that, but I know that MIT Kerberos supports that (as far as I can tell, that protocol exists just because firewall people are dumb, but that's neither here nor there).  That contains a wrapper ASN.1 structure which has the
target realm in it so you could use that for routing (although the target domain is listed as an optional element to the KDC_PROXY_MESSAGE so that suggests to me you can't rely on it).  So you're still going to have to write code to parse an ASN.1
structure to do backend routing.

It does occur to me that maybe if you have different KDC hostnames but the same IP address you could use TLS SNI or hostname routing which you indicated you already use and maybe that would be simpler?  That presumes the client implementations set the
SNI field (I see that it does send a "Host" header, and it looks like MIT Kerberos does set the SNI hostname).

--Ken
________________________________________________
Kerberos mailing list          [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If
you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you
are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

________________________________________________
Kerberos mailing list          [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: [email protected] (Ken Hornstein)
Copy: [email protected]

This is well tested:
https://github.com/latchset/kdcproxy


On Wed, 2024-03-13 at 17:32 +0100, Yoann Gini wrote:

Le 13 mars 2024 à 17:21, Ken Hornstein <[email protected]> a écrit :

It does occur to me that maybe if you have different KDC hostnames but
the same IP address you could use TLS SNI or hostname routing which
you indicated you already use and maybe that would be simpler? That presumes the client implementations set the SNI field (I see that it
does send a "Host" header, and it looks like MIT Kerberos does set the
SNI hostname).

This is what I have in mind looking at the documentation of kkdcp (reading as exchanging here). Using SNI to select the KDC.

I will give it a try, it looks like the option I need here.

And yes, all of those complexities would have been avoided by network teams just supporting IPv6 and not blocking random ports for no reasons…
________________________________________________
Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos

--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: [email protected] (Yoann Gini)
To: [email protected] (Ken Hornstein)
Copy: [email protected] ([email protected])

The site philosophy can be expressed as fail open / fail closed /fail safe / fail deadly...
________________________________
From: Brent Kimberley
Sent: Wednesday, March 13, 2024 5:41:58 PM
To: Simo Sorce <[email protected]>; Yoann Gini <[email protected]>; Ken Hornstein <[email protected]>
Cc: [email protected] <[email protected]>
Subject: RE: Looking for a "Kerberos Router"?

To the best of my knowledge, all IPV6 ports should be closed by design and only opened if/when approved.

-----Original Message-----
From: Kerberos <[email protected]> On Behalf Of Simo Sorce
Sent: Wednesday, March 13, 2024 4:48 PM
To: Yoann Gini <[email protected]>; Ken Hornstein <[email protected]> Cc: [email protected]
Subject: Re: Looking for a "Kerberos Router"?

[You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

This is well tested: https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flatchset%2Fkdcproxy&data=05%7C02%7Cbrent.kimberley%40durham.ca%7Cde3f8941d2b64fc0ec6f08dc439ee352%7C52d7c9c2d54941b69b1f9da198dc3f16%7C0%7C0%7C638459596905104881%7CUnknown%
7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=4H0nZRxcUm0XdRKqLsydlI06oDz2pfHxBiKC7HxZmv4%3D&reserved=0<https://github.com/latchset/kdcproxy>


On Wed, 2024-03-13 at 17:32 +0100, Yoann Gini wrote:

Le 13 mars 2024 � 17:21, Ken Hornstein <[email protected]> a �crit :

It does occur to me that maybe if you have different KDC hostnames
but the same IP address you could use TLS SNI or hostname routing
which you indicated you already use and maybe that would be simpler?
That presumes the client implementations set the SNI field (I see
that it does send a "Host" header, and it looks like MIT Kerberos
does set the SNI hostname).

This is what I have in mind looking at the documentation of kkdcp (reading as exchanging here). Using SNI to select the KDC.

I will give it a try, it looks like the option I need here.

And yes, all of those complexities would have been avoided by network
teams just supporting IPv6 and not blocking random ports for no reasons� ________________________________________________
Kerberos mailing list [email protected] https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail<https://mail/>
man.mit.edu%2Fmailman%2Flistinfo%2Fkerberos&data=05%7C02%7Cbrent.kimbe rley%40durham.ca%7Cde3f8941d2b64fc0ec6f08dc439ee352%7C52d7c9c2d54941b6 9b1f9da198dc3f16%7C0%7C0%7C638459596905112923%7CUnknown%7CTWFpbGZsb3d8 eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0 %7C%7C%7C&sdata=dZYepxHAXNhDO%2F4F%2FpLx7fDYgT6xEYGEKtjEK7l1H74%3D&res erved=0

--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc









________________________________________________
Kerberos mailing list [email protected] https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.mit.edu%2Fmailman%2Flistinfo%2Fkerberos&data=05%7C02%7Cbrent.kimberley%40durham.ca%7Cde3f8941d2b64fc0ec6f08dc439ee352%7C52d7c9c2d54941b69b1f9da198dc3f16%7C0%7C0%
7C638459596905118780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=dzii88nyGoDkbNfjgCWFYvNUHCh%2B%2FiR4CIc%2FQggCEjs%3D&reserved=0<https://mailman.mit.edu/mailman/listinfo/kerberos>
THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If
you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you
are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: [email protected] (Yoann Gini)
To: [email protected] (Ken Hornstein)
Copy: [email protected] ([email protected])

To the best of my knowledge, all IPV6 ports should be closed by design and only opened if/when approved.

-----Original Message-----
From: Kerberos <[email protected]> On Behalf Of Simo Sorce
Sent: Wednesday, March 13, 2024 4:48 PM
To: Yoann Gini <[email protected]>; Ken Hornstein <[email protected]> Cc: [email protected]
Subject: Re: Looking for a "Kerberos Router"?

[You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

This is well tested:
https://github.com/latchset/kdcproxy


On Wed, 2024-03-13 at 17:32 +0100, Yoann Gini wrote:

Le 13 mars 2024 � 17:21, Ken Hornstein <[email protected]> a �crit :

It does occur to me that maybe if you have different KDC hostnames
but the same IP address you could use TLS SNI or hostname routing
which you indicated you already use and maybe that would be simpler?
That presumes the client implementations set the SNI field (I see
that it does send a "Host" header, and it looks like MIT Kerberos
does set the SNI hostname).

This is what I have in mind looking at the documentation of kkdcp (reading as exchanging here). Using SNI to select the KDC.

I will give it a try, it looks like the option I need here.

And yes, all of those complexities would have been avoided by network
teams just supporting IPv6 and not blocking random ports for no reasons... ________________________________________________
Kerberos mailing list [email protected]
https://mail/ man.mit.edu%2Fmailman%2Flistinfo%2Fkerberos&data=05%7C02%7Cbrent.kimbe rley%40durham.ca%7Cde3f8941d2b64fc0ec6f08dc439ee352%7C52d7c9c2d54941b6 9b1f9da198dc3f16%7C0%7C0%7C638459596905112923%7CUnknown%7CTWFpbGZsb3d8 eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0 %7C%7C%7C&sdata=dZYepxHAXNhDO%2F4F%2FpLx7fDYgT6xEYGEKtjEK7l1H74%3D&res erved=0

--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc









________________________________________________
Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If
you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you
are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

VGhhbmsgeW91LCBJIHdpbGwgcHV0IHRoaXMgb24gdGVzdC4KClRoaXMgaXMgd2VsbCB0ZXN0ZWQ6 Cmh0dHBzOi8vZ2l0aHViLmNvbS9sYXRjaHNldC9rZGNwcm94eQpPbiBXZWQsIDIwMjQtMDMtMTMg YXQgMTc6MzIgKzAxMDAsIFlvYW5uIEdpbmkgd3JvdGU6Cj4KCj4KCj4gTGUgMTMgbWFycyAyMDI0 IMOgIDE3OjIxLCBLZW4gSG9ybnN0ZWluICBhIMOpY3JpdCA6Cgo+Cgo+Cgo+Cgo+IEl0IGRvZXMg b2NjdXIgdG8gbWUgdGhhdCBtYXliZSBpZiB5b3UgaGF2ZSBkaWZmZXJlbnQgS0RDIGhvc3RuYW1l cyBidXQKCj4KCj4gdGhlIHNhbWUgSVAgYWRkcmVzcyB5b3UgY291bGQgdXNlIFRMUyBTTkkgb3Ig aG9zdG5hbWUgcm91dGluZyB3aGljaAoKPgoKPiB5b3UgaW5kaWNhdGVkIHlvdSBhbHJlYWR5IHVz ZSBhbmQgbWF5YmUgdGhhdCB3b3VsZCBiZSBzaW1wbGVyPyAgVGhhdAoKPgoKPiBwcmVzdW1lcyB0 aGUgY2xpZW50IGltcGxlbWVudGF0aW9ucyBzZXQgdGhlIFNOSSBmaWVsZCAoSSBzZWUgdGhhdCBp dAoKPgoKPiBkb2VzIHNlbmQgYSAiSG9zdCIgaGVhZGVyLCBhbmQgaXQgbG9va3MgbGlrZSBNSVQg S2VyYmVyb3MgZG9lcyBzZXQgdGhlCgo+Cgo+IFNOSSBob3N0bmFtZSkuCgo+Cgo+CgpUaGlzIGlz IHdoYXQgSSBoYXZlIGluIG1pbmQgbG9va2luZyBhdCB0aGUgZG9jdW1lbnRhdGlvbiBvZiBra2Rj cCAocmVhZGluZyBhcyBleGNoYW5naW5nIGhlcmUpLiBVc2luZyBTTkkgdG8gc2VsZWN0IHRoZSBL REMuCgo+Cgo+CgpJIHdpbGwgZ2l2ZSBpdCBhIHRyeSwgaXQgbG9va3MgbGlrZSB0aGUgb3B0aW9u IEkgbmVlZCBoZXJlLgoKPgoKPgoKQW5kIHllcywgYWxsIG9mIHRob3NlIGNvbXBsZXhpdGllcyB3 b3VsZCBoYXZlIGJlZW4gYXZvaWRlZCBieSBuZXR3b3JrIHRlYW1zIGp1c3Qgc3VwcG9ydGluZyBJ UHY2IGFuZCBub3QgYmxvY2tpbmcgcmFuZG9tIHBvcnRzIGZvciBubyByZWFzb25z4oCmCgo+Pj4K Ck9uZSB0aGluZyB0aGF0IGxlYXBzIG91dCBhdCBtZSBpcyB0aGF0IGJ5IGRlZmF1bHQgYSBsb3Qg b2YgS2VyYmVyb3MKCj4+PgoKbWVzc2FnZXMgZGVmYXVsdCB0byBVRFAgdHJhbnNwb3J0IHNvIHRo YXQgbWlnaHQgYmUgYSBiaXQgdHJpY2tpZXIgdG8KCj4+PgoKcHJveHkgdGhlbSAoYnV0IG5vdCBp bXBvc3NpYmxlKS4KaHR0cHM6Ly93d3cudnBucGFsdmVsdXQuY29tLwo+PgoKWWVzLCB0aGF0J3Mg YW5vdGhlciBhc3BlY3Qgb2YgdGhlIGlzc3VlLCBvdXIgZXhwZWN0YXRpb25zIHNvIGZhciBhcmUg b24KCj4+CgpzdXBwb3J0IGZvciBUQ1Agb25seSBjbGllbnRzLiBTaW5jZSBpdCdzIGZvciBtb2Jp bGUgdXNlcnMgdGhhdCB3ZSBhcmUKCj4+Cgpsb29raW5nIHRvIGhhdmUgdGhpcyBzdXBwb3J0LCBp dCBzaG91bGRuJ3QgYmUgYW4gaXNzdWUuCgo+Cgo+CgpJIHdvdWxkIGNhdXRpb24geW91IHRoYXQg SSB0aGluayB0aGF0IGlzIHNvbWV0aGluZyB5b3UncmUgZ29pbmcgdG8gaGF2ZQoKPgoKdG8gZ3Jh cHBsZSB3aXRoIG11Y2ggc29vbmVyIHRoYW4geW91IHRoaW5rLgoKPgoKPgoKQSBsb25nIHRpbWUg YWdvIHdlIGhhZCBkZXZlbG9wZWQgYSBzbWFsbCBLZXJiZXJvcyBwcm94eSB0aGF0IGZvcndhcmRl ZAoKPgoKb24gS2VyYmVyb3MgbWVzc2FnZXMgYnkgcHJlcGVuZGluZyB0aGUgc291cmNlIElQIGFk ZHJlc3MvcG9ydCB0byB0aGUKCj4KClVEUCBtZXNzYWdlIChvdXIgS0RDIGF0IHRoZSB0aW1lIHdh cyBtb2RpZmllZCB0byByZWNvZ25pemUgdGhpcwoKPgoKYW5kIHNlbnQgdGhlIHByZXBlbmRlZCBi eXRlcyBiYWNrIHRvIHRoZSBwcm94eSBzbyBpdCBjb3VsZCBzZW5kIGl0IHRvCgo+Cgp0aGUgY29y cmVjdCBvcmlnaW5hdG9yKS4=

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)