Hi,
with thanks to the note taker and jabber scribes
please let me know if anything is not correct.
Klaas
====
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.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
