[Standards] TLS certificate fun

[Dave Cridland]

I'm implementing this at the moment, and noticing some aspects of
this that weren't apparent to me before.

There are a grand total of three different subject-alt-names we can
consider, and then the commonname components from the subject, too.
But there's no guidance on which combinations are correct, except
that we never consider the commonName components unless there's
nothing else.

After carefully reading RFC 4985, I think we shouldn't be using
SRVName to identify a remote entity, due to the closing points of its
Section 2.

This leaves id-on-xmppAddr and dNSName. The former is,according to
RFC 3920 Section 14.2, and similar text in Section 15.2 of the bis
draft, always preferred over the latter - ie, if the former exists,
the latter is ignored.

This means, amongst other things, that we cannot identify the XMPP
service responding to conference.jabber.org via the certificate it
presents, since it doesn't include an id-on-xmppAddr of
conference.jabber.org.

But wait, because rfc3920bis does state that, in 6.4.2, servers
SHOULD use a representation where jids MUST be included as a dNSName
- and conference.jabber.org does indeed match one of the
certificate's dNSNames. So essentially, it's sort of up to me whether
I accept its certificate, and what jids I authorize it to use.

However, the jabber.org server doesn't know if the connection it
opens to me has been authenticated as conference.jabber.org,
jabber.org, or both; unless it specifies one or the other in the SASL
EXTERNAL negotiation. - which of course will only tell it if I've
accepted that identity alone.

Moreover, it has no way to communicate to me whether or not it
accepts my certificate - so I don't know if I've authenticated, and
therefore I don't know if I can send anything.

Now, of course, both ends can clearly communicate whether they've
received data with a from JID they don't consider authenticated. The
bad news is that <invalid-from/> is a stream error, and will
therefore close the connection. This is not what one might call fun.

So far, then, this leaves me thinking that the only way to use TLS
and SASL EXTERNAL is to use unidirectional streams, one per domain,
which leaves us worse, in terms of efficiency, than dialback.

This doesn't seem like it should be right, somehow...

Dave.
--
Dave Cridland - mailto:dave (AT) cridland (DOT) net - xmpp:dwd (AT) jabber (DOT) org
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[Dave Cridland]

On Tue May 13 13:50:14 2008, Dave Cridland wrote:
> However, the jabber.org server doesn't know if the connection it
> opens to me has been authenticated as conference.jabber.org,
> jabber.org, or both; unless it specifies one or the other in the
> SASL EXTERNAL negotiation. - which of course will only tell it if
> I've accepted that identity alone.
>
>
Further thought - if it sends dialback to me when I recognise and
accept its certificate, I can reasonably choose to return acceptances
of them without actually dialling back, trusting that given the TLS
certificate, I can assume they work.

This means that the SASL EXTERNAL actually becomes optional, but it
also means that at least TLS is no worse than dialback in terms of
efficiency.


> Moreover, it has no way to communicate to me whether or not it
> accepts my certificate - so I don't know if I've authenticated, and
> therefore I don't know if I can send anything.

I could, of course, send jabber.org dialback requests through the
connection it's opened to me, given that I trust that it's
jabber.org. However, sending dialback requests from the receiver to
the originator is unusual - do people think it'd be safe to do this?

Dave.
--
Dave Cridland - mailto:dave (AT) cridland (DOT) net - xmpp:dwd (AT) jabber (DOT) org
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[Justin Karneges]

On Tuesday 13 May 2008 5:50 am, Dave Cridland wrote:
> After carefully reading RFC 4985, I think we shouldn't be using
> SRVName to identify a remote entity, due to the closing points of its
> Section 2.

Right, we shouldn't use this, since XMPP-Core does not specify that it should
be used. But this may change.

> This leaves id-on-xmppAddr and dNSName. The former is,according to
> RFC 3920 Section 14.2, and similar text in Section 15.2 of the bis
> draft, always preferred over the latter - ie, if the former exists,
> the latter is ignored.
>
> This means, amongst other things, that we cannot identify the XMPP
> service responding to conference.jabber.org via the certificate it
> presents, since it doesn't include an id-on-xmppAddr of
> conference.jabber.org.
>
> But wait, because rfc3920bis does state that, in 6.4.2, servers
> SHOULD use a representation where jids MUST be included as a dNSName
> - and conference.jabber.org does indeed match one of the
> certificate's dNSNames. So essentially, it's sort of up to me whether
> I accept its certificate, and what jids I authorize it to use.

"Sort of up to me" sounds like there's guesswork. Compare a jid against the
certificate according to the rules, and you'll know if it is authorizable.

> However, the jabber.org server doesn't know if the connection it
> opens to me has been authenticated as conference.jabber.org,
> jabber.org, or both; unless it specifies one or the other in the SASL
> EXTERNAL negotiation. - which of course will only tell it if I've
> accepted that identity alone.

Yes. I believe authzid is necessary with SASL EXTERNAL. And yes, you can
only authorize one identity per TCP connection.

> Moreover, it has no way to communicate to me whether or not it
> accepts my certificate - so I don't know if I've authenticated, and
> therefore I don't know if I can send anything.

The receiving entity is authorized as whatever domain was present in the
stream 'to' attribute sent by the initiating entity. This field is optional
if you plan to use dialback, but required if you plan to use TLS/SASL.

> Now, of course, both ends can clearly communicate whether they've
> received data with a from JID they don't consider authenticated. The
> bad news is that <invalid-from/> is a stream error, and will
> therefore close the connection. This is not what one might call fun.

Don't need to go there. :)

> So far, then, this leaves me thinking that the only way to use TLS
> and SASL EXTERNAL is to use unidirectional streams, one per domain,
> which leaves us worse, in terms of efficiency, than dialback.

Yep, this is how it is.

-Justin

[Shumon Huque]

On Tue, May 13, 2008 at 01:50:14PM +0100, Dave Cridland wrote:
>
> After carefully reading RFC 4985, I think we shouldn't be using
> SRVName to identify a remote entity, due to the closing points of its
> Section 2.

Hi Dave,

I assume you're referring to the following:

--
A present SRVName in a certificate MUST NOT be used to identify a
host unless one of the following conditions applies:

* Use of this name form is specified by the security protocol being
used and the identified service has a defined service name
according to RFC 2782, or;
--

This just means that if XMPP wants to use SRVName then it
should explicitly say so in 3920bis. And that's exactly what
some of us are proposing.

I think the intent of the text is to exclude implicit use
of this SAN name form. Otherwise other application protocols
(that use RFC2782) that have their own preferred method of
subject identification would each have to explicitly put in
text in their own specs to exclude the use of RFC4985.

I personally think we want to encourage the use of a generalized
name form rather than an XMPP specific one. It will be much
easier to get commercial CAs and other entities down the road
to issue certs with general purpose extensions.

--Shumon.

[Dave Cridland]

On Tue May 13 17:16:39 2008, Shumon Huque wrote:
> I personally think we want to encourage the use of a generalized
> name form rather than an XMPP specific one. It will be much
> easier to get commercial CAs and other entities down the road
> to issue certs with general purpose extensions.

Kind of - I'd prefer that certificates intended to be used as
authorization to act as a particular jid should use id-on-xmppAddr.

XMPP Peer/Server identification is a particular case of this, but can
also be treated as a general form of SRV based lookup and
authentication, so either is probably useful in this case. Note that
servers using RFC 4985 would either require different certficates on
C2S and S2S ports, or else use a certificate with at least two
SRVNames.

My (cynical) bet is that obtaining a single certificate with multiple
SRVNames will be just as hard/expensive/annoying as it is to obtain a
certificate with id-on-xmppAddr in - if for no other reason than the
commercial CAs will spot a way of making more money by forcing you to
get two certificates for the price of two, whereas the xmppAddr style
is at least usable for all XMPP-related purposes, including C2S
client authentication.

Dave.
--
Dave Cridland - mailto:dave (AT) cridland (DOT) net - xmpp:dwd (AT) jabber (DOT) org
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[Dave Cridland]

On Tue May 13 16:38:22 2008, Justin Karneges wrote:
> On Tuesday 13 May 2008 5:50 am, Dave Cridland wrote:
> > After carefully reading RFC 4985, I think we shouldn't be using
> > SRVName to identify a remote entity, due to the closing points of
> its
> > Section 2.
>
> Right, we shouldn't use this, since XMPP-Core does not specify that
> it should
> be used. But this may change.
>
>
Right.


> > This leaves id-on-xmppAddr and dNSName. The former is,according to
> > RFC 3920 Section 14.2, and similar text in Section 15.2 of the bis
> > draft, always preferred over the latter - ie, if the former
> exists,
> > the latter is ignored.
> >
> > This means, amongst other things, that we cannot identify the XMPP
> > service responding to conference.jabber.org via the certificate it
> > presents, since it doesn't include an id-on-xmppAddr of
> > conference.jabber.org.
> >
> > But wait, because rfc3920bis does state that, in 6.4.2, servers
> > SHOULD use a representation where jids MUST be included as a
> dNSName
> > - and conference.jabber.org does indeed match one of the
> > certificate's dNSNames. So essentially, it's sort of up to me
> whether
> > I accept its certificate, and what jids I authorize it to use.
>
> "Sort of up to me" sounds like there's guesswork. Compare a jid
> against the
> certificate according to the rules, and you'll know if it is
> authorizable.
>
>
Sure. Which rules, given that there are two sets in rfc3920bis? And
how do I know which you're using?


> Yes. I believe authzid is necessary with SASL EXTERNAL. And yes,
> you can
> only authorize one identity per TCP connection.
>
>
Ah... Firstly, authzid isn't required for SASL EXTERNAL - you can
request that the other end uses the default - but it's certainly a
sensible choice here. Secondly, this seems like a step down in terms
of efficiency.

> The receiving entity is authorized as whatever domain was present
> in the
> stream 'to' attribute sent by the initiating entity. This field is
> optional
> if you plan to use dialback, but required if you plan to use
> TLS/SASL.

Okay, so we assume that the S2S originator authenticates us if it
continues to use SASL EXTERNAL? That's okay, I suppose - what mildly
concerns me is that the S2S originator is forced into trusting the
reciever even if the receiver's certificate is not trustworthy, but I
can't think of a reason why you'd want to authenticate anyway if that
meant you weren't happy to receive stanzas. So yeah, I'll go along
with this, with some relief.

This gets us as far as a bidirectional channel between identities.

Now, if each server has two identities, both represented in the same
certificate, then this would mean 4 connections, whereas we currently
use 2 unidirectional streams. This seems a bit silly, so I was
wondering how to reduce this.

So consider a server A with two identities A-1 and A-2, contacting a
server B, which has identities B-1 and B-2. If A uses identity A-1 in
its SASL EXTERNAL, and addresses streams to B-1, then A and B know
they have authenicated each other as A-1 and B-1.

It seems logical that if a server A sends a stanza to server B from a
jid which relates to A-1, to a jid which relates to identity B-2,
then B can then assume that A will accept stanzas from B-2. This
really suggests that on connection, both ends could ping the other's
known identities, so the traffic immediately after A authenticates
with SASL EXTERNAL to B would be pings from A-1 to B-2, and B-1 to
A-2, thus reducing the connections to a single bidirectional
connection.

The problem is that any identity that is only matched by the
certificate using wildcards isn't going to be known to the other side
- not sure how we might handle that, although using a simple <iq/> to
ask the other side would work, it'd just need stream features to
support it, so not be as cleanly backwards compatible.

Dave.
--
Dave Cridland - mailto:dave (AT) cridland (DOT) net - xmpp:dwd (AT) jabber (DOT) org
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[Justin Karneges]

On Tuesday 13 May 2008 9:51 am, Dave Cridland wrote:
> On Tue May 13 16:38:22 2008, Justin Karneges wrote:
> > "Sort of up to me" sounds like there's guesswork. Compare a jid
> > against the
> > certificate according to the rules, and you'll know if it is
> > authorizable.
>
> Sure. Which rules, given that there are two sets in rfc3920bis? And
> how do I know which you're using?

Two sets?

> > Yes. I believe authzid is necessary with SASL EXTERNAL. And yes,
> > you can
> > only authorize one identity per TCP connection.
>
> Ah... Firstly, authzid isn't required for SASL EXTERNAL - you can
> request that the other end uses the default - but it's certainly a
> sensible choice here.

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.

> > The receiving entity is authorized as whatever domain was present
> > in the
> > stream 'to' attribute sent by the initiating entity. This field is
> > optional
> > if you plan to use dialback, but required if you plan to use
> > TLS/SASL.
>
> Okay, so we assume that the S2S originator authenticates us if it
> continues to use SASL EXTERNAL? That's okay, I suppose - what mildly
> concerns me is that the S2S originator is forced into trusting the
> reciever even if the receiver's certificate is not trustworthy, but I
> can't think of a reason why you'd want to authenticate anyway if that
> meant you weren't happy to receive stanzas. So yeah, I'll go along
> with this, with some relief.

The initiatior is not forced into trusting the receiver. It nukes the TCP
connection if the receiver's certificate is no good, before proceeding to
SASL.

> This gets us as far as a bidirectional channel between identities.

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.

> Now, if each server has two identities, both represented in the same
> certificate, then this would mean 4 connections, whereas we currently
> use 2 unidirectional streams. This seems a bit silly, so I was
> wondering how to reduce this.

Right. It is not as efficient as dialback.

> So consider a server A with two identities A-1 and A-2, contacting a
> server B, which has identities B-1 and B-2. If A uses identity A-1 in
> its SASL EXTERNAL, and addresses streams to B-1, then A and B know
> they have authenicated each other as A-1 and B-1.
>
> It seems logical that if a server A sends a stanza to server B from a
> jid which relates to A-1, to a jid which relates to identity B-2,
> then B can then assume that A will accept stanzas from B-2. This
> really suggests that on connection, both ends could ping the other's
> known identities, so the traffic immediately after A authenticates
> with SASL EXTERNAL to B would be pings from A-1 to B-2, and B-1 to
> A-2, thus reducing the connections to a single bidirectional
> connection.
>
> The problem is that any identity that is only matched by the
> certificate using wildcards isn't going to be known to the other side
> - not sure how we might handle that, although using a simple <iq/> to
> ask the other side would work, it'd just need stream features to
> support it, so not be as cleanly backwards compatible.

Optimizing SASL-based s2s would be nice. I'm not sure if I agree with the
ping approach though. I'd have to give it more thought. Dialback
doesn't "probe" for known identities, so I don't think we need that here.
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.

-Justin

[Dave Cridland]

On Tue May 13 19:29:33 2008, Justin Karneges wrote:
> On Tuesday 13 May 2008 9:51 am, Dave Cridland wrote:
> > On Tue May 13 16:38:22 2008, Justin Karneges wrote:
> > > "Sort of up to me" sounds like there's guesswork. Compare a jid
> > > against the
> > > certificate according to the rules, and you'll know if it is
> > > authorizable.
> >
> > Sure. Which rules, given that there are two sets in rfc3920bis?
> And
> > how do I know which you're using?
>
> 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.


> > > Yes. I believe authzid is necessary with SASL EXTERNAL. And
> yes,
> > > you can
> > > only authorize one identity per TCP connection.
> >
> > Ah... Firstly, authzid isn't required for SASL EXTERNAL - you can
> > request that the other end uses the default - but it's certainly a
> > sensible choice here.
>
> 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.


> > > The receiving entity is authorized as whatever domain was
> present
> > > in the
> > > stream 'to' attribute sent by the initiating entity. This
> field is
> > > optional
> > > if you plan to use dialback, but required if you plan to use
> > > TLS/SASL.
> >
> > Okay, so we assume that the S2S originator authenticates us if it
> > continues to use SASL EXTERNAL? That's okay, I suppose - what
> mildly
> > concerns me is that the S2S originator is forced into trusting the
> > reciever even if the receiver's certificate is not trustworthy,
> but I
> > can't think of a reason why you'd want to authenticate anyway if
> that
> > meant you weren't happy to receive stanzas. So yeah, I'll go
> along
> > with this, with some relief.
>
> The initiatior is not forced into trusting the receiver. It nukes
> the TCP
> connection if the receiver's certificate is no good, before
> proceeding to
> SASL.
>
>
Well, yes - there being no point I can think of in having a channel
there unless it's to be mutually trusted.


> > This gets us as far as a bidirectional channel between identities.
>
> 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.


> > Now, if each server has two identities, both represented in the
> same
> > certificate, then this would mean 4 connections, whereas we
> currently
> > use 2 unidirectional streams. This seems a bit silly, so I was
> > wondering how to reduce this.
>
> Right. It is not as efficient as dialback.
>
>
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.


> > So consider a server A with two identities A-1 and A-2,
> contacting a
> > server B, which has identities B-1 and B-2. If A uses identity
> A-1 in
> > its SASL EXTERNAL, and addresses streams to B-1, then A and B know
> > they have authenicated each other as A-1 and B-1.
> >
> > It seems logical that if a server A sends a stanza to server B
> from a
> > jid which relates to A-1, to a jid which relates to identity B-2,
> > then B can then assume that A will accept stanzas from B-2. This
> > really suggests that on connection, both ends could ping the
> other's
> > known identities, so the traffic immediately after A authenticates
> > with SASL EXTERNAL to B would be pings from A-1 to B-2, and B-1 to
> > A-2, thus reducing the connections to a single bidirectional
> > connection.
> >
> > The problem is that any identity that is only matched by the
> > certificate using wildcards isn't going to be known to the other
> side
> > - not sure how we might handle that, although using a simple
> <iq/> to
> > ask the other side would work, it'd just need stream features to
> > support it, so not be as cleanly backwards compatible.
>
> Optimizing SASL-based s2s would be nice. I'm not sure if I agree
> with the
> ping approach though. I'd have to give it more thought. Dialback
> doesn't "probe" for known identities, so I don't think we need that
> here.
> 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.

Dave.
--
Dave Cridland - mailto:dave (AT) cridland (DOT) net - xmpp:dwd (AT) jabber (DOT) org
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[Shumon Huque]

On Tue, May 13, 2008 at 05:51:00PM +0100, Dave Cridland wrote:
> On Tue May 13 17:16:39 2008, Shumon Huque wrote:
> >I personally think we want to encourage the use of a generalized
> >name form rather than an XMPP specific one. It will be much
> >easier to get commercial CAs and other entities down the road
> >to issue certs with general purpose extensions.
>
> Kind of - I'd prefer that certificates intended to be used as
> authorization to act as a particular jid should use id-on-xmppAddr.

Of course, a potential application neutral option for this exists
as well: the uniformResourceIdentifier SAN fields populated with
jids in the xmpp URI scheme, eg. xmpp:stpeter (AT) jabber (DOT) org.

> XMPP Peer/Server identification is a particular case of this, but can
> also be treated as a general form of SRV based lookup and
> authentication, so either is probably useful in this case. Note that
> servers using RFC 4985 would either require different certficates on
> C2S and S2S ports, or else use a certificate with at least two
> SRVNames.

Right ..

> My (cynical) bet is that obtaining a single certificate with multiple
> SRVNames will be just as hard/expensive/annoying as it is to obtain a
> certificate with id-on-xmppAddr in - if for no other reason than the
> commercial CAs will spot a way of making more money by forcing you to
> get two certificates for the price of two,

You might be right about that. I wonder if commercial CAs charge more
for issuing certificates with multiple dNSNames?

> whereas the xmppAddr style
> is at least usable for all XMPP-related purposes, including C2S
> client authentication.

Again URI is an alternative option here ..

--Shumon.

[Justin Karneges]

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?

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

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

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

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

-Justin

[Dave Cridland]

Let's give this one a different subject, then, eh?

On Tue May 13 20:12:53 2008, Shumon Huque wrote:
> On Tue, May 13, 2008 at 05:51:00PM +0100, Dave Cridland wrote:
> > On Tue May 13 17:16:39 2008, Shumon Huque wrote:
> > >I personally think we want to encourage the use of a generalized
> > >name form rather than an XMPP specific one. It will be much
> > >easier to get commercial CAs and other entities down the road
> > >to issue certs with general purpose extensions.
> >
> > Kind of - I'd prefer that certificates intended to be used as
> > authorization to act as a particular jid should use
> id-on-xmppAddr.
>
> Of course, a potential application neutral option for this exists
> as well: the uniformResourceIdentifier SAN fields populated with
> jids in the xmpp URI scheme, eg. xmpp:stpeter (AT) jabber (DOT) org.
>
>
xmpp://stpeter (AT) jabber (DOT) org maybe. For this instance, I'm not sure.
Would xmpp:stpeter (AT) jabber (DOT) org provide authentication to talk to PSA?
:-)

I'm not convinced, because I don't know what it's intended to mean.

> > My (cynical) bet is that obtaining a single certificate with
> multiple
> > SRVNames will be just as hard/expensive/annoying as it is to
> obtain a
> > certificate with id-on-xmppAddr in - if for no other reason than
> the
> > commercial CAs will spot a way of making more money by forcing
> you to
> > get two certificates for the price of two,
>
> You might be right about that. I wonder if commercial CAs charge
> more
> for issuing certificates with multiple dNSNames?
>
>
I've no idea. It doesn't appear so, they just sign the CSR. But given
that the specifications (and entire point of PKI) mandate that they
check the Subject and every SAN, I think they'd probably be justified
in charging a bit more, to be fair.


> > whereas the xmppAddr style
> > is at least usable for all XMPP-related purposes, including C2S
> > client authentication.
>
> Again URI is an alternative option here ..

Yes, but historically, X.509 has simply had specific bits for each
usage, so ORNames for signing email, and similar identifiers to act
as P1 channels. Only DAP/LDAP have been immune from this, and really
because their concept of identity and identifiers is fundamental to
X.509 anyway, hence the DNs used for Subject and Issuer.

I've actually no idea what the URI General Name is for, but it
wouldn't surprise me if it has a very specific purpose that XMPP
authentication wouldn't fit. In lieu of wild guesses, though, I'll
ask the guy who sits next to me here, who's pretty knowledgeable on
X.509, and no doubt spawn an exciting office debate on the finer
details of the X.500 series.

(Yeah, we have to remind people here it's not X.MPP...)

Dave.
--
Dave Cridland - mailto:dave (AT) cridland (DOT) net - xmpp:dwd (AT) jabber (DOT) org
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[Dave Cridland]

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:dave (AT) cridland (DOT) net - xmpp:dwd (AT) jabber (DOT) org
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[Peter Saint-Andre]

On 05/13/2008 2:44 PM, Dave Cridland wrote:
> Let's give this one a different subject, then, eh?
>
> On Tue May 13 20:12:53 2008, Shumon Huque wrote:
>> On Tue, May 13, 2008 at 05:51:00PM +0100, Dave Cridland wrote:
>> > On Tue May 13 17:16:39 2008, Shumon Huque wrote:
>> > >I personally think we want to encourage the use of a generalized
>> > >name form rather than an XMPP specific one. It will be much
>> > >easier to get commercial CAs and other entities down the road
>> > >to issue certs with general purpose extensions.
>> >
>> > Kind of - I'd prefer that certificates intended to be used as
>> > authorization to act as a particular jid should use id-on-xmppAddr.
>>
>> Of course, a potential application neutral option for this exists
>> as well: the uniformResourceIdentifier SAN fields populated with
>> jids in the xmpp URI scheme, eg. xmpp:stpeter (AT) jabber (DOT) org.
>>
>>
> xmpp://stpeter (AT) jabber (DOT) org maybe. For this instance, I'm not sure. Would
> xmpp:stpeter (AT) jabber (DOT) org provide authentication to talk to PSA? :-)
>
> I'm not convinced, because I don't know what it's intended to mean.

it = the URI?

Back in the dark ages of discussion about XMPP URIs, our illustrious
area director at the IETF suggested that we could specify an entity to
authorize *as* by including that identity as the authority component.

So if you want people to be able to log in as guest (AT) example (DOT) com, the URI
would be:

xmpp://guest (AT) example (DOT) com

If you want people to be able to log in as guest (AT) example (DOT) com and send a
message to support (AT) example (DOT) com, the URI would be

xmpp://guest (AT) example (DOT) com/support (AT) example (DOT) com?message

Yes this looks confusing. That's because it is. Basically just ignore
the authority component, i.e., don't include it in XMPP URIs. :)

>> > My (cynical) bet is that obtaining a single certificate with multiple
>> > SRVNames will be just as hard/expensive/annoying as it is to obtain a
>> > certificate with id-on-xmppAddr in - if for no other reason than the
>> > commercial CAs will spot a way of making more money by forcing you to
>> > get two certificates for the price of two,
>>
>> You might be right about that. I wonder if commercial CAs charge more
>> for issuing certificates with multiple dNSNames?

The XMPP ICA doesn't charge any money. :P

> I've no idea. It doesn't appear so, they just sign the CSR. But given
> that the specifications (and entire point of PKI) mandate that they
> check the Subject and every SAN, I think they'd probably be justified in
> charging a bit more, to be fair.
>
>
>> > whereas the xmppAddr style
>> > is at least usable for all XMPP-related purposes, including C2S
>> > client authentication.
>>
>> Again URI is an alternative option here ..
>
> Yes, but historically, X.509 has simply had specific bits for each
> usage, so ORNames for signing email, and similar identifiers to act as
> P1 channels. Only DAP/LDAP have been immune from this, and really
> because their concept of identity and identifiers is fundamental to
> X.509 anyway, hence the DNs used for Subject and Issuer.
>
> I've actually no idea what the URI General Name is for, but it wouldn't
> surprise me if it has a very specific purpose that XMPP authentication
> wouldn't fit. In lieu of wild guesses, though, I'll ask the guy who sits
> next to me here, who's pretty knowledgeable on X.509, and no doubt spawn
> an exciting office debate on the finer details of the X.500 series.

And the result was...? :)

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Dave Cridland]

On Thu May 22 21:56:48 2008, Peter Saint-Andre wrote:
> >> Of course, a potential application neutral option for this exists
> >> as well: the uniformResourceIdentifier SAN fields populated with
> >> jids in the xmpp URI scheme, eg. xmpp:stpeter (AT) jabber (DOT) org.
> >>
> >>
> > xmpp://stpeter (AT) jabber (DOT) org maybe. For this instance, I'm not sure.
> Would
> > xmpp:stpeter (AT) jabber (DOT) org provide authentication to talk to PSA? :-)
> >
> > I'm not convinced, because I don't know what it's intended to
> mean.
>
> it = the URI?
>
> Back in the dark ages of discussion about XMPP URIs, our illustrious
> area director at the IETF suggested that we could specify an entity
> to
> authorize *as* by including that identity as the authority
> component.
>
> So if you want people to be able to log in as guest (AT) example (DOT) com,
> the URI
> would be:
>
> xmpp://guest (AT) example (DOT) com
>
> If you want people to be able to log in as guest (AT) example (DOT) com and
> send a
> message to support (AT) example (DOT) com, the URI would be
>
> xmpp://guest (AT) example (DOT) com/support (AT) example (DOT) com?message
>
> Yes this looks confusing. That's because it is. Basically just
> ignore
> the authority component, i.e., don't include it in XMPP URIs. :)
>
>
Right, but in *this* case, if the URI General Name is intended to
grant access *to* the contained URI, then a certificate containing
xmpp://stpeter (AT) jabber (DOT) org/ would grant access to authorize as
stpeter (AT) jabber (DOT) org.

Maybe.

> > I've actually no idea what the URI General Name is for, but it
> wouldn't
> > surprise me if it has a very specific purpose that XMPP
> authentication
> > wouldn't fit. In lieu of wild guesses, though, I'll ask the guy
> who sits
> > next to me here, who's pretty knowledgeable on X.509, and no
> doubt spawn
> > an exciting office debate on the finer details of the X.500
> series.
>
> And the result was...? :)

An exciting office debate on the finer details of the X.500 series,
of course. I was only lucky it didn't spill over onto discussions of
X.400, which has the unique ability to make X.509 suddenly seem quite
interesting.

I shall ask quietly over email. :-)

Dave.
--
Dave Cridland - mailto:dave (AT) cridland (DOT) net - xmpp:dwd (AT) jabber (DOT) org
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[Peter Saint-Andre]

On 05/13/2008 2:47 PM, Dave Cridland wrote:
> 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.

The text in bis-04 is out of date with the emerging consensus, which is
why it needs to be seriously revised or replaced. I need to find time to
crank out bis-05...

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Peter Saint-Andre]

On 05/13/2008 2:47 PM, Dave Cridland wrote:
> 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.

Is the new text clearer?

http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-05.html#security-certificates

Perhaps I'll post it to the list here as a new thread so that folks can
comment on it....

Peter

--
Peter Saint-Andre
https://stpeter.im/