[standards-jig] JEP 34 (SASL)

Peter Saint-Andre stpeter at jabber.org
Wed Aug 21 20:27:00 UTC 2002


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'>cm9iAHNlY3JldA==</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
> 




More information about the Standards mailing list