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 such that the mechanism can tell if any secrets in the cred_store are to be allowed or not. Recall that the form of a cred store in the C bindings would be: typedef struct gss_cred_store_element_struct { const char *urn; const char *value; } gss_cred_store_element, *gss_cred_store_element_t; typedef const struct gss_cred_store_element *gss_const_cred_store_element_t; typedef struct gss_cred_store_struct { OM_uint32 count; gss_const_cred_store_element_t *elements; } gss_cred_store, *gss_cred_store_t; typedef const struct gss_cred_store_struct *gss_const_cred_store_t; I can see several possible extensions for allowing secret values here. My preference would be to have a per-element flag field because it that would allow the app/mech to distinguish the origin of each element. Perhaps cred stores should be opaque and should have accessor by which to add key/value pairs, then the accesspor could have an argument indicating the origin of the key/value pair. If we wanted to have a function for learning what the current cred store is then we'd need to concern ourselves with memory management, and then the lessons of gss_buffer_t and friends should push us to using an opaque object type here! I do realize that in order to use GSS_Acquire/Add_cred_from() as the basis for a GSS-API interactive initial credential acquisition interface we'd need a way to tell the app what cred store elements the mechanism needs, and that perhaps this is not the best approach to a generic initial cred acquisition API. However, I also don't want to make it harder to re-use the cred store functions later on if we should want to use them as the basis of an interactive initial credential acquisition API. So my proposal, then, is to make the gss_cred_store_t into an opaque type and to provide a constructor, a destructor, a function by which to add elements, and a function by which to iterate elements, with elements consisting of: key, value, flag, and one flag defined to indicate that the value was obtained interactively or from an appropriate store of secrets. Comments? Nico -- _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </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 doesn't solve it. 2) Consider a SASL resumption mechanism. This could work by having the server compute a cookie that the client could present later on to get the same access it got last time. I'm not sure if this is best done by extending core SASL with resumption features or adding a new mechanism-negotiating-mechanism that handles resumption and invokes some other mechanism. Neither approach is appealing to me. 3) Rely on the secure channel resumption capabilities. Clients appear to be able to implement TLS resume. We could use an EXTERNAL-like mechanism that leverages the SASL state associated with the last TLS channel, e.g. EXTERNAL-RESUME-TLS. I don't think EXTERNAL will work, its semantics is too under-specified and the failures are difficult to recover from. If the EXTERNAL-RESUME-TLS mechanism is advertised the server has some SASL state stored for the client, and the client could decide to leverage that, or start a completely new handshake. The client could also more gracefully handle failures in EXTERNAL-RESUME-TLS (e.g., session expiration) and fall back to the initial SASL mechanism used. The EXTERNAL-RESUME-TLS could be GSS-API mechanism too. Are there other solutions? Thoughts? The background for this is the following discussion: http://thread.gmane.org/gmane.comp.security.lasso.devel/171/focus=187 /Simon _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </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 - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+EqqUACgkQNL8k5A2w/vzHeQCfTX6rF+MAqj05uz/ojJpPDkMT RaMAn2AWoWO3lRiDgxfPmDZy7B4wyawX =xNtO -----END PGP SIGNATURE----- _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </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 enforce a timeout. For example: OM_uint32 gss_sec_context_timeout (OM_uint32 *minor_status, OM_uint32 timeout); or something more general, in case there are similar concerns for other functions: OM_uint32 gss_set_timeouts (OM_uint32 *minor_status, OM_uint32 sec_context_timeout, OM_uint32 micwrap_timeout); FWIW, in my implementation I'll probably use a 5 minute timeout or something like that. /Simon _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </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 actually has to be parsed. There are real difference between the complextity needed for XOAUTH and for the proposed OAUTH mechanism.  XOAUTH does everything in the URL, where the OAUTH proposal  I'll post here the Google XOAUTH SASL message format, and an example form the draft spec: From http://sites.google.com/site/oauthgoog/Home/oauthimap for XOAUTH: For example, before base64-encoding, the initial client request might look like this (with linebreaks added for clarity): (2-legged OAuth) GET https://mail.google.com/mail/b/someuser&lt; at &gt;example.com/imap/?xoauth_requestor_id=someuser%40example.com     oauth_consumer_key="example.com",     oauth_nonce="4710307327925439451",     oauth_signature="75%2BB63NbW2GdDMaOCEd%2Fy%2Fb%2B0Qk%3D",     oauth_signature_method="HMAC-SHA1",     oauth_timestamp="1260933683",     oauth_version="1.0" For the OAUTH mechanism a similar style signed request example is: GET / HTTP/1.1 Host: server.example.com User: user&lt; at &gt;example.com Authorization: MAC token="h480djs93hd8",timestamp="137131200", nonce="dj83hs9s",signature="YTVjyNSujYs1WsDurFnvFi4JK6o=" The OAUTH mechanism will require (as currently specified) parsing of a Host, User, and Authorization header. The path and query is actually ignored at present. Based on this message I'll be posing questions to the list. Regards, -bill  _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </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 url, redirect url, dummy '=' response, sreg, empty response). This caused some complexity in my implementation, but not significant. The document is a bit terse with examples, and there may be room for different interpretation of the SREG vs non-SREG cases, and also when the authentication fails. To get other people's feedback with the hope of improving interoperability, I wanted to give examples of the variants I could think of. (The output below is actually from my self-tests.) Running successful authentication without SREG: S: `' (0) GSASL_NEEDS_MORE C: `biwsaHR0cDovL3VzZXIuZXhhbXBsZS5vcmcv' (36) GSASL_NEEDS_MORE S: `aHR0cDovL2lkcC5leGFtcGxlL05PTkNFLz9vcGVuaWQuZm9vPWJhcg==' (56) GSASL_NEEDS_MORE C: `PQ==' (4) GSASL_OK S: `' (0) GSASL_OK C: `' (0) GSASL_OK S: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES C: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES Running successful authentication with SREG: S: `' (0) GSASL_NEEDS_MORE C: `biwsaHR0cDovL3VzZXIuZXhhbXBsZS5vcmcv' (36) GSASL_NEEDS_MORE S: `aHR0cDovL2lkcC5leGFtcGxlL05PTkNFLz9vcGVuaWQuZm9vPWJhcg==' (56) GSASL_NEEDS_MORE C: `PQ==' (4) GSASL_OK S: `bmlja25hbWU9amFz' (16) GSASL_OK C: `' (0) GSASL_OK S: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES C: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES Running successful authentication without SREG with authzid: S: `' (0) GSASL_NEEDS_MORE C: `bixhPXVzZXIsaHR0cDovL3VzZXIuZXhhbXBsZS5vcmcv' (44) GSASL_NEEDS_MORE S: `aHR0cDovL2lkcC5leGFtcGxlL05PTkNFLz9vcGVuaWQuZm9vPWJhcg==' (56) GSASL_NEEDS_MORE C: `PQ==' (4) GSASL_OK S: `bmlja25hbWU9amFz' (16) GSASL_OK C: `' (0) GSASL_OK S: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES C: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES Running successful authentication with SREG with authzid: S: `' (0) GSASL_NEEDS_MORE C: `bixhPXVzZXIsaHR0cDovL3VzZXIuZXhhbXBsZS5vcmcv' (44) GSASL_NEEDS_MORE S: `aHR0cDovL2lkcC5leGFtcGxlL05PTkNFLz9vcGVuaWQuZm9vPWJhcg==' (56) GSASL_NEEDS_MORE C: `PQ==' (4) GSASL_OK S: `bmlja25hbWU9amFz' (16) GSASL_OK C: `' (0) GSASL_OK S: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES C: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES Running failed authentication: S: `' (0) GSASL_NEEDS_MORE C: `bixhPXVzZXIsaHR0cDovL3VzZXIuZXhhbXBsZS5vcmcv' (44) GSASL_NEEDS_MORE S: `aHR0cDovL2lkcC5leGFtcGxlL05PTkNFLz9vcGVuaWQuZm9vPWJhcg==' (56) GSASL_NEEDS_MORE C: `PQ==' (4) GSASL_OK S: `b3BlbmlkLmVycm9yPWZhaWw=' (24) GSASL_NEEDS_MORE C: `PQ==' (4) GSASL_NEEDS_MORE S: GSASL_AUTHENTICATION_ERROR C: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES Does anyone have different interpretation of how the round-trips should look like? Finally, I I noticed a nit in section 2.1: The nonce value MUST be at least 2^32 large and large enough to handle well in excess of the number of concurrent transactions a SASL server shall see. Presumably the intention is not to use 2^32 = 4GB large nonces. I used a 32 byte nonce, but possibly the intention was that the minimum required length should be 4 bytes? That is reinforced by the examples using 4 bytes. /Simon [1] https://lists.gnu.org/archive/html/help-gsasl/2012-03/msg00003.html _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </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/doc/draft-ietf-kitten-gssapi-naming-exts/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </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). So I need to define a mechanism name type and import/export guidance. I'm curious how that can be left out of the non-EC SAML mechanism, which has the same problem, seems to me. (Same goes for OAuth and OpenID, IMHO, though not in terms of SAML obviously.) Anyway, I'm going to be doing some work to draft something on that shortly. If I'm right that this problem applies to the non-EC mechanism, I'm of course willing to discuss something in common with those authors. The other major open item involves per-message token support. I exchanged some mail a while ago on that with Sam and I have at least a general idea on what to try adding, but the name issue above is higher priority at the moment. Finally, I'm tracking http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-naming-02 and I would guess that I'll want to reference that from the EC draft as a convention for putting the SAML information into naming attributes. Those are the issues I'm aware of at this point. The two OASIS dependencies are so far holding stable, but I'm not advancing them there until I know for sure they don't need changes. </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 most significant or primary component of the name from - the remainder. If there is no space, the primary component is the - entire name, otherwise it defines the interpretation of the remainder - of the name.s + the remainder. We may refer to the primary component of the + attribute name as the attribute name's "prefix". If there is no + space, the primary component is the entire name, otherwise it defines + the interpretation of the remainder of the name.s 2) Re-write of second to last paragraph of section 6: - A sufficient prefix of attribute names needs to be dictated by a - mechanism in order to describe the context. For example it would be - problematic to represent SAML attribute names as the name format URI, - a space, and the remainder of the name. A carefully crafted SAML - assertion could appear to be a name from another mechanism or - context. Typically a SAML attribute name would include a prefix - describing the trust model and other context of the attribute name. + Since attribute names are split at the first space into prefix and + suffix, there is a potential for ambiguity if a mechanism blindly + passes through a name attribute whose name it does not understand. + In order to prevent such ambiguities the mechanism MUST always prefix + raw name attributes with a prefix that reflects the context of the + attribute. 3) Reserving local attribute names with at-signs in them: If the primary component contains an ASCII : (0x3a), then the primary component is a URI. Otherwise, the attribute is a local attribute and the primary component has meaning to the implementation of GSS- - API or to the specific configuration of the application. At this - time, local attribute names are not standardized; there is debate - about whether such standardization will be useful. Any future - standardizations will need to balance potential problems resulting - from attribute names used before standardization. + API or to the specific configuration of the application. Local + attribute names with an at-sign ('&lt; at &gt;') in them are reserved for future + allocation by the IETF. Comments? Nico -- _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </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 as a bulleted list. - I don't really get the 2nd last paragraph of section 6, what's that saying? - The last para of section 6 is also a bit unclear, I think you mean where the administrator controls all aspects (e.g. both the KDC and the relying applications) but I'm not 100% sure. - 7.1, last sentence - would it be better to spell this out some more? E.g. maybe say that ordering of SET OF OCTET STRING MUST be preserved. - The danger in the 2nd last para of 7.6 is not crystal clear. Might be worth spelling that out some more. - An example or two would be nice, or a pointer to such if its easily referenced. Thanks, Stephen. _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </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 in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-ec-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-ec-01.txt _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </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 requirement that I think is not intended. I suggest the following changes. In Section 1, change "existing security layers, such as Transport Layer Security (TLS)" to "existing security layers, such as Transport Layer Security (TLS) or Secure Shell (SSH)" just to give at least one TLS alternative example. Then in Section 5, update "The mutual authentication property..." paragraph as follows: "The mutual authentication property of this mechanism relies on successfully comparing the server identity from the existing security layer (TLS, SSH, etc.) with the negotiated target name. Since the existing security layer is managed by the application outside of the GSS-API mechanism, the mechanism itself is unable to confirm the name. For this reason, applications MUST match the server identity from the existing security layer with the target name. For TLS, this matching MUST be perfored as discussed in [RFC6125]. For SSH, this matching MUST be performed as discussed in [RFC4462]. Applications may rely on the GSS-API mechanism to perform this matching by passing the server identity as targ_name to GSS_Init_sec_context()." As you can probably guess from the above, our initial target application for this GSS-API mechanism is SSH (RFC 4462). Thanks, Jim _______________________________________________ Kitten mailing list Kitten&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/kitten </pre> Jim Basney 2012-02-21T20:24:06 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.sasl