[radext] IETF 88: Preliminary Meeting Notes

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

Below are preliminary meeting notes for your review.   Thanks go to Dorothy
for note taking.  

Please post to mailing list any corrections/feedback.

Thanks,
Jouni and Mauricio 

--------------------------
RADEXT
IETF 88
Vancouver, Canada

Monday, November 5, 2013
Meeting started 1:01PM and adjourned 2:10PM

Chairs:
Jouni Korhonen <jouni.korhonen at broadcom.com>
Mauricio Sanchez <mauricio.sanchez at hp.com>

AD:
Benoit Claise <bclaise at cisco.com>

1.Preliminaries
a. Blue sheet reminder
b. Jabber scribe: Alan DeKok
c. Minute taker: Dorothy Stanley
d. Status:
i. No RFCs Published, in editor queue.
ii. IEEE 802 attributes ­ version -09 published 2013-10-20, one of 24 issues
still open.
iii. NAI-based peer discovery ­ version -08 published 2013-10-16, no open
issues.
iv. Network Access Identifier ­ version -04 published ­ still one issue,
raised by Sam Hartman should be closed before the end of the week.
v. Support of fragmentation of RADIUS packets ­ version -01 published, will
be discussed today.
vi. Larger Packets for RADIUS over TCP ­ Version -00 published 2013-10, to
be discussed.
vii. Have 2 documents that are outside the current charter: Data type in
RADIUS and RADIUS extensions for key management in WLAN network.
viii. Chair reviewed WG goals and milestones; way beyond deadlines; however,
have momentum on progressing documents.

****************************************************************************
*****
2. Alan DeKok ­ DTLS draft, see
http://tools.ietf.org/id/draft-ietf-radext-dtls and
http://www.ietf.org/proceedings/88/slides/slides-88-radext-2.ppt
a. Secdir and opsdir reviews completed.
b. No more open issues.
c. Submit for publication?
d. Comment: Transport director review still coming.
e. Radsec proxy and Jradius work.
3. Alan DeKok ­ NAI based peer discovery, see
http://tools.ietf.org/html/draft-ietf-radext-nai and
http://www.ietf.org/proceedings/88/slides/slides-88-radext-4.ppt
a. Main sticking point ­ normalization done at edge or core.
b. Realm part is a DNS name; if register, then valid.
c. RFC 4282 not implemented.
d. Let DNS people handle internationalization.
e. Have happy users at the edge. Get on the network; computer puts blob into
EAP. UTF-8? Can RADIUS server determine the domain name from the UTF-8 blob.
This is the open issue.
f. Given an end user machine and a proxy, if at same Unicode version ­ can
normalization be done?
g. Can¹t upgrade a billion edge devices.
h. Comment - even if not at same unicode version, will match for many
values.
i. Little feedback from il8n folks to date; goal to close on this by end of
this week.
j. Comment ­ what is the problem with RFC4282?
k. Bans unassigned unicode code points. If proxy receives an unassigned code
point, then drop. Does not support upgrading proxies.
l. http://tools.ietf.org/html/draft-ietf-radext-nai

****************************************************************************
*****
4. Bernard Aboba ­ IEEE 802 extensions draft, see
http://tools.ietf.org/html/draft-ietf-radext-ieee802ext and
http://www.ietf.org/proceedings/88/slides/slides-88-radext-3.ppt
a. WGLC has concluded.
b. One remaining issue ­ how to use RADIUS with wired extensions defined in
IEEE 802.1X-2010 Review of TLV types, 0-127 possible TLVs.
c. Proposal is to create an EAPoL-Announcement attribute which can be
present in all RADIUS message and include the TLVs.
d. Define how to deal with multiple announcements attributes in a packet.
Allows TLVs longer than 253 octets to be transported by RADIUS.
e. Proposal is in the draft. Confirm on the list, and with Joe Salowey that
he is ok with the proposed solution.
f. Question on the concatenation. Is there a spec that we can reference?
g. http://tools.ietf.org/html/draft-ietf-radext-ieee802ext

****************************************************************************
*****
5. Diego Lopez ­ RADIUS Fragmentation, see
http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation and
http://www.ietf.org/proceedings/88/slides/slides-88-radext-6.pdf
a. Reviewed status: accepted as a WG document 2013-08-26. Solution focused
on transport of large amounts of auth info.
b. Changes made to text to address issues.
i. Added text clarifying that proxies are assumed to base their routing
decisions on the value of the User-name attribute.
ii. New text regarding how proxies implement RFC6929 ­ SHOULD forward
packages even if invalid attributes are found.
iii. Included an example for SAML ­ roundtrips required.
c. Review of remaining issues
i. Proxy-State-Length attribute
ii. Detailed description of CoA handling.
d. Chair: how many people have read the -01 version? Small number of hands.
e. Alan: This is a hack to get data through existing systems; don¹t depend
on it.
f. Sam: Believe the draft is ready for AD review and transport area review;
recommend sending to those directorates for review sooner rather than later.
g. Get AD review when we do WGLC on -02.

****************************************************************************
*****
6. Stefan not available: defer.1:25 - 1:30PM RADIUS dynamic discovery,
Stefan Winter (5 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

****************************************************************************
*****
7. Sam Hartman - Larger Packets for Remote RADIUS over TCP, see
http://tools.ietf.org/html/draft-hartman-radext-bigger-packets and
http://www.ietf.org/proceedings/88/slides/slides-88-radext-5.pdf
a. Review of goals: carry packets with more than 4096 octets of attributes
b. Applications carrying RADIUS over TLS; when security available, then can
carry more info.
c. Review of open issue: Capability negotiation requested.
i. Unclear that this is needed. No way to tell if server supports large
packets.
ii. Really capability discovery.
iii. But is capability discovery really needed.
iv. Mitigated by experimental status of TCP transport, with no reasonable
fallback.
v. Problem with multiple outstanding requests.
vi. Negotiation is strongly desired.
d. Review of open issue: Error Response.
i. Use error codes or access-reject
ii. Need feedback.
e. Question: Are there other circumstances when there are many packets in
flight and one causes connection to be dropped?
i. If send malformed packet, issue introduced. Only case known.
f. Fix issues, post updated draft; raise any objections now.
g. Question: Why doesn¹t new infrastructure require larger packets?
i. Interest in implementing for RADIUS.
ii. Discussion on supporting RADIUS larger packets closed with approved
re-charter.
iii. Let market decide. Some implementers and applications not interested in
moving to DIAMETER.
8. Wrap-up, next steps
a. Plan to have further discussion re: guidance on RADIUS and DIAMETER.
b. Benoit Claise: Call for action
i. There has been a request for a AAA tutorial to capture institutional
knowledge.
ii. Please direct your interest in guidance on RADIUS and DIAMETER to the
AAA tutorial.
c. Alan DeKok ­ CoA and proxy
d. Alan DeKok - Data Types draft
e. Re-charter (or not)
f. How many people have read Sam¹s draft? About 4. Revision to be published
soon, get more eyes on the revision.

****************************************************************************
*****
9. Meeting adjourned 1410.