[standards-jig] JEP 34 (SASL)

Joe Hildebrand JHildebrand at jabber.com
Wed Aug 21 23:44:51 UTC 2002


Ok, after an involved set of discussions this afternoon, let me take another
crack at this.  I still like the IQ's.  I've been convinced that we don't
*need* the to's, particularly if the username inside the sasl blob has
enough info to generate a user at host jid on the server side.  Apparently
using user at realm as the sasl username has precedent.

I'm still not ready to give up on the requirement for a jabber:iq:auth/set
to set the resource, so how about this:

C: <iq type='get' id='1'>
C:  <mechanisms xmnls='http://www.iana.org/assignments/sasl-mechanisms'>
C: </iq>

S: <iq type='result' id='1'>
S:  <mechanisms xmlns='http://www.iana.org/assignments/sasl-mechanisms'>
S:   <mechanism>PLAIN</mechanism>
S:   <mechanism>DIGEST-MD5</mechanism>
S:   <mechanism>EXTERNAL</mechanism>
S:  </mechanisms>
S: </iq>

C: <iq type='set' id='2'>
C:  <auth xmnls='http://www.iana.org/assignments/sasl-mechanisms'
C:         mechanism='PLAIN'><resource>Work</resource></auth>
C: </iq>

(Note the resource)

S: <iq type='set id='3'>
S:  <challenge xmnls='http://www.iana.org/assignments/sasl-mechanisms'/>
S: </iq>

C: <iq to='myuser at myhost/foo' type='result' id='3'>
C:  <result
xmnls='http://www.iana.org/assignments/sasl-mechanisms'>cm9iQGNhdGFjbHlzbS5u
ZXQAc2VjcmV0</result>
C: </iq>

(aside: "cm9iQGNhdGFjbHlzbS5uZXQAc2VjcmV0" is the base64 of
"rob at cataclysm.net\000secret", where \000 is a NUL character.  I was off in
my last post; the current PLAIN example is "rob\000secret", not "rob
secret".)

S: <iq from='myuser at myhost/foo' type='result' id='2'>
S:  <auth xmnls='http://www.iana.org/assignments/sasl-mechanisms'/>
S: </iq>

(note: session now created)

Having a user at host JID inside will allow components and S2S connections to
use the same auth mechanism.

I understand the desire to have the authentication mechanism be able to
support multiple credentials for the same stream.  I think that opens a very
large can of worms on the current protocol, and with the current
implementations.

-- 
Joe Hildebrand

> -----Original Message-----
> From: Peter Saint-Andre [mailto:stpeter at jabber.org]
> Sent: Wednesday, August 21, 2002 2:27 PM
> To: standards-jig at jabber.org
> Cc: jabber-ietf at jabber.org
> Subject: [Jabber-IETF] Re: [standards-jig] JEP 34 (SASL)
> 
> 
> I like the IQs, that is more in line with the Jabber Way, methinks.
> 
> I'll fix the error in Example 3.
> 
> Still ruminating on the to='user at host/resource'.
> 
> Peter
> 
> --
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.html
> 
> On Tue, 20 Aug 2002, Joe Hildebrand wrote:
> 
> > 
> > (CC'd to the jabber-ietf list, since I think that group 
> should join in
> > the fun.)
> > 
> > Craig and I were talking about this today.  This is an attempt to
> > summarize what we talked about.
> > 
> > Yes, you can de-base64 the challenges and responses, and figure out
> > the user name, but in actual practice, that means that the thing at
> > the edge (jpoll, ccm, jadc2s, etc.) needs to understand 
> *way* too much
> > about SASL.  Yes, that may be where the initial 
> implementation put the
> > SASL logic, but we want to put it somewhere else.  Also, for things
> > like PLAIN, you don't actually get user information in the 
> challenges
> > and responses.
> > 
> > (As an aside, can we please have base64-decoded versions of the
> > example messages in the JEP, for those of us who aren't geeky enough
> > to have written their own base64 decoders just for the purpose of
> > reading this JEP?)
> > 
> > My proposal is that all the SASL packets have a 
> to='myuser at myhost/foo'
> > attribute on them.  A nice side-effect of this approach is that
> > different users can continue to have different authentication
> > approaches.  And, the jabber:iq:auth namespace is not needed at the
> > end to set the resource, since we have all of the 
> information we need
> > to set upa session when the authentication is finished.
> > 
> > While we're at it, is there some reason why all of the SASL elements
> > can't be in IQ's?
> > 
> > So, I'd propose this:
> > 
> > C: <iq to='myuser at myhost/foo' type='get' id='1'>
> > C:  <mechanisms 
> xmnls='http://www.iana.org/assignments/sasl-mechanisms'>
> > C: </iq>
> > 
> > S: <iq from='myuser at myhost/foo' type='result' id='1'>
> > S:  <mechanisms 
> xmlns='http://www.iana.org/assignments/sasl-mechanisms'>
> > S:   <mechanism>PLAIN</mechanism>
> > S:   <mechanism>DIGEST-MD5</mechanism>
> > S:   <mechanism>EXTERNAL</mechanism>
> > S:  </mechanisms>
> > S: </iq>
> > 
> > C: <iq to='myuser at myhost/foo' type='set' id='2'>
> > C:  <auth xmnls='http://www.iana.org/assignments/sasl-mechanisms'
> > C:         mechanism='PLAIN'/>
> > C: </iq>
> > 
> > S: <iq from='myuser at myhost/foo' type='set id='3'>
> > S:  <challenge 
> xmnls='http://www.iana.org/assignments/sasl-mechanisms'/>
> > S: </iq>
> > 
> > (aside: the xml is wrong in example 3 in the JEP.)
> > 
> > C: <iq to='myuser at myhost/foo' type='result' id='3'>
> > C:  <result 
> xmnls='http://www.iana.org/assignments/sasl-mechanisms'>cm9iAH
> NlY3JldA==</result>
> > C: </iq>
> > 
> > (aside: "cm9iAHNlY3JldA==" is the base64 of "rob secret")
> > 
> > S: <iq from='myuser at myhost/foo' type='result' id='2'>
> > S:  <auth xmnls='http://www.iana.org/assignments/sasl-mechanisms'/>
> > S: </iq>
> > 
> > (note: the id here is intentionally '2', to match the 
> type='set' above.)
> > 
> > I don't think we need to extend the basic protocol to do this.  You
> > can still add something as a flag in the stream:stream, but 
> it doesn't
> > really *have* to be a xmlns.  Even if it is, the xmlns inside the iq
> > should probably be something different, so that existing server
> > implementations will work ok.
> > 
> > -- 
> > Joe Hildebrand
> > 
> > 
> > Craig <ckaes at jabber.com> writes:
> > 
> > > I've got a couple issues with the SASL jep.
> > >
> > > Issue one (from section 2.2):
> > > 1)  Client says, "<stream:stream..." (translated, "I like SASL.")
> > > 2)  Server says, "<stream:stream...><sasl:mech...." 
> (translated, "Me
> > > too!  I support these methods."
> > > 3)  Client says, "<sasl:auth mech='PLAIN'>base64(foo)..." 
> (translated,
> > > "I like plaintext, my password is "foo").
> > >
> > > Now in the doc, the Server says, "<sasl:success>" but I'm 
> wondering
> > > how it did this without knowing the jid of the user trying to
> > > authenticate.
> > >
> > > One way to attack this problem would be:
> > >
> > > 1)  Same.
> > > 2)  Server says, "<stream:stream...><sasl:challenge>base64(Who are
> > > you?)</sasl:challenge>
> > > 3)  Client says, "<sasl:response>base64(bubba708)</sasl:response>"
> > > 4   Server says, 
> "<sasl:challenge>base64(PLAIN,DIGEST)</sasl:challenge>....
> > > 5)  Client does step 3 from before.
> > >
> > > It should be obvious why having the user id might be desirable for
> > > authentication.  Why would it be desirable to have it 
> before methods
> > > are given?  Because I have top-secret clearance and must 
> use Kerberos
> > > but you are just a plain ol' office worker and plaintext 
> is fine for
> > > you. The server ensures that I auth using a method 
> appropriate for my
> > > clearance.
> > >
> > > Issue two:
> > >
> > > We are not required to use base64 encoding of everything. 
>  Is there a
> > > reason that this was chosen other than that IMAP did it?  
> Is this so
> > > that we can support Kerberos in the future?  It makes it 
> difficult to
> > > test in the present.
> > >
> > > Issue three:
> > >
> > > This is a minor point raised by step 3 in the second 
> sequence above
> > > (<sasl:response>base64(bubba708)</sasl:response) and that 
> is whether
> > > we want to send bubba708 at foo.org or just bubba708 like we 
> do today.
> > > This becomes a bit of an issue with respect to base64 
> encoding in that
> > > for authentication to happen correctly, we'd have to snag 
> the host out
> > > of the stream header (we do this today), unencode the 
> response to get
> > > "bubba708" (don't do today), glue it onto the "foo.org" 
> (we do this
> > > today), and re-encode the whole mess (don't do today) 
> before handing
> > > off to the sasl libs.
> > >
> > > Thoughts?
> > >
> > > --C
> > >
> > > _______________________________________________
> > > Standards-JIG mailing list
> > > Standards-JIG at jabber.org
> > > http://mailman.jabber.org/listinfo/standards-jig
> > 
> > _______________________________________________
> > Standards-JIG mailing list
> > Standards-JIG at jabber.org
> > http://mailman.jabber.org/listinfo/standards-jig
> > 
> 
> _______________________________________________
> Jabber-IETF mailing list
> Jabber-IETF at jabber.org
> http://jabber.org/cgi-bin/mailman/listinfo/jabber-ietf
> 



More information about the Standards mailing list