Subject: [xmpp] Finalizing draft-ietf-xmpp-3920bis-12

From: Ben Campbell <[email-masked]>
Date: Thu, 12 Aug 2010 14:23:02 -0500

Hi,

It looks like we are very close to being ready to request publication of draft-ietf-xmpp-3920bis. It looks like all the open issues have been closed. But before we publish it, we'd like people to make one last "proof reading" pass. There's been a number of changes from the two WGLCs, and we want to make sure that these have not introduced regression errors, cut and paste problems, etc.

Therefore we're declaring a "work group really-last-this-time proofreading call". This informal WGRLTTPC ends on 18 August, at close-of-business in whatever time zone Peter happens to be at the time.

Thanks!

Ben.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 12 Aug 2010 14:07:41 -0600

On 8/12/10 1:23 PM, Ben Campbell wrote:
> Hi,
> 
> It looks like we are very close to being ready to request publication
> of draft-ietf-xmpp-3920bis. It looks like all the open issues have
> been closed. But before we publish it, we'd like people to make one
> last "proof reading" pass. There's been a number of changes from the
> two WGLCs, and we want to make sure that these have not introduced
> regression errors, cut and paste problems, etc.
> 
> Therefore we're declaring a "work group really-last-this-time
> proofreading call". This informal WGRLTTPC ends on 18 August, at
> close-of-business in whatever time zone Peter happens to be at the
> time.

Thanks, Ben. Last night I reviewed the diffs since -08 and found a few
typos, so I've fixed those in my working copy. I've also updated the
acknowledgements to at least thank those who provided WGLC feedback.
Once the proofreading call is done I'll submit a revised I-D for review
during IETF Last Call.

Peter

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

---

From: Kevin Smith <[email-masked]>
Date: Sat, 14 Aug 2010 12:59:40 +0100

> Therefore we're declaring a "work group really-last-this-time proofreading call". This informal WGRLTTPC ends on 18 August, at close-of-business in whatever time zone Peter happens to be at the tim…

Sorry that I've not reviewed the diffs for 3920bis yet. I'm finding it
difficult to find time for both 3921 and 3920 at once - I'll try and
get another pass in before WGRLTTPC ends.

/K

---

From: Philipp Hancke <[email-masked]>
Date: Tue, 17 Aug 2010 16:39:41 +0200

> Therefore we're declaring a "work group really-last-this-time proofreading call". This informal WGRLTTPC ends on 18 August, at close-of-business in whatever time zone Peter happens to be at the tim…

I simply re-read the whole thing again. Mostly minor issues, but there 
is a serious inconsistency about the inclusion of the authorization 
identity between XEP 0178 section 6.2.8...

XEP 0178 (s2s step 10) says that "Server1 SHOULD include an 
authorization identity [...]"
whereas section 6.2.8. tells us not to include or accept an 
authorization identity on s2s streams:
"MUST NOT attempt to negotiate an authorization identity" and
"MUST NOT accept an authorization identity".
Is there a strong to forbid the inclusion? If so, there needs to be a 
backward compability note, because servers do include one currently.

Other issues (labelled T for typos, E for minor editoral nitpicks):
1.3.
T: most deployed serverS
E: s/older dialback/dialback/

4.2.6.
E: s/older dialback/dialback/

4.6.1.:
"MUST set the value to one of its own hostnames"
A minor clarification: MUST set the value to the domain part of the 
'from' attribute of the stanza that caused the stream to be established 
- not just any of its own hostnames.

4.6.3.:
Is the id security critical for any other purpose than in dialback and 
legacy authentication? If not, it might be good to add a reference to 
that context in the security note.

4.7.4.:
s2s streams SHOULD declare for the 'jabber:server:dialback' namespace in 
the stream header for backward compability reasons. Strange things may 
happen otherwise, at least back in 2006. I have not seen that 
recommendation elsewhere, but we can put it into XEP 220, too.

4.8.1.4.:
E: The order of the bullets seems to be back to front. I would expect 
stream errors first, followed by explaining the difference to stanza 
errors since the section header is about stream errors.

4.8.3.14.:
this is no longer supposed to happen for dialback, so the text about 
that should be a backward compability note.

4.8.3.15.: 
 
This is supposed to be used as (not, see below) described in 13.7.2.3? 
It is also mentioned in the section about (avoiding) TLS renegotiation.

5.3.3.3.:
T: #2 'from' is used without single quotes here.

6.2.4.:
The example inside the parenthesis contains a criticial requirement.
What about changing that to:
If during prior TLS negotiation the initiating entity presented a
certificate that is acceptable to the receiving entity for purposes
of strong identity verification in accordance with local service
policies (e.g. because said certificate is unexpired, unrevoked and is
anchored to a root trusted by the receiving entity)
and the receiving entity expects that the initiating entity will be able 
to authenticate and authorize as the identity provided in the 
certificate [or in the streams 'from' attribute???], then ...

This mimicks the behaviour described in XEP 0178. However, there is a 
security consideration associated with that.
The receiving entity has to make a guess about the identity that the 
initiating entity will attempt to authorize as during the next step, 
i.e. it seeks a match for the stream 'from' attribute in the presented 
identifiers similar to what is described in TLS-CERTS section 4.3 before 
offering EXTERNAL. No problem so far.
Now the XEP 0178 strategy is not to offer EXTERNAL if there is no match.
This means that dialback will be used as a fallback, which hides the 
problem of a wrong certificate.

8.1.1.2.:
the domainpart of the JID in the 'to' attribute must have been 
previously negotiated, similar to 8.1.2.2.

9.1.:
T: mechanism as <[email-masked]"

13.7.2.3.:
What does "MUST perform a full re-authentication of the stream" mean? 
Given the <reset/> stream error i thought that the appropriate action is 
to terminate the stream.

Really-the-last-time?

philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Aug 2010 16:24:43 -0600

On 8/17/10 8:39 AM, Philipp Hancke wrote:
>> close-of-business in whatever time zone Peter happens to be at the time.
> 
> I simply re-read the whole thing again. 

Thanks for the extra review.

> Mostly minor issues, but there

On the plane to Maastricht recently I took the time to read XEP-0178
again and it needs to be significantly revised, in part to bring it into
line with 3920bis. I'll post about that to [email-masked] in the
near future.

> E: s/older dialback/dialback/

Fixed. I've also changed "server dialback" and mere "dialback" to
"Server Dialback" in all instances.

> - not just any of its own hostnames.

That's a good fix, thanks.

> that context in the security note.

As far as I know, the stream ID is security-critical only if it is
re-used during authentication, and I don't know of any SASL-based
authentication mechanisms that re-use it, so I think this note is
effectively limited to Server Dialback and jabber:iq:auth. However, I
suppose some future SASL mechanism might make use of the stream ID, too.
I've changed it to:

      Security Note: The stream ID MUST be both unpredictable and non-
      repeating because it can be security-critical when re-used by an
      authentication mechanisms, as is the case for Server Dialback
      [XEP-0220] and the "XMPP 0.9" authentication mechanism used before
      RFC 3920 defined the use of SASL in XMPP; for recommendations
      regarding randomness for security purposes, see [RANDOM].

Do you mean 4.7.3?

> recommendation elsewhere, but we can put it into XEP 220, too.

I don't think it's the place of 3920bis to say that servers SHOULD
declare the 'jabber:server:dialback' namespace. That "SHOULD" belongs in
XEP-0220.

However, we might want to add an interoperability note to 4.7.3 ("Other
Namespaces"), such as:

      Interoperability Note: For historical reasons, some server
      implementations expect a declaration of the 'jabber:server:
      dialback' namespace on server-to-server streams; for details, see
      [XEP-0220].

> errors since the section header is about stream errors.

Sure, that makes sense.

I think that belongs in XEP-0220.

I've added cross-references to those sections:

###

4.8.3.15.  reset

   The server is closing the stream because it has new (typically
   security-critical) features to offer, because the keys or
   certificates used to establish a secure context for the stream have
   expired or have been revoked during the life of the stream
   (Section 13.7.2.3), because the TLS sequence number has wrapped
   (Section 5.2.5), etc.

###

> T: #2 'from' is used without single quotes here.

Fixed.

> certificate [or in the streams 'from' attribute???], then ...

The existing sentence is horribly long. I suggest the following rewrite,
incorporating your suggestion (but taking it one step farther):

###

6.2.4.  Mechanism Offers

   If the receiving entity considers TLS negotiation (Section 5) to be
   mandatory before authentication via a particular SASL mechanism will
   be acceptable, the receiving entity MUST NOT advertise that mechanism
   in its list of available SASL mechanisms before TLS negotiation has
   been completed.

   The receiving entity MUST offer the SASL EXTERNAL mechanism if both
   of the following conditions hold:

   1.  During TLS negotiation the initiating entity presented a
       certificate that is acceptable to the receiving entity for
       purposes of strong identity verification in accordance with local
       service policies (e.g., because said certificate is unexpired, is
       unrevoked, and is anchored to a root trusted by the receiving
       entity).

   2.  The domain presented in or derived from the information in the
       certificate matches domainpart of the JID provided in the 'from'
       attribute of the initial stream header.

   However, the receiving entity MAY offer the SASL EXTERNAL mechanism
   under other circumstances, as well.

   When the receiving entity offers the SASL EXTERNAL mechanism, it
   SHOULD prefer that mechanism so that the parties have the potential
   to negotiate mutual authentication.

   Section 13.8 specifies SASL mechanisms that MUST be supported;
   naturally, other SASL mechanisms MAY be supported as well.

      Informational Note: Best practices for the use of SASL in the
      context of XMPP are described in [XEP-0175] for the ANONYMOUS
      mechanism and in [XEP-0178] for the EXTERNAL mechanism.

###

> problem of a wrong certificate.

TLS + Dialback is underspecified, but I don't think it's the task of
3920bis to specify it more fully; instead I think that XEP-0220 needs to
be updated to cover that case.

And see previous note about "authorization" in SASL EXTERNAL. I don't
think that concept applies to s2s streams.

> previously negotiated, similar to 8.1.2.2.

Good catch.

> T: mechanism as <[email-masked]"

Fixed. I found another instance in 13.7.1.4.

You are correct. I think this is clearer (a few text tweaks in the
bullet points and a rewritten paragraph after those):

###

13.7.2.3.  Checking of Certificates in Long-Lived Streams

   Because XMPP uses long-lived XML streams, it is possible that a
   certificate presented during stream negotiation might expire or be
   revoked while the stream is still live (this is especially relevant
   in the context of server-to-server streams).  Therefore, each party
   to a long-lived stream SHOULD:

   1.  Cache the expiration date of the certificate presented by the
       other party and any certificates on which that certificate
       depends (such as a root or intermediate certificate for a
       certification authority), and close the stream when any such
       certificate expires, with a stream error of <reset/>
       (Section 4.8.3.15).

   2.  Periodically query the Online Certificate Status Protocol [OCSP]
       responder listed in the Authority Information Access (AIA)
       extension of the certificate presented by the other party and any
       certificates on which that certificate depends (such as a root or
       intermediate certificate for a certification authority), and
       close the stream if any such certificate has been revoked, with a
       stream error of <reset/> (Section 4.8.3.15).

   After the stream is closed, the initiating entity from the closed
   stream will need to re-connect and the receiving entity will need to
   authenticate the initiating entity based on whatever certificate it
   presents during negotiation of the new stream.

###

> Really-the-last-time?

I hope so. :) Thanks again.

Peter

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

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 18 Aug 2010 12:04:01 +0200

Peter Saint-Andre wrote:
[...]
> line with 3920bis. I'll post about that to [email-masked] in the

XEP 0178 will certainly benefit that (especially the improved 
terminology in TLS-CERTS).
However, you can not change this issue there, since servers currently 
send and expect an authorization id.

Afaics, it was Matthias who wanted an authorization id:
http://mail.jabber.org/pipermail/standards/2006-September/012344.html
The argument is not compelling imo, but I think we're stuck with 
including one now, even if it meaningless.

>> Other issues (labelled T for typos, E for minor editoral nitpicks):

[...]
+9 (or +1 on the 9 issues)

>     of the following conditions hold:

s/MUST/SHOULD/ please. When you attempt to do DWD, you avoid offering 
EXTERNAL at that point.

>         attribute of the initial stream header.

Not quite. Unfortunately, this needs to cover c2s and s2s, which 
complicates things.

What you do in any case is to seek a match for the JID provided in the 
'from' attribute in the list of presented identifiers.

For s2s, this process is the one described in the server-id-check draft 
with roles reversed, i.e. the receiving entity checks the server 
certificate provided by the initiating entity. Do you have a section (or 
short note) there that covers mutual authentication in server-to-server 
communication?

>     under other circumstances, as well.

If the receiving entity can not offer the EXTERNAL mechanism but 
requires high security (i.e. there are no mechanisms left and it can not 
offer dialback), it should terminate the stream (<policy-violation/>?). 
Unless that is already covered elsewhere.

>     to negotiate mutual authentication.

I think that should be (s/it/initiating entity/):
When the receiving entity offers the SASL EXTERNAL mechanism, the 
initiating entity SHOULD prefer ...

>        mechanism and in [XEP-0178] for the EXTERNAL mechanism.

+1

> be updated to cover that case.

Dave promised to write something about that.

> think that concept applies to s2s streams.

[...]
+4

> I hope so. :) Thanks again.

Oh, we could go on for years :-)

philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Aug 2010 09:03:11 -0600

> including one now, even if it meaningless.

IMHO that's not a good argument. This is our chance to delete or
deprecate things that are unused or meaningless, like the session
establishment command in RFC 3921. Now is the time to delete
authorization identities for s2s if they are meaningless (and I think
they are).

However, maybe we need an implementation note to the effect that some
existing implementations support and send authorization identities in
s2s authentication, but I think it is appropriate for us to actively
deprecate that behavior for the reasons already discussed on this list.

> s/MUST/SHOULD/ please. When you attempt to do DWD, you avoid offering

Agreed, SHOULD is better here.

> Not quite. Unfortunately, this needs to cover c2s and s2s, which

Yes, I was thinking of s2s when I wrote the second condition.

> certificate provided by the initiating entity. 

I think the following text is much more complete:

   2.  The receiving entity expects that the initiating entity will be
       able to authenticate and authorize as the identity provided in
       the certificate; in the case of a server-to-server stream, the
       receiving entity might have such an expectation because a DNS
       domain name presented in the initiating entity's certificate
       matches the domain referenced in the 'from' attribute of the
       initial stream header, where the matching rules of [TLS-CERTS]
       apply; in the case of a client-to-server stream, the receiving
       entity might have such an expectation because the bare JID
       presented in the initiating entity's certificate matches a user
       account that is registered with the server or because other
       information contained in the initiating entity's certificate
       matches that of an entity that has permission to use the server
       for access to an XMPP network.

> Do you have a section (or

Not yet, because we've pretty much punted on mutual authentication
pending further implementation experience and discussion.

> offer dialback), it should terminate the stream (<policy-violation/>?).

Hmm, I don't think that's right. My reading of RFC 3365 indicates that
"strong security" means authentication, confidentiality, and integrity.
There might be ways to enforce all three of those without the use of
SASL EXTERNAL. Are you thinking here only of s2s streams? Even there, a
SASL mechanism other than EXTERNAL might enable strong security (e.g.,
TLS with pre-shared keys or secure remote password).

> Unless that is already covered elsewhere.

It is not, because we've never had a detailed discussion about the
meaning of "strong security" -- and I don't know that we want to have
such a discussion now, because it might delay the publication of 3920bis
by several years. ;-)

> initiating entity SHOULD prefer ...

I think we mean that *both* entities should prefer EXTERNAL (i.e., the
receiving entity lists EXTERNAL first among the offered mechanisms and
the initiating entity tries EXTERNAL first). Thus I suggest this text:

   When the receiving entity offers the SASL EXTERNAL mechanism, the
   receiving entity SHOULD list the EXTERNAL mechanism first among its
   offered SASL mechanisms and the initiating entity SHOULD attempt SASL
   negotiation using the EXTERNAL mechanism first (this preference will
   tend to increase the likelihood that the parties can negotiate mutual
   authentication).

> Dave promised to write something about that.

Super. It doesn't belong in 3920bis, though, so he's got time.

> Oh, we could go on for years :-)

We already have. :)

BTW we'll have another opportunity to fix things if we decide to advance
from Proposed Standard to Draft Standard, so this is not your last
chance to ever make comments. However, I think that any future diffs
would be fairly small given all the work that's gone into 3920bis.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Aug 2010 09:17:31 -0600

> deprecate that behavior for the reasons already discussed on this list.

Here is the complete text of Section 6.2.8 in my working copy, including
my suggestion for the interoperability note:

###

6.2.8.  Authorization Identity

   An authorization identity is an optional identity specified by the
   initiating entity, which is typically used by an administrator to
   perform some management task on behalf of another user.  If the
   initiating entity wishes to act on behalf of another entity and the
   selected SASL mechanism supports transmission of an authorization
   identity, the initiating entity MUST provide an authorization
   identity during SASL negotiation.  If the initiating entity does not
   wish to act on behalf of another entity, it MUST NOT provide an
   authorization identity.  As specified in [SASL], the initiating
   entity MUST NOT provide an authorization identity unless the
   authorization identity is different from the default authorization
   identity derived from the authentication identity.

   Authorization identities are allowed only for client-to-server
   streams.  Because a server-to-server stream is valid only for the
   particular domain pair authenticated during stream negotiation,
   authorization of any additional domains for the stream needs to be
   completed by means of protocol extensions above the core XMPP stream
   layer.  Therefore in the case of server-to-server communication the
   initiating server MUST NOT attempt to negotiate an authorization
   identity during SASL negotiation and the receiving server MUST NOT
   accept an authorization identity from the initiating server.

      Interoperability Note: RFC 3920 allowed the use of authorization
      identities for server-to-server streams, and some existing server
      implementations send and accept such authorization identities.

   In the case of client-to-server communication, the value of an
   authorization identity MUST be a bare JID of the form
   <localpart@domainpart> (i.e., localpart and domainpart).

      Informational Note: The authorization identity communicated during
      SASL negotiation is used to determine the canonical address for
      the initiating client according to the receiving server, as
      described under Section 4.2.6.

###

/psa

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 18 Aug 2010 18:19:52 +0200

> authorization identities for s2s if they are meaningless (and I think

We did not have any post-rfc3920 xep that strongly encouraged everyone 
to do session binding... but if you are going to spearhead this with 
jabber.org, I think we can "fix" that quite quickly.

> deprecate that behavior for the reasons already discussed on this list.

It seems that I have missed those reasons :-/

A question about your proposed implementation note: what am I expected 
to do if I encounter a server that includes them?

[...]

+1

> "strong security" means authentication, confidentiality, and integrity.

Ooops. I did not mean to write "strong security"!

What about:
For server-to-server streams, if the receiving entity can not offer the 
EXTERNAL [or any other SASL] mechanism and weak identity verification as 
provided by Server Dialback is not sufficient, it should terminate the 
stream [and the underlying blabla] with a <policy-violation/> stream error.
?

> SASL EXTERNAL. Are you thinking here only of s2s streams? Even there, a

I usually don't care about c2s :-)

> such a discussion now, because it might delay the publication of 3920bis

Nooooooo!

>     tend to increase the likelihood that the parties can negotiate mutual

Ah, so as the receiving entity preferring EXTERNAL just means that I put 
it first in the list of mechanisms? But does it really matter to the 
client which should choose its preferred mechanism regardless of the 
position in the list? Anyway...

cheers

philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Aug 2010 11:46:50 -0600

> It seems that I have missed those reasons :-/

IIRC the topic emerged in the thread starting here:

http://www.ietf.org/mail-archive/web/xmpp/current/msg00332.html

> to do if I encounter a server that includes them?

If you don't accept authorization identities, then accept only the
authentication identity and close the stream with an <invalid-from/>
stream error if the initiating entity attempts to send stanzas for which
the domainpart of the JID in the 'from' address does not match the
hostname of the authentication identiy; see Section 8.1.2.2.

> stream [and the underlying blabla] with a <policy-violation/> stream error.

Yes, I think that a note like that would be appropriate. The best place
I can find for it is Section 6.3.5 ("SASL Failure").

<snip/>

> position in the list? Anyway...

Yes, the initiating entity has its own ordered list of SASL mechanisms.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Aug 2010 11:57:30 -0600

> I can find for it is Section 6.3.5 ("SASL Failure").

Proposed text for placement at the end of Section 6.3.5:

      Implementation Note: For server-to-server streams, if the
      receiving entity cannot offer the SASL EXTERNAL mechanism or any
      other SASL mechanism based on the security context established
      during TLS negotiation, the receiving entity MAY attempt to
      complete weak identity verification using the Server Dialback
      protocol [XEP-0220]; however, if according to local service
      policies weak identity verification is insufficient then the
      receiving entity SHOULD instead close the stream with a <policy-
      violation/> stream error.

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 19 Aug 2010 09:40:10 +0200

Peter Saint-Andre wrote:
[...]
> authentication identity and close the stream with an<invalid-from/>

While that sounds reasonable it does not answer my question. Let me try 
again:

What if a server sends me an (from XEP 0178)
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='EXTERNAL'>
    Y29uZmVyZW5jZS5leGFtcGxlLm9yZwo=          (=conference.example.org)
</auth>
and the stream from attribute is set to "conference.example.org".

Does "MUST NOT accept" mean that I am supposed to terminate the stream 
by sending a SASL failure?

philipp

---

From: Dave Cridland <[email-masked]>
Date: Thu, 19 Aug 2010 08:53:28 +0100

On Thu Aug 19 08:40:10 2010, Philipp Hancke wrote:
> While that sounds reasonable it does not answer my question. Let me  
> try again:
> 
> Does "MUST NOT accept" mean that I am supposed to terminate the  
> stream by sending a SASL failure?

I'm going to wade into this in a bit in full, but FWIW, M-Link always  
sends its domainname as both the stream's from and the authcid in  
EXTERNAL, exectly as this example.

It offers EXTERNAL if the stream's from matches the certificate, or -  
if the stream has no from - it's possible for a provided XMPP authcid  
to match the certificate.

In the latter case, if no default authcid could be extracted from the  
certificate, we actually require an authcid to be presented during  
the EXTERNAL exchange.

I have a long-standing argument with Kurt that providing an authcid  
does not inherently mean that the authcid MUST be distinct from the  
authzid used (Kurt disagrees).

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Dave Cridland <[email-masked]>
Date: Thu, 19 Aug 2010 09:06:30 +0100

> http://www.ietf.org/mail-archive/web/xmpp/current/msg00332.html

Just as a minor point on this, id-on-xmppaddr contains an  
authorization identifier, which should always be a jid in any  
mechanism.

The authcid in SASL EXTERNAL is "some vague property of the  
underlying stream" - typically mapping to an X.509 certificate  
presented by the client, although it could be something else entirely  
(like the server using the mere presence of TLS to ensure IP spoofing  
isn't realistic, and then using a static mapping of IP address to  
client). Note that there's no string form of the authcid at all in  
many of these cases.

Since a client doesn't *know* that'll be where the default authzid  
comes from (let alone which default authzid it might pick) not  
specifying the intended authzid seems like leaving a lot to good will  
and chance.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 19 Aug 2010 09:57:14 -0600

>> by sending a SASL failure?

Thanks to Philipp for pushing on this issue.

> It offers EXTERNAL if the stream's from matches the certificate, or - if
> the stream has no from - it's possible for a provided XMPP authcid to
> match the certificate.

I was thinking about this a bit more last night and realized that there
is (at least!) one problem with forbidding the authorization identity:
if the presented identifier in the cert is a wildcard domain name such
as *.example.com, I think we'd need the authorization identity to "fill
in the blanks" (e.g., conference.example.com). Thus the text about "MUST
NOT send or accept an authorization identity" is misguided in that
respect at least.

Clearly we need better text on this point, which I'll try to write up
today (but I have a meeting right now so it will be delayed by a few hours).

> certificate, we actually require an authcid to be presented during the
> EXTERNAL exchange.
> 
> I have a long-standing argument with Kurt that providing an authcid does
> not inherently mean that the authcid MUST be distinct from the authzid
> used (Kurt disagrees).

Is there any consensus on that matter in the SASL community?

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 19 Aug 2010 15:23:04 -0600

Please review and comment.

> today (but I have a meeting right now so it will be delayed by a few hours).

OK, I see two places that need to be adjusted. Here is what I now have
in my working copy.

###

4.2.6.  Determination of Addresses

   After the parties to an XML stream have completed the appropriate
   aspects of stream negotiation (typically SASL negotiation (Section 6)
   and, for client-to-server streams, resource binding (Section 7)) the
   receiving entity for a stream MUST determine the initiating entity's
   JID.

   For client-to-server communication, the client's bare JID
   (<localpart@domainpart>) MUST be the authorization identity (as
   defined by [SASL]), either (1) as directly communicated by the client
   during SASL negotiation (Section 6) or (2) as derived by the server
   from the authentication identity if no authorization identity was
   specified during SASL negotiation.  The resourcepart of the full JID
   (<localpart@domainpart/resource>) MUST be the resource negotiated by
   the client and server during resource binding (Section 7).  A client
   MUST NOT attempt to guess at its JID but instead MUST consider its
   JID to be whatever the server returns to it during resource binding.
   The server MUST ensure that the resulting JID (including localpart,
   domainpart, resourcepart, and separator characters) conforms to the
   canonical format for XMPP addresses defined in [XMPP-ADDR]; to meet
   this restriction, the server MAY replace the JID sent by the client
   with the canonicalized JID as determined by the server and
   communicate that JID to the client during resource binding.

   For server-to-server communication, the initiating server's JID
   (<domainpart>) MUST be the authorization identity (as defined by
   [SASL]), either (1) as directly communicated by the initiating server
   during SASL negotiation (Section 6) or (2) as derived by the
   receiving server from the authentication identity if no authorization
   identity was specified during SASL negotiation; in the absence of
   SASL negotiation, the receiving server MAY consider the authorization
   identity to be the 'from' address on the initial stream header
   received from the initiating entity or an identity negotiated within
   the relevant verification protocol (e.g., the 'from' attribute of the
   <result/> element in Server Dialback [XEP-0220]).

      Security Note: Because it is possible for a third party to tamper
      with information that is sent over the stream before a security
      layer such as TLS is successfully negotiated, it is advisable for
      the receiving server to treat any such unprotected information
      with caution.

###

   An authorization identity is an optional identity specified by the
   initiating entity; in client-to-server streams it is typically used
   by an administrator to perform some management task on behalf of
   another user, whereas in server-to-server streams it is typically
   used to specify a particular application at a service (e.g., a multi-
   user chat server at conference.example.com that is hosted by the
   example.com XMPP service).  If the initiating entity wishes to act on
   behalf of another entity and the selected SASL mechanism supports
   transmission of an authorization identity, the initiating entity
   SHOULD provide an authorization identity during SASL negotiation.  If
   the initiating entity does not wish to act on behalf of another
   entity, it SHOULD NOT provide an authorization identity.

   In the case of client-to-server communication, the value of an
   authorization identity MUST be a bare JID (<localpart@domainpart>)
   and not a full JID (<localpart@domainpart/resourcepart>).

   In the case of server-to-server communication, the value of an
   authorization identity MUST be a domainpart only (<domainpart>).

   If the initiating entity provides an authorization identity during
   SASL negotiation, the receiving entity is responsible for verifying
   that the initiating entity is in fact allowed to assume the specified
   authorization identity; if not, the receiving entity MUST return an
   <invalid-authzid/> SASL error as described under Section 6.4.6.

###

>> certificate, we actually require an authcid to be presented during the

How does the initiating entity know that no default authorization
identity could be extracted from the certificate? Isn't that a matter of
local service policy at the receiving entity?

>> not inherently mean that the authcid MUST be distinct from the authzid

RFC 4422 states:

   A non-empty authorization identity string indicates that the client
   wishes to act as the identity represented by the string.

I see no point in including an authorization identity if it's the same
as the authentication identity. However, that's a topic for the SASL
(now KITTEN) WG at the IETF and in any case I have removed the following
sentence from 3920bis because upon review of RFC 4422 I do not find a
firm basis for its claim:

   As specified in [SASL], the initiating
   entity MUST NOT provide an authorization identity unless the
   authorization identity is different from the default authorization
   identity derived from the authentication identity.

/psa

---

From: Dave Cridland <[email-masked]>
Date: Thu, 19 Aug 2010 22:35:49 +0100

> Please review and comment.
I like all this at a quick skim.

> server
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 20 Aug 2010 11:24:44 -0600

> I like all this at a quick skim.

Thanks, Dave. I'll wait until early next week before submitting -13, so
that folks have time to review this text before we move ahead to IETF
Last Call.

Peter

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

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 23 Aug 2010 21:11:52 +0200

> Please review and comment.

Looks good.

[...]
[...]
>     identity to be the 'from' address on the initial stream header

This MAY sounds like what is called 'legacy auth' - which is actually 
the lack of any check.

>     <result/>  element in Server Dialback [XEP-0220]).

Is it a problem that dialback can negotiate multiple 'from'? That means 
we can have more than one identity.

philipp

---

From: "Peter Saint Andre" <[email-masked]>
Date: Mon, 23 Aug 2010 13:52:41 -0700

(Sent from my phone, sorry about top-posting.)

In s2s the 'from' attribute has nothing to do with legacy auth, by which I assume you mean jabber:iq:auth (XEP 78). Some servers seem to use the 'from' address as a kind of placeholder for the peer's desired authorization identity, and this text allows that. As to the multiple identities allowed during server dialback, that is a matter for the dialback spec. Do you think the text in 3920bis needs to be adjusted to cover the possibilitiy of multiple authorization identities? The text I proposed seems fine to me on that score...

----- Original Message -----
From: [email-masked] <[email-masked]>
To: XMPP Working Group <[email-masked]>
Sent: Mon Aug 23 12:11:52 2010
Subject: Re: [xmpp] Finalizing draft-ietf-xmpp-3920bis-12

Looks good.

[...]
[...]

philipp

---

From: Philipp Hancke <[email-masked]>
Date: Tue, 24 Aug 2010 15:37:37 +0200

Peter Saint Andre wrote:
> In s2s the 'from' attribute has nothing to do with legacy auth, by which I assume you mean jabber:iq:auth (XEP 78).

No, I meant the jabberd 1.0 legacy s2s.

> Some servers seem to use the 'from' address as a kind of placeholder for the peer's desired authorization identity, and this text allows that.

Like M-Link, as Dave said? But that is when using SASL...
When would you "consider the authentication identity to be the 'from' 
address on the initial stream header after TLS" (while at the same time 
not doing either SASL or dialback)?

> As to the multiple identities allowed during server dialback, that is a matter for the dialback spec. Do you think the text in 3920bis needs to be adjusted to cover the possibilitiy of multiple authorization identities? The text I proposed seems fine to me on that score...

I think that is described in 220 - without using the term 'authorization 
identity'. And thanks for already fixing a minor issue from -12 by 
saying that you use the 'from' of the <result/> in dialback, not the 
'from' of the stream header :-)
Anyway: WFM.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 24 Aug 2010 08:15:19 -0600

On 8/24/10 7:37 AM, Philipp Hancke wrote:
> Peter Saint Andre wrote:
>> In s2s the 'from' attribute has nothing to do with legacy auth, by
>> which I assume you mean jabber:iq:auth (XEP 78).
> 

Oh. But that was no authentication at all. IMHO the use of the term
"authorization identity" in that clause does not remove the need for
authentication or, as in the case of server dialback, weak identity
verification -- but the identity that the receiving server allows the
peer to assume might be based on the 'from' address or the negotiation
protocol.

However, I am happy to change it to:

   in the absence of SASL negotiation, the receiving server MAY
   consider the authorization identity to be an identity negotiated
   within the relevant verification protocol (e.g., the 'from'
   attribute of the <result/> element in Server Dialback [XEP-0220])

That leaves less to "creative" interpretation.

>> Some servers seem to use the 'from' address as a kind of placeholder
>> for the peer's desired authorization identity, and this text allows that.
> 

Definitely not.

>> As to the multiple identities allowed during server dialback, that is
>> a matter for the dialback spec. Do you think the text in 3920bis needs
>> to be adjusted to cover the possibilitiy of multiple authorization
>> identities? The text I proposed seems fine to me on that score...
> 

Yep. :)

> Anyway: WFM.

I think it's better to leave out that stuff about the 'from' on the
stream header, because in reality we have only SASL or dialback; if
someone wants to define a third method for negotiating the authzid they
are free to do so, and it would be covered by the text about "an
identity negotiated within the relevant verification protocol".

If there are no further comments, I'll post -13 tonight.

Peter

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