Subject: [xmpp] SASLprep vs. nodeprep

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Aug 2009 13:46:21 -0600

The SCRAM I-D (draft-ietf-sasl-scram-04) says the following:

   Before sending the username to the server, the client MUST
   prepare the username using the "SASLPrep" profile [RFC4013]
   of the "stringprep" algorithm [RFC3454].

This might be perceived as contradicting 3920bis, where we say that the
localpart of a JabberID "MUST be formatted such that the Nodeprep
profile of [STRINGPREP] can be applied without failing". However, I
think that nodeprep is more strict than SASLprep, so perhaps we are OK.

In any case, I think that the text in the SCRAM I-D needs to say that
the SASLprep profile can be applied without failing, not that the
username must be prepared using SASLprep.

Thoughts?

Peter

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

---

From: Dave Cridland <[email-masked]>
Date: Mon, 10 Aug 2009 21:08:01 +0100

On Mon Aug 10 20:46:21 2009, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
I don't think there's a contradiction:

A jid node MUST pass Nodeprep.

A simple username MUST be the jid node.

A simple username used in SCRAM MUST have SASLprep applied before  
transmission.

None of the above have a conflict I can see - it's merely that a  
jid's node might be have more restrictions than previously we've  
considered. It would be worthwhile mentioning this case in  
particular, and in general, that implementations may have further  
restrictions on the form of a node identifier, in section 3.3.

> username must be prepared using SASLprep.
I'll answer this one on the SASL list.

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: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Aug 2009 14:27:07 -0600

> I don't think there's a contradiction:

I don't think there's a contradiction, either, which is why I said that
people might perceive a contradiction.

> None of the above have a conflict I can see - it's merely that a jid's
> node might be have more restrictions than previously we've considered.
> It would be worthwhile mentioning this case in particular, and in
> general, that implementations may have further restrictions on the form
> of a node identifier, in section 3.3.

Agreed.

But does this mean that an entity must apply two different stringprep
profiles, in series (nodeprep then SASLprep)? Isn't that expensive?

> I'll answer this one on the SASL list.

OK.

Peter

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

---

From: Dave Cridland <[email-masked]>
Date: Mon, 10 Aug 2009 21:58:22 +0100

> profiles, in series (nodeprep then SASLprep)? Isn't that expensive?

I think it's a drop in the ocean compared to the rest of the  
session-setup experience - TLS and the remainder of SCRAM are much  
bigger fruit, if higher up.

Moreover, trying to solve this neccesitates a "special" SCRAM  
implementation for XMPP which elides the SASLprep, potentially.

I'm certainly not against your proposed changes to SCRAM, but I don't  
think it's worth worrying over.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Aug 2009 15:08:55 -0600

> bigger fruit, if higher up.

True.

> implementation for XMPP which elides the SASLprep, potentially.

That would be bad. I'm not convinced that would be necessary, but if so
I would prefer to avoid any XMPP-specific SCRAM libraries (or calls
within those libraries).

> think it's worth worrying over.

Point taken.

Peter

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 12 Aug 2009 13:24:50 +0100

>think that nodeprep is more strict than SASLprep, so perhaps we are OK.
Peter, there is no contradiction here. Think of the SCRAM authentication 
mechanism (or any SASL authentication) as of a black box: SCRAM takes a 
simple username as input; once SCRAM authentication is successful, the 
protocol that invoked SCRAM authentication would get an identity, that 
needs to be converted to the format used by the protocol (JID in case of 
XMPP).
This also means that if one enters a bare JID to be used as the SCRAM 
username, there is an implied conversion step from JID to SCRAM format. 
This just happens to be noop for bare JIDs.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 Aug 2009 11:13:54 -0600

> This just happens to be noop for bare JIDs.

I think you are right, but I want to make sure this is clear in 3920bis
so that developers are not confused about which stringprep profile to
apply (and when). I'll work on some text about this.

Peter

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