On Tue May 13 20:37:39 2008, Justin Karneges wrote:
On Tuesday 13 May 2008 11:40 am, Dave Cridland wrote:
> On Tue May 13 19:29:33 2008, Justin Karneges wrote:
> > Two sets?
>
> Yes. One that says "If any xmppAddr is present, use only
xmppAddr",
> another that says "but fallback to dNSName". This is okay as long
as
> both ends know which identities are authenticated.
3920, section 14.2, case #1 essentially says that if the xmpp field
is present
then use it, otherwise fall back to dNSName (and then commonName).
Where is
the other set of rules?
Hmmm... I suppose you could read that as the method for checking
certificates, and 6.4.2 as the method for generating them. I think
both could be a lot clearer, though.
> > I'm not sure how you work out a default authzid from a
certificate,
> > but
> > assuming there's an unambiguous way to do that then yes this
would
> > be fine.
>
> There isn't, this is highlighting that we need to ensure that an
> authzid is explicitly stated.
Right, so in the context of XMPP, we'd require an authzid when using
certificate auth.
Well, you'd want to say that XMPP servers SHOULD supply an explicit
authorization identifer when using SASL. The mechanism is probably
immaterial, and SASL has no concept of "certificate auth", nor does
X.509 have any concept of an authorization identifer. But this is
nitpicking.
> > Yes, a mutually authenticated bidirectional channel. To clarify
> > though, if
> > this is an s2s channel then stanzas can only flow in the
> > initiator->receiver
> > direction.
>
> Why? If it's mutually authenticated, this seems silly.
I asked the same thing in 2004. :) The stanza direction issue has
nothing to
do with mutual authentication. Dialback streams are also mutually
authenticated, and non-stanza traffic can be exchanged
bidirectionally. It's
just a historic property of s2s channels to be unidirectional for
stanzas.
Maybe this helps with race conditions when two servers contact each
other at
the same time, or maybe helps with load balancing (different
machines for
outbound/inbound). I dunno. This is just how it is in the spec.
So I see. Section 4.4 in the bis draft. Makes no sense, and in
particular, we've established and agreed that each peer does
authenticate with the other.
I suppose the inbound/outbound split might make sense, but I'm not
convinced - but if it's important, a signalling mechanism might make
sense. See below.
> Drastically so for deployments with significant numbers of
> identities. Two servers with two identities need 4 bidirectional
> channels, or 8 unidirectional channels. Two servers with three
> identities would need 18 unidirectional channels - you need N*M
> directions.
Oops, you're right. 8 connections for two servers with two
identities.
A1->B1, A1->B2, A2->B1, A2->B2, and then the reverse for each.
Of course, I'm not right in my equation - you need 2*N*M directions,
or N*M bidirectional channels. So if you have a couple of servers
with MUC and PubSub services, that's 18 unidirectional channels,
potentially, between them. Of course, typically, we wouldn't expect
MUC and PubSub channels to cross-talk, so that's probably only 6, but
that could very easily change if we get the concept of chaining those
services.
> > We'd just need a way to specify additional explicit from/to
domains
> > on an
> > as-needed basis (exactly like dialback), which also avoids
wildcard
> > problems.
>
> *nods* I think dialback itself will essentially work, the trouble
is
> that an originator won't be expecting a dialback initiated by the
> receiver.
>
> Dialback is an assertion that states "I am this identity".
Typically,
> the receiver tests the assertion by dialling back, but
realistically,
> nothing stops the receiver testing the assertion by checking a
> certificate associated with the channel.
True. What we'd want to prevent is the receiver actually dialing
back though,
since, as you say, the initiator would not be expecting it in a
pure-SASL
case.
There could be a stream feature offered by the receiver, that
indicates
<db:result> may be used post-TLS/SASL auth for adding more
cert-based
identities. Hmmm.. at that point I'd suggest just using a new
element
rather than hijacking the dialback ones, to reduce confusion. They
are so
simple anyway.
*nods* The advantage of dialback is that if the assertion is
unsupportable by the TLS certificate presented, then there's another
option to validate it if the recipient of the dialback so chooses.
Okay, so a feature, definitely. You'd need to signal that it was
supported by the originator, too, so it'd need a "I don't have any
more identities I want to tell you about" form.
Each identity would need individual positive and negative responses.
Absence of the feature being negotiated would, presumably, also mean
that the stream would have to be unidirectional. (Maybe we have an
explicit signal on this too, so you can setup odd combinations, where
you say that you'd like to be able to send stanzas for a domain, but
you can't receive them.).
Question is, is this an <iq/>, a <db:result/>, or is this a new
element entirely?
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
