http://blog.gmane.org/gmane.ietf.sasl hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.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://comments.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://comments.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 http://comments.gmane.org/gmane.ietf.sasl/5721 <pre>Recap: Simo and I have a proposal to add three new functions dealing with acquisition of creds from "credential stores" and storing credentials into credential stores. A credential store is a sequence of key/value pairs where the keys are URNs and the value syntaxes given by the keys. Among the possible keys as "password file" and such. Simo intends to use these functions in a context where the key/value pairs come from a configuration file. It would be inappropriate to allow passwords/keys/PINs/secrets of any kind to be encoded in a configuration file, so he proposes that no URNs be provided by which to pass secret values to the mechanism. But I see a general replacement for gss_acquire_cred_with_password() in these new functions and I don't want to either preclude such a use or force apps to write secrets into temporary files. At the same time I completely agree that no secrets should be stored in configuration files... So I'd like to propose an extension to the GSS_Acquire/Add_cred_from() functions</pre> Nico Williams 2012-05-08T21:28:38 http://comments.gmane.org/gmane.ietf.sasl/5720 <pre>I've uploaded draft minutes of the Kitten WG IETF83 session to the Meeting Materials website: http://www.ietf.org/proceedings/83/minutes/minutes-83-kitten.txt Please let me know if there are corrections that I should make. Thanks. _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> Tom Yu 2012-04-26T21:18:10 http://comments.gmane.org/gmane.ietf.sasl/5718 <pre>Hi. The ABFAB working group has just started a last call on draft-ietf-abfab-gss-eap-06. This defines a GSS-API/SASL mechanism and so it would be desirable to get kitten's review. Comments should be sent to abfab&lt; at &gt;ietf.org by May 1. Simon has already pointed out that we got our SASL registration off. _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> Sam Hartman 2012-04-17T20:24:03 http://comments.gmane.org/gmane.ietf.sasl/5705 <pre>All, When experimenting with the OPENID20/SAML20 mechanisms, I've been reminded that a usual pattern for SASL clients is to open several connections to a server. Traditionally this hasn't been a problem: the passphrase or Kerberos ticket is cached so the client re-handshakes SASL using CRAM-MD5, SCRAM-SHA-1 or GSS-API. Both OPENID20 and SAML20 potentially need human interaction that can be be slow. Other mechanisms (e.g., SAML20EC and GSS-EAP) are less dependent on human interaction but can still be slow. Thus we have a problem that 1) clients expect to be able to open multiple connections, and 2) some mechanisms may be costly to perform. I see some solutions: 1) Recommend that OPENID20 and SAML20 are deployed in ways that minimize human interaction. Normally, IdPs have an option of remembering an authorization decision of a user, so by using that, OPENID20/SAML20 can complete more quickly: the user would just see several browser windows flash by. This mitigate the consequences of the problem, but d</pre> Simon Josefsson 2012-04-12T09:26:57 http://comments.gmane.org/gmane.ietf.sasl/5697 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At the PRECIS WG session in Paris, we had quite a discussion about spaces in user names. Alexey maintained that this must have been included in SASLprep (RFC 4013) for a good reason, but the reason wasn't clear to folks in the meeting. So I have a few questions: 1. Do SASL user names really need to include spaces? 2. If SASL user names do *not* need to include spaces, would it be fine to re-use the PRECIS NameClass for simple user names in SASL? 3. If SASL user names *do* need to include spaces, would it be fine to define simple user names in SASL as a space-separated list of NameClass entities? Option #3 seems preferable to (a) specifying that the PRECIS NameClass needs to include space (to which there was a lot of resistance during the PRECIS WG session), (b) enabling folks to superclass PRECIS string classes (to which there was also a lot of resistance), or (c) severely subclassing the PRECIS FreeClass to be something like NameClass+SP. Peter - -- Pete</pre> Peter Saint-Andre 2012-04-10T21:48:21 http://comments.gmane.org/gmane.ietf.sasl/5669 <pre>Maybe this ought to have been in the specs since most people appear to compute them by hand, but it isn't. So the DER encoding of the OPENID20 OID that I'm using is: gss_OID_desc GSS_OPENID20_static = { 6, (void *) "\x2b\x06\x01\x05\x05\x10" }; and for SAML20 it is: gss_OID_desc GSS_SAML20_static = { 6, (void *) "\x2b\x06\x01\x05\x05\x11" }; If I prepend \x06 (tag for OID) and \x06 (length 06) I can DER decode the OIDs using e.g. 'dumpasn1' and it looks right. However, it would be good if someone else confirmed this independently (or at least as independently as can be hoped for since I have now posted my guess). /Simon _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> Simon Josefsson 2012-04-04T14:49:45 http://comments.gmane.org/gmane.ietf.sasl/5667 <pre>When implementing the GSS-API part of OPENID20/SAML20 I noticed that the processes can hang waiting for a long time. Server may want to wait one minute or more to allow a user to finish the IdP authentication. I think Nico discussed asynchronous GSS-API before. However it is a significant amount of work to specify and implement. I think it is simpler for applications to create a separate process or thread for the GSS-API part, and to enforce its own timeouts. Sometimes there are other reasons for having separate processes/threads anyway. Still, even an asynchronous interface may want to use some timeouts where authentication is no longer expected to ever finish. So it is not clear that an asynchronous interface is the solution to this problem. Does anyone have any thoughts on what a reasonable timeout should be? Or should GSS-API initiators and acceptors never timeout, but just hang indefinitely in case the authentication eventually completes? Of course, we could have a new GSS-API interface to enf</pre> Simon Josefsson 2012-04-04T14:43:39 http://comments.gmane.org/gmane.ietf.sasl/5661 <pre> I went to IETF #83 specifically to get feedback (and I though a tentative decision) on the question of whether the SASL message format currently there which uses HTTP was a good idea or not.  I did get a ton of good feedback in individual conversations, the conversation in the working group itself was a little less lively. From the WG meeting: -    several folks promised to read deeper and bring comments back to the list. -    Hannes' comment at the mic (my summary) was that given the many successful integrations against Google's XOAUTH that staying close to those has great value for getting successful uptake, and that adapting the code those clients use to new endpoints  From general feedback from random folks: -    Many folks said HTTP is in fact very hard to parse correctly if you have to parse it fully. -    Some folks felt existing implementations close to a proposed spec are likely to add to successful adoption. -    a few folks felt that it's reasonable to limit the stuff that act</pre> William Mills 2012-04-04T00:10:39 http://comments.gmane.org/gmane.ietf.sasl/5658 <pre>Hello, I have set up a SMTP server with SAML20 support on "interop.josefsson.org" port 2001, for interop purposes. Currently it only knows about Feide's OpenIdP and ProtectNetwork's IdP, but send me metadata for your IdP and I'll add it. For details on how the server works, see: https://lists.gnu.org/archive/html/help-gsasl/2012-04/msg00001.html In the post you can see a step-by-step example of a succesful SAML20 authenticated login to the SMTP server. The server software is GNU SASL 1.7.3 and the SAML implementation is Lasso. The spec is still a bit unclear on whether the final client response is empty or '='. I believe we discussed this before, and came to the resolution that it should be '='. The document still says 'empty' in a few places, to be fixed in AUTH48 hopefully. /Simon _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> Simon Josefsson 2012-04-03T12:41:25 http://comments.gmane.org/gmane.ietf.sasl/5655 <pre>Hello, Version 1.7.2 of GNU SASL (announcement in [1]) supports the OPENID20 mechanism and contains a example server which is running on "interop.josefsson.org" port 2000 using the SMTP protocol. The server accepts any OpenID URLs and will happily redirect you to its IdP and accept its authentication decision. Real servers would probably have some pre-filtering of acceptable OpenID URLs before proceeding with the redirect (i.e., the URL must match some identity in the database of authorized users). There are hints on how to test the server here: https://lists.gnu.org/archive/html/help-gsasl/2012-03/msg00004.html In the post you can see a step-by-step example of a succesful OpenID authenticated login to interop.josefsson.org. What is unusual about this mechanism compared to all other SASL mechanisms I have implemented is that it is variable-roundtrip. It can complete successfully after the second roundtrip (i.e., openid url, redirect url, dummy '=' response) or after the third roundtrip (i.e., openid </pre> Simon Josefsson 2012-03-28T19:10:40 http://comments.gmane.org/gmane.ietf.sasl/5654 <pre>Dear all, the full recording (synchronized video, audio, slides and jabber room) of KITTEN session at IETF-83 is available. You can watch it by either clicking the proper link on the remote participation page (http://www.ietf.org/meeting/83/remote-participation.html#Meetecho), or by directly accessing the following URL: http://www.meetecho.com/ietf83/recordings#KITTEN_IETF83 For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-support&lt; at &gt;meetecho.com. Cheers, the Meetecho team </pre> Meetecho IETF support 2012-03-27T19:24:45 http://comments.gmane.org/gmane.ietf.sasl/5653 <pre> The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'GSS-API Naming Extensions' &lt;draft-ietf-kitten-gssapi-naming-exts-14.txt&gt; as a 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&lt; at &gt;ietf.org mailing lists by 2012-04-10. Exceptionally, comments may be sent to iesg&lt; at &gt;ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-kitten-gssapi-naming-exts/ IESG discussion can be tracked via http://datatracker.ietf.org/d</pre> The IESG 2012-03-27T12:48:18 http://comments.gmane.org/gmane.ietf.sasl/5648 <pre>Hi all, a virtual room has been reserved on the Meetecho system for Tuesday's KITTEN/KRB WG meeting session. Access to the on-line session (including audio and video streams) will be available at: http://www.meetecho.com/ietf83/kitten The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. Remote participants might also send their own voice to the room, if they want to. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf83/tutorials Cheers, the Meetecho team </pre> Meetecho IETF support 2012-03-26T16:33:33 http://comments.gmane.org/gmane.ietf.sasl/5646 <pre>I hope to be in the chatroom tomorrow morning (my time), but regardless, here's a current summary: NCSA has implementation work proceeding as part of a funded project to prototype the draft mechanism initially with SSH as the test protocol. The initial feedback from that work was incorporated into a new draft last month, mostly to relax some assumptions about TLS being the only secure transport layer involved, which is not true with SSH of course. An additional item identified by the work was the absence of proper guidance on mechanism name handling, which I had identified a while ago as something that needed attention. The acceptor side will be based on GSS_C_NT_HOSTBASED_SERVICE, but there needs to be language added on mapping that to and from SAML entityID format. The initiator name needs to be expressed in terms of the SAML NameID element, or in its absence, some convention for representing an anonymous initiator (which could be carrying GSS naming attributes to actually identify the subject of course</pre> Cantor, Scott 2012-03-26T15:39:39 http://comments.gmane.org/gmane.ietf.sasl/5640 <pre>Sorry for proposing last minute changes. I have three changes to propose, of which only one is substantive: - clarify section 6 to indicate that "primary attribute component" and "prefix" are the same thing - re-write the second to last paragraph of section 6 - reserve a subset of the "local" attribute namespace ("local" attributes are ones with neither colons nor spaces) This is the substantive change. Sam and I believe that it will eventually be desirable to have simple attribute names that are not URNs -- developers and users/sysadmins (to the extent that attribute names leak into user/admin interfaces) will want non-URN, user-friendly, portable and generic attribute names. Sam proposes to reserve local attribute names that have an at-sign. This change requires confirmation on the list, thus this post. The proposed changes are as follows. 1) Clarification of "prefix": If an attribute name contains a space (ASCII 0x20), the first space separates the m</pre> Nico Williams 2012-03-16T22:04:16 http://comments.gmane.org/gmane.ietf.sasl/5610 <pre> Hi, Shawn has requested publication of this draft. This is my AD review of that prior to starting IETF last call. I've 3 questions that I think need answering. I think a revised I-D is likely needed before IETF LC to handle those. (If not then you'll argue about that:-) I've also some other comments that can be handled before or during IETF LC along with whatever other comments crop up. Things that need handling: 1. Shouldn't this UPDATE something? Maybe 2743 and 2744? (I don't care much really, but others do;-) 2. The IANA considerations section doesn't seem clear enough for IANA to action. What's the update rule, what's the name of the registry, ... 3. Nico's address bounces. Please fix unless there's some good reason - is there? Other comments/questions, (not blocking):- - Section 6 is a bit unclear. In particular the "otherwise" in the 2nd para on p8 - does that mean "if there's no colon" or "if there's no space and no colon"? The clarity of this section could be improved, maybe by laying it out</pre> Stephen Farrell 2012-03-08T14:16:43 http://comments.gmane.org/gmane.ietf.sasl/5602 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : SAML Enhanced Client SASL and GSS-API Mechanisms Author(s) : Scott Cantor Simon Josefsson Filename : draft-ietf-kitten-sasl-saml-ec-01.txt Pages : 27 Date : 2012-02-28 Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication </pre> internet-drafts< at >ietf.org 2012-02-28T16:58:14 http://comments.gmane.org/gmane.ietf.sasl/5597 <pre>Hi, We're working on a GSS-API mechanism implementation according to draft-ietf-kitten-sasl-saml-ec-00, and so far the following comments/questions have come up: What should gss_accept_sec_context() return for src_name (initiator's identity)? Is there a particular SAML attribute value our GSS-API mechanism should be looking for to indicate the user's identity? What should gss_context_time() return? GSS_C_INDEFINITE? Or should we look in the SAML assertion for NotBefore/NotOnOrAfter times? The SAML ECP spec says that the “service provider MUST return an HTTP error status" on errors, but there's no HTTP between the GSS initiator and acceptor, and we assume errors are indicated by GSS status codes. A clarifying statement in draft-ietf-kitten-sasl-saml-ec that the "MUST return an HTTP error status" requirement doesn't apply to GSS-API would be helpful. If you agree, I'm willing to propose text. Section 5 says "applications MUST match the TLS server identity with the target name" which introduces a TLS req</pre> Jim Basney 2012-02-21T20:24:06 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.sasl