Agenda (afbfab) - Mon 30th July 2012 - Agenda Bashing and Note Well (Chairs, 5 min) - Document status * Architecture Draft (Jim Schaad, 20 min) * User Interface (Rhys Smith, 10 min) * EAP Applicability (Joe Salowey, 5 min) - Milestones and remaining document status (Chairs, 10 min) Open Mic (All, 45 min) Chair's opening remarks LE: Core GSSAP document now at Last Call WG Last Call for Use Cases Document on Friday Hannes - Status of AD comments? Interesting issue: some use-cases 'wishful thinking'; how are we doing with actual adoption/deployment? KW: Are the use-cases invalid, or just misunderstood? Hannes - e.g. 'Smart Object' use-case: would feel happier if someone were actually implementing it. Rhys Smith: A mix of real and aspirational use-cases is good, but happy to take suggestions for revision. LE: please use the Last Call to express any reservations over candidate use-cases. LE: Any comments on GSSA Naming? Again, please comment via Last Call. - Document status * Architecture Draft (Jim Schaad, 20 min) * User Interface (Rhys Smith, 10 min) EAP Applicability (Joe Salowey, 5 min) 1 - Rhys Smith - Usability UI Considerations, status update (currently at Internet Draft) Aim of this document is to articulate UI and usability issues for potential adopters of abfab (not least because these are abstract concepts not well understood by potential users), e.g. terminology, managing identities, mapping identities to services, handling the gamut of possible errors, and even success handling (because it's important to keep users appropriately informed). -> Please review the document for omissions, language, technical aspects of error conditions etc. Patrick Patterson: Should users be shown not just the identity in use, but also any claims being sent to a given service? RS: Draft doesn't describe implementation, it expresses potential issues. Ken Klingenstein: What other aspects of UI will be addressed, in addition to Identity Selection? (E.g. what about Discovery?) RS: Discovery is out of scope for abfab itself... it's assumed to be addressed by an NAI component or equivalent. Stephen Farrell: Will the final document have as many 'MUST' statements in as the draft? LE: We're intentionally aiming low for the time being, as we haven't decided what kind of doc this will be, beyond a simple problem statement. Semi-normative content could be hived off into a separate document. Lucy Lynch: Volunteering to review current draft. Section on constraints to user-accessible functions (as constrained by GSSAPI functionality) would be a useful addition. Ken Klingenstein: Would this work usefully be combined with 'adjacent' user activities - e.g. activities/contexts the user would just have undertaken? Patrick Patterson: Will also review. Jim Schaad: Will also review. LE: Recap - 3 volunteer reviewers: LL, PP, JS and maybe ANO 2 - Joe Salowey: EAP Applicability Removed non abfab-specific content from current draft in the interest of brevity and clarity. LE: Conscious decision to have a narrow scope. GSSEAP expresses a normative reference. Goal is to have a Last Call soon after IETF84. JS to re-submit as Draft [with stable name] 00 this week, within the WG (not as an individual draft). 3 - Jim Schaad: ABFAB Architecture (Draft 3) Document now successfully says: 'For each of 3 different comms sets, here are the protocols used.' (As promised...) Next draft to be expected 1st Sept., with expanded Section 2 and substantive revision of Section 3. Privacy section will also be reviewed and compared with IAB privacy paper. Help requested on a number of issues: i - how soon will IAB privacy paper be published, and if not soon, should we remove dependency on it? Hannes: IAB Privacy paper ready in terms of content, but not reviewed yet. Should be sent for IETF-wide comments within next couple of months, and suitable for dependency by year end 2012. Rhys Smith: Working on the privacy section of abfab, and agreed to review the IAB privacy paper. ii - deployment considerations (in addition to Eduroam); especially any issues experienced with infrastructure and/or application deployment. E.g. how does an IDP represent that it is available to multiple federations (does it have to have multiple URLs, servers etc)? Have existing federations addressed this, and if so how? How are attributes within SAML statements named in such a way as to retain interoperability? iii - SAML assertion profile and attribute providers Any implementation or deployment experience would be gratefully received. RS - Have some experience of SAML assertion and attribute exchange, but only as a proof of technology; have not yet addressed the trickier parts such as naming conventions etc. iv - EAP restrictions Required vs. suggested EAP attributes; channel binding practicalities; implications of tunnelled and/or non-tunnelled EAP deployments (in the absence of any standard for EAP tunnelling). Joe Salowey: Description of EAP tunnelling and related crypto is almost done and review is invited. Jim Schaad: submission of cert-based credentials to a tunnelled implementation has not been exercised/documented. Klaas W: Why do you care what tunnelled EAP method should be used? [out of, e.g. TEAP, TILS, EAP-FAST] Jim Schaad: because it imposes constraints on functions such as channel binding, and thence on GSSEAP technical trust. Klaas W: explain why channel binding is important Jim Schaad: check the large doc section on channel binding... Margaret Wasserman: Isn't it because a 'must implement' set of candidate methods is a pre-req for interoperability. Jim S: If you have *no* common EAP methods with an IDP, it's hard to open a protocol with them in the first place. Margaret Wasserman: Sam Hartman's 'this is how you implement GSS EAP' document is currently at Last Call. Sam Hartman (remotely): Agrees with Klaas - the prescription of a particular set of methods should be left until late. Klaas: as a client, you only need one shared EAP method, and that's the one between your EAP supplicant and your IDP. The IDP should transparently handle any other IDPs' methods. Sam Hartman (remotely): EAP suffers from its method standardisation status. Ondrej Sury: There will be multiple methods in play... Jim Schaad: Just want to establish principles such as: 'if your EAP method does not support mutual authentication, channel binding, etc... then these are the implications' v - Application development support: EAP suffers from a shortage of introductory documentation, and guidance on GSS-API channel binding, transport requirements etc.. The latter are adequately documented for the authentication phase (sequence, 'lockstep', re-sends, etc.), but not as well specified for normal operations - including services such as credential management. Are there design patterns that ought to be applied to these functional use-cases as well? Request for review. -> Please review and let us know any missing topics/concerns/considerations... even if it's just at the level of 'I don't understand how you get from this point to this point' LE: Call for volunteers. Responses from: Ken Klingenstein Paul Leach Jim Schaad: Any questions about the document in general? LE: There were lots of issues in the Tracker; what's the current status? Jim S: v2 cleared about 70% of open issues; about 6 open issues in the Tracker LE: Any issues you want to highlight for discussion now, while we have face to face time? If so, let us know in open mic. [pending...] ----------------------------------------------- - Milestones and remaining document status (Chairs, 10 min) Chair: Where are we with the Charter document? Well in hand (within 3 months): gss-eap eapapplicability gss-naming Coming along... architecture aaa-saml ui Needs work: aaa-diameter Hannes: (re: aaa-diameter document) Mike Jones' participation hampered by having switched companies Stephen Farrell: is Diameter really of interest? LE: current deployments only use Radius... KW: We say we do 'SAML over AAA', where AAA translates to Radius or Diameter... Hannes: Telcos are big Diameter users, so they ought to have use-cases for which Diameter is the answer... Diego: Diameter is mostly used for mobile deployments; we (telco) use both Radius and Diameter. Univ of Murcia is working on a testable deployment based on SAML + Diameter, which we hope to make available soon. Don't feel able to contribute a document, but will ask some (more Diameter-focussed) colleagues for their input. LE: Please engage any mobile industry colleagues to contribute their thoughts/effort on Diameter implementation and deployment. Jim Schaad: 2 substantive issues for further discussion, out of those still in the Tracker i - What constitutes a Federation? ii - 'Should you separate Attribute Authorities from IDPs? (Only if you're suicidal)' KK: What timeframe are these answers required in? Some of these (especially attributes from APs to IDPs for storage...) are of current interest. Jim Schaad: How can architectures cope with multiple distributed APs, and what's the trust model? Multiple APs assume some RP trust mechanisms specific to the RP-AP relationship, not the abfab-specified relationship with an IDP... (so is this in scope for abfab...?) Stephen Farrell/LE: Issue around ESCaping of / and @ characters in GSS names; needs to be handled in the same way as Kerberos can... volunteer invited. Sam Hartman (remotely): We need someone who knows ABNF... I can teach them the Kerberos bits. Rhys Smith: I will find ANO from Cardiff.