Action Summary from session: ----- 1) Make privacy more explicit in moonshot related materials - including the charter. 2) Charter needs to specifically mention liaison with OASIS about the SAML RADIUS binding. 3) Order deliverables in the charter in a more logical fashion. 4) Charter needs use-cases and architectures as deliverables. 5) In the charter, change "within the GSS-API" to "within the application" on the 4th deliverable for broader applicability. ========= Minutes of fedauth BoF meeting, IETF 78 - 27/07/2010 1) Intro ----- * Welcome from Sam and Leif. * Thanks to Rhys and Jeff for scribing and jabbering. * Shawn Turner, as sponsoring AD, said a few words 2) A description of the use cases - Klaas Wierenga and Josh Howlett ----- * Klaas presented an overview of federated identity, federated network access, and his hybrid non-web fed auth proposal (using web SSO in a non-web context). * Josh presented on R&E federations encountering growing pains, and four particular use cases for fed auto (outsourcing, HPC, learning from Web SSO issues, trust in SAML metadata) * Q from Aaoron Falk - How ephemeral are identities issued in the R&E context? -> Josh - depends on the institution. Increasingly we are seeing alumni accounts. 3) Moonshot problem statement - Hannes Tschofenig ----- * Leif and Sam switched items in agenda - Hannes first, Shawn next, rather than the other way around. * Hannes presented on taking three party authentication from theory to practice, need for building on existing AAA infrastructure with minimum changes to help deployment. 4) Related work - Shawn Emery ----- * Shawn presented on Kitten rechartering, SASL-openid, SASL-SAML, and what is next on their todo lists. * Sam posed the question - Other related work is ongoing but already has a home in other WGs. Is there a conflict? -> No responses. 5) Discussion on use cases, problem, related work ---- * Q from Sampo ?: Has there been any attempt to use SAML proxy authentication to solve the problem of users with multiple accounts? -> Scott Cantor (on jabber via Joe Hildebrand): privacy makes using that as a solution to that problem is impractical -> Sam Hartman: Privacy *and* trust makes that impractical (e.g. user might not want to bind their identities in the different contexts) -> Josh Howlett: It might be technically possible but not reasonable to deploy. * Q from Glen Zonn: SSO has been solved in many forms. The work presented so far sounds like "a cool project", but is it right for the IETF? -> Leif Johansson: The work presented has talked about federated authentication, not SSO. -> Elliot Lear: Restating Glen's question - What are the elements to standardise that aren't already, and what are the design principles? -> Sam Hartman: We want a solution using existing infrastructure for enabling federated authentication in an app with broader scope than the web * Q from Yuri Dechenco: The statement of the problem is not clear and missing an area of work around architecture (e.g. no explanation of session management). Is the work targeted at access control authentication or authorisation? -> Leif Johansson: Tech question, ask later. * Q from Lionel Morand - Existing solutions already exist in e.g. 3GPP, liberty. -> Hannes: We're not talking about HTTP applications. What specific solutions solutions are there that fulfil that? (i.e. liberty is HTTP based) -> Lionel: There are other tech that AAA (e.g. GBA??? (similar to kerb)). -> Sampo: Liberty is still alive (org is dead, specs are alive). ID-FF has an authentication service that might be useful. * Q from Ronny Bjones:- Use cases are currently very enterprise specific, not focussed enough on users and user privacy -> Josh: Privacy is very important, it hasn't been mentioned because it has been seen as self-evident, not because it's not important. That needs rectifying. ===== ACTION: Make privacy more explicit in moonshot related materials - including charter. ===== * Leif - Hum "Do you understand the problem" - thumbs up from AD - Hum "Is it useful to work on this in the IETF" - thumbs up from AD 6) The Moonshot proposal - Josh Howlett ----- * Josh presented on Moonshot * Q during talk from Glenn Zonn: If the IETF decided this wasn't worth doing, what would you do? Are you really technology neutral - If the WG decided the moonshot solution wasn't doable, would you be happy to change to a different solution? -> Leif: The proposed WG is separate from the moonshot mailing lists, the WG would not be tied to a particular proposal. * Q during talk from Igor ? - Why do you call it non-web SSO, would it also work with web SSO? -> Josh: yes it would -> Sam: it would work but because of vary aspects of it you wouldn't want to use it as a competitor to e.g. oauth or opened 7) Technical discussion ----- * Q from Joe Hildenbrand: In terms of deployability in the enterprise environment - it is less likely you'll be able to get to the EAP server. -> Sam: The client never talks to infrastructure, that's how RADIUS works * Q from Yuri: Does moonshot do AuthN or AuthZ? AAA doesn't do AuthZ. -> Hannes: Disbelief that AAA doesn't do AuthZ -> Yuri: Restated the question - A number of issues re authz are missing in AAA documentations such as session management, credential management policy, etc -> Sam: SAML has a broader Authz infrastructure than AAA, which has a simpler but not as comprehensive authorisation model. Moonshot will work with both. * Q from Joe Salaway? (Cisco): Has looked as EAP in GSS previous, came to the conclusion that naming was one of the hardest issues. How much does moonshot rely on this problem begin solved? -> Sam: Moonshot relies on EAP channel binding. Naming is a hard but tractable problem. -> Leif: There has been some implementation experience recently around GSS naming * Q from Glenn: GSS is very flexible. Is GSS-API in the picture simply because we have apps that use GSS or is there another reason? -> Sam: Yes, main reason is to enable access to apps that already use GSS. -> Josh: Though moonshot might not want to be tied to GSS -> Glenn: Could do EAP over PANA? * Q from Paul Hoffman - Use cases are pretty broad, and a solution is already being presented - is this limiting the use cases, and does that limit the solution? -> Leif: Moonshot is just a proposed solution to the outlined use cases. -> Paul & Sam: Discussion of this. -> Paul: for example e.g. users couldn't know their NAI -> Leif: this kind of info could be provisioned -> Sam: feasibility document says moonshot wouldn't work well without pre-provisioning. -> Paul: that's an important use-case limitation. That needs emphasising. -> Paul: so everything will be provisioned, including credentials? -> Sam: no, we need to work with an organisation's existing infrastructure. The organisation can use whatever credentials the org has. Federation decouples the authentication between user and IdP, and IdP and RP. * Q from Subir Das: Today every network wants to do 802.1x stuff for network Authentication - would an organisation have to do EAP twice if they then want use moonshot? The first time you connect to the network you authenticate, then for GSS you would authenticate again? -> Josh: yes, would AuthN twice. The MSK would be different. * Q from Sampo ?: Is there only a single SAML assertion in a single RADIUS attribute? Could it be too large? (i.e. limited RADIUS over UDP MTU size) -> Josh: No, SAML assns are only usually large because they are signed, and they don't need to be. -> Sampo: But there would be a size limit? -> Elliot Lear: FYI, There is a draft for RADIUS over TCP that would allow larger RADIUS messages. -> Sam: RADSEC/RADIUS over TCP would give higher MTU / or you could compress the assertion / or you could use a small SAML assertion * Q from David Burk: Need to know more about moonshot's use of SAML - what level of changes will be required for those using RADIUS and SAML infrastructure already? Is the SAML generated going to be consumable by all parties? -> Leif: Implementation issue, not a problem. -> Sam: No required changes in the IdP or SP, apart from when binding RADIUS and SAML infrastructure. -> Sam: SAML will be normal SAML according to SAML profiles so generally consumable * Q from ? - Could do EAP over dedicated protocol instead of over AAA. Have you considered that? -> Josh: inventing out of band approach - advantage of moonshot is this is in-band. -> ?: what about apps that don't use GSS? -> Josh: we assume GSS or SASL -> Sam: there's work involved in integrating an app either way. * Q from Subir (following up previous question): Would be nice to combine with network authentication step. IETF should look at that - as it would represent a more generic case. -> Sam: Important to separate network auth step to app auth step as they have different security contexts. For performance an EAP method that derived an MSK from previous key material would be the way to do this - hard but could do. Using the same key for both steps would violate various RFCs. * Q from Sampo: Metadata distribution problem was a use-case, but it hasn't been addressed any further in this session. -> Leif: very small community interested in that, so it is out of scope for the BoF since it would consume valuable time. * Leif - Hum for "Can we proceed with charter discussion"? - Thumbs up from AD Charter overview - Sam Hartman ----- * Sam: proposing to start working from moonshot but not necessarily end with moonshot * Sam: WG is not chartered to change RADIUS/DIAMETER - it can help tidy up certain aspects of keying, etc, but not change core protocols. * Sam: note that we have some comments from Elliot that haven't been addressed in the current draft of the charter: -> making sure usability elements are described -> we expect v2 may rewrite v1 based on usability experience Charter discussion ----- * Q from Glenn Zonn: Clarification sought - we are not chartering the WG to rubber-stamp moonshot, but we're going to start with it and we can't change it? -> Leif: Is there a counter proposal? -> Glenn: There are existing standardised proposals to use, e.g. PANA -> Sam: none are standardised. Work in making apps use PANA is more work than moonshot, and in-band key management is desirable. -> Glenn: Followup - RADIUS keeps being mentioned. Is this tied to RADIUS only? -> Sam: This protocol should be deployable over DIAMETER as well. * Q from Glenn Zonn: sounds like a "cool project" to work on but doesn't seem generally useful. -> Discussion in the room. * Q from David Black: where does the SAML work happen? The existing RADIUS-SAML draft is very light on detail, and the charter mentions OASIS but doesn't specify what is needed. -> Sam - agrees draft-howlett-radius-saml-attr-00 needs more detail and more detail on interaction with OASIS should be in the charter ===== ACTION: Charter needs to specifically mention liaison with OASIS about the SAML RADIUS binding. ===== * Q from Yuri: The deliverables mentioned in the charter aren't ordered logically, and the charter needs more detail on use-cases and architectures as deliverables of the WG. Yuri would be happy to help work on those. ===== ACTION: Order deliverables on charter in a logical fashion. ===== ===== ACTION: Needs use-cases and architectures as deliverables (Note: Yuri would be happy to help work on those). ===== * Q from Alpri: - Other solutions than moonshot aren't allowed in the WG? -> Leif: Other properly thought out proposals should go into the WG. -> Alpri: The WG should start with use-cases, not solutions. * Q from Dave Crocker: The IETF is about looking for issues with a solution, not raising issues with a technology because the individual does not like it. The charter needs to be clear about what choices/assumptions have already been made and which are flexible. The relative rigidity and flexibility of assumptions could be better expressed within the charter - but the existing charter a good starting point. -> Discussion in room * Q from Elliot Lear: The proponents have done a good job at delivering a bunch of work as a good starting point. This represents a good opportunity for leveraging the R&E community to get the output of the WG into real world use. The IESG looks at the importance of problem - and this is important. * Q from Gaetan Fege: The parts of charter between IETF and OASIS are crucial. -> Sam: Shawn and OASIS have talked, don't anticipate problems with this area. * Q from Subir: What flexibility would the charter allow for not using GSS-API? Change "within the GSS-API" to "within the application" - 4th deliverable. ===== ACTION: Change "within the GSS-API" to "within the application" - 4th deliverable. ===== * Leif: Hum for "ok with with charter module agreed changes" - thumbs up from AD * Sam: Requested hands up for volunteers in working on drafts and reading and reviewing. Sufficient number of hands raised. * Meeting ended.