ABFAB WG Meeting - 2014-03-07-11-50 Scribe: Adam Bishop Jabber Attendance: Jim Schad Steve Olshansky Alejandro Perez Mendez metricamerica oej semery draft-ietf-aaa-saml (Rhys Smith) ================================ Josh Howlett has sent in an update - most issues have been worked through, -09 update recently, mostly fixing typos. Proposal for SAML naming of AAA entities to be submitted by josh soon... Alejandro has noted that we can make use of the state of a state attribute in the fragmentation draft - however, during RADEXT it was decided that this is not required as the fragmentation drft is experimental. Sam Hartman: Is this point that he expects abfab to have the same issue as fragmentation? Unknown - discussion to be started on the list. Jim: This is still an issue with this draft (large packet fragmentation). If the first packet is just a SAML request, we have the same issue. Propose to state that SAML is an authentication attribute, then no problem. Decision - take discussion to the list. Jim: I am unsure that I ike the way that we are naming subjects. It is a weird way to use the subject confimation method to ask about attributes from somebody. Linus to review aaa-saml draft. Jim has review notes pending. usability-ui (Rhys Smith) ========================= Updates from feedback, up to -04. Mostly complete, aside from errors seen by user. Some comments still unhandled, will follow up on list. Scott Cantor has suggested broadening the scope beyond abfab - document has broad applicability to GSS-API Sam: Recommendation to take comments, but not increase scope of the document - this document is for abfab, but if scott has additional content that is useful, add it. Success criteria is "is this useful for abfab", but if we can add additional content, great. Jim: Get it done - let's not waste time on making it really general. David Chadwick: Two issues: scope within or scope outside of abfab. Leif: Should this be a charter discussion? Steven: If the group want to have a charter ddiscussion, thats ok, but don't just broaden the scope outside of abfab. More work to do, but good progress being made. Mark donnelly to assist with errors section - suubstantial chunk of work to do there. Sam: propose error that are possible - if things can be done with the current GSS-API, then great, otherwise if there are good ideas they can be taken to kitten, but we should avoid includig things that are impossible in GSS-API. abfab-ephem-keying (Linus Nordberg) =================================== Between the client and RP, we don't have as much protection as we would like. An observer can see the NAI, acceptor name, MSK, x509 certs... The suggested solution is to extend RFC7055 to require the initiator and acceptor to use DH to derive a symmetric key. -01 now up to -04, fixing a few small but important changes. Open questions: Should we bother? The draft doesn't actually contain enough to create an implementation Implied costs? (of all kinds) Bid down attacks (downgrade)? (in or out of scope) Optional or mandatory?) Daniel Gilmore - clarification on bid down, session resumption may not be used in future due to other security issues. Renegociation too. Sam: TEAP depends on session resumption for performance. Klass: how applicable to GSS beyond abfab? Sam: EMU KITTEN ABFAB contacted, no one disagreed when asked if this should be abfab specific. This is an EAP lower layer issue. Adam: As far as Moonshot is concerned, the information that is leaked is undesirable - we would be interested in implementing this if drafted. Sam: Don't know what best practice is for doing DH - need support for draft from a crypto person. Jim: Are you willing to do ECDH or just traditional DH? Sam: Undecided. Steven: Cookbook being worked on for oppotunistic keying - not ready yet though, would provide some guidance. Rechartering and Future Direction ================================= Core documents should be done soon, DH is not on our charter but would likely not be strongly objected to if added to the charter. UI and AAA-saml done by Toronto? Could hibernate the group while discussing ephemeral keying. May be no meeting in Toronto, unless there is enough interest. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238