IETF 79 - kitten Working Group Minutes ====================================== Location: Beijing, China - Shangri-La Hotel Beijing Time: 11/09/10 at 9:00-11:30 Local time Co-Chairs: Tom Yu Shawn Emery Scribe: Shawn Emery Security Area Director: Tim Polk Action Items: ============= Tom Yu: Peform PROTO write-up for draft-ietf-kitten-digest-to-historic. Co-chairs: There will be a consensus call on the list to decide whether to adopt the SASL-SAML-EC and SASL-OAuth drafts in the WG and to discuss how to address the security issues associated with these and the SASL OpenID and SAML drafts currently in the WG charter. Co-chairs: Find authors/editors to take on specific work items outlined in draft-yu-kitten-api-wishlist: initial/new credentials asynchronous calls Sam Hartman: Will update the gssapi-naming-exts draft and submit a new draft discusing the SAML mechanism implementation for naming extensions. Conference Session: =================== Summary ------- WG Update: http://tools.ietf.org/agenda/79/slides/kitten-2.pdf Implementing kitten Technologies: http://tools.ietf.org/agenda/79/slides/kitten-1.pdf Differences between SASL-SAML and SASL-SAML-EC: http://tools.ietf.org/agenda/79/slides/kitten-0.pdf SASL-OAuth: http://tools.ietf.org/agenda/79/slides/kitten-3.pdf -- WG Update: gssapi-extensions-iana ---------------------- Consensus on the list was to standardize a per programming language register. Co-chairs will ask the editor again to update the draft with per programming language registry text. draft-ietf-kitten-digest-to-historic ------------------------------------ Tom Yu has agreed to perform the PROTO write-up for this draft. gssapi-naming-exts ------------------ Current state is: Revised ID needed. Sam Hartman has volunteered to provide text to resolve issues that he has presented at the last IETF meeting. He has also agreed to create a separate SAML mechanism implementation draft for naming extensions. draft-ietf-kitten-sasl-openid ----------------------------- Still looking for review and comments. draft-ietf-kitten-sasl-saml --------------------------- New version submitted to clarify security considerations section to include a secure channel for the mechanism. The draft was updated to use a URI redirect instead of an HTTP. Looking for review and comments. Presentations ------------- Implementation Feed-back of Kitten Technologies by Sam Hartman Sam discussed some positive feed-back in implementing a GSS-API mechanism besides Kerberos, GSS-EAP. There were some limitations and some complimentary libraries required to perform mappings, for example. SASL-SAML and SASL-SAML-EC by Klaas Wierenga There was confusion on the list between the differences between SASL-SAML and SASL-SAML-EC mechanisms. Klaas discussed the infrastructure and protocol differences between the two mechanisms. SASL-OAuth by Hannes Tschofenig There will be a consensus call on the list to decide whether to adopt the SASL-SAML-EC and SASL-OAuth drafts in the WG and to discuss how to address the security issues associated with these and the SASL OpenID and SAML drafts currently in the WG charter. Charter Discussion ------------------ Still looking for volunteers for the following work items initialization/new credentials listing/iterating credentials exporting/importing credentials error message reporting asynchronous calls security strength reporting programmer friendliness There has been greater interest in initial credentials and asynchronous calls. The WG should pursue these fairly soon. -- Transcription: Shawn Emery: Prelminaries Shawn: Agenda, WG update, 3 presentations Shawn: Active WG items Shawn: IANA extensions, concensus on the list, preference was registry per programming language Shawn: Will ask Nico to make update for per progamming language Shawn: Digest to historic needs PROTO write-up. Tom Yu: I'll do the write-up Shawn: Naming extensions is currently in revised ID needed. Sam Hartman: Will send text to Leif to include update to the original draft. Sam: In regards to creating a separate SAML naming attribute draft; there is enough SAML people here that it doesn't matter if this is created in kitten or abfab. Shawn: SASL-OpenID needs review and comments to the list. Shawn: SASL-SAML needs review and comments to the list. Shawn: New version of SASL-SAML has been made to include text in the security consideration section that the mechanism is used in a secure channel and that redirects are for a URI. Shawn: Sam Hartman will present lessons learned implementing kitten technologies: http://tools.ietf.org/agenda/79/slides/kitten-1.pdf ... Shawn: In regards to the use of the Shebeloth library; is there any short-comings with the GSS-API in regards to mapping standard attributes to local? Sam: No, we wanted unqualified names that were locally scoped or unqualified names with a URI that is standardized. These URIs get mapped to local name attributes by local policy. The Sheboleth service does a good job in mapping SAML name attributes to local names. Shawn: The last time NegoEX was brought to the WG there was some controversy of abstraction violation (get_mic). Sam: This is not call to standardize NegoEX, but when building a mechanism interop should considered (e.g. by provisioning a GUID). Shawn: Klaas Wierenga will present differences between SASL-SAML and SASL-SAML-EC: http://tools.ietf.org/agenda/79/slides/kitten-0.pdf ... Jeff Hodges: When you are talking about authentication, you are talking about a SAML profile not protocol. Klaas: Point taken. Alexey Melnikov: How does the SASL server correlate a SAML exchange to the SASL connection? Klaas: The sasl server does an access request to the RP and the RP creates a session ID that is included in the response to the SASL client. Sam: You could put session IDs in the SAML assertions, but this is an implementation detail that could be specified in the draft, but only as guidance. Scott Cantor: ECP implementations do exist, Sampo. Jeff Hodges: Keep in mind that Sheboleth is just a SAML implementation which supports multiple identity management. Sam: SASL-SAML has all the phishing problems of having a separate path for client authentication and server authentication. Sam: SASL-SAML-EC has a major advantage over SASL-SAML in that it is supports CB. Sam: SASL-SAML not inheritly worse than plain text pw, but not much better. Sam: Since SASL-SAML is already in our charter we should accept this mechanism. Sam: If we are going to support SAML exchanges then I'm in strong support of the SASL-SAML-EC mechanism, preferably as a GS2 mechanism. Jeff Hodges: I worry about polluting this space and confusing people. We should have separate separate plugins for each approach. Peter St Andre: Once it's deployed it will be out there forever. Is SASL-SAML just an experiment? Klaas: For the ECP approach my issue is that the client has to change, the IdPs have to be updated, and on the SP side. Klaas: Would support something in the draft that says if your IdP support EC then select this profile. Leif Johansson: Does the SASL-OpenID share the same security issues? Hannes Tschofenig: Elliot is interested in moving forward with this mechanism. Hannes: There was never a question between adopting OpenID or SAML. Sam: We should ask the question; when adopting a new work items is this an affective use of a security area's WG time? Sam: We didn't know the security properties (channel binding, mutual authentication, etc.) of the mechanisms (SAML and OpenID) when we adopted these into the charter. That was probably a mistake. Hannes: We have to build on existing technology, so we have to deal with some of these deployment circumstances. Groups have agreed upon security requirements. Shawn: What it be reasonable to standardize options for OpenID and SAML that had better security properties and documenting the assumptions on security for the mechasims that have weak security properties? Sam: I don't we should spend type documenting security properties of these mechanisms. We should spend time on designing mechanisms with good security properties. Sam: I'll appeal to BCP61. Sam: I'm in favor of designing mechanisms that reduce phishing, that have strong authentication, that supports the use of cryptographic primitives, and let the rest of the IETF or individuals work on other things. Klaas: I would like to see a development of a secure solution. I don't want to make things worse than what currently exists on the Internet. Tim Polk: The issue that I've seen with competing standards is that none of them was widely adopted. We don't want to spend cycles on a vanity publication. Tim: There is value to the community if the mechanism can leverage existing infrastructure (SASL-SAML). Tim: We should progress things that provide good security and actually get deployed. Sam: I believe we can find rough consensus in the group that SASL-SAML-EC is a better solution than SASL-SAML and that SASL-SAML is much easier to implement. Also that adopting SASL-SAML will discourage usage of SASL-SAML-EC. Hannes: How many are implementers vs standards people do we have here? Peter: I don't think we're making a lot of progress here. We should take it to the list: 1. Who are going to implement which mechanism. 2. Who has read the documents and to take a look at these again. Sam: There were a number of people that had raised concerns about documents already on our charter, but has there been any against SASL-SAML-EC? Hannes: I'm not concerned about implementing EC. Scott: Much more work to do for EC, the client side is not trivial in both EC and non-EC, going to implement the SASL server part, but the client side is less clear. Tim: I didn't say that we were going to block for both being standardized. I just don't want the WG working on a vanity publication. Leif: When Scott's organization implements something, it is considered a major implementor of the technology. Hannes: But implementation is not deployment. Hannes presents SASL-OAuth: http://tools.ietf.org/agenda/79/slides/kitten-3.pdf ... Sam: Is this two-legged authentication? Hannes: No. Sam: Does the resource server and the client share a signature key? Hannes: Yes. Sam: We should only adopt mechanisms that have good security properties. Sam: You could come up with a good approach with the HMAC scheme. Sam: Not so sure that you could come up with one for the asymmetric scheme. Sam: I would be willing to work with the authors to see if this is possible. Sam: If we don't do this then we need to have discussions on what we do and don't adopt. Sam: The way you could deal with load-balancers is to use TLS-endpoint instead of TLS-unique and the client knows which certificate the load balancer is using. Hannes: Keep in mind that we are using a three-party protocol not a two-party protocol. Sam: What's the properties between the authorization server and resource server? Hannes: There are no standarized exchanges between those entities. Sam: I'm interested about whether a resource server has an API key or I use a web form that asks permission to give a resource server key and to identify yourself? Hannes: This is a step that happens previously and is not a standardized exchange. Sam: Yes but it should be desirable in the OAuth community that the client is talking to the right server. Hannes: This could happen between the service providers. Sam: This should be documented in the security considerations section, but could be difficult, though the protocol exchange would not be difficult. Tim: It seems that we have agreement that the documents should be updated to flesh out the security considerations this week and then do a concensus call to add it to the working group. Shawn: Still looking for volunteers for the following work items. Async calls Security strength Programming friendliness Exporting/importing credentials Iterating credentials Initial authentication Sam: If we are still moving forward on some things then we should still exist. Sam: We are making forward progress on a couple of drafts then we an active WG. Tim: We should get with the chairs to pick out the most urgent issues and start recruiting. Tim: We could then recharter with the other items excluded from the charter. Tom Yu: For the async API we can get Nico together w/other folks to hash out a solution. Shawn: It would be nice to have editors to help document the proposed solutions that have already been made. Sam: We have initial credential implementations that we don't have a specification for. Sam: There is gss_acquire_cred_with_password, MIT 1.9 is shipping and I think Solaris ships. Sam: Moonshot is depending on and GS2 SASL bridge depends on. Tom: The Kerberos Consortium has interest in async and we may be able to drag in volunteers. -- Open mic: none. ================ Session Over