headers
Shawn M Emery | 5 Jun 2007 01:59
Picon

GSS API v2: C# Bindings


The kitten-wg is in need of an editor to continue work on the GSS API v2 
C# bindings draft:

http://tools.ietf.org/html/draft-ietf-kitten-gssapi-csharp-bindings-00

The editor would be responsible for incorporating any changes from past 
and future reviewer comments.  The past review comments by Horst 
Reiterer can be found here:

http://www1.ietf.org/mail-archive/web/kitten/current/msg00743.html

The kitten-wg would also like to have volunteers to review the -00 rev 
of this document.

Thank you,

--

-- 
Shawn - kitten-wg co-chair
Permalink | Reply | 0 comments |
headers
Peter Saint-Andre | 12 Jun 2007 00:42

domain-based service names redux

Warning: I am far from a Kerberos or SASL expert, and this email mostly 
channels feedback from several XMPP developers (cc'd on this message, 
also cc'ing sasl <at> ietf.org). My apologies for any inaccuracies.

That said...

I'm working to understand if draft-ietf-kitten-gssapi-domain-based-names 
and draft-ietf-kitten-krb5-gssapi-domain-based-names solve a problem 
we're having in the XMPP community. As you may know, XMPP (RFC 3920) 
essentially streams XML over a long-lived TCP connection. Large XMPP 
deployments tend to require tens of thousands of TCP connections (or 
more) from clients to a server, with the result that they are often 
architected with multiple connection managers (perhaps one CM per 10k 
clients) hooked into a core router. Client connections to the connection 
managers are often managed through a front-end load balancer. We can 
visualize as follows (where "CM" is a connection manager and "C" is a 
client):

             XMPP ROUTER
            /     |    \
          CM     CM     CM
            \     |    /
            LOAD BALANCER
            /     |    \
           C      C     C

(Such a solution *could* be managed via SRV, but in practice that is not 
feasible for some large XMPP deployments.)

The problem is that a client doesn't know which CM it has connected to
(Continue reading)

Permalink | Reply | 15 comments |
headers
Jeffrey Hutzelman | 12 Jun 2007 22:02
Picon
Favicon

Re: domain-based service names redux


On Monday, June 11, 2007 04:42:02 PM -0600 Peter Saint-Andre 
<stpeter <at> jabber.org> wrote:

> It is less clear to me how this service name should be communicated to
> the XMPP client. Currently in some XMPP implementations the Service
> Principal Name of the connection manager is returned to the client from
> the CM after the TCP connection is made (typically after TLS has been
> negotiated):
>
> http://mail.jabber.org/pipermail/xmppwg/2006-April/002379.html
>
> This is a mere assertion, but no one in the XMPP community has yet
> figured out a better method for communicating the CM's name to the client
> (at least in a way that is deployable in existing organizational
> environments).

So, the model we had in mind was that you'd do a SRV record or reverse DNS 
lookup and use the result of that for the "hostname" part of the 
domain-based service name, with the "domain" part being whatever domain the 
client was configured to talk to.  Of course, that doesn't work when you 
use a "transparent" load balancer; as you noted, you need some other way of 
discovering the hostname.

> My reading
> of draft-ietf-kitten-gssapi-domain-based-names indicates that the
> "hostname" portion of the GSS_C_NT_DOMAINBASED_SERVICE name may be
> obtained via insecure service discovery mechanisms (DNS SRV is mentioned)
> as long as the service and domain are obtained in a secure fashion. Would
> communication of the GSS_C_NT_DOMAINBASED_SERVICE name after TLS
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Rex | 12 Jun 2007 23:03
Picon
Favicon

Re: domain-based service names redux

Peter Saint-Andre wrote:
> 
>              XMPP ROUTER
>             /     |    \
>           CM     CM     CM
>             \     |    /
>             LOAD BALANCER
>             /     |    \
>            C      C     C
> 
> The problem is that a client doesn't know which CM it has connected to 
> (e.g., cm6.example.com), since that information is hidden by the load 
> balancer in the middle (all clients appear to be connected to the IP 
> address of the load balancer). For non-Kerberos deployments that doesn't 
> matter, but it does matter for Kerberos deployments since a client needs 
> to know the address of its service.

I never liked hostbased service names ;-)

For "old-fashioned" 2-token Kerberos authentication (which is the
authentication exchange currently covered by the official Kerberos 5
gssapi mechanisms (rfc-1964 and rfc-4121), the sharing of the
server credentials is a problem.  (session replay to servers sharing
credentials but not sharing the replay cache).

If Kerberos user2user authentication is used (exclusively), such a
vulnerability from sharing the server credentials does not exist.
Microsoft has implemented the 3-token user2user authentication exchange
in addition to the 2-token authentication exchange of the IETF-defined
Kerberos 5 gssapi mechanism, it has already been available in Windows 2000.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Peter Saint-Andre | 14 Jun 2007 20:33

Re: domain-based service names redux

Martin Rex wrote:
> Peter Saint-Andre wrote:
>>              XMPP ROUTER
>>             /     |    \
>>           CM     CM     CM
>>             \     |    /
>>             LOAD BALANCER
>>             /     |    \
>>            C      C     C
>>
>> The problem is that a client doesn't know which CM it has connected to 
>> (e.g., cm6.example.com), since that information is hidden by the load 
>> balancer in the middle (all clients appear to be connected to the IP 
>> address of the load balancer). For non-Kerberos deployments that doesn't 
>> matter, but it does matter for Kerberos deployments since a client needs 
>> to know the address of its service.
> 
> I never liked hostbased service names ;-)
> 
> For "old-fashioned" 2-token Kerberos authentication (which is the
> authentication exchange currently covered by the official Kerberos 5
> gssapi mechanisms (rfc-1964 and rfc-4121), the sharing of the
> server credentials is a problem.  (session replay to servers sharing
> credentials but not sharing the replay cache).
> 
> If Kerberos user2user authentication is used (exclusively), such a
> vulnerability from sharing the server credentials does not exist.
> Microsoft has implemented the 3-token user2user authentication exchange
> in addition to the 2-token authentication exchange of the IETF-defined
> Kerberos 5 gssapi mechanism, it has already been available in Windows 2000.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jeffrey Hutzelman | 14 Jun 2007 21:05
Picon
Favicon

Re: domain-based service names redux


On Thursday, June 14, 2007 12:33:45 PM -0600 Peter Saint-Andre 
<stpeter <at> jabber.org> wrote:

> It's not clear to me how the session replay attack you mention is
> specific to the architecture I described. Couldn't an attacker send an
> earlier ticket even if there is only one service involved (i.e., in my
> description, only one connection manager)?

The basic Kerberos protocol provides only a limited amount of reply 
protection for applications, by requiring that clients include in their 
request a timestamp which must be "close enough" to the server's clock. 
The idea is that you get full replay protection by combining this with a 
cache which stores all messages received within the "close enough" period 
-- messages that are too old are rejected outright; more recent messages 
are rejected if they appear in the replay cache.  This only works if 
servers which share the same service key also share the same replay cache.

(BTW, the details of Kerberos are getting just a bit far afield for the 
Kitten list; at the GSS-API layer you're not supposed to care much what 
mechanism is being used, and at the SASL layer you should care even less).

Depending on the application involved, this may not be an issue.  For 
example, some application protocols are designed such that the application 
messages themselves are protected from replays, or require some sort of 
initial exchange that makes a replay impossible.

Similarly, you have to see a message to replay it, so if you are always 
using TLS _and checking the server's certificate_, then you need not worry 
about your credentials being replayed to a server.  Of course, servers do
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jeffrey Hutzelman | 14 Jun 2007 22:24
Picon
Favicon

Re: domain-based service names redux

On Thu, 14 Jun 2007, Joe Hildebrand wrote:

> I'm not tracking what you meant by "not necessary".  Are you saying
> it's OK for the the CM to send it's service principal name to the
> client through an insecure channel?

No; I'm saying that it is not necessary to make the security of
sasl-gss-krb5 dependent on the security of the TLS tunnel over which it is
run, and that therefore it would be a poor design choice to introduce such
a dependency by specifying a means for obtaining the service principal
name that depends on the security of that tunnel.

That said, if you are using domain-based service names and doing so
correctly, it _is_ OK for the CM to send the hostname part to the client
through an insecure channel, as long as the service and domain parts are
obtained securely -- for example, from the protocol spec and the user,
respectively.

That is, if the user wants to talk to the XMPP service at example.com,
then the only acceptable value for the service part is "xmpp" (per the
spec), and the only acceptable value for the domain part is "example.com"
(from the user).  The hostname can be obtained from the CM by any means
you want.

-- Jeff
Permalink | Reply | 1 comment |
headers
Joe Hildebrand | 14 Jun 2007 22:05
Gravatar

Re: domain-based service names redux


On Jun 14, 2007, at 1:05 PM, Jeffrey Hutzelman wrote:

> Also, "the connection manager has provided appropriate credentials"  
> is unfortunately not a very good presumption.  Between users  
> ignoring warning dialogs, software that ships with who-knows-what  
> trust anchors, and software that just plain doesn't bother to  
> validate server credentials, it is often the case that a TLS  
> connection is established without the server actually proving its  
> identity.  While this may be the best you can do for some  
> authentication methods, I would not count on it for the security of  
> Kerberos authentication, where it clearly is not necessary.

I'm not tracking what you meant by "not necessary".  Are you saying  
it's OK for the the CM to send it's service principal name to the  
client through an insecure channel?

--

-- 
Joe Hildebrand
Permalink | Reply | 2 comments |
headers
Peter Saint-Andre | 14 Jun 2007 22:51

Re: domain-based service names redux

Jeffrey Hutzelman wrote:
> On Thu, 14 Jun 2007, Joe Hildebrand wrote:
> 
>> I'm not tracking what you meant by "not necessary".  Are you saying
>> it's OK for the the CM to send it's service principal name to the
>> client through an insecure channel?
> 
> No; I'm saying that it is not necessary to make the security of
> sasl-gss-krb5 dependent on the security of the TLS tunnel over which it is
> run, and that therefore it would be a poor design choice to introduce such
> a dependency by specifying a means for obtaining the service principal
> name that depends on the security of that tunnel.
> 
> 
> That said, if you are using domain-based service names and doing so
> correctly, it _is_ OK for the CM to send the hostname part to the client
> through an insecure channel, as long as the service and domain parts are
> obtained securely -- for example, from the protocol spec and the user,
> respectively.
> 
> That is, if the user wants to talk to the XMPP service at example.com,
> then the only acceptable value for the service part is "xmpp" (per the
> spec), and the only acceptable value for the domain part is "example.com"
> (from the user).  The hostname can be obtained from the CM by any means
> you want.

Aha, OK. In our case it is indeed true that (1) the only acceptable 
value for the service part is "xmpp" and (2) the domain part will be 
provided by the user. It also happens to be true that in a typical 
high-security deployment the hostname of the CM will be communicated
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shawn M Emery | 15 Jun 2007 06:54
Picon

Agenda Review


We've published the agenda proposed for the kitten-wg meeting in July here:

http://www3.ietf.org/proceedings/07jul/agenda/kitten.txt

Please provide any comments or questions.

Thank you,

--

-- 
Shawn.
Permalink | Reply | 0 comments |

Gmane