[radext] RADEXT: IETF87 meeting notes

["Sanchez, Mauricio" <[e-mail]>]

Meeting notes have been uploaded to IETF site. Also pasted below for your
review.  Any corrections/additions welcome.  Thanks go out to Nancy for
taking notes. 

-Jouni and Mauricio
---------------


RADEXT
IETF 87
Berlin, Germany

Tuesday, July 30, 2013
Meeting started 5:01PM and adjourned 6:31PM

Chairs:

Jouni Korhonen <jouni.korhonen at renesasmobile.com>

Mauricio Sanchez <mauricio.sanchez at hp.com>



AD:

Benoit Claise <bclaise at cisco.com>

1.Preliminaries

Nancy Cam-Winget volunteered to take notes.

Mauricio reviews Note Well and agenda; no comments/feedback to agenda

Radext status:

- RFC6911 now published
- RFC6929 now published
- Nothing in editor's queue or WLC
- Review of current work in progress to be discussed today (e.g. attributes
draft has a couple comments that is targeted to address today, DTLS no new
version but should be ready for WLC that could start this week, NAI-based
discovery does have new version and 1 open issue, fragmentation charter
discussion, Radius extended request based on deacon- draft, new work around
data types and request go address key management)
- Discussion of goals/milestones shows WG is behind by almost a year: focus
needs to close these items before adding any new items and/or closing group

****************************************************************************
*****
2.DTLS (Alan deKok)

Main diff between last IETF include:

- removal of port overloading based on Joe's comments of TLS changing coming
and presumptions may no longer apply
- need to issue new draft now that freeze is over
- no open issues remaining
- Mauricio states that next step is WLC after IETF 87

****************************************************************************
*****
3.NAI (4282 bis...Alan deKok)

- new version -04 coming to address Bernard's comment
- Sticking points:
o Normalization done at edge or core?  No one does this right now at edge,
do we want to force lots of devices vs. less at the core.  Question is
whether Unicode string can be normalized without doing anything; while it
may be feasible, there may be resistant to change though there may be some
places where it is infeasible.  Can suggest proxies can normalize, but there
are cases in which they can not (if that's the case then use it as an opaque
blob)
o Feedback from il8n has been very little (they say "maybe")
- Mauricio asks if it'd be useful to put it as a request from il8n to get
more responses e.g. put more weight behind this?  Alan believes "yes" would
be good. It'd be useful to have this documented and agree on a standard, so
officially asking for a proper response would be helpful.  Mauricio and
Jouni will work with Alan to elicit better response.
- Stefan: situation of # devices at the edge is not as grim as thought.
Most deployments would use ascii realm; this would be more for the future so
just need to make sure new supplicants can support this.  The deployed base
should not prevent this from moving forward
- Alan: People don't use internationalized domain names; if they are, likely
doing it wrong.  They take blob and take it to the AAA server and server
needs to figure it out....which means upgrades are needed.
- Bernard: its really about realm not user name.  Needs to compare realm to
realm table...basically a domainname and domainname comparison; so if you're
able to lookup domainname, it's the same process.  So not sure the problem
is that complex
- Alan: may not doing DNS lookup so you'd have to do domainname comparison
themselves; can work with Benoit to get answer from idna (?) people....as
they claim use of different formats and hope for the best in interpretation
- Stefan: nobody does this because specs is a mess, so Eduroam recognized
this and stated not to use it for domainnames.  But don't see that this is a
big issue, as soon as use internationalized doaminnames these have to be
clarified.
- Mauricio closes that follow thru is needed with the group.
- Bernard: if someone converts, need to determine if it is in il8n form or
not
- Jim Schaad: believes that is the case
- Alan: worries using Unicode version of realname which may be a bad thing
to do

****************************************************************************
*****
4.Dynamic Discovery (Stefan Winter)

- -07 now to integrate Jim Schaad comments hopefully resolving all of them
- Issue based on Trac #168
- Discovery process via NAPTR->SRV do you have to follow all paths?  Spec
says you don't have to if highest priority is discovered target else have to
follow dns flow...needs discussion
- Security considerations per Alan's comments as there's a potential DoS and
2nd comment based on misconfigurations regarding negative connection
attempts usurping compute power based on excessive retries.  Have updated
the text to keep memory for a configured time length
- Still need to resolve MTI mechanism for server authZ:
o   Need cert property to express authoritative server for the NAI realm as
using subjectaltname:dnsname is sloppy
o   Doesn't need to be in the same domain as the dns: suggest use UTF8.
o   Based on posh BoF, Radius is not the only one having this problem...not
sure if posh can provide anything for this
- Diego Lopez: why look at subjectAltName:nairealm as it may be more sloppy
than using CommonName
- Stefan: can put realmname in certificate and could buy argument for
including it
- Diego: could be dirty but quick
- Jim: only thing needed in pkix to assign this field...should have no
blocking gateway for including this
- Stefan: other issue is to get OID assigned.  If there's a way to address
this, would be good to have a wildcard match (equivalent of accounting
departments...but not sure it makes sense)
- Joe: agrees that we should not do that as the radius accounting already
define how to do the matching
- Stefan: not sure the reasons apply, though we should continue to use the
wildcard
- Joe: this is a little different
- Stefan: ok, will change to have wildcards on leftmost label then
- Stefan discusses privacy implications per Jim's comments...nothing to be
learned by the dns lookups being performed so not sure updates are needed.
- Jim: getting more exact info of where user's going to (depending on
whether there's a single server acting as a gateway)....learning where a
particular server is going to vs. having traffic from radius client to a
single radius proxy, now going to a particular radius proxy.  Disclosing
info on which domains are being traversed.
- Stefan: question is who gets to know more or less....proxies would learn
more
- Jim: it's a question of who the trusted identities are
- Stefan: so yes, anyone can observe the traffic, but believes its
reasonable tradeoff
- Jim: that's fine as long as tradeoff is documented
- Stefan: naptr->srv->a/aaaa maintains more state which may be more complex
but should be acceptable.  But problem is based on misconfiguration: if you
should know realm is different than what's on your table, if find it thru
the discovery, what to do?  That could be bad....if full result is provided
then it can help....can do loop detection to address this as discovery can
onlyl capture loops introduced due to discovery.  As you don't want to spend
that much time on discovery especially if accuracy is not required....agrees
there's sense to that argument; but no draft/text to do this due to lack of
interest....so do we address this as a separate I-D.
-  Could add a loop detection attribute, but it could be a couple 100's
iterations before converging.  If looking at recent alignment based on 4K
radius boundaries, then limiting rate could help, but more work is needed
-  Mauricio checks consensus:
o   After completing our WG items, how many want to address loop detection:
mostly consensus to address this
- Stefan mentions there could be  a draft ready before next IETF

****************************************************************************
*****
5.IEEE 802 attributes (Bernard Aboba)

- Bernard asks if any IEEE on meetecho (Jim says Yes, Mick Seaman is on...)
- Issues to discuss:
o   WLAN SSID: suggest to remove it as its redundant to Called-station-ID
o   Stefan: not catastrophe to remove it, but to address this the fix may
not be as clean.  Same thing may apply for the MPPE keys
o   Bernard: if you send this and not the other stuff, you'll break current
implementations.  This is an interoperability problem....this is same info
as the called-station-ID attribute (namely SSID)
o   Sam: what's status of this document?  Would be comfortable if copied
text from called station ID into this document
o   Bernard: OK
o   Issue with Access-info:  this TLV is included in EAPoL announcement and
MACSec PDUs...what messages could this go in and what does the NAS do with
this?  Worked thru with Joe and Brian on the model.  Determined that 0 or 1
Access-Info attribute can be present in all RADIUS messages.  In the
Access-Request it reflects what the use has sent in the Eapol announcement
(could be in MACSec PDU or MKA PDU).
o   Sam: clarify, I'm sending CoA and ask to announce this to the world?
o   Bernard: if sent with a NID name, its unicast addr and doesn't apply to
a port, case where it's a disconnect request
o   Sam: not necessarily part of the session
o   Bernard: but you'd be online and want to CoA
o   Joe: you would be part of it
o   Sam: but the CoA server could lie
o   Bernard: all CoA has to be linked to a session
o   Sam: trusting AAA server to get linking right
o   Bernard: you have to be specific enough to figure out the destination
o   Sam: why can't the NAS figure the dest
o   Bernard: it can.  There's a 'specific' and 'generic' as several can be
on a generic port
o   Sam: process problem.  CoA is experimental and this normative text
depends on CoA...don't understand how this is useful in standards track
normative text
o   Bernard: still applies to Access Accept/Reject/Challenge
o   Sam: believe CoA description requires a normative down rev
o   Bernard: we have dozens of documents that mention CoA
o   Sam: may be but it's a process problem...would like to open an issue
that describing CoA usage in standards doc requires down rev to the spec
o   Bernard: ok, but first need to understand how it works.  Back to
description: believes it goes in all radius messages...in Accounting Request
reflects and EAPol announcement sent from NAS to user
o   An Eapol-announcement can be for a specific nid or not...need to
determine type...if NID is not included then maps to the port...what other
TLVs would be relevant?  Brian mentioned MACsec cipher suites, key
management tlv and organization or more?
o   Brian Weiss: will need more than one
o   Bernard: can make it match the 802...so take TLV info string and copy it
to Radius.  Issue may be whether it fits in a radius packet (vs. breaking
each into a separate TLV)...more announcement TLVs may be needed, like
organizational specific set or individual TLVs?
o   Mauricio: if it's a question to the group...
o   Brian: can't remember diff between set or single organizational tlv
o   Bernard: but question of do we look at others or do arbitrary
assignments?
o   Mauricio: we're out of time, what next?
o   Bernard: will send proposal and will discuss in reflector

****************************************************************************
*****
6.Fragmentation (Diego Lopez)

- 1st proposal is to add this only applies in authZ exchanges
- now in version -06
- addressed comments against -05 version:
o   clarification of fragmentation mechanism
o   clarification of the se cases and alternatives in the intro
o   satisfy abfab requirements
o   new intro section to highlight scope (including new section for scope,
filename and title change)
- Discussion of details of authN and authZ
o   Decompose radius chat in 3 phases: pre-authZ, authZ and post-authZ
o   Include implementation goals: including open source code
- Stefan: believes its work needed in abfab so would support this work, but
realizes this is really a hack
- Diego: agrees    
- Stefan: problem would go away if we had bigger packets.  What happened to
Sam's work in enlarging the packet?
- Sam: I support adoption of this draft where there are scenarios that need
to work with proxies.  Preference is that for TLS we raise the packet
size....but didn't get any positive feedback on the reflector for this so
didn't move forward.
- Stefan: suggests that Sam do generate a draft for this.  Follow up is to
ask why TCP is different than UDP? So if raise it for TCP/TLS, why not do it
for UDP too? There's no inherent reason not to do it
- Diego: it is a quick hack and can last for a while
- Sam: reason you don't now is it doesn't help with existing proxies.
Without a path into the mechanism it doesn't work...udp doesn't have such a
path
- Mauricio: lots of healthy discussion, not sure if we have convergence for
adoption.  With the focus change, what's different? Only the messages?
- Diego: applies for authZ exchanges only, so scope changes.  It originated
within abfab and there was a previous misunderstanding
- Mauricio: charter is more general so more discussion is needed
- Diego: but this is a part of the solution
- Mauricio: so implicitly, there'd be other drafts to cover the other or
generality
- Diego: yes, like Sam's proposal
- Mauricio: asks who read draft...answer: a few.  Believes this is on
trajectory for adoption, so need to put to reflector and ask volunteer
review

****************************************************************************
*****
7.Data Types (Alan)

- Data types named in RFC 2865 was used but practice has not continued in
other RFCs
- 3162 "address" is IPv6 and other examples
- suggest that data types be defined in a new document and create IANA
registry to track data types.  Change attribute registry to include data
type column and description so that now XML registry can be pulled to create
dictionaries and avoid ASCII art
- do not see any downside as this is common practice
- Mauricio: comments that downside is that its about 10yrs late; as its good
to look at historical and put in place improvements for future.  But at this
time, can't take new work as we need to focus on current backlog items.
Propose to keep this in the parking lot and once we reduce backlog, bring it
back to the group to see if its adopted as another item to work thru
- Alan: may make new standards easier to write, so before we adopt new
attributes, this work should precede those.

****************************************************************************
*****
8.Radius extensions for Key Management in WLAN Network (Li Xue)

- Lots of discussion on the reflector for why its needed.  Review of the use
cases...
- Traditional operator example use case: service GW connects to AAA, SW and
AC.  The GW as the management service, then it needs the information as its
also acting as the Authenticator.  GW is more centralized than an AC.
- Define radius packets for sharing key information.  Defines 2 new
attributes for providing key announcement and key material.
- Security considerations will be addressed in future draft
- Mauricio: is the intent to have informational or standards track?
- Li: wants it to be standards track
- Stefan: looking at the problem statement, usually the function is in the
AC not SGW....now that you've taken it from AC to SGW things break.
Proposing that we fix the break, going out of the way in fixing something
that was intended to work one way to make it fit your model; so do not buy
into this solution.  Is it that your company line is wanting to do it this
way?
- Li: for the operators there are many reasons that the GW should be the
authenticator.  If AC is the authenticator and the EAP proxy too.
- Stefan: AC is already getting Radius packets already to get the key, so
its basically the same code.
- Li: not right, because then AC has to be both
- Stefan: AC then has to speak some EAP or the GW has to speak all of EAP.
I don't think the problem is that complex to address.  Don't see what you
gain by this proposal
- Li: operators want to find a more single solution, want to simplify AC.
- Stefan: we can go on, but I still don't see the point.  You don't have to
do this at the IETF now, you can just try it on your devices first and if
you can prove that this is better than what the standards have, then we can
contemplate it. You don't need to have standards approval
- Mauricio: agrees with Stefan.  At this point, can't expand the charter to
adopt this as a WG item, but encourage you to keep moving forward in your
solution set.  Will keep it in the parking lot.

Meeting adjourns