Thanks to note taker Nat Sakimura: =========== Abfab =========== MONDAY, November 5, 2012 1300-1500 Salon B, Atlanta Hilton Attendees =============== refer to the bluesheet. Agenda Bashing and Note Well (Chairs, 5 min) ============================================== No additions/changes Architecture Draft (Jim Schaad, 20 min) ========================================= Previous updates Hannes: Diego Lopez's colleague interested in the work but going needs to secure funding, Hannes will follow up Jim: Help wanted on: feedback on deployment considerations SAML assertion profile and attribute providers EAP restrictions Apps Development Questions: Leif: Implementation advice to architecture document? Sam: Architecturally appropriate to have impl. advices as long as informational but should not delay the process. Jim: LC as soon as SAML document has passed the last call. Leif: How long from LC? JIM: Three iterations at least, as SAML documentation needs iterations. EAP Applicability (Joe Salowey + Sam Hartman, 10 min) ====================================================== Scope is important. EAP in network authn and in apps authn is different. Yoshi: This issue is common to EAP. Option 1: Update EAP applicability. Option 2: Update the retrunasmittion section. Sam: Current docs fine net and apps protocols need to be differentiated. Apps -- reliable transport desired. like TLS over TCP. Focus on Apps. Joe: First focus on this particular case. Sam: Have not covered client discard case but did server side. RFC3579 allows recovery. Need working through informative text. Jim: TEAP should discuss lock step protocol over the EAP document. Sam: RFC3748 should align with RFC3579. Yoshi: Informative doc good. Sam: This document should not require what apps normative needs to do. => Yoshi is going to review the text. Leif: Three to sit down and hash them out this week? Jim: How much of what you said needs to be restated in ABFAB context in architecure document. Sam: Re-authentication - cool when ending a session is expensive. Need to discuss whether it makes sense in EAP. Joe: re-auth in many case triggered by session timout. We do not see problem in documenting -> Sam: OK. Sam: Authorization Lifetime: apps authz lifetime is app specific -> should we document? Hannes: So application dependent. Steven: It should be written in the architecture docs. Consensus call: - want to cover retransmission in the EAP? Yes: 7, No: 0, Don't care: 1, Need more info: 0 => Support for yes. - Re-authentication: Yes: 5, No: 0, Don't care: 1 => Propose text. - Authz Lifetime: Move to architecture: Yes: 12, No: 1, => move, with Sam's text. AAA SAML (Sam Hartman/Josh Howlett) ===================================== Proposed URN identifiers: seems wrong. We need to go investigate the proper way to allocate the URNs. Use of XML signatures: MAY, but not validate mandatory to implement? What does it mean? Jim: "MUST NOT" langauge is confusing. -- Architecture document should have federation agreement etc. Scott: struggling with the sentence. Profile does not have anything to say about the use of signatures. At minimum, there has to be a statement on MTI. Sam: XML Dsig is optional and need not to be implemented. It must be possible to disable the validation. Leif (as individual): Why in core document? Why not in profile document? Steven: Justification on consensus needs to be documented. Consensus on: - Signatures are optional in SAML assetions or protocol messages - Signature validation MUST be implemented (as opposed to MAY) (Steven) => yes (strong) No consensus on: - RPs must support a mode where existing signatures are not validated vs. - Radius servers implementing this specification MUST support stripping signature. ==> needs to go to list. => Josh to propose actual text. RADIUS SAML binding ================== Jim: Authn context and attribute query needs two request. No way to do it in one request. Scott: Maybe this is the time to do a profile. Jim: machine vs. person meeting a requirement. Scott: move those into attribute. If machine is a first order construct, call out two assertion on two subjects (machine, and human). Alan : Mandate use of RADIUS packet fragmentation => no objections. Jim+Scott: Naming. Need to define a way of referring to the entity we are talking about without specifically naming them. NameID. Sender Vouches. Sam: What happens if it overflows the request. Alan: Everything will break with 1K or more authn request. => Jim will provide new text. Questions Sam: mis-registered (mis-capitalized) fix ok? => yes. (Jim, Steven) Milestones and remaining document status (Chairs, 10 min) ================================================================ draft-ietf-abfab-aaa-saml-04 : A few more drafts for WGLC. abfab-arch-04: ditto. eapapplicability-01 on agenda gss-eap-09 in editor queue. gss-eap-naming-06 IESG approved, need Gen-ART review writeup. usecases-05 in editor queue, waiting on abfab-arch. diameter-abfab expired. Maybe removed. UI draft needs reviewer. Ken, Sam and Scott will review.