Simon Josefsson | 13 Aug 22:55 2014

RFC 6120 CA cert keyUsage digitalSignature bit requirement?

Hi,

I'm generating certificates for use in a XMPP environment, and I'm
seeking clarification of one aspect of RFC 6120:

   The following rules apply to certification authority (CA)
   certificates that are used by issuers of XMPP end entity
   certificates:
...
   2.  The certificate MUST contain a keyUsage extension with the
       digitalSignature bit set.

My question: Why is the digitalSignature bit a requirement?

Speculation: Was the keyCertSign bit intended here?  Reading RFC 5280 it
seems the keyCertSign would be more appropriate than digitalSignature.
What non-certificate/CRL objects is it that XMPP environments expect to
be signed by the CA?

      KeyUsage ::= BIT STRING {
           digitalSignature        (0),
...
           keyCertSign             (5),
...
      The digitalSignature bit is asserted when the subject public key
      is used for verifying digital signatures, other than signatures on
      certificates (bit 5) and CRLs (bit 6), such as those used in an
      entity authentication service, a data origin authentication
      service, and/or an integrity service.
...
(Continue reading)

internet-drafts | 12 Aug 01:09 2014
Picon

I-D Action: draft-ietf-xmpp-websocket-09.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.

        Title           : An XMPP Sub-protocol for WebSocket
        Authors         : Lance Stout
                          Jack Moffitt
                          Eric Cestari
	Filename        : draft-ietf-xmpp-websocket-09.txt
	Pages           : 16
	Date            : 2014-08-11

Abstract:
   This document defines a binding for the XMPP protocol over a
   WebSocket transport layer.  A WebSocket binding for XMPP provides
   higher performance than the current HTTP binding for XMPP.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xmpp-websocket-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-websocket-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
(Continue reading)

Joe Hildebrand (jhildebr | 1 Aug 18:55 2014
Picon

Does 6122bis need to update 5122?

On 8/1/14, 10:49 AM, "Peter Saint-Andre" <stpeter <at> stpeter.im> wrote:

>In that case, we'd specify an XMPP URI (RFC 5122).
>
>Thus I might suggest:
>
>    For an XMPP client [RFC6120] using STUN and TURN, the ORIGIN
>    attribute is an XMPP URI [RFC5122] representing the domainpart
>    of the client's Jabber ID (JID) [RFC6122]; for example, if the
>    client's JID is "juliet <at> im.example.com/balcony" then the ORIGIN
>    attribute would be "xmpp:im.example.com".

This made me wonder if we need to either rev 5122 to point to 6122bis, or
just have 6122 update 5122 (which I think I'd prefer, so we don't open up
a can of IRI worms).

--

-- 
Joe Hildebrand
Alan Johnston | 1 Aug 16:50 2014
Picon

Help on XMPP/Jabber Origin for STUN/TURN

Hi,

In the TRAM WG, we are working on an extension to STUN/TURN for a client to convey origin information to a server.  


The driver for this effort is WebRTC, where the origin is the HTTP origin of the web site that is establishing the Peer Connection.  Other users of STUN and TURN can also provide origin information.  The draft currently has this text about SIP and XMPP:

   For a SIP User Agent [RFC3261] using STUN and TURN, the ORIGIN
   attribute is set to be the URI of the registrar server used by the
   User Agent (i.e. the Request-URI of a REGISTER method).

   For a Jabber client [RFC6120] using STUN and TURN, the ORIGIN
   attribute is the Jabber ID (JID) [RFC6122] of the Jabber Server that
   the client is using.

We would greatly appreciate feedback from you on what this text should say about XMPP/Jabber in terms of a useful origin.

- Alan -
_______________________________________________
xmpp mailing list
xmpp <at> ietf.org
https://www.ietf.org/mailman/listinfo/xmpp
Peter Saint-Andre | 11 Jul 03:21 2014

next steps on draft-ietf-xmpp-websocket

Dear Authors and WG,

This morning, at Richard's invitation and as the document shepherd for 
draft-ietf-xmpp-websocket, I briefly joined the IESG telechat to talk 
through the DISCUSS positions lodged by Stephen Farrell and Ted Lemon:

https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ballot/

As a result, I'd like to ask the authors to complete several tasks (and 
I will be happy to propose or help with text for these items, since I 
was present during the IESG discussion):

1. More clearly describe the delegation scenario outlined in the second 
paragraph of Section 6:

    Browser based applications are not able to inspect and verify at the
    application layer the certificate used for the WebSocket connection
    to ensure that it corresponds to the domain specified as the "to"
    address of the XMPP stream.  For hosts whose domain matches the
    origin for the WebSocket connection, that check is already performed
    by the browser.  However, in situations where the domain of the XMPP
    server might not match the origin for the WebSocket endpoint
    (especially multi-tenant hosting situations), the web host metadata
    method (see [RFC6415] and [XEP-0156]) MAY be used to delegate trust
    from the XMPP server domain to the WebSocket origin.

In particular, it would be very helpful to add two examples (one in 
which the WebSocket origin matches the domain of the XMPP service, and 
one in which it does not, e.g., delegation of foo.example to 
hosting.example.net) and to explain that the delegation model is 
conceptually the same as for the existing DNS SRV lookup methods 
described in RFC 6120, except using web linking in the WebSocket case. 
Extra credit for walking through the examples in enough depth that 
readers of this document can see all the key the steps involved (go to 
HTTPS URL at source domain for host-meta data, retrieve the appropriate 
web link, resolve that link to an IP address, connect there via wss: URI 
or HTTP upgrade, etc. - and what certificate to check at the end of that 
process, tying in with RFC 2818 for checking rules).

2. In Section 6.1, briefly describe why the choice of transport binding 
(WebSocket here vs. TCP as in RFC 6120), including the different message 
framing method used here, does not have an impact on the effectiveness 
of end-to-end stanza encryption methods.

3. There was a bit of confusion (reflected in Ted Lemon's DISCUSS) about 
the exact purpose of the WebSocket binding. To clear up this confusion, 
it would be good to explain that the WebSocket binding is an alternative 
way to interact with the same service that one might interact with using 
the TCP binding (in an IM context, one would be able to retrieve the 
same contact list, chat with the same people, etc.). That is, the point 
of the WebSocket binding is mainly to enable browser-based clients to 
connect to servers (in a more efficient way than BOSH), since such 
clients don't have access to facilities that would enable them to open 
TCP connections as in RFC 6120. It would be best if one aspect of this 
explanation would include a discussion of the security context for 
web-based interactions with XMPP services - e.g., the web origin concept 
(RFC 6454) applies, discovery occurs via host-meta and web linking, and 
browsers don't allow access to the application-layer certificates 
(perhaps there are other salient points to raise here, too, but those 
seem like the key ones to me).

Richard, does that accurately summarize the discussion?

Naturally, the authors also need to address the various other comments 
provided by IESG members (again, see 
<https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ballot/>).

Let me know if you have any questions or comments.

Thanks!

Peter
The IESG | 21 Jun 01:56 2014
Picon

Last Call: <draft-ietf-xmpp-websocket-07.txt> (An XMPP Sub-protocol for WebSocket) to Proposed Standard


The IESG has received a request from the Extensible Messaging and
Presence Protocol WG (xmpp) to consider the following document:
- 'An XMPP Sub-protocol for WebSocket'
  <draft-ietf-xmpp-websocket-07.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2014-07-04. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document defines a binding for the XMPP protocol over a
   WebSocket transport layer.  A WebSocket binding for XMPP provides
   higher performance than the current HTTP binding for XMPP.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ballot/

No IPR declarations have been submitted directly on this I-D.
Richard Barnes | 20 Jun 22:09 2014

AD review of draft-ietf-xmpp-websocket

I have reviewed this draft in preparation for IETF LC.  Overall, it looks to be in good shape.  Thanks for a nice document.  I've requested last call, and there are a few minor comments below to consider along with LC comments.

Thanks,
--Richard


MINOR

S3.1. "WebSocket messages sent or received will conform"
Should this be "MUST conform"?

S3.6.1. "a different transport, such as BOSH"
How is the recipient of one of these messages supposed to tell what transport?  Does the use of an http- or https-schemed URI imply BOSH?

S3.7. "[Streams implicitly closed]"
Does this usage map cleanly to the TCP case?  That is, would a </stream> element be sent in this closure case?  I'm just imagining that if you have, say, a relatively naïve gateway that translates <stream> to <open> and </stream> to <close>, this could cause problems.

_______________________________________________
xmpp mailing list
xmpp <at> ietf.org
https://www.ietf.org/mailman/listinfo/xmpp
internet-drafts | 20 Jun 05:40 2014
Picon

I-D Action: draft-ietf-xmpp-posh-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.

        Title           : PKIX over Secure HTTP (POSH)
        Authors         : Matthew Miller
                          Peter Saint-Andre
	Filename        : draft-ietf-xmpp-posh-01.txt
	Pages           : 14
	Date            : 2014-06-19

Abstract:
   Experience has shown that it is extremely difficult to deploy proper
   PKIX certificates for TLS in multi-tenanted environments, since
   certification authorities will not issue certificates for hosted
   domains to hosting services, hosted domains do not want hosting
   services to hold their private keys, and hosting services wish to
   avoid liability for holding those keys.  As a result, domains hosted
   in multi-tenanted environments often deploy non-HTTP applications
   such as email and instant messaging using certificates that identify
   the hosting service, not the hosted domain.  Such deployments force
   end users and peer services to accept a certificate with an improper
   identifier, resulting in obvious security implications.  This
   document defines two methods that make it easier to deploy
   certificates for proper server identity checking in non-HTTP
   application protocols.  The first method enables the TLS client
   associated with a user agent or peer application server to obtain the
   end-entity certificate of a hosted domain over secure HTTP as an
   alternative to standard PKIX techniques.  The second method enables a
   hosted domain to securely delegate a non-HTTP application to a
   hosting service using redirects provided by HTTPS itself or by a
   pointer in a file served over HTTPS at the hosted domain.  While this
   approach was developed for use in the Extensible Messaging and
   Presence Protocol (XMPP) as a Domain Name Association prooftype, it
   can be applied to any non-HTTP application protocol.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xmpp-posh-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-posh-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Ben Campbell | 17 Jun 16:29 2014

Publication Requested for draft-ietf-xmpp-websocket-07

Hi Everyone,

We just requested publication for draft-ietf-xmpp-websocket-07. It's in the hands of the IESG now. 

Thanks to the authors for all the hard work on this (so far :-) ). Thanks also go to all those who reviewed and
discussed it.

Ben.
Dave Cridland | 9 Jun 12:14 2014
Picon

draft-cridland-xmpp-session-00

https://datatracker.ietf.org/doc/draft-cridland-xmpp-session/

After some discussion in the XSF's chatrooms, I've submitted this which I think captures current practise and seems to be the least-unsensible option.

Happy to have the WG adopt this if the chairs and WG desire, otherwise I'll go fishing for an AD sponsor.

The nub is as described in its Section 2:

2.  The Session Establishment Tombstone

   This specification formalizes the <optional/> marker and explicitly
   defines the Session Establishment request itself as a no-op.

Dave.
_______________________________________________
xmpp mailing list
xmpp <at> ietf.org
https://www.ietf.org/mailman/listinfo/xmpp
Matt Miller | 5 Jun 00:17 2014
Picon

Fwd: [POSH] What's the point of using JWKs in POSH?


[ Forwarding to the xmpp <at> ietf.org mailing list on behalf of Thjis
Alkemade ]

Hello,

Today, I've spent some time on trying to implement POSH-checking for
xmpp.net. My implementation aimed to do two things: doing the
validation as described and showing someone how they could set up
their .well-known file by converting their X509 certificates to JSON
Web Keys.

The latter part was a lot more work than the former and made me wonder
why it is defined the way it is.

From draft-ietf-xmpp-posh:

  Each included JWK object MUST possess the following information:

   o  The "kty" field set to the appropriate key type used for TLS
      connections (e.g., "RSA" for a certificate using an RSA key).

   o  The required public parameters for the key type (e.g., "n" and "e"
      for a certificate using an RSA key).

   o  The "x5t" field set to the certificate thumbprint, as described in
      section 3.6 of [JOSE-JWK].

Yet the data that is required in the first and second bullet is never
used. It doesn't specify if and how clients should verify it.
Verification only uses the x5t field and optionally x5c.

There are good arguments for "pinning" just the public key.
draft-ietf-websec-key-pinning only uses the SPKI field, DANE can use
either the full cert or its SPKI field (and optionally hashed). But
the way it is specified here won't allow that: the x5t field always
needs to be present and clients should verify it.

So the public parameters of the key are useless here, but they make a
key >10x as large is they have to be. Generating them is also not as
easy: most certificate viewers show a SHA1 fingerprint and it's really
easy to do with the openssl cli tool, but extracting n and e and
base64-encoding them is a lot more work. I wouldn't even know what to
do for ECDSA keys.

Are there any interoperability reasons for using JWKs that I'm not
aware of? Couldn't it just use a list of SHA1 hashes?

Best regards,
Thijs

Gmane