http://permalink.gmane.org/gmane.ietf.sasl hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.sasl/5756 <pre>Ah hah!  Eager readers can see the txt or PDF version at https://datatracker.ietf.org/submit/status/41447/ ----- Original Message ----- _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> William Mills 2012-05-19T05:00:19 http://permalink.gmane.org/gmane.ietf.sasl/5755 <pre>Well, I've got a draft done, however it's not playing nice with the submission tool, even though it passes all of the xml2rfc tools I checked.  -bill ----- Original Message ----- _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> William Mills 2012-05-19T04:33:27 http://permalink.gmane.org/gmane.ietf.sasl/5754 <pre>If the only difference is to say "I don't want to use/don't have access to channel binding data", then I think 2 variants of 1 mechanism are actually simpler to implement overall. _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> Alexey Melnikov 2012-05-16T15:24:04 http://permalink.gmane.org/gmane.ietf.sasl/5753 <pre>Right. I don't think CRLF is particularly problematic. Using just LF is fine as well. This is indeed a minor issue, but using a character that would be hard to type in telnet (such as NUL) would make debugging more difficult. _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> Alexey Melnikov 2012-05-16T15:17:34 http://permalink.gmane.org/gmane.ietf.sasl/5752 <pre>I slightly prefer KV, but I can live with either. _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> Alexey Melnikov 2012-05-16T15:12:50 http://permalink.gmane.org/gmane.ietf.sasl/5751 <pre>Hi, I mentioned in a post a few months ago that we've been working on a GSS-API mechanism implementation according to draft-ietf-kitten-sasl-saml-ec. We've now got it working with the MIT GSS example programs and Shibboleth identity provider using HTTP Basic Authentication, so I figure it's a good time to send around a pointer to our code: https://github.com/jbasney/mech_saml_ec If you have a chance to give it a try, please let me know. Any contributions (patches, bug reports, etc.) are very welcome. Next we're going to try to get it working with OpenSSH. -Jim _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> Jim Basney 2012-05-16T15:03:29 http://permalink.gmane.org/gmane.ietf.sasl/5750 <pre> While admittedly this is a wire protocol, I still think it's a bad idea to assume that TAB will survive unmolested. All it takes is editing test data in a "helpful" editor and now your TAB is some number of spaces and you have a confusing and strange problem that you're probably going to waste some time on. If we go that round, I think we'd be better off with some control character that editors are unlikely to assign special properties to, like Ctrl-A, Ctrl-C, or Ctrl-G. </pre> Russ Allbery 2012-05-15T21:34:05 http://permalink.gmane.org/gmane.ietf.sasl/5749 <pre> Thinking about how SAML20 and SAML20EC could be collapsed into one mechanism (it would become quite complex), I am inclined to agree. I guess it depends on the underlying protocol, for SCRAM it makes sense to have both variants in the same document, but for complex environments like SAML and OAuth it might not make sense. /Simon _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> Simon Josefsson 2012-05-15T19:55:25 http://permalink.gmane.org/gmane.ietf.sasl/5748 <pre> We are firmly in bikeshedding land here, but what about TAB as the separator? /Simon _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> Simon Josefsson 2012-05-15T18:22:24 http://permalink.gmane.org/gmane.ietf.sasl/5747 <pre>Inline... I don't believe so, but there can be line continuations, that is escaped CRLF.  I was going to specifically disallow that in the syntax. I'm not rabidly against NULL, though it makes life harder for the producer of the string to have to embed nulls and it's more annoying in other languages than C variants.  C variants can easily replace some other fencepost with NULL for in place string handling.  Agreed that EOL conversion is a PITA.  If it's not CRLF I would be more inclined to pick a control character like control-A or control-C (which has the tag EOT in ascii and so is weirdly pleasing). _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> William Mills 2012-05-15T17:07:03 http://permalink.gmane.org/gmane.ietf.sasl/5746 <pre> Is there some other character that isn't used in authorization headers that could be used as a separator? I also dislike having to base64 encode values if it can be avoided. Another option is to escape "," but escaping is often troublesome as well. What I don't like about CRLF is that in some environments you may end up combatting EOL conversions. Also, doesn't some HTTP header allow embedded CRLF as whitespace? Another approach is to use ASCII NUL as separator. The length is implicit anyway, since you know when to stop parse. That is: key = [A-Za-z0-9_-]+ value = [^\00]* kvpair = key "=" value msg = kvpair (%x00 kvpair)* This has the following properties: * Easy to parse * All non-NUL data values can be expressed (binary data with embedded NULs will have to be base64 encoded) * No escaping * You can use strlen and friends to find the end of the string to parse /Simon _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten</pre> Simon Josefsson 2012-05-15T16:33:30 http://permalink.gmane.org/gmane.ietf.sasl/5745 <pre> I think that's right for the OAuth case. No strong preference here. Peter </pre> Peter Saint-Andre 2012-05-15T16:12:42 http://permalink.gmane.org/gmane.ietf.sasl/5744 <pre> Descriptive key names I like.  "=" instead of "SP" is fine too.  Comma separated means that the authorization header value will have to be base64 encoded, and I'm not sure I'm a big fan of that.  CRLF won't appear in the auth header. Re-using the parser from 5801/5802 is attractive though.  Not sure what I prefer there. _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> William Mills 2012-05-15T16:00:08 http://permalink.gmane.org/gmane.ietf.sasl/5743 <pre>I'd prefer to go with two mechanisms.  It makes the logic MUCH simpler.  Policy is then implemented by the mechanism you advertise. -bill Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> William Mills 2012-05-15T15:53:52 http://permalink.gmane.org/gmane.ietf.sasl/5742 <pre> +1 What hasn't been clear to me if there is any way to achieve channel binding with OAuth. Possibly it is in a similar situation as SAML which resulted in the two SASL mechanisms SAML20 and SAML20EC, namely, that the traditional and most common deployment of the protocol does not easily support it, but it may be possible to use some extension to achieve channel bindings. If this is the case, I think it would be nice if both variants could be achieved within the same SASL mechanism. Unless that becomes very ugly. If it becomes ugly, it may be simpler to have two SASL mechanisms that each become less complex. /Simon _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> Simon Josefsson 2012-05-15T13:57:40 http://permalink.gmane.org/gmane.ietf.sasl/5741 <pre> Great. I like a key=value approach. To me, it is better than JSON since it is easier to parse when you don't have external libraries available. Why digits as keys? Some consistency with RFC 5801/RFC5802 would be nice, so how about something like the following, in pseudo ABNF/regexp language: key = [A-Za-z0-9_-]+ value = [^,]* kvpair = key "=" value msg = kvpair ("," kvpair)* This allows descriptive names for the "key" names. /Simon _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> Simon Josefsson 2012-05-15T13:53:53 http://permalink.gmane.org/gmane.ietf.sasl/5740 <pre> Very much so, yes. But that doesn't mean that you can't create new SASL mechanisms that can't do channel binding. The key is that if a mechanism could support it given its fundamentals, then it must support it. Nico -- _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> Nico Williams 2012-05-15T02:04:28 http://permalink.gmane.org/gmane.ietf.sasl/5739 <pre>What's the prevailing wisdom on channel binding, is it still the case that we SHOULD define SASL mechanisms that support channel binding along with non-bound ones? Thanks, -bill _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> William Mills 2012-05-15T00:02:37 http://permalink.gmane.org/gmane.ietf.sasl/5738 <pre>I don't have a preference.  The key value format is easier to parse.  JSON has libraries. Folks please weigh in with JSON vs. KV votes please. Thanks, -bill Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> William Mills 2012-05-14T22:37:20 http://permalink.gmane.org/gmane.ietf.sasl/5737 <pre> +1. This approach seems more easily parseable than HTTPish headers (especially given questions about how complete one's HTTP parser needs to be). However, if we're going to have a simple key-value format, why not use JSON instead of defining something new? (And yes, I'm an XML guy myself...) Peter </pre> Peter Saint-Andre 2012-05-14T22:09:17 http://permalink.gmane.org/gmane.ietf.sasl/5736 <pre>Having inquired of a number of folks that have implemented the XOAUTH mechanism and getting no reply, I'm planning to go with "silence == consent" and presume there's no big objection to moving away form the HTTP format style for the SASL messages.  I' planning on a key/value pair format, which is easily extensible.  My plan was something like:     NONZERO ::= %x31-39     key ::= NONZERO *DIGIT      value ::= *(SP HTAB VCHAR)     msg_line ::= key SP value CRLF     sasl_msg ::= +msg_line CRLF We would need an IANA registry for keys.  Objections?  Other preferred formats? -bill_______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> William Mills 2012-05-14T21:59:03 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.sasl