IETF 80 - kitten Working Group Minutes ====================================== Location: Prague, Czech Republic - Hilton Prague Session 2011-04-01 1300-1400: Barcelona/Berlin Session 2011-04-01 1415-1515: Barcelona/Berlin Co-Chairs: Tom Yu Shawn Emery Alexey Melnikov Scribe: James Schaad Security Area Director: Stephen Farrell Action Items: ============= Chairs: Perform a consensus call on the list on whether to adopt the following drafts as WG items: draft-mills-kitten-sasl-oauth draft-cantor-ietf-kitten-saml-ec Chairs: Confirm with Brian Carpenter on whether/what GFD reference can be a normative for draft-ietf-kitten-gssapi-naming-exts. Chairs: Start a consenss call on the list on whether anyone is interested in adopting a WG item to standardize (error) responses for authentication protocols. Conference Session: =================== Agenda Active Working Group Items gssapi-naming-exts ------------------ Sam Hartman: - Simon had new WGLC comments - Nico & Sam believe comments should be addressed - Proposed on list - no objections - no chair action to date Shawn - no problems Shawn - GFD.024 normative reference question Sam - policy is GFD documents reference ok? Stephen (AD) - should not be a problem Sam - what is state of document? we don't really know Shawn - take as action item to determine the state of the document Leif - had dissussion a few ago - recollection is ok to do the reference. Sam - should be fine - it would have been ok when he was on IESG Lief - proposal was to write a separate document to describe - pushd back was just could reference. Stephen (AD) - if stable no big deal Elliot - Is there easy access to the document? Sam - yes - urls exist Sam - recommend to chairs - look for GGF lieason and ask them. Jeff - Read message from archive (from Simon) Sam - dealt w/ that as layer violation on API - getting set of buffer out look at 2743 to see what a buffer is. Simon - tech concern was w/ kitten not GFD document. Elliot - Informational - is currently no liaison. Sam - ask Brian Carpenter then sasl-openid ----------- Elliot Lear: - no last call comments - had earlier comments - has one self question. references openid so might be a problem on standards track could make it experiemental instead Tom - IESG opionions? Tom - is it sufficently normative Elliot - problem was raised by PSA - is the org sufficent for a normative reference? Tim - Was it the org or the doc? Elliot - issue was org not doc as presented to him Step - Do what is right - fix it later if lots of errors Tim - WG recommends - AD can change it later if necessary Shawn - ok - just move foward and Steve (AD) - no changes in current status Stephen (AD) - people worked on it before? - look at how reviewed it is sasl-saml --------- Presentation: Klaas Wierenga Sam - How do I map from a domain to finding the right meta data Elliot - Same as in ABFAB - internal RP process Sam - Can you give me an example that works in saml stack today Klaas - Not specified in saml standard (Elliot - use NAPTR) - Scott Canter - don't use it today Klaas - use static configurations - limited number of domains - usually 1 Scott - can we have both options? could look from the start - not all clients have the typeing restriction Klaas - Don't want to be complicated Scott - use basic grammer check - such as contains a colon Jeff - what other than URI Scott - ether URI or domain name Scott - mild preference Sam - support w/ mild prefernce also Sean - any one else w/ a preference? Klaas - or objections? Elliot - looks to be a simple discriminator Sam - not sure that the RP code changes - if doing database lookup Elliot - the id is opaque to the client? Sam - Depends on what you are using this for - for some classes of implementation it is - client want to do something special for IdP - then not opaque. If server has non simple method of resolve then not opaque to server. Channel Bindings for SAML-EC ---------------------------- Presentation: Scott Cantor Sam - awesome - same token format SCRAM uses. Should talk about GSS channel binding stuff - everything you want to do is possible, but some layering issues may be confusing things. Recommend in OASIS spec - (not required by IETF but Msft makes it necessary) - sever send set of channel bindings Scott - we do this. Scott - channel binding header get used multiple times - types support on server & client side, server sned multiple - include multiple in request - return multiple verified. no assumptions about how it is necessarily used. Sam - GSS doesn't know the type Scott - may be necssary to change scheme to relax some things like specifying the type. SASL and GSS-API for Two Factor ------------------------------- Presentation: Shawn on behalf of Simon Josefsson Sam - OTP in Krb does require confentiality - the OTP is the password it is not two factor. The pin thing might be two factor - not as much key derivation. If thinking of GSS-EAP - ABFAB is suppose to provide an applicatity statement of when it is approparite - but not written yet. First version (probably) - recommend when seperation of password through authenticator and the party doing the authentication is desired. esp if decoulple types of creds used. So OTP server is not on the machine which is the acceptor would be an example. esp if mutiple types of credential acceptors. WG no consus since no document yet exists - please contribute if you don't like it. GSS-EAP not more heavy weight if you implemente things - more than minumal SCRAM + OTP however. Nice to compare the functionaltiy of this and the krb-OTP draft to see what the changes are. Authentication Reponses for Protocols ------------------------------------- Presentation: Alexey Melnikov Shawn - what are you looking for? Feedback on design of exetions? Alexey - is it a good idea? Will need IANA registration document. Sam - this is a real problem - This is a needed step to solve. Tom - Better solution than GSSAPI Sam - wrong layer Shawn - short on resources? Jeff - Please make concise problem statement Sam - App behavior depends on - that password is incrorect is different from account disabled - needs to be able to map SASL errors to my app is needed. As platofrm is more complicated different failures will change behavior. Some needs to be carried back in app protocol - may want to even if you don't need to. Have a standardized way to display this. Best to have arbgument once than per app. Jeff - Think like or neutral on having dissucsion once - that apps need to indicate on way up. Some other frame work provide same set of things. Will be protocol/app specific in any event. How mapping is done is very app dependent. Master table is a lost cause. Alexey - not for all known protocols - just a basic set. Others could add to the table Jeff - all colums except for our errors - leads to a duplication of error codes Alexey - only registry is for SMTP enhanced - others are scattered around Jeff - Create set of error conditions and make sure it is complete and other protocols can represent these errors. Leery of add new column work. Shawn - Non-normative reference? Jeff - Could produce a table which is a survey - need to do that research anyway to determine if work is missing. Different than registrory. Alexey - willing to write draft and do the initial research Shawn - any others? Sam, Jeff(?), PSA(?) PSA - Looking at new errors that might arrise in the future for SASL as well as current problems. Not for XMPP to say what the definitive list is. Alexey - Good example of new error conddtion - missing channel binding - would not have thought of this 3-4 years ago - so consistancy of adding new failures across protocols is good. Shawn - application currenlty interested, XMPP, IMAP, LDAP, SMTP Recharter --------- Shawn: Some wish liste items are languish w/ no volenteers to write docs Sam: - hope to find out if have energy for someting in the cred management space by Quebec Hannes - posted an updated draft and release source code. Also a google/gmail implementation. Still working in OAUTH in doing final specfiication. Alexey - might be the one to integerate changes into sasl. Issue w/ OAUTH dependency. Don't want to recharter until OAUTH is going to complete in specific period. Sam - kind of like not to be a mechisism working group. Don't want to see PAKE here int he WG - work on framework is more important. If doing one SAML should do both. Sam - thought we were going to choose at last re-charter and was asleep at the switch. If we are doing mech. then scott's is good and would like to give it a fair shot. Making no comment on oath. Hannes - Don't wnat to become mech but should have the one I like - not really reasonable. Sam - happy if we take the ones that people can make a strong argument for now. Find do to that at large intervals. Stephen (AD) - don't have to re-charter right now. could domant for a while. Jeff - sam's comment not on if it shoudl be done. But don't wnat to do vanity publication of mechisnisms Tom - People want to see new mech be published and reviewed. Sam says should not sepend bulk of time on framewrok not on mech. Alexey - Different types of charters say anything of type x is ok - this charter is very specific - should not change that. Jeff - New model for building mechinisms - now - what mech exists where people are willing to do work and are useful to have and don't currently exist. Make a specific list of these rather than open gateway. Not out of work - think we have work that is about to finish and work we haven't started because no resources is not the same as being out of work. Hannes - Compare w/ EAP - conncern is don't waste time on every EAP method - higher bar for std track docs. Other EAP methods can be added to registry. Market shakes out what is successful. See if deplyment catches up and then wg can move to std track. Sam - EMU model sounds good - but our model is even more liberal than theirs. We have two on the talbe - don't want more than that - strong on ec, neutral on oauth. Scott - defer to working group process. Did not know what was the process and wanted to get WG review to improve things. Might not have happened if just poseted to list for review. Tom - read text from charter Jeff - Reasonable to only do std track work - Reasonable to review other things. New std track mech to be built as dual SASL/GSS when possible. Support Channel Bindings and CB PRF. Don't think that only things on the table should be the things people are currently pushing - Should do a search for other things that fit the pattern and somebody is willing to work on. Tom - should we revise chater to reflect that Jeff - yes should have that reflected Shawn - sounds like there are althernatives if these drafts are not adopted by this working group. Any requireemnts that they be std track? POLLS - Should we adopt this document: 3 people for the oauth document - 1 oppose saml-ec - 9 for - 0 oppose Alexey - might possibly drop some of the ones that have not yet been started as well? Shawn - might be nice to keep open because no volinteers on drafts - but some discussion has been made. Tom - interest is probably strong enough that if resources exist then move quickly. ============ Session Over