RADIUS Extensions (radext)
Working Group, March 27, 2009 9:00 am-11:30 am
Notes: Dorothy Stanley
Chairs: Bernard Aboba <bernard_aboba@hotmail.com>
David Nelson <d.b.nelson@comcast.net>
Chair (Bernard Aboba)
called the meeting to order at 9:05am.
-
Obtained volunteers for note takers (Dorothy
Stanley, Alan DeKok) and a jabber scribe.
-
“Note Well”, Intellectual property notice.
-
When starting a presentation you MUST
say if:
i.
There is IPR
associated with your draft
ii.
The restrictions
listed in section 5 of RFC 3978/4748 apply to your draft
-
When asking questions or commenting on a
draft:
i.
You MUST disclose
any IPR you know of relating to the technology under discussion
-
References: RFC 5378 and RFC 3979
(updated by RFC 4879), Note well” text
-
Review of agenda, no changes identified
-
Summary & Wrap-up (5 minutes) IETF 74
RADEXT WG Agenda, San Francisco, California, Friday, March 27,2009
-
9 AM - 9:10 Preliminaries (10 minutes) -
Blue Sheets, Note Takers, Jabber Scribe, Agenda bashing
-
Document Status - Documents completing
IETF Last Call (15 minutes)
i. 9:10 - 9:15 AM RADIUS Authorization for NAS Management, David Nelson (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-management-authorization
ii. 9:15 - 9:25 AM RADIUS Design Guidelines, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-design
b. Documents that have completed RADEXT WG Last Call (35 minutes)
i. 9:25 - 9:30 AM New Tunnel Type Values, Abhishek Tiwari (5 minutes) http://tools.ietf.org/html/draft-ietf-radext-tunnel-type
ii. 9:30 AM – 9:40 AM Status-Server, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-status-server
iii. 9:40 AM – 9:50 AM Extended RADIUS Attributes, Glen Zorn (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-extended-attributes
iv. 9:50 AM - 10:00 AM RADIUS Crypto-agility Requirements, David Nelson (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements
c. Documents in RADEXT WG last call (10 minutes)
i. 10:00 AM - 10:10 AM RADSEC, Stefan Winter (10 minutes http://tools.ietf.org/html/draft-ietf-radext-radsec
d. Working Group Work Items (10 minutes)
i. 10:10 AM - 10:20 AM TCP Transport, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-tcp-transport
e. Individual Submissions (40 minutes)
i. 10:20 AM - 10:30 AM RADIUS attributes for IPv6 Access Networks, Benoit Lourdelet (10 minutes) http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access
ii. 10:30 AM - 10:40 AM NAI-based Dynamic Peer Discovery, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-winter-dynamic-discovery
iii. 10:40 AM - 10:50 AM RADIUS Attributes for IEEE 802.16 PKMv1, Glen Zorn (10 minutes) http://tools.ietf.org/html/draft-zorn-radius-pkmv1
iv. 10:50 AM - 11:00 AM RADIUS Confidentiality, Glen Zorn (10 minutes) http://tools.ietf.org/html/draft-zorn-radius-encattr
f. Summary & Wrap-up
-
Discussion on RADIUS Authorization for NAS
Management, David Nelson http://tools.ietf.org/html/draft-ietf-radext-management-authorization
-
IETF Last call completed
-
GenArt Review generated comments. Need
context for discussion of SNMP vs RADIUS terminology, Clarification of a
length field
-
Reviewed IETF Last call issues
-
Reviewed IESG Discuss comments
i.
Pasi/Tim/Jari
provided comments: specify relationship between the numeric value of the
Management-Privilege-Level Attribute and actual rights.
ii.
Can the NAS infer
anything about access rights from the SSH server module in the NAS?
iii.
Comment: Can
request a service.
iv.
Dave: No range is
specified.
v.
Chair reviewed
proposed resolution. No objection
-
Discussion on RADIUS Design Guidelines, Alan
DeKok
http://tools.ietf.org/html/draft-ietf-radext-design
-
IETF last call has completed. Review
from Alfred Hoenes. No other
IETF last call comments.
-
Changes to RADIUS MUST NOT be done
outside of the IETF
-
Lots of word-smithing and clarifications
-
This document has gone through many WG
last calls (might be a record)
-
Next step – IESG agenda.
-
Update on New Tunnel Type Values, Abhishek
Tiwari
http://tools.ietf.org/html/draft-ietf-radext-tunnel-type - Bernard,
channeling the authors
-
Had a WG Last call announced on Nov 25,
2008, ending December 15, 2008. Updated document with resolutions to
comments.
-
Proposal is to send to IETF last call.
No objections.
-
Discussion on Status-Server, Alan DeKok
http://tools.ietf.org/html/draft-ietf-radext-status-server
-
Has gone through multiple last calls,
comments from Alfred Hoenes. Removed extra text (TCP, other uses),
removed Care of Address. Goal of document is to document existing
practice.
-
Comment – Glen
Zorn
– Removing the extensions is “perfect” thing to do – this is a RADIUS
Extensions WG.
-
Where will the extensions be described?
RADIUS TCP document.
-
Issues – Is it a connection watchdog?
COA extensions are useful. If
have COA relationship with the NAS, can add functionality.
-
Chair: This documents existing practices
such as they are. Who will review it? Glen has some of the old Ascend
source. Chair will try to dig up someone from Ascend.
-
Message integrity – security was also
added.\
-
Outstanding issues on Status server –
Alan will check to see if these have been closed.
-
Update on Extended RADIUS attributes, Glen Zorn.
http://tools.ietf.org/html/draft-ietf-radext-extended-attributes
-
Six open technical issues had been
identified
-
Believe that issues 225, 278 and 279 are
closed. Remaining issues include
IANA considerations (reservation of attributes 0-255) and Diameter
compatibility. Diameter issue
was discussed at the AAA doctors meeting this week.
-
Alan: Do we want to reserve the value
for encapsulating legacy attributes?
-
Stefan – 279 is also closed – can split
attributes.
-
New draft will be submitted by Glen Zorn
in the DIME WG to address issues 251 and 290.
-
Will the dependency on the new document
in DIME WG be normative? Unclear. New draft will obviate the need for a
Diameter considerations section in the Extended Attributes document,
which it currently isn’t
possible to write.
-
Update on RADIUS Crypto-agility
Requirements, David Nelson
http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements
-
Had an early review by Pasi Eronen
(Security AD). A significant number of issues were raised:
i.
Issues of
interpretation, need to refine text
ii.
Hop-by-hop vs end
to end. RADIUS only has hop-by-hop security. The document should explain the
goals and whether end-to-end security is to be covered.
iii.
Forward secrecy
of keys. Discussion on what forward
secrecy they are referring to. Is this
about forward secrecy in the keys themselves (orthogonal to crypto-agility) or
forward secrecy of the key wrap? Do
crypto agility solutions need to provide forward secrecy of the wrapping
algorithm?
iv.
Tim Polk: Not
prepared to channel Pasi. Assume he wants us to know which security attributes
we are expecting. Current document is silent, need to document expectations.
v.
Chair: WRT Key
wrapping, if keys don’t have forward secrecy, does that have implications for
the wrap?
vi.
Joe Salowey: The
focus of the document is Crypto-Agility, not improving the overall security
properties. Adding these
considerations expand the scope of work.
.
vii.
Tim: Perhaps Pasi
is assuming the scope is broader. Perhaps explaining and tightening the scope
will resolve his comment.
viii.
Does transport of
keys provide new requirements?
ix.
Authentication
and long-term credentials, which kinds are supported? For example, is it
required to support only pre-shared keys, or are there other requirements as
well (e.g. certification authentication between RADIUS clients and servers)?
In other words, do the requirements include authentication method
agility, versus algorithm agility?
x.
Maybe part of the
problem is that the draft goes too far in some areas.
xi.
Discussion of
automated key management.
Previous understanding was that the document needed to analyze RADIUS
requirements against the RFC 4107 guidelines for automated key management.
Do Pasi’s requirements fit within the RFC 4107 framework, or do they
represent additional requirements?
If they are additional requirements, on what basis are they being imposed?
xii.
Replay
protection. Glen Zorn indicates
that RADIUS intentionally doesn’t provide Replay Protection.
With respect to Authentication, if a packet is retransmitted by the
RADIUS client, the RADIUS server sends the same response, since it is stateless
– it doesn’t discard the retransmitted packet.
In RADIUS accounting, a packet can be retransmitted and will be submitted
to the billing system, which is expected to remove duplicates.
As a result, Replay Protection is not a requirement for RADIUS.
xiii.
What about
Message Integrity? RFC 2865 does
not provide integrity protection in all circumstances.
So the scope of the document is merely to allow negotiation of integrity
protection algorithms in situations where this is already required – not to
require message integrity in situations in all situations.
After all, systems that don’t provide message integrity are by definition
legacy implementations that could be 15+ years old.
These systems are highly unlikely to implement Crypto-Agility.
Fixing all security problems of RADIUS is outside the scope of this work
item.
xiv.
Meaning of
“negotiation” – negotiate in the protocol or by system administrators? Agree
that this needs to be clarified in the document.
xv.
Automated Key
management – generating fresh session keys is beyond the scope of the current
draft. What is meant be session key here? Radius
is stateless. It does have
encrypted attributes; is the key
used to encrypt the attributes considered a session key? Every RADIUS message is
its own session, or need to establish a session outside of the radius protocol.
Need to clarify what the commenter is referring to, and clarify the current
baseline of requirements in the protocol. “Session”
key needs to be clarified. Strongly encourage talking directly with Pasi.
xvi.
Glen Zorn:
Another draft would have enabled RADIUS sessions (referring to a past draft,
authored by Glen)
xvii.
Avi Lior: what is
a transaction session? Access Request and several challenges?
xviii.
Joe Salowey:
Right now it is a request and response.
xix.
Compromise of
legacy shared secrets. The goal is
to provide security for enhanced ciphrsuites even in situations where the legacy
shared secret has been compromised.
However, this does not imply that the attacker “knows all secrets” (even secrets
for other more secure ciphersuites).
If that were true, then crypto-agility would be pointless.
It is merely required that compromise of the legacy shared secret not
enable compromise of the secrets for more secure ciphersuites.
xx.
Chair: We need to
articulate the transition model.
Let’s assume we start out with legacy RADIUS clients ands ervers.
We first upgrade the RADIUS servers to enable crypto-agile operation.
Then the RADIUS clients are upgraded over time.
After all the RADIUS clients are upgraded, use of legacy ciphersuites is
no longer allowed. We need to
assume that the transition is completed prior to the point at which an attacker
can forge RADIUS packets at will.
We also need to assume basic RADIUS hygene – each RADIUS client has a unique
legacy shared secret of sufficient strength.
If these assumptions are true, then during th transition period, we can
provide security, either by implementing RADIUS server policy (e.g. require
upgraded RADIUS clients to utilize upgraded ciphersuites) or via “negotiation”
protected by MD5 and the legacy shared secret. don’t allow the legacy systems.
After forgery becomes possible, RADIUS
servers can no longer allow use of legacy ciphersuites, since this would enable
a “bidding down” attack. We need to
clarify the transition model in the document.
xxi.
Operational model
– do we mean operations and management?
Probably means the same thing as in the RADIUS Design Guidelines
document.
xxii.
What is a RADIUS
service – what type of proposals would this definition allow/disqualify?
xxiii.
Plan –
incorporate changes discussed so far, submit to Pasi for review.
10. RADSEC, Stefan Winter http://tools.ietf.org/html/draft-ietf-radext-radsec
-
The document is now in its fourth
revision, fixed comments from first WGLC.
-
Now have additional comments on the list
from Joe Salowey. Clarify TLS-PSK and identifier field. Could use IP
address as identifier for backward compatibility.
Clarify this in the draft.
-
Joe: This will partially address the
comment. Identity of the NAS is bound to an IP address. We have the
opportunity to change that – e.g. the NAS is identified some other way.
That is a good thing – IP addresses behind NATs. But potential security
and operational security. Need discussion of this in the draft.
-
Concern – mixing TLS layer and RADIUS
layer information. Can we assume
that a RADIUS is integrated with TLS? We need this assumption if we are
to permit a RADSEC implementation to utilize a NULL shared secret.
-
Would it be mandatory to verify an
identity at the TLS layer? If applying policy at those layers, we then
need to verify. Need more discussion on this.
-
Allan: If attacker can force a server to
complete TLS authentication then there is a DoS issue, since this would
require a public key operation.
-
Glen: “you can call it anything” is not
helpful. Guidance would be helpful, identifier fields should not be free
form.
-
Joe: You have to create entries in a
database – what is the NAS identifier? Right now it is the RADIUS client
IPv4/IPv6 address for the purposes of shared secret verification.
The draft is introducing new possibilities such as certificate
information. Need guidelines.
-
Comment: Certificates on NAS entities
may be used for additional purposes.
-
Comment: Describe possible scenarios in
the draft. Outline a subset of what everyone should support for a
minimal level of interoperability.
-
Chair: The use of unique credentials
impacts security. If credentials aren’t unique then one NAS can
impersonate another NAS. Various
documents describe the need for a first hop proxy to check the NAS
Identifying attributes (NAS-IP-Address, NAS-IPv6-Address) against the
packet source address. Those
checks are still needed. So the
document needs to somehow relate NAS Identities utilized in RADSEC to
NAS Identification attributes within the RADIUS packet.
-
Authors: Agree that there should be
guidelines. Need recommendations for what is minimally supported.
Author will draft text for this
-
Comment on shared secret: How is legacy
radius processing handled with message authentication? RADIUS processing
is the same. Can use/tolerate a null shared secret in some cases. Need
text to describe this. Has to know that there is a protocol underneath.
Clarify this in the text.
-
Should we include discussion of TLS &
DTLS in one document? Have had discussions on how this could be done.
Having both entirely in one document might slow down the process.
Proposal: Put DTLS specific
items in Alan’s document on DTLS.
-
Main issue with DTLS is effectively
building a connection over UDP. None of RADIUS servers handle
connections in UDP. In a server that accepts DTLS, application needs to
keep track of source/port info. 2 pages of text on this, not relevant to
radsec, transport related.
-
DTLS has some unique implementation
aspects, due to running RADIUS and DTLS on the same port. Would be
useful to have a separate draft to address these and other unique
issues, then see what we still need to cover.
It can be assumed that many of the implementation issues with
DTLS will be the same as with RADSEC.
-
Allan will rev his DTLS document.
-
Tim Polk: Question for the room –
integration of RADIUS and transmission layer security.
How widely supported is this? If omission of a shared secret is
allowed this is only allowed as long as the RADIUS implementation can
know that transmission layer security is in place (e.g. RADIUS is
protected by TLS/DTLS/IPsec). Is
this typically supported?
-
Chair: If
use of a NULL shared secret is to be allowed, then the RADIUS
implementation must be aware that transmission layer security is in use.
This is part of the transition issue that Pasi identified, discussed
earlier.
-
Comment:
Existing RADIUS implementations are not necessarily aware of
transmission layer security.
Once the RADIUS packet is delivered by TLS/DTLS and handed to the RADIUS
implementation, the RADIUS implementation may or may not behave
differently. RFC 2865 does not
allow use of a pre-defined shared secret, and existing implementations
may also not allow this. In
order to prevent a bidding down attack, the RADIUS layer needs to know
that transmission layer security is in use.
-
Using TLS Key export to create the
shared secret could eliminate the concern.
Need to discover this
capability.
-
Exporting the property that you have TLS
– plan to do this.
-
Another issue on the list – issue 308–
certificate handling. When is it acceptable to not validate the
certificate? Should go to a different document. Is there a URL that
would be useful for RADIUS. Seems strange to add URL if we don’t know
how it will be used. Used to point to URNs. Don’t think we need to
standardize. Would do stringmatch. Rules for URL?
-
AM TCP
Transport, Alan DeKok
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport
-
Review from Alfred Hoenes.
-
Bare TCP (Unprotected RADIUS over a TCP
connection) is not recommended. However, RADIUS over TCP protected by
TLS or IPSEC is ok.
-
There are issues with proxies handling
reliable and non-reliable transports. For
example a proxy receiving packets over UDP and sending over TCP might
find that the rate of incoming packets is greater than the rate at which
it can send packets. Unless the
RADIUS client implements backoff (e.g. RFC 5080) there may not be a way
for the proxy to provide “back pressure” upstream to slow down the rate
of incoming packets.
-
Notes on large UDP packets. Issue seen
in eduroam. 802.1X over the Ethernet – 2K radius packets, fragments
dropped. Using TCP to transport RADIUS packets > MTU addresses this.
However, the sender still can’t assume that the RADIUS server can
handle packets larger than 4096.
-
Chair: Are outstanding issues resolved?
Several were first brought up by the Transport Area Director (Magnus) so
they need to be resolved prior to submission of the document to the
IESG. Alan will check. Believe that most are resolved, will incorporate
text.
-
RADIUS attributes for IPv6 Access Networks,
Benoit Lourdelet
http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access
-
Chair: Document is currently in review
for acceptance as a WG work item.
Only one review so far, which indicates that the document is not
yet ready. Please review the
document and send comments to the list!
-
Problem statement – RFC3162 needs
additions to accommodate IPv6 production networks. Feedback is coming in
from actual deployments. Need flexibility.
-
IPv6 DNS location needs to be configured
on a subscriber basis – wholesale, VPN.
-
Implementation can happen in DHCP and
SLAAC.
-
Review of requirements – individual IPv6
addresses must be offered to the subscriber as concatenation of prefix
and interface id attributes does not cover all cases.
-
More specific routes should be
transmitted to the subscriber – multi-homing, multiple attachments – see
draft-dec-dhcpv6-route-option-01.
-
Prefix lifetimes must be configured on a
prefix basis.
-
Glen Zorn: New attributes should be
added – No objection to do this from the WG.
-
Discussion on NAI-based Dynamic Peer
Discovery, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-winter-dynamic-discovery
-
Chair:
This document is also in review for acceptance as a WG work item.
So far, no comments have been posted.
Please read this document and send your opinions to the list!
-
Several open issues. Document describes
DNS lookup but not all NAIs necessarily have corresponding DNS domains.
For example, it is possible for an NAI to not have a realm
portion. The document has been
discussed in previous IETF meetings. When doing a DNS lookup, the query
needs to be correctly encoded.
This implies keeping track of both the original encoding and the
punycode-encoded version. This
is not very user friendly. Need to discuss.
-
Bernard: the NAI need not have a realm.
If it does have a realm, then this would need to be converted to
punycode prior to enclosure in a DNS query that goes over the Internet.
However, the conversion can fail – for example, the realm might include
characters that are not permitted within an FQDN under IDNA.
Note that the valid characters have changed between the original
IDNA RFC (3490) and IDNAbis. So
even if the punycode conversion succeeds under an RFC 3490 ToASCII()
implementation, it is possible that the realm might still not be valid
under IDNAbis. Since the RADIUS
User-Name attribute is 8-bit clean, and both EAP and PPP are also 8-bit
clean, it is possible for any characters to be transported within it.
Therefore many implementations treat the NAI like an opaque blob
(and this is a sensible to do).
However, the realm portion of the opaque blob might not necessarily be
encoded in UTF-8 (as is often done in existing implementations) or
punycode (as advocated in RFC 4282, but rarely implemented).
For example, Windows implementations may utilize an ANSI code
page to encode the EAP-Response/Identity, rather than UTF-8.
So what do we do with internationalized realms?
Today, users have usernames and
realm encoded in a variety of ways – and as long as the user and RADIUS
server encode the NAI in the same way, things work.
However, once the RADIUS server
attempts to issue a DNS query, things can break.
Maybe the realm is encoded in an ANSI code page rather than
UTF-8. Can the RADIUS server
figure this out and convert it to UTF-8?
Maybe the realm name is encoded in UTF-8, but ToASCII() fails.
Maybe ToASCII() succeeds, but the DNS RR isn’t encoded in
punycode so the lookup fails (Windows DNS server encodes
internationalized RRs in UTF-8 instead of punycode).
If the RADIUS exchange is protected by certificates
(e.g. TLS/DTLS or IPsec) then the subjectAltName in the
certificate better be encoded in correctly, or we could even have a
problem authenticating the RADIUS exchange!
-
Will an NAI realm always have “the”
associated AAA server? What about special purpose AAA servers for
specific uses? Pre-pend “euduroam”. Could use underscore constructs
also.
-
Register NAPTR “AAAS+RADSECT” value. How
do NAPTR registrations work? Hannes will forward information.
-
Chair; have we covered all the bases
here? Can we handle RADIUS over
DTLS/UDP? RADIUS over TCP over
IPsec? Check to make sure all possibilities are listed.
If have multiple transports, how
do we indicate a preference?
14. RADIUS PKMv1 attributes, Glen Zorn (10 minutes). http://tools.ietf.org/html/draft-zorn-radius-pkmv1
a. Chair: Comments on this document were solicited from IEEE 802.16 and WiMAX Forum. WiMAX Forum indicated that they were only utilizing PKMv2 (mobile operation), so that the document was not relevant to them. IEEE 802.16 indicated that they did not have comments on the document, and that unlike IEEE 802.1, they did not want to be active in developing RADIUS support for IEEE 802.16.
b. Question: Do implementations of this document utilize standard RADIUS attributes or VSAs?
c. Glen Zorn: They utilize standard RADIUS attributes.
d. Question: which ones? Don’t these conflict with existing attributes?
e. Glen Zorn: Yes, existing implementations have utilized attributes within the Experimental RADIUS attribute space. However, the implementers are willing to change to standard attributes, but are not interested in utilizing VSAs. Since IEEE 802 was not interested in the document, it would not be possible to allocate VSAs from the IEEE 802 VSA space.
f. Dan Romascanu: I am willing to sponsor this document for publication as Informational RFC, provided that it is reviewed by the RADEXT WG.
g. Chair: The RADEXT WG can review this document from the perspective of compliance to the RADIUS Design Guidelines. Since there was insufficient interest from IEEE 802.16 or WiMAX Forum, we cannot review it from an IEEE 802.16 perspective.
15. RADIUS Confidentiality, Glen Zorn (10 minutes), http://tools.ietf.org/html/draft-zorn-radius-encattr
a. Glen Zorn: This document has not changed in a long time.
b. Chair: Dan Harkins reviewed the most recently version of the document (see http://ops.ietf.org/lists/radiusext/2009/msg00142.html, Issue 305). Were responses to the review incorporated?
c. Glen Zorn: The comments were ignored.
d. Chair: The process for taking on WG work items requires comments to be responded to.
e. Glen Zorn: In general, it would help if comments suggested new text. I’m not an expert on SIV, for example, so I can’t write text to integrate this by myself.
16. Prefix Authorization, Behcet Sarikaya (10 minutes), http://tools.ietf.org/html/draft-sarikaya-radext-prefix-authorization
a. Presenter was not available in the room or on Jabber.
b. Is there still interest in making this presentation? Not clear.
Meeting adjourned.