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



_______________________________________________
Kitten mailing list
Kittenlists.ietf.org
https:/
/www1.ietf.org/mailman/listinfo/kitten

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 
from the CM to the user over a TLS-encrypted XML stream;
however, at an 
implementation level TLS is not yet required in XMPP so it
possible that 
the hostname of the CM may be communicated over an XML
stream that is 
not TLS-encrypted -- but you are saying that doesn't matter
anyway.

BTW this issue will probably not be addressed in rfc3920bis
because it 
is a bit of an edge case that is useful only for certain
deployments, 
but we will probably define an XMPP extension for this
functionality in 
a spec produced by the XMPP Standards Foundation.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://w
ww.xmpp.org/xsf/people/stpeter.shtml


_______________________________________________
Kitten mailing list
Kittenlists.ietf.org
https:/
/www1.ietf.org/mailman/listinfo/kitten