ABFAB Minutes IETF 82 note taker: Jim Schaad jabber scribe: Josh Howlett, Joe Salowey * Agenda * EAP Applicibility statement Leif: - is the content close to last call ? Stefan Winter - some people violenty disagree. Have covered what was targed. So happy w/ content Joe Salowey - NEA text is still missing to some degree. Leif: - emu working group disucssion w/ different options on hosting - in our chater - Stephen - what should we do? Stefan - chainging something fundamental in EAP Stephen Farrell- What dependencies? Sam Hartman - normative dependancy on the core spec Leif - why normative? Sam - core should not be published before this - it is currently not legal to use EAP this way. States what needs to be done to use EAP beyond net access. Core wants to say how these requirements are met. Klaas - why do you care about how much we need it? Stephen - could be contentious in other working groups - could drag on. Sean Turner - if you cross call last call then I don't have a problem. Sean - does it need to be done at all? Sam -yes Eliot Lear - app doc has been used to say don't do that in the past. How to we phase this. Sam - as an AD said that you cannot use EAP w/o updating the app statement. Stephen - have a chat and see what it should be done. Leif - Joe did hum in emu - some consus that they wanted to own the document. Steve/Joe should we ask or say if EMU wants to own then let it Joe - No more natural of a home in EMU - targeted to methods - abfab has bigger need - needs to be large review but no stake in where it gets done. Leif - dissucss with ADs and then go forward. Joe - would be useful if more things were going to happen - more guidence for future things makes sense. ACTION - chairs and ADs meet to make a decision. * GSS-EAP Straw Poll - is the internationalization method as given good - sense of room was yes RFC 3961/4121 - plan is to move to the 3961 back - ask for objections on the list Leif - Sam - please push thread to resolutions and gauge consensus then the chair will concensus call * GSS-Naming * AAA-SAML Leif - possible to profile to add the feature? Josh - ok to do later Issue - the name of the file contains AAA but only does radius - is that an issue? Stephen - not an issue Issue - Signatures on the SAML message Eliot - Under what circumstances would a signature be sent where it would have to be ignored? Josh - RP could chose to rely on the transport Sam - Have signature w/ legacy IdP - NAS does not have trust anchors to validate signature - already have RADIUS to provide integrity. - don't want to reject assertion that is signed because it cannot be validated, but would have accepted if unisgned Leif - counter argument on profile - can always write a new profile that required signatures Eliot - Should say both MUST NOT check and SHOULD NOT send for consistency in the past. Sam - better than MUST NOT send Leif - Easy to strip signatures if needed - really easy to do. Leif - in SAML space - common to separate implementation profile, deployment profile - Implement must supply or deployment must turn on. - need to call this out Josh - deployment profile Sam - don't think deployment profile should be a std track document - need a implementation profile - deployment profile in BCP or arch document. Josh - XML digsig needs restrictions to get interop. Sam - IETF constrain implementations not deployments. Leif - +1 what sam says Stephen - can be one or many hops? - MANY hops Sam - no - hops are integrity protected Hannes - difference between specified and deployed Sam - trusted third party proxy security gets deployed. Payload size Eliot - average size of a SAML transaction? Josh - currently not really known Diego Lopez - compression of assertion? Josh - One binding allows for Leif - 3.5 k for one sample - signed - real issue Jim - Option 1- need to at least error - #2 go to diameter Eliot - sub options #2 - go to diameter Leif - actual attributes were only one K Hannes - using diameter should be ok - good implementations exist. - avoid option #3 - routs around why we did abfab to begin with - fragmentation layer - looks like a real hack - would prefer TCP/TLS version of radius Sam - two implementations of NCP over radius have 4k limit even on TCP - radius spec is hard coded Diego - option 2 is wisest - but in a federations somebody will break it. - proxies or deployment of radius Hannes - how much can you actually change? - depends on the specific deployment. Bigger radius deployments are start radius and then go to private version - may not always be an issue. Diego - moment single assertion grows to large means all deployments need to change Hannes - how far should we bend to deal with existing deployments Klaas - option 3 - should be considered - not talking about applications but radius server talking to IDP - not same set of problems as what abfab Hannes - work w/ existing AAA structure - both right - Eliot - Lots of homework - size - environment being measured - network auth vs other uses - some is prognosticating - for an architecture should assume grossly expensive Leif - will see wide span of number and type of attributes - hard to predict a small size assume can get really big ELiot - agree option #1 is not an option. - option #4 seems like more work than revisiting diameter draft Jim - Humongous SAML statements Hannes - what does option #4 look like Josh - have possible to do resolution by reference to identifier - have mime type and chuck. Sam - think sever only access request Leif - Can combine different options such as 2 and 3. Define a RESTful SAML binding - (already done) Think Diego has a point - any deployment will be unpredictable Stepen - If option #4 means generic then needs to go out of this group. Sam - if not on there - then add radius based mech for doing only SAML assertions generic fragmentation would be painful - would need RADEXT review Jeff Hutzelman - can RPs do the artifact resolving over an arbitrary large federation? Leif - no - but all solutions add new requirements. Leif - Present updated set of options and have round 2 discussion on the mailing list * abfab arch & Uses Cases Tracker discussion and etiquette * use cases JIM - find the Plasma use cases - somebody agreed to do that Consensus call - should the OID document be a working group document - Much yes - zero no - one no idea * Multihop Federations & Trust Router Leif - we have a charter item that covers the problem statement. Not clear that this the only way to skin the cat. Leif - would be willing to review - might give alternative solutions as well. Problem is broader than just ABFAB. Current trust router draft narrows down to a specific model (hub and spoke) very quickly. Good approach to start by having a discussion around the problems if it were really general. Klaas - Many related options exist (routing prototcols, group management protocols etc), not clear what unique problem is solved. Margaret - current statement is a motivation for the work not a general problem statement. Poll - Who is interested in working on the problem statement draft Yes - Leif, Diego, Hannes, Josh, Karen, Jim, Tom Yu No - no hands * Current technical Issues - 3GPP Issues - no discussion in this meeting - continue on the list - Report No consensus for adoption of draft-jones-diameter - no response. Intend to re-issue.