abfab WG meeting IETF 83 - Paris, France March 29, 2012 ------------------------ Note Well presented Slides are here: https://datatracker.ietf.org/meeting/83/materials.html (search for "abfab" under Security Area). --- WG Draft status --- - AAA-SAML (Josh Howlett) -03 version has minor changes since -02, including removal of constraints on use of SAML signatures. -04 will have more changes from list discussion, plus a start on the Assertion Request Profile (in addition to Authentication Profile that's in current version). Discussion: RADIUS fragmentation support needs to be mandatory to implement for clients (acceptors) and servers (longer discussion about servers, but "MUST" for both is rough consensus of hum in meeting with minor dissent). Have to mandate one way to do it - will be based on draft-perez- radext-radius-fragmentation. The "MUST" for both conclusion will taken to list for confirmation. Discussion: Need to be able to bind assertions in RADIUS attributes to authenticator (client needs to be able to rely on the assertions coming from the same entity that verified the authentication). This affects GSSAPI naming. Discussion: New Assertion Request Profile will be in same draft, not a new draft. - GSS-EAP (Sam Hartman) Significant changes since last IETF to close open issues. Identity flow has not been changed, but MIC token format has. Lots of other changes and cleanups - many thanks to reviewers who commented. Major remaining open issue: IANA RADIUS registrations not done. Other minor changes still needed - WG Last Call soon. - GSS-EAP Naming (Sam Hartman) A number of updates have been made in response to comments. For plasma WG usage, will plan to work on additional documentthat meets those needs, don't want to hold up this draft to add support for plasma use cases. Hence, this document only applies after successful RADIUS authentication (hum confirms this, no dissent, will be confirmed on list). Character encoding will be specified in this draft - it'll just be UTF-8. Long discussion of UTF-8 comparison - result summary is that hostname comparison will be done per idna2008, and all other comparisons are binary match of machine-generated UTF-8, hence not problematic. Pete Resnick (i18n expert) is involved and will review Sam's text. - Use Cases (Rhys Smith) Minor updates, PLASMA use case will be provided soon request for more use cases. There's a placeholder for a SIP use case, but it's not clear whether there is one. Sam Hartman and Margaret Wasserman have written a whitepaper on possible use of abfab in consumer technologies that may be a source of useful SIP text. Extended cloud use case (virtualized infrastructure) will be added - Yuri Demchecko will write a paragraph or two and send to Rhys ASAP for inclusion in draft (ASAP means days ...). All additional usecase text need to go to Rhys soon (very soon). New version of draft will appear by end of April and should be headed to WG Last Call. - OID Registry (Rhys Smith) Have two oids issued. This draft is currently an individual submission. Taipei meeting agreed to make this a WG document - but discussion concluded that GSS-EAP draft will just pick up these OIDs now that the legwork's been done to obtain them. - UI Considerations (Rhys Smith) Also an individual submission, has expired due to lack of comments. Author needs to resubmit as individual submission w/at most minor changes and ask for review on list. - EAP Applicability Statement Have authors working on a draft. Will split off abfab applicability of EAP into a separate draft that can make progress faster. May be done by paring down current draft - will be an abfab WG draft. - Architecture draft (Jim Schaad) Primary author (Hannes Tschofenig) is not here. Minor updates have been made, but the interesting significant issues remain to be resolved. Jim Schaad intends to become a co-author of this draft - needs to talk to the current co-authors first. --- RADIUS Fragmentation (draft-perez-radext-radius-fragmentation) --- See above - the mechanism in this draft will be mandatory to implement for abfab. RADIUS problems occur when packet size exceeds 4KB. abfab can cause this. Use a new attribute (More-Data-Pending) to tag each fragment as a fragment, fragments sent in order, but not independently numbered. Doesn't work for Access-Accept because new attribute can't be included - see slides for how this is dealt with (can't put new attribute in first fragment, but it does appear in intermediate fragments). Proxies cause complications (surprise ;-). Sizing chunks to be less than 4k max enables a proxy to insert its own attributes w/o refragmenting. This will be a SHOULD, and works with legacy proxies that *only* add attributes. A Proxy that modifies attributes (as opposed to just adding its own) has to be upgraded to add support for this draft, because it has to look at all the chunks to find the attributes that it needs. Q: Do proxies need to modify SAML assertions issued by an Identify Provider? Summary: YES! (emphatically) Details ... A (Josh Howlett): Attribute translation across domains. Discussion: This requires stripping original SAML signature, but proxy may resign with its identity. AAA framework has to be used to establish trust in the proxy's identity in addition to the original IdP's identity. Would prefer to only do this sort of rewrite at endpoints, butreal world doesn't actually work that way :-(. A (Leif Johannsen): Lots of real world deployments rewrite assertions on the fly to hide identities and the like. A (Jim Schaad): Proxy at federation boundary limits the need to understand cross-domain mapping between domains to the proxy - don't have to tell all the endpoints about how to do the mapping. Alternative: Proxy could translate SAML to RADIUS assertions if that's going to work better (or v.v.). Reiteration: Proxy that does a rewrite generally needs to colled the entire RADIUS message to do the rewrite - it can't usually proceed chunk by chunk. A (Rhys Smith): Government application - hub sits between IdP and RP, checks IdP signature, adds additional attributes and resigns as hub - RP trusts hub and hence is satisfied with that signature (does not need original IdP signature). Discussion: Proxy credentials and restricted delegation are complex - Sam Hartman would prefer to steer clear of specifying policy mechanisms in favor of advice to consider policy implications of deploying abfab. This WG is not a good place to work on policy. ... end of details. Sam H: The radext WG is in the process of rechartering. Please look @ new radext WG charter, and make sure document is in scope. If not, someone needs to propose new text for radext charter to make sure that radext can (and probably will) pick this up. Sam DeKok will take this issue to radext and try to ensure that new radext charter has text that supports radext working on this draft. Draft author: No IPR disclosure expected, don't believe that source of funding constrains usage of this draft. --- Trust Router Problem Statement (Josh Howlett) --- This (trust router protocol) is a candidate for new work for the abfab WG. From Taipei abfab meeting discussion: Need a clear problem statement first. This problem statement draft is an individual draft that is intended to fill that need before work could commence on an actual protocol. Proposes a new trust establishment mechansim that is complementary to shared secret and certificate-based trust establishment mechanisms. Motivation is that these existing trust establishment mechanisms make abfab deployment harder, and new mechanism will help (abfab still useful/usable without this addition). Problems w/existing trust establishment mechanisms: * Cost (e.g., purchase certs, set up/manage CA, config churn [esp. w/shared secrets]) Underlying problem is that any centralized trust infrastructure causes problems. Don't want to force adoption of specific credential type for abfab. (Leif Johanssen as individual): Want some sort of federated trust infrastructure that isn't based on cross-CA trust, but may use public key credentials. (Sam Hartman): Want to be able to use different types of credentials in same trust infrastructure (so not everyone needs public key + certificate). (Yuri Demchenko): Trust router should apply to virtualized cloud infrastructure. Need dynamically established trust infrastructure (probably requires dynamic credential provisioning). Yuri will read draft and suggest text if needed. (Alan DeKok and Sam Hartman): Bootstrapping needs attention. * Scaling - up (larger scale does not impose significant additional costs on participants), down (works for small communities) and sideways (community sizes change over time) See slides for Terminology and Roles. Goal is separation of technical trust (identity verification is a minimum requirement) and behavioral trust (usage of identity in other contexts, where abuse may be deterred by community norms and/or legal/regulatory countermeasures as opposed to be prevented by protocol means). See diagram example in slides - behavioral intermediary establishes reasons for RP to rely on identity credential from IdP. Different intermediaries may be able to establish different strengths of reasons to rely on same credential from IdP. See goals slide. Long discussion of what the short summary of the problem is and what the scope of the new work should be. Sam Hartman has strong opinions that this includes credential agility and some sort of ability to find introducers. Discussion turns to process of getting to WG agreement that this is an interesting problem that the WG wants to work on. Stephen Farrell (AD) - Step 0: Do the existing work first. - Draft is more of an architecture, need a problem statement. - Next step is to get a problem statement and determine WG interest in it. Claus (WG chair): Need to state what's broken and why it isn't solved by current work doesn't solve it. Further discussion reinforces that a concise problem statement is missing and needed. Leif (WG chair) and Stephen (AD): Must be in WG Last Call on core abfab documents in order to devote any meeting time to this topic at next abfab meeting @ IETF in Vancouver.