[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Preliminary Meeting Minutes from IETF 73
IETF 73 - RADEXT WG Meeting Minutes
Tuesday, November 18, 3008
Agenda Bashing
--------------
No changes to agenda.
Document Status
---------------
For update, see http://www.drizzle.com/~aboba/RADEXT/
Completed IETF last call
NAS Management Authorization (completed November 11, 2008)
Design Guidelines (completed November 11, 2008)
Completed WG last call
Crypto-agility requirements (2 issues still open)
Extended Attributes (6 issues still open)
In WG Last Call
RADSEC (completes November 25, 2008)
Status Server (completes November 25, 2008)
WG Work items
draft-tiwari-radext-tunnel-types-02
Individual submissions
draft-dekok-radext-tcp-transport-00 (review completes November 19, 2008)
draft-lourdelet-radext-rfc3162bis-02 (discussion in progress)
draft-aboba-radext-wlan-09.txt (IEEE 802.1 review completed)
draft-zorn-radius-encatrr-15.txt
draft-dekok-radiusext-dlts-02.txt
draft-zorn-radius-pkmv1-01.txt (IEEE 802.16 review in progress)
IEEE 802 Reviews
----------------
Initial IEEE 802.1 review of draft-aboba-radext-wlan completed, comments incorporated
into -09. More comments may still be coming; aspects such as Status indications are
still in flux.
Joe Salowey: Stuff still happening in 802.1, but it's settling down. We'll get
more comments when the new 802.1X-REV draft comes out.
WiMax Forum and IEEE 802.16 (comments received today) have reviewed draft-zorn-radius-pkmv1.
Completed IETF Last Call
9:10 - 9:20 AM RADIUS Authorization for NAS Management, David Nelson (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06
David Nelson: IETF last call comments received.
1 issue was talking about understanding of text, discussion of SNMP vs. RADIUS
terminology. Another comment involved editorial nits (nothing earth shaking),
a request for changes to the ASCII art. Typically DIME WG uses dots/colon,
RADIUS docs don't use anything. There was a missing reference for HTTPS;
a request that IANA actions about code points to be assigned remain in
the published RFC. Might not be necessary to keep those in.
That's it -- no technical or substantive comments received.
WG Chair instruction is to address the comments, issue an -07 revision.
9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-design-05
Alan DeKok: A few comments were received in IETF last call. These Will be
addressed in next revision.
Appendix B lists the complex attributes and why they are good/bad.
Might be good to put in Called-Station-Id which has SSID/Mac Address.
David Nelson: Remember that documents in IETF last call are under IESG
change control. So you need IESG permission to make this change. Perhaps
you could consider it an IETF last call comment; however, you need to talk
to the AD to get permission to make the change.
In WG Last Call
9:30 AM - 9:40 AM Status-Server, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server-02
Alan DeKok: A few comments received in WG last call, will be fixed in next
revision. One issue is whether to permit an Access-Accept sent from an
accounting port.
David Nelson: The charter of this work item is to document existing
practice, not to extend the protocol. I flinch at Access-Accepts coming
from Accounting ports. RADIUS meets itself at the end and snaps....
Alan DeKok: RFC 2865/66 doesn't tie down originating ports, only
destination ports.
Bernard Aboba: Status-Server has been around since the mid-1990s, when
it was originated by Ascend Communications. So we are documenting
existing practice. Agree that RFC 2865/66 doesn't talk about
originating ports, so it's legal. But do existing implementations do
this? There are many things in this document that were judged
nonconformant/inappropriate at the time (which is why it was
not published as an RFC). We are documenting it because it's
widely implemented.
David Nelson: It is historical... but not creating a precedent.
Alan DeKok: The Access-Accept cannot contain authorization attributes.
Client sends a Status-Server (application layer ping), server responds
with an Access-Accept & no authorizations.
TCP draft uses this as the application layer watchdog.
Suggestion from Glen: Extend Status-Server to a CoA port... for server
to tell the NAS that they're up again.
dave mitton: some of us are trying to forget the Ascend days!
Bernard Aboba: Do existing implementations actually do this?
Alan DeKok: maybe WG consensus is to remove text on CoA.
9:40 AM - 9:50 AM RADSEC, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec-02
Stefan Winter: New version published. Two open issues (281, 282).
WG last call lasts until 25 november.
One question is whether to use SRV RRs (as in SIP) or A/AAAA RRs (as in DIAMETER).
There is also a question on how to register NAPTR RRs with IANA. The draft
currently follows RFC 3588, which says to do NAPTR lookup, if unsuccessful,
look up A/AAAA RRs within _radsec._tcp.domain.
This may not be an appropriate thing to do. Why not just use SRV RRs?
Bernard Aboba: There are some avantages to using SRV (can specify ports,
weighting). We talked about this on the list.
Stefan: Diameter is the only one using A/AAAA with NAPTR. Everyone else
(e.g. SIP) uses SRV.
Bernard Aboba:
SIP has separate document on how to find a server (RFC 3263).
It might be a good thing to split this out into a separate document,
rather than including it in RADSEC, especially for i18n issues.
Stefan: document is silent on i18n issues. Could put algorithm into another
document. RFC 3263 is an example of how to do this.
Joe: Does diameter have any recommendation here?
Bernard: yes, RFC 3588. But does anyone implement it? (silence)
Stefan: How do I register NAPTR construct? I have no clue! Asking for help...
Bernard: Ask Hannes. I think DIME WG is considering a revision to use
SRV RRs, instead of A/AAAA RRs.
Bernard: Last call on the RADSEC document goes to November 25th. Please read it.
Completed WG Last Call
9:50 AM - 10:00 AM Extended RADIUS Attributes, Bernard Aboba (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05
Bernard Aboba: The Extended Attributes document has completed RADEXT WG
last call. We are currently in issues resolution. Some issues are
currently in dispute; we currently have 5 open issues, some open more
than a year. Other WGs have dependencies on this document, but it
doesn't seem to be moving forward. We are hoping that the discussion
will converge, but it is hard to determine consensus from a small group
of people saying "yes" and "no". We are requesting that the WG read it
and send comments/opinions on the open issues.
Open issues include 225, 251, 278, 279 and 287.
Issue 250 was closed by Greg Weber.
Issue 272 was withdrawn by Glen.
The issues status has been updated on the RADEXT WG Issues web
page (http://www.drizzle.com/~aboba/RADEXT).
Stefan: There is an issue about when you are allowed to fragment if you have less
than 246 octets... no consensus so far.
Alan DeKok: doing weird little fragments is a great way to break things
Dave Nelson: if it's a matter of efficiency, then it would be a RECOMMENDED
or SHOULD behavior, unless it breaks interoperability. It doesn't need to be
a MUST.
Bernard Aboba: I think there is an issue with the DIAMETER considerations section.
Since the Type-Code was changed to two bytes, Extended Attributes doesn't
conform to the RFC 2865 recommended VSA format any more. RFC 4005 assumes
that VSAs are in this format, for translation from RADIUS to Diameter.
So an update to RFC 4005 is probably required. We will need to bring
in DIME WG folks to deal with this. As RFC 4005 stands, attribute 26 is
not allowed in Diameter.
Dave Nelson: Dave mitton had presented slides about attribute 26 and Diameter
Bernard: Yes. See:
http://www.watersprings.org/pub/id/draft-mitton-diameter-radius-vsas-01.txt
However, DIME currently doesn't have a work item for revision
of RFC 4005. In response to Issue 251, Glen Zorn has claimed that the
extended attributes can be translated to Diameter using the RADIUS/Diameter
gateway defined in RFC 4005. That used to be the case, before the Type
Code was extended to two bytes. But it isn't the case any more.
Also, there is an IANA considerations issue. Can we allocate from the
Extended Attribute space before the standard RADIUS attribute space is
exhausted? Some documents are specifying use of Extended Attributes;
should they have to wait until the standard attribute space is exhausted
before they can get an allocation? Or can they request an allocation
from the Extended space, and get one right away?
What about documents that are specifying standard RADIUS attributes?
Do they automatically get an allocation from the Extended RADIUS attribute
space once the standard base is exhausted? Or do we need to find a way to
extend allocations in the standard RADIUS attribute format as well?
Also, we have documents that are requesting a lot of attributes (5+).
IESG has asked whether DIAMETER AVPs should be allocated within the
RADIUS attribute space (MIPv6, Diameter QoS, etc.). This could result
in rapid exhaustion of the standard RADIUS attribute space. Should
requests for a lot of attribute receive automatic allocations within
the extended Attribute space, rather than the standard space?
Dan Romascanu: what do we do if we have a request for allocation of
Extended Attributes?
Bernard: Since the draft isn't approved for publication as an RFC,
IANA cannot make the allocation.
Dan Romascanu: This draft needs to be progressed in sync with changes
to Diameter.
Bernard: Yes, DIME WG has to figure out how to translate RADIUS
Extended Attributes. Dave Mitton's proposal might be one way forward.
Dan Romascanu: This is an action item for the DIME WG, and text needs
to be put into the IANA and DIAMETER considerations sections. This
text isn't in the document now, People shoudl be able to sit down
at a table for 1-2 hours and get consensus on these issues.
Bernard; might be good to show up in DIME WG and discuss this.
David Nelson: We can also talk about this at the AAA Doctors lunch.
There are functional enhancements as well as exhaustion issues. In the
absence of text, IANA should allow allocations in the extended space
prior to exhaustion of the RADIUS standard attribute space, on request.
People shouldn't need to wait until standard space is exhausted.
davem: Can I resurect the draft if there is interest?
Bernard: Ask the DIME WG.
10:00 AM - 10:10 AM RADIUS Cryptoagility Requirements, David Nelson (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02
David Nelson: 2 open issues (274, 275), some editorial issues. -01 submitted this week.
We have had some discussion relating to automated key management; there was consensus
that this was not a requirement. There is also an issue relating to ciphersuite
negotiation. RADIUS doesn't support negotiation in general. The best we can do
is for the NAS to provide a hint, and for the RADIUS server to accept or reject the
hint. The question is how to avoid bidding down attacks.
Bernard Aboba: What happens if the NAS offers an upgraded ciphersuite, but the packet
is integrity protected and authenticated using MD5? If the MD5 secret is recovered
by an attacker, then the attacker can create a new packet that removes the upgraded
ciphersuite offer and any upgraded security services (integrity/confidentiality).
If the RADIUS server is configured to require upgraded security, then it can
reject this (tampered) Access-Request. But if it is configured to still accept
MD5 security as well as upgraded ciphersuites, then it will be fooled by the
bidding-down attack.
Joe Salowey: How does the RADIUS client know why its been rejected?
Bernard Aboba: If it is rejected because of an inappropriate ciphersuite offer, then
maybe it can figure out that something went wrong (unless the attacker also modifies
the error message coming back). Not clear that the RADIUS Error-Cause attribute is
sufficient for this....
Joe Salowey: The problem is that the RADIUS Access-Request is not really a hint. If
a password or key is encrypted with a new ciphersuite, then the two sides need to agree.
David Nelson: We could use another round trip as call-check..
Bernard: We don't need to design a solution here... but we do need to figure out the
requirements.
One requirement is to avoid cascaded compromise. If the MD5 secret is compromised,
don't also want to compromise keys used for the upgraded ciphersuites. For
example, we can require that keys used in enhanced ciphersuites be cryptographically
independent of the MD5 secret. So if the MD5 secret is compromised, then this doesn't
also compromise enhanced ciphersuites.
Joe Salowey: There has been lots of discussion on the list about requirements. We
don't want to write stupid requirements.
Bernard Aboba: The big question is what the transition model is. During some
period we will have a mixture of MD5 and ugpraded ciphersuites, at least before
MD5 compromise of a strong shared secret becomes practical. Once that happens,
we can try to limit the damage (e.g. via cryptographic independence of keys),
but without policy (requiring upgraded ciphersuites) we probably cannot prevent
bidding down attacks.
Maybe we should explicitly describe the transition strategy: do you upgrade
the RADIUS server first, so as to support the new functionality and upgraded
ciphersuites? This is usually easier than upgrading legacy NASes.
Also, what policy configurations do we assume/require? Maybe an upgraded
RADIUS server initially accepts MD5 as well as upgraded ciphersuites, then
eventually requires upgraded ciphseruites once all NASes are upgraded.
Or maybe upgraded NASes can be configured to require that the RADIUS server
supports crypto-agility.
In that configuration, the NAS would not accept a response from the RADIUS
server protected with MD5; it assumes that it MUST support upgraded
ciphersuites. Perhaps the NAS can be configured not to use MD5 at all,
just an upgraded ciphersuite. If the RADIUS server only supports MD5,
then the RADIUS server will silently discard the packet (unless an attacker
already knows the MD5 secret and can forge integrity/authentication).
David Nelson: Crypto-agility solutions can't depend on introduction of
new negotiation capabilities into RADIUS. We are looking for feedback
on this (either in the room, or on the list).
Joe: back to issues slide
David Nelson: slides were proposal; let's see if it's reasonable
Joe: seems reasonable, seems to be right direction
Individual Submissions
10:10 AM - 10:20 AM TCP Transport, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00
Goal is to take TCP-specific issues in RADSEC draft that were
independent of TLS issues and handle them separately. The
goal is to describe how to transport RADIUS over TCP. The
RADIUS protocol isn't changed; this should simplify implementations.
There are some TCP-specific issues.
Once the three-way handshake is set up, you don't have to validate
the IP address on each message.
The TCP connection has to be reset after receiving a malformed packet.
Magnus Westerlund: It depends on how you structure the protocol. If
you would provide framing around it, not raw RADIUS, then perhaps
you could recover from a malformed packet.
Alan DeKok: No framing... just raw RADIUS. So if the packet is malformed,
there is no way to re-sync.
Magnus: I understand..
Alan: Also, if you have attributes with length of 0 or 1, you reset the TCP
connection.
There is a problem with Identifiers. The Identifier space is only 8 bits,
so you can only have 256 IDs... so only 256 messages can be in flight for
a single Op Code. RADSEC sends both accounting and authentication packets
over one TCP connection.
Magnus: Is it outstanding requests or packets in flight?
Alan: Outstanding requests.
Magnus: This will interact badly with TCP connection state.... won't keep
enough traffic in flow. Opening another connection will also be problematic
with respect to congestion.
Bernard Aboba: You don't want to have lots of connections open, all in
slow start, ramping up rapidly....
Bernard Aboba: Are we trying to enable RADIUS over TCP without RADSEC?
Magnus Westerlund: It seems generic. SCTP might be a better fit.
Also, the applicability statement seems to be a bit off. My
impression is that sending less than one packet per RTT doesn't disqualify
TCP. What is the applicability and what do you want to gain here?
David Nelson: There is WG consensus, and there is what makes sense.
We had WG consensus to separate the document, so it could be used
for things other than RADSEC. We may need to revisit this if we determine
that this was a bad idea.
Alan DeKok: The document is relatively silent on this right now.
Alan: The issue of 256 IDs interacts with the watchdog timer.
There needs to be a way to distinguish Access-Accepts sent in
response to a Status-Server from Access-Requests sent in response to
an Accesss-Request. Otherwise, the RADSEC client can have 256
outstanding requests, using up all the ID space. Now you try to
send a Status-Server packet, but you can't because there are no
free IDs yet. Nobody likes this idea. If anyone has a better
suggestion?
WG: Collective groan.
Alan: This is RADIUS. It is disgusting.
Bernard: This is beyond disgusting... it's badly broken.
David Nelson: We need to avoid this....
Bernard: We should open an issue on this...
Alan DeKok: Another issue that has arisen is with respect to SNMP MIBs.
Should RADSEC implementations use the existing RADIUS client/server MIBs?
Dan Romascanu: We might want to separate UDP/TCP counters... could do this in next MIB revision.
In the standard MIB... there is only global counters.
Magnus Westerlund: There is an issue here when you are using TCP for one leg and
another leg is using UDP. This could cause transport problems.
Bernard Aboba: This is an issue even if TCP is being used for both legs. Today's
RADIUS proxies forward UDP packets without sending an acknowledgement, so that the
transport dynamics (RTT, frame loss) are effectively end-to-end. This isn't
true anymore when there is even one TCP leg in the path. RFC 3539 talks about
this. Two control loops are always less stable than one.
Bernard: We should open an issue on this as well.
Alan DeKok: A lot of transport area review needs to be done.
Bernard: We will ask the Transport Directorate for assignment of an advisor.
10:20 AM - 10:25 AM New Tunnel-Type Values, Abhishek Tiwari (5 minutes)
http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02
David Nelson: Is there any objection in the room to starting WG last call on
tunnel-type value draft?
Room: None.
David Nelson: I will start the WG last call.
10:25 AM - 10:30 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (5 minutes)
http://tools.ietf.org/html/draft-aboba-radext-wlan-09
Bernard Aboba: This draft contains attributes for IEEE 802.11i, 11r, 11s as well as
IEEE 802.1X-REV. IEEE 802.1X-REV has been evolving. IEEE 802.1X-2004 included text
from what was eventually published as RFC 3580. That text has now been removed in
favor of a reference to RFC 3580. IEEE 802.1X-REV D2.9 now references this draft
in Appendix E.
The -09 draft contains 2 attributes to support IEEE 802.1X-REV: Network-ID-Name and
Access-Status. Network-ID-Name can be up to 253 octets, so it is smaller than the
SSID (32 octets) and wouldn't necessarily fit within a Called-Station-Id attribute,
so it has to be separate.
The current draft includes functionality for IEEE 802.11s (Mesh Key Distributors), but
11s status is uncertain. The ETA of 11s has slipped; there is currently no editor
for the document; there was a suggestion at the last IEEE 802 plenary that the
group be dissolved.
Since IEEE 802.1X-REV has a dependency on this document, and it has an ETA of
2009 (was December 2008, but it slipped), depending on IEEE 802.11s functionality
that isn't solid probably isn't a good idea.
Next steps are to sync the draft with the next revision of IEEE 802.1X-REV, and
also to remove material relating to 11s. At that point, we will request wider
review and adoption as a RADEXT WG work item.
10:30 AM - 10:40 AM , Transmitting Confidential Data in RADIUS, Joe Salowey (10 minutes)
http://tools.ietf.org/html/draft-zorn-radius-encattr-15
Joe: Quick update on the encrypted attributes draft.
In the latest draft, we merged multiple attributes into 1 for wrapper to encrypt data. This
may be keys or other data.
Alan DeKok: "Comsiderations" ? Very telco-centric.
Joe: Is this document ready for adoption as WG item?
David Nelson: We are currently discussing crypto-agility requirements. Are there
additional WG work items that this document depends on?
Joe Salowey: would need to be some supporting things around negotiation.
May be some kind of error indication.
Dave Nelson: would be nice to keep requirements && solution documents in sync
Bernard: Keep in mind that this document negotiates a bunch of
different things. We want to be able to avoid bidding down attacks,
either via cryptographic or policy measures.
Joe: Every RADIUS response now has crypto implied. Many requests do, too.
Bernard: say MD5 gets cracked tomorrow... that wouldn't allow the attacker
to recover encryption keys or passwords, right?
Joe: We might say that passwords should be encrypted with AES rather than MD5.
Dave: It is implicit in crypto agility that all algorithms will someday fail.
We can't assume that there's no bidding down attack.
Bernard: if we assume that you wouldn't be doing encryption with an enhanced
ciphersutie without a stronger hash as well, we'd be better than where we are now.
When MD5 gets cracked, you lose both encryption and integrity of RADIUS as
it currently exists. Once that happens, the transition becomes a lot tougher,
because you need a "flag day".
Once this document is implemented, we will have crypto-graphic negotiation
in place; assuming that the algorithm protecting the negotiation itself is
not compromised, then we will be able to securely negotiate new ciphersuites
if an existing one is compromised.
David Nelson: if we're talking about a transition strategy from RADIUS to
this new approach, negotiations can only be protected with classic RADIUS.
Bernard: In an environment where the RADIUS proxy/server only supports MD5,
yes. In that situation, I don't believe we can avoid a bidding down attack,
but we can avoid compromise of keys used to protect the enhanced ciphersuite,
by keeping them cryptographically separate from the MD5 secret.
However, if the RADIUS proxy/server supports this document, then a NAS
can be configured to require support for enhanced ciphersuites, and avoid
use of MD5.
So overall, we need to describe the migration strategy.
Joe: If we can get this document deployed, then this solves a lot of problems.
Bernard: The document should talk more about the migration strategy (e.g. what
is upgraded first, how to avoid bidding down via policy, how to deal with
compromise of MD5 and other algorithms, etc.).
Internationalization
10:40 AM - 11 AM i8n Issues with RFC 4282, Alan DeKok (10 minutes)
http://tools.ietf.org/html/rfc4282
Bernard Aboba: How many people were present in EMU WG and have heard
this talk already?
Room: Quite a few hands go up.
Bernard Aboba: I guess we don't need to repeat the EMU WG presentation.
Alan DeKok: The main issue here is that RFC 4282 is out of sync with
what implementations actually do. In practice, Windows, MacOS and
Linux implementations of EAP and RADIUS use UTF-8, both for the
username and the realm.
Bernard Aboba: Not all versions of Windows use UTF-8. In Vista,
IEEE 802.11 is based on an RFC 3748 implementation (EAPHOST). This
uses UTF-8. However, the EAP implementation used by PPP and VPN
(L2TP, PPTP, SSTP) is based on RFC 2284, and this implementation
uses code pages. Windows XP SP2 and earlier as well as Windows 2000
also use this earlier implementation, so they will also not put out
UTF-8 in EAP-Response/Identity packets.
Stefan Winter: We also saw non UTF-8 coming from Windows xP SP3.
Bernard Aboba: That is under investigation.
Alan DeKok: There are several issues that this brings up:
* RFC 3748 says that the EAP-Request/Identity uses UTF-8 but not
the EAP-Response. This looks like an oversight.
* RADIUS RFCs state that the User-Name attribute is encoded in
UTF-8.
* Both EAP and RADIUS are 8-bit clean. So there is in practice
no need for punycode in order to support a 7-bit channel.
* Existing implementations often treat the NAI like an opaque blob.
The NAI may be configured for the user, or the user may not even
able to enter it (e.g. Windows). In these cases, there is no
normalization issue; the client sends what the server is
configured to accept.
Bernard Aboba: I think the problem originated from the assumption
of RFC 2486 that the NAI had the same syntax as an email address.
Shortly thereafter, operating systems began to support UTF-8 based
hostnames and usernames, so this wasn't true any more.
Alan DeKok: Another issue with RFC 4282 is that it isn't in sync
with IDNAbis. This means that RFC 4282 can't support new versions
of UNICODE or new scripts. It isn't in sync with the new bidi
draft, with the updated tables, etc. Character have since been
prohibited/added, new scripts have been added, etc.
Bernard Aboba: So far, we've just been discussing the NAI. However,
there are also issues with respect to password handling, and in some
cases, EAP methods. For example, it appears that RFC 2759 refers to
usernames/passwords encoded in ASCII. There are documented cases
where UTF-8 usernames have failed to authenticate. For some reason
the hashes are actually failing to run over the UTF-8 bits in the
username. There is an errata filed on RFC 2759 currently which
appears to relate to this. RFC 3748 Section 5 talks about
non-ASCII characters in passphrases:
EAP methods MAY support authentication based on shared secrets. If
the shared secret is a passphrase entered by the user,
implementations MAY support entering passphrases with non-ASCII
characters. In this case, the input should be processed using an
appropriate stringprep [RFC3454] profile, and encoded in octets using
UTF-8 encoding [RFC2279]. A preliminary version of a possible
stringprep profile is described in [SASLPREP].
Does anyone actually implement this?
Alan DeKok: I don't think so. Passphrases (like NAIs) are generally
treated like opaque bits.
Bernard Aboba: Maybe a step forward would be to create a draft
describing what implementations actually do? This might require
some testing... but at least we'd know how big the issue really is.
IPv6
11:00 AM - 11:10 AM Prefix Authorization, Behcet Sarikaya (10 minutes)
http://tools.ietf.org/id/draft-sarikaya-radext-prefix-authorization-01
Bernard Aboba: Some background. RFC 3162 was developed largely to
support IPv6 over PPP. Ralph Droms and others attempted to use
this to support DHCPv6 prefix delegation and discovered it didn't
work, because if the user had a router on the premises, then the
IPV6 address model required that the prefixe be assigned to the
link between the user and the NAS, not for use in the user network.
So we had to develop RFC 4818 to support DHCPv6 prefix delegation.
Then we discovered some additional confusion in RFC 3162 with
respect to the Framed-IPv6-Prefix attribute. Could this attribute
be used to configure a /128 prefix for the user (e.g. assign an
IPv6 address)? If the intent was to cause the assigned prefix
to be advertised by the NAS in an RA sent to the user, then this
doesn't make sense. Such a prefix could only be as large as
a /64. The Framed-Interface-Id attribute is used to specify
the Identifier portion of the address. This issue was clarified
in RFC 5080 (which unexplicably, did not update RFC 3162).
Behcet: Now we need the Authorized-UserId-Prefix attribute.
Joe Salowey: what is a prefix authorization user id?
Behcet: The RADIUS server needs to identify the user.
Joe Salowey: So the the RADIUS client stores this value, and puts
this value in an Access-Request?
Behcet: It is also needed for renumbering via a CoA-Request and
CoA-ACK.
Bernard Aboba: If renumbering occurs, how does the end user obtain
their new address? RFC 3162 assumes this happens by having the NAS
issue an RA with the new prefix. But this draft is assuming another
address assignment mechanism, right?
Joe Salowey: The RADIUS Access-Request already has context information about who's
requesting things, namely the User-Name Attribute. So why do we need a separate
attribute to specify this?
Bernard: Are there other things associated with the prefix?
Benoit: How does this draft relate to RFC 4818? Is it using DHCPv6 Prefix Delegation?
Behcet: It is completely different from RFC 4818. In RFC 4818, the AAA server provides
prefixes to the NAS, for use with DHCPv6 prefix delegation. Here the AAA server provides
prefixes to the AAA client.
Bernard Aboba: How does the AAA client communicate the prefixes to the user? Does
this document assume that the NAS is implementing an alternative to DHCPv6 prefix
delegation? If so, what mechanism is being used? One constraint in the RADEXT WG
is that we cannot define new network functionality in this WG. Documents have to
reference an existing service model. RFC 4818 references the DHCPv6 prefix delegation
RFCs. RFC 3162 refers to the PPP over IPv6 RFC 2472, the IPv6 addressing architecture
and other IPv6 documents. What existing prefix assignment mechanism is being depended
on here? The RADEXT WG can't be used to define an alternative mechanism for prefix
delegation.
Frank: The DHCP radius interface excludes the possibility that this can be done
by AAA only. DHCPv6 can deal with renumbering. AAA can't do that. This draft
violates the basic principles of IPv6 address allocation.
11:10 AM - 11:20 AM RFC 3162bis, Benoit Lourdelet (10 minutes)
http://tools.ietf.org/html/draft-lourdelet-radext-rfc3162bis-02
Benoit: This document is being proposed to accomodate IPv6 production networks,
in which there is an issue of how to configure the DNS server address. This
can be delivered to the client either via DHCPv6 or via a Router Advertisement
option.
Bernard Aboba: it would be great to have those references in the document.
However, this also raises the question of whether we might also have requests
for allocations of RADIUS attributes corresponding to other DHCP options.
We don't have enough remaining RADIUS attribute space to handle all the
potential allocation requests that this could generate. So, should we
be defining a single RADIUS attribute to carry lots of DHCP options,
rather than a single RADIUS attribute?
Benoit: The need to configure a DNS server is independent of DHCP,
since it can also be communicated in a router advertisement. So
we probably need a separate DNS server attribute in RADIUS. But
future DHCPv6 options might require a more generic approach.
Bernard Aboba: Another issue that was discussed on the list was whether
this document needed to update RFC 3162 or not. From the draft, it looked
like the only issue that needed clarification was the use of the
Framed-IPv6-Prefix attribute to carry IPv6 addresses. RFC 5080
discourages that, so you don't need to revise RFC 3162 to clarify
that issue; you can just reference RFC 5080 and perhaps include an
Updates: RFC 3162 in the document header.
That said, I don't want to discourage you if you want to volunteer
to update RFC 3162... it's just that you don't need to do that in order
to progress this document.
Benoit: I'd rather go with a standalone document, if that can be done.
Bernard Aboba: A separate document (rather than an RFC 3162 revision) seems to
be the way forward.
David Nelson: if this is talking about services other than DHCP... do we define
a new service in a RADIUS document?
Bernard: It looks like this document just references existing services such
as DHCPv6 and Router Advertisement.
Glen: I am opposed to both this draft and the previous one, because they are
not AAA-related. It might not be a bad idea to define a new service as they are
not per-user attributes. The RADIUS client is likely to be a DHCP server/relay
rather than a NAS.
Bernard Aboba: Couldn't the DNS server attribute be used with a NAS implementing
either a DHCPv6 server or stateless autoconfig (e.g. RA)? The authentication could
be IEEE 802.1X or PPP, for example. So there are some usage cases that seem
quite conventional.
David Nelson: This document still has some issues that need attention. We need
an indication of what goes in what document. Do we have two separate documents,
or do we merge them? Or do we deal with the "service reference" issue first?
Bernard Aboba: All RADEXT documents need to be able to provide a service reference
in order to be accepted as WG work items. We can't define new services here; we just
define how RADIUS can manage existing services.
Bernard: The 2 documents in IETF last call, plus the 4 documents in WG last call have
consumed the group. We need to make more rapid progress on those work items, get
the documents in IETF last call into the RFC Editor Queue, get the 4 documents in WG
last call ready for consideration by the IESG. Once we have done this we will have
more cycles for the other work that people want to get going on.
However, document authors of individual submissions can still make progress on their own.
They can solicit feedback, they can get get their own reviews from other areas, they
can clarify the service references, provide applicability statements, etc. So work
doesn't need to stop waiting for RADEXT WG attention and cycles to free up.
Meeting Ended.