Issue 300: Attribute Usage
Submitter name: Bernard Aboba
Submitter email address: Bernard_Aboba@hotmail.com
Date first submitted: December 30, 2008
Reference: http://ops.ietf.org/lists/radiusext/2009/msg00020.html
Document:
DESIGN
Comment type: T
Priority: S
Section: 1, Appendix B
Rationale/Explanation of issue:
In order to characterize current attribute usage, both the basic and complex data types defined in the existing RADIUS RFCs are reviewed, together with the ad-hoc extensions to that data model that have been used in Vendor-Specific Attributes.
IMHO, we should avoid discussing ad-hoc extensions to VSA's. They are either horrible (as noted before), or simply new data types. The new data types aren't compatible with traditional RADIUS, but if the SDOs want them for their own specifications, that's fine. > Either the document needs to add material relating to ad-hoc extensions, > or this > portion of the sentence needs to be removed. That portion of the sentence needs to be removed.
Proposed Resolution: Accept
Issue 301: Data Type Advice
Submitter name: Bernard Aboba
Submitter email address: Bernard_Aboba@hotmail.com
Date first submitted: December 30, 2008
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00012.html
Document:
DESIGN
Comment type: Technical
Priority: S
Section: Appendix A 1.1
Rationale/Explanation of issue:
Does the data fit within the existing RADIUS data model, as outlined below? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS attribute, or in a [RFC2865] format RADIUS VSA.As noted in an earlier issue, Appendix B does not cover data types utilized within RADIUS VSAs,
Does the data fit within the RADIUS standard attribute data model, as outlined below? If so, it MAY be encapsulated either in a [RFC2865] format RADIUS attribute, or in a [RFC2865] format RADIUS VSA.Assuming that the promised survey of ad-hoc data model extensions is actually included in the
Does the data fit utilize ad-hoc extensions to the RADIUS data model, as outlined in below? If so, it SHOULD be encapsulated in a RADIUS VSA or an Extended Attribute [EXTENDED].
Proposed Resolution: Discuss
Issue 302: Extended Attributes
Dependency
Submitter name: Bernard Aboba
Submitter email address: Bernard_Aboba@hotmail.com
Date first submitted: December 30, 2008
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00016.html
Document: DESIGN
Comment type: T
Priority: S
Section: A 1.2
Rationale/Explanation of issue:
Where possible, the data types defined above in Section A.1.1 SHOULD
be used. The extended data types defined in [EXTEN] SHOULD be used
only where there is no clear method of expressing the data using
existing types.
Does the data fit within the extended RADIUS data model, as outlined
below? If so, it SHOULD be encapsulated in a [EXTEN] format RADIUS
VSA.
* Attributes grouped into a logical container.
This does not include nested groups.
* Attributes requiring the transport of more than 247 octets of
Text or String data. This includes the opaque encapsulation
of data structures defined outside of RADIUS. See also Section
A.1.3, below.
This text includes normative statements relating to the Extended
Attributes document, and yet [EXTEN] is only listed as an
Informative reference. Either a normative reference needs to be
added, or this section needs to be removed.
[Alan DeKok]
I suggest adding [EXTEN] as a normative reference.
Proposed Resolution: Accept
Issue 303: Review
Submitter name: Pasi Eronen
Submitter email address: Pasi.Eronen@nokia.com
Date first submitted: February 18, 2009
Reference: http://ops.ietf.org/lists/radiusext/2009/msg00086.html
Document:
Crypto-agility
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
At Dan Romascanu's request, I've taken an early look at draft-ietf- radext-crypto-agility-requirements-01. This was probably a good idea from Dan, since if I had sent a DISCUSS this long at IESG evaluation time, the WG might have (somewhat justifiably) suggested doing some rubber-hose discuss clearing on a dark San Francisco back alley :-) Overall comment: Currently, much of the text in this draft seems to be open to multiple interpretations. It's possible that the WG members agree on the interpretation (but it's also possible that they only *think* they agree...), but someone who hasn't participated in the WG discussions will be somewhat confused. Personally, I'm not really a big fan of requirements RFCs (and would rather spend the energy in getting the solutions right)... but the AAA space certainly has some history of requirements open to multiple interpretations (including the infamous "Housley criteria" that became RFC 4962), and a special branch of hermeneutics devoted to interpreting them in ways that were not always very productive :-) [and BTW -- I've certainly done some of that myself...] The outcome I'd really like to avoid is having IESG first approve these requirements, and then getting a solution draft that in WG's opinion meets the requiremnts, but is very different from how IESG understood the requirements. So, the main intent of the remaining comments is reducing the likelihood of this happening. Hop-by-hop/end-to-end: The document currently considers only "hop-by-hop" security mechanisms, not any "end-to-end" protection (across proxies). I think this is OK and perfectly reasonable -- but the document should say this, and explain what this means for interpreting RFC 4962 Much of RFC 4962 is open to multiple interpretations, and some parts of it can be read as requiring more than hop-by-hop security. IMHO exactly the same parts can also be read as saying hop-by-hop can be sufficient (when done properly), and I think this document should explicitly say it's interpreting 4962 the latter way. (And once the document has this explanation, you might want to run it by some other ADs, too -- e.g. Tim and Russ) Forward secrecy: Sometimes RADIUS is used to deliver keys (like EAP MSK) that will be used (perhaps indirectly via additional key derivation steps) to encrypt information that may be valuable for a long time. Given this, the document needs some discussion about "forward secrecy" (whether revealing the long-term credential allows decrypting all past communications), and if the conclusion is that crypto-agility solutions don't need to support forward secrecy (even as optional-to-use feature), explain the rationale behind this conclusion. Authentication/long-term credentials: Authenticating the RADIUS client and server will require (manual) configuration of some kinds of credentials (currently, the RADIUS shared secret). The document should say something about what kinds of long-term authentication credentials (for RADIUS entities) the crypto-agility solutions are expected to support. Presumably, they MUST support pair-wise shared secrets. Other possibilities for long-term credentials could include e.g. X.509 certificates with PKI, public keys without certification infrastructure (generate keypair + configure fingerprint of peer's key), or Kerberos. Even if the conclusion is that nothing else than pairwise shared secrets is needed, that should be said in the document (with rationale explaining why). Replay protection: Section 4.2 says "Proposals MUST support replay protection. The existing mechanisms for replay protection are considered adequate and should be maintained." I think the latter sentence needs some clarification. If the intent is to say replay protection provided by the current mechanisms (i.e., basically none for Access-Request messages) is good enough, I would disagree with that (or at least would expect to see an explanation why that's the case for Access-Requests). If the intent is something else, the text needs to be clearer. Meaning of negotiation: The document says proposals MUST support negotiation of cryptographic algorithms. Does "negotiation" here mean picking which algorithm to use in the protocol (RADIUS client and server figure out an algorithm supported by both of them), or would negotiation between system administrators meet this requirement? I assume the WG has rough consensus about what this means, and ordinarily, I would have automatically assumed it's the former. But some earlier proposals in this space have supported only the latter kind (which does provide some kind of algorithm agility -- it's better than hardcoding MD5 -- but could mean synchronized manual work for every transition)... Automated Key Management: Well... RADIUS certainly requires only O(n) keys, but on the other hand, the amount of data encrypted with a single key is not necessarily small (when considering the "value of the data" and time aspects -- in terms of gigabytes, it's probably small compared to what decent algorithms can handle). And if you anyway support negotiating the algorithms (in the protocol), generating a fresh session key may not be that much extra effort, and may be needed anyway since the key can depend on the selected algorithm (if you negotiate 256-bit AES, you need a 256-bit key; if it's 3DES, 168 bits, etc.). And the solutions should avoid using the same cryptographic key with multiple algorithms (and the easiest way to ensure this would probably be fresh session keys). Generating a fresh session key probably also simplifies replay protection (it's the obvious time to e.g. reset counters to zero), but other approaches to replays are certainly feasible. And obviously, forward secrecy and supporting any other types of long-term credentials than shared secrets requires automated key management of some kind. So, I think the conclusion here needs at the very least some qualification and additional explanation. *If* a solution not supporting forward secrecy and not supporting other types of credentials is acceptable, *and* replay protection is solved in certain way, *and* the solution can ensure that the negotiated algorithms get keys appropriate for them, *and* the solution can ensure that two algorithms don't use the same key, then you might get away with no AKM. But even then, AKM might be less work. Compromise of legacy shared secret: Section 4.2 says "Crypto-agility solutions MUST avoid security compromise, even in situations where the existing cryptographic algorithms utilized by RADIUS implementations are shown to be weak enough to provide little or no security (e.g. in event of compromise of the legacy RADIUS shared secret). Included in this would be protection against bidding down attacks." If interpreted literally, this requirement could be very difficult to meet (perhaps impossible). It seems to assume that for this particular peer, the administrator has configured two different shared secrets (one for the current security mechanisms, another for the new ones), but has not configured whether to use the old or new mechanisms (with this particular peer), and instead, that is negotiated somehow. If the attacker knows the legacy shared secret, and has complete control over the communication channel (and in particular, can drop messages going from A to B), then it seems the attacker will be indistinguishable from a valid peer that supports only the legacy mechanisms (and does not know the new shared secret), and detecting bidding down will not be possible. Preventing bidding down in less extreme cases of compromise is of course both possible and desirable (e.g. if the algorithms are just weak but not breakable in real time, or if the attacker doesn't have complete control over the communications). And the administrator could always configure just the "new shared secret", if he/she knows that the peer supports it. Backward compatibility/negotiation: Section 4.3 says "Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, a crypto-agility solution needs to be able to send packets that a legacy RADIUS client or server will receive and process successfully. Similarly, a crypto-agility solution needs to be capable of receiving and processing packets from a legacy RADIUS client or server." The intent of this paragraph is probably right, but currently, it's somewhat open to multiple interpretations. Would something like this capture the intent? "Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both the crypto-agility solution and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms). Acceptable solutions to determining which set of mechanisms is used (with a particular peer) include some kind of negotiation, and manual configuration." Note that *not* meeting this requirement would actually be quite difficult... if the intent of this paragraph was to require some kind of negotiation (interpreted loosely -- anything more automatic than manual configuration), the text should say so. "Operational model"? Section 4.3 says "Crypto-agility solutions SHOULD NOT require changes to the RADIUS operational model, such as the introduction of new commands or maintenance of [additional] state on the RADIUS server." I'm not sure what "operational" means here -- at first I thought it might mean "operations and management" (so the requirement would be basically "SHOULD not complicate life for administrators"), but the two examples given don't seem to fit that very well. And it seems any solution that e.g. derives fresh session keys will involve some small (but greater than zero) amount of additional state on clients and servers. If the intent was really operations and management, perhaps the should be rephased something like "When using long-term shared secrets for authentication, crypto-agility solutions SHOULD NOT require more operations and management work than the current solutions." "RADIUS service?" Section 4.3 says "For example, proposals SHOULD NOT [..] include definition of new RADIUS services." What's a RADIUS service -- i.e. what types of proposals this definition would disqualify? (In RFC 2865, "service" is defined as the service provided by the NAS to the user, but that definition doesn't seem applicable here.)
[David Nelson]
> The outcome I'd really like to avoid is having IESG first approve > these requirements, and then getting a solution draft that in WG's > opinion meets the requiremnts, but is very different from how IESG > understood the requirements. So, the main intent of the remaining > comments is reducing the likelihood of this happening. Exactly! I can propose some text to resolve the editorial issues -- lack of clarity because of poor wording. I'll need assistance from the WG in resolving the substantive issues, such as whether RADIUS should have a true negotiation mechanism for cipher-suites and whether RADIUS needs forward secrecy or to be retrofitted with Automated Key Management. WG members, please comment on the issues that Pasi has raised in his review, ASAP. If we get some good discussion going, we could have a -02 version of the draft prior to IETF 74 (coming up real soon now).
Proposed Resolution: Discuss
Issue 304: Comments on Design
Guidelines
Submitter name: Bernard Aboba
Submitter email address: bernard_aboba@hotmail.com
Date first submitted: February 25, 2009
Reference: http://ops.ietf.org/lists/radiusext/2009/msg00099.html
Document:
DESIGN-06
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's
Legal
Provisions Relating to IETF Documents in effect on the date
of
publication of this document
(http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe
your rights
and restrictions with respect to this document.
This document includes quotes from pre-5738 RFCs. Should we be
using
the new "pre-5738" boilerplate?
It is RECOMMENDED that SDOs and vendors seek review of
RADIUS
attribute specifications from the IETF. However, when
specifications
are SDO specific, re-use existing data types, and follow
these
guidelines, they do not require IETF review.
. . .
The advice in this document applies to attributes used to
encode
service-provisioning or authentication data. RADIUS
protocol
changes, or specification of attributes (such as
Service-Type) that
can be used to, in effect, provide new RADIUS commands
require
greater expertise and deeper review, as do changes to the
RADIUS
operational model, as described in Section 3.3 . Such
changes SHOULD
NOT be undertaken outside the IETF and when handled within
the IETF
require "IETF Consensus" for adoption, as noted in
[RFC3575] Section
2.1.
This would seem to suggest that support for new authentication
mechanisms
can be standardized outside the IETF, as long as the guidelines are
followed.
Also, the use of SHOULD NOT implies that there are circumstances in
which
protocol changes or new commands can be standardized outside the IETF.
Is
this what was intended?
Note that the Vendor type field in the recommended VSA
format is only
a single octet, like the RADIUS type field. While
this limitation
results in an efficient encoding, there are situations in
which a
vendor or SDO will eventually wish to define more than 255
attributes. Also, an SDO can be comprised of multiple
subgroups,
each of whom can desire autonomy over the definition of
attributes
within their group. In such a situation, a 16-bit
Vendor type field
would be more appropriate:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type |
Length
|
Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id
(cont)
| Vendor
type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor length | Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If additional functionality is required, the format defined
in
[EXTEN] SHOULD be used.
Since [EXTEN] defines extensions to the standard RADIUS attribute
space and this section is talking about VSAs, the reference is a bit
confusing. Is the intent to suggest that VSAs other than type 0
can also use the [EXTEN] format?
As a last resort, where
the above techniques cannot
be made to work, it may be possible
to apply the techniques
described in [RFC4821] to discovery the
maximum supported RADIUS
packet size on the path between a
RADIUS client and a home
server.
s/discovery/discover/
Even though the type is Text, the rest of the description
indicates
that it is a complex attribute:
Since accounting data is typically only written to stable storage
without
examination, does the reasoning against complex attributes really apply
here?
Proposed Resolution: Discuss
Issue 305: Review
Submitter name: Dan Harkins
Submitter email address: dharkins@lounge.org
Date first submitted: March 16, 2009
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00142.html
Document:
draft-zorn-radius-encattr-15
Comment type: Techical
Priority: S
Section: Various
Rationale/Explanation of issue:
I just read draft-zorn-radius-encattr-15 and have a few comments.
- an appendix showing at least two examples (with nice
ASCII art figures too!) would be most helpful.
- apparently there is a requirement (unstated) to support
encryption of random data as well as key wrapping, and to
be able to authenticate encrypted data. To do this the
draft mandates AES-CBC-128 (for encryption of arbitrary
data), AES Key Wrap (for key wrapping), and HMAC-SHA1 to
integrity check the encrypted data and the rest of the
message.
These three tasks could be accomplished by one single
cipher mode: SIV. SIV can do authentication encryption
with associated data of arbitrary-sized plaintext when a
nonce is included in its input, or do deterministic key
wrapping when a component of the plaintext contains a
random key.
Furthermore, there seems to be a desire to integrity check
a message that does not have any encrypted components. To
satifsy this requirement (also unstated) the draft mandates
HMAC-SHA1 instead of AES-CMAC.
If the draft mandated support for AES-SIV-CMAC to do
authenticated encryption (with associated data!) and
AES-CMAC for encryption-less integrity protection then
it can be implemented with a single primitive. Since
AES-SIV-CMAC itself uses AES-CMAC you get it for free.
Then the draft could build upon a single foundation and
its security would be based on the assumption that AES
is a secure pseudo-random permutation (which I believe
is the basis for the proof of both AES-CMAC and AES-SIV).
I recommend the mandatory-to-implement encryption algorithm
be AES-SIV-CMAC and the mandatory to implement integrity
check (when encryption is not used) be AES-CMAC.
- 3.5 says that "Applications using [Key-Liftime] SHOULD
consider the beginning of the lifetime to be the point
in time when the key is first used." Why not when it was
first exponsed (albeit encrypted)? If there is going to
be a recommendation I think it would help if there's some
reasoning to go along with it, otherwise just get rid of
the recommendation.
- 3.6 says, "If the data encapsulated in the Encrypted-Data
TLV represents a cryptographic key and the algorithm
specified by the Encryption-Type TLV requires the use of
an initialization vector (IV), this TLV may be used to
communicate the IV from the RADIUS server to its client."
Actually, if the encryption algorithm is AES-CBC then this
TLV is needed whether the data being encrypted is a key or
not. I think it would be better to say, "If the encryption
algorithm specified by the Encryption-Type TLV requires an
IV or the data being protected is not a key then this TLV
may be used to communicate the IV from the RADIUS server
to its client."
Also it MAY be appropriate to use "MAY" instead of "may".
- 3.7, the "algorithms" in this section might be a nice place
to mention that AES Key Wrap operates on blocks of 64-bits
even though the block cipher on which it is based operates
on 128-bit blocks.
The input of AES-SIV-CMAC includes associated data so the
two "algorithms", send and receive, should include mention
of this fact right after they mention an IV.
- 3.8, the description should mandate this TLV is also required
for encryption algorithms that do not produce authenticated
ciphertext, like AES-CBC.
- 3.8.1.1 "...the value of the MAC field is a hash..." What
about when using AES-CMAC? Does that produce a hash too?
Perhaps "output from a pseudo-random function" would be better.
- in 3.8.1.1 MAC=MAC-ALG(x,y) while in 3.8.1.2 MAC=HASH-ALG(x,y).
How about calling making it more generic: MAC=PRF(x,y)?
- 3.8.2, what about when using AES-SIV? The RFC 5116 interface
is mentioned in 3.1 and that produces an authenticating tag
concatenated with encrypted plaintext as a single "ciphertext"
output. So when AES-SIV is used should the Message-Authentication-
Code attributes signify individual components of AAD (since
SIV can take a vector of inputs and not just a single concatenated
input)? I think using an Encryption-Type TLV with NULL encryption
to accomodate traditional RADIUS attributes is wrong, it will also
screw up AES-SIV since AES-SIV will expect an Encryption-Type TLV
somewhere that says AES-SIV as the type. It would be better to
define an Envelope TLV to contain traditional RADIUS attributes.
- 3.8.2: doesn't CMAC-AES return 16 bytes?
- 3.9, what's the point of the MAC-Randomizer? In the case of key
wrapping semantic security is achieved because a component of
the plaintext is a key. In the case of non-key wrapping encryption
semantic security is achieved by the IV. In the case of an
unencrypted message I don't see the need for a MAC-Randomizer.
If I'm missing something then I'd wager some other people are too
and a justification is in order.
- 6, what's "the strength of the algorithm used" if that algorithm
is HMAC-SHA1?
Proposed Resolution: Discuss
Issue 306: NAS Identity
Submitter name: Joseph Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted: March 26, 2009
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00154.html
Document:
draft-ietf-radext-radsec-04
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Current RADIUS specs the NAS identity is tightly coupled with IP
address
because this is how the shared secret is referenced. With new
modes of
authentication it seems that the identity need not be tied to IP
address anymore. This could help with dynamic addressing and
NATS.
Requested change:
Discuss in the document that the NAS can be identified by something
other than source IP address.
[Stefan Winter]
This is a proposed new section 2.3 to cover issue "NAS Identity": Please comment... 2.3. Connecting Client Identity In RADIUS, clients are uniquely identified by their IP address. This does not permit to determine whether the connecting entity is a NAS or a different server which proxies a request. When NAT is used on the path to the server, it also does not permit to determine whether there is more than one entity connecting from the same IP address. RADIUS over TLS makes it possible to preserve this traditional RADIUS semantics by identifying a connecting client by the IP address which initiated the TLS connection. In addition, it does permit a much more fine-grained identification. The parameters of the TLS connection can be attributed to the RADIUS packets inside the TLS connection. An implementation of RADIUS over TLS should expose as many details of the TLS connection which belongs to an incoming RADIUS packet as possible to the application administrator to allow the administrator to define the identification criteria which are applicable to his desired operational model. In X.509 certificate operation, at least the following parameters of the TLS connection should be exposed: o Originating IP address o Certificate Fingerprint o Issuer o Subject o all X509v3 Extended Key Usage o all X509v3 Subject Alternative Name o all X509v3 Certificate Policies In TLS-PSK operation, at least the following parameters of the TLS connection should be exposed: o Originating IP address o TLS Identifier
Proposed Resolution: Discuss
Issue 307: RADSEC and DTLS docs
Submitter name: Joseph Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted: March 26, 2009
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00153.html
Document:
draft-ietf-radext-radsec-04
Comment type: T
Priority: 1
Section: Various
Rationale/Explanation of issue:
Many of the details between RADSEC and DTLS should be the same.
I'm
worried that the two specs may diverge if the progress differently
through the
IETF. Is there any reason why we cannot cover DTLS in this draft
as well?
Requested change:
Have the document cover DTLS.
Proposed Resolution: Discuss
Issue 308: RADSEC certificate
handling
Submitter name: Joseph Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted: March 26, 2009
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00152.html
Document:
draft-ietf-radext-radsec-04
Comment type: T
Priority: S
Section: 2.2
Rationale/Explanation of issue:
This connection setup and certificate handling section is improved, but I
think
it could still use some work.
Requested change:
1. The discussion of TLS cipher suites is broken apart into several
places in
the document, some of them normative and some of them informative.
I
believe the normative and informative information is reversed. The
implementation requirements for supported cipher suites should go in
this
section.
2. When is it acceptable not to validate the SRV entry in the
certificate?
3. The section should state that matching should be done against locally
configured names (as opposed to information retrieved from DNS).
4. Is there any particular URI type that would be useful for RADIUS?
[Stefan Winter]
Hi,
> Requested change:
>
> 1. The discussion of TLS cipher suites is broken apart into several
> places in the document, some of them normative and some of them
> informative. I believe the normative and informative information is
> reversed. The implementation requirements for supported cipher suites
> should go in this section.
>
Looking at the current text, the following is said in normative (2.2):
" * The client MUST NOT negotiate cipher suites which only provide
integrity protection.
* The TLS session MAY use mutual PSKs for connection setup.
* Negotiation of compression for the TLS session is OPTIONAL.
* RADIUS over TLS implementations MUST support the mandatory to
implement cipher suites specified in TLS (i.e.
TLS_RSA_WITH_3DES_EDE_CBC_SHA). For purposes of compatibility
with some current deployments implementations SHOULD support
TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as
well (see Section 3.2 (1) )."
The following is said in informative (3.2):
"3.2. Ciphersuites and Compression Negotiation Considerations
Not all TLS ciphersuites in [RFC5246] are supported by available TLS
tool kits, and licenses may be required in some cases. The existing
implementations of RADIUS over TLS use OpenSSL as cryptographic
backend, which supports all of the ciphersuites listed in the rules
in the normative section.
The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to-
implement according to [RFC5246] and thus has to be supported by
RADIUS over TLS nodes.
The two other ciphersuites in the normative section are widely
implemented in TLS toolkits and are considered good practice to
implement."
This text doesn't contain any additional requirements to be mentioned in
normative text IMO (note that the one named ciphersuite here is also
already mentioned in the normative part).
The security considerations section has some additional text:
" Some TLS ciphersuites only provide integrity validation of their
payload, and provide no encryption. This specification forbids the
use of such ciphersuites. Since the RADIUS payload's shared secret
is fixed and well-known, failure to comply with this requirement will
expose the entire datagram payload in plain text, including User-
Password, to intermediate IP nodes."
and the constraint mentioned in that section is reflected in the MUST in
the first bullet of the normative section already.
I am unsure what specifically should be changed here, and suggest to
leave the text as-is.
> 2. When is it acceptable not to validate the SRV entry in the
> certificate?
>
To formulate it positively: it *only* makes sense when DNS SRV
resolution was used to arrive at this TLS peer. In all other cases, the
a subjectAltName:SRV can be ignored. The current text doesn't contain
this latter sentence. I suggest to add that sentence.
> 3. The section should state that matching should be done against locally
> configured names (as opposed to information retrieved from DNS).
>
I have extended the sentence in that section:
Certificate validation MUST include the verification rules as per <xref
target="RFC5280" />, using information from trusted sources only (e.g.
locally configured names).
I hope that addresses the issue.
> 4. Is there any particular URI type that would be useful for RADIUS?
>
I don't think there is any RADIUS-global answer to this question. A
roaming consortium decides which X.509 certificate holders to trust. It
will determine the eligibility via *some* handle in the certificate. A
plausible candidate for subjectAltName:URI is a URL pointing to some
kind of consortium policy.
It is also thinkable that a consortium defines a specific certificate
policy statement for its CA(s), and uses the Policy OID field to point
to these policies. A peer would then check for the presence of this
policy OID.
It just seems prudent for an implementation to expose as many fields
from the incoming certificate as possible to the application layer, so
that an Administrator has a handle to check the incoming connection for
eligibility according to whatever policy is defined for the consortium.
The same text as earlier in the document should be applicable here:
In X.509 certificate operation, at least the following parameters of
the TLS connection should be exposed:
o Originating IP address
o Certificate Fingerprint
o Issuer
o Subject
o all X509v3 Extended Key Usage
o all X509v3 Subject Alternative Name
o all X509v3 Certificate Policies
In TLS-PSK operation, at least the following parameters of the TLS
connection should be exposed:
o Originating IP address
o TLS Identifier
(this is from my proposed text for NAS Identity Issue)
Would the proposed changes address your concerns?
Proposed Resolution: Discuss
Issue 309: Review
Submitter name: Bernard Aboba
Submitter email address: bernard_aboba@hotmail.com
Date first submitted: August 9, 2009
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00355.html
Document:
status-server
Comment type: technical
Priority: S
Section: Various
Rationale/Explanation of issue:
RFC 2865 defines a Status-Server code for use in RADIUS, but labels
it as "Experimental" without further discussion. This document
describes a practical use for the Status-Server packet code, which is
to let clients query the status of a RADIUS server. These queries,
and responses (if any) enable the client to make more informed
decisions. The result is a more stable, and more robust RADIUS
architecture.
How about something more along the lines of the RFC 5176 abstract?
This document describes a deployed extension to the Remote
Authentication Dial In User Service (RADIUS) protocol, enabling
clients to query the status of a RADIUS server. This extension
utilizes the Status-Server (12) Code, which was reserved for
experimental use in RFC 2865.
Section 1
The RADIUS Working Group was formed in 1995 to document the protocol
of the same name, and created a number of standards surrounding the
protocol. It also defined experimental commands within the protocol,
without elaborating further on the potential uses of those commands.
One of the commands so defined was Status-Server ([RFC2865] Section
3.).
This document describes how some current implementations are using
Status-Server packets as a method for querying the status of a RADIUS
server. These queries do not otherwise affect the normal operation
of a server, and do not result in any side effects other than perhaps
incrementing an internal packet counter.
These queries are not intended to implement the application-layer
watchdog messages described in [RFC3539] Section 3.4. That document
describes Authentication, Authorization, and Accounting (AAA)
protocols that run over reliable transports which handle
retransmissions internally. Since RADIUS runs over the User Datagram
Protocol (UDP) rather than Transport Control Protocol (TCP), the full
watchdog mechanism is not applicable here.
Not sure the history is necessarily correct (e.g. I believe that the RADIUS Working Group was formed earlier).
In any case, it is probably best to focus on the purpose of this document. How about this?
This document specifies a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling
clients to query the status of a RADIUS server. While the Status-Server Code (12) was defined as experimental in [RFC2865]
Section 3, details of the operation and potential uses of the Code were not provided.
As with the core RADIUS protocol, the Status-Server extension is stateless, and queries do not
otherwise affect the normal operation of a server, nor do they result in any side effects, other
than perhaps incrementing of an internal packet counter. Most of the implementations of
this extension have utilized it alongside implementations of RADIUS as defined in [RFC2865],
so that this document focuses solely on the use of this extension with UDP transport.
Network Access Server (NAS)
The device providing access to the network. Also known as the
Authenticator (in IEEE 802.1x terminology) or RADIUS client.
"x" -> "X"
Proxy Server
A RADIUS server that acts as a Home Server to the NAS, but in turn
proxies the request to another Proxy Server, or to a Home Server.
I am not sure that the use of the term "Home Server" here adds clarity. The definition of proxy from
RFC 2607 might be more applicable:
RADIUS proxy
In order to provide for the routing of RADIUS authentication and
accounting requests, a RADIUS proxy can be employed. To the NAS,
the RADIUS proxy appears to act as a RADIUS server, and to the
RADIUS server, the proxy appears to act as a RADIUS client.
1.1 Applicability
I think this document needs an applicability section, to explain potential differences between
this specification and existing implementations, as well as why it is being published as Informational,
as opposed to Experimental or Standards Track. Suggest the following:
1.1. Applicability
This protocol is being recommended for publication as an
Informational RFC rather than as a standards-track RFC because of
problems that cannot be fixed without creating incompatibilities with
deployed implementations. This includes security vulnerabilities.
While fixes are recommended, they cannot be made mandatory since
this would be incompatible with existing implementations.
Existing implementations of this protocol do not support the
Message-Authenticator attribute. This enables spoofing of
Status-Server packets. In order to remedy this problem,
this specification recommends the use of the Message-Authenticator
attribute to provide per-packet authentication and integrity
protection.
With existing implementations of this protocol, the potential
exists for Status-Server requests to be in conflict with Access-Request
or Accounting-Requests packets using the same Identifier. This
specification recommends techniques to avoid this problem.
[Add information on other issues here]
2. Problem Statement
It is often useful to know if a RADIUS server is alive and responding
to requests. The most accurate way to obtain this information is to
query the server via application protocol traffic, as other methods
are either less accurate, or cannot be performed remotely.
The reasons for wanting to know the status of a server are many. The
administrator may simply be curious if the server is responding, and
may not have access to NAS or traffic data that would give him that
information. The queries may also be performed automatically by a
NAS or proxy server, which is configured to send packets to a RADIUS
server, and where that server may not be responding. That is, while
[RFC2865] Section 2.6 indicates that sending Keep-Alives is harmful,
it may be useful to send "Are you Alive" queries to a server once it
has been marked "dead" due to prior unresponsiveness.
The occasional query to a "dead" server offers little additional load
on the network or server, and permits clients to more quickly
discover when the server returns to a responsive state. Overall,
status queries can be a useful part of the deployment of a RADIUS
server.
RFC 2865 Section 2.6 strongly discourages the use of keep-alives.
From reading this section, I am unclear whether the intent is to refute the
arguments made there, or to articulate how the uses of Status-Server
defined here go beyond those of the "test RADIUS request" described
in RFC 2865.
For example, unlike a RADIUS Access-Request, the Status-Server packet
cannot be forwarded, and therefore the lack of a response can only be
due either to packet loss or to a problem with the server to whom the
packet is sent. In contrast, an Access-Request might not be answered
because of a problem somewhere along the chain between the sender and
the RADIUS server. This difference allows the Status-Server packet to
be used as a diagnostic tool in ways that an Access-Request could not
be.
Overall, I wonder whether some of the introductory material in Section 4.3
might be removed from that section and instead be revised and presented
in this section. For example:
A common problem in RADIUS client implementations is the
implementation of a robust fail-over mechanism between proxies. A
client may have multiple proxies configured, with one proxy marked
as primary and another marked as secondary. If the client does
not receive a response to a request sent to the primary proxy,
it can "fail over" to the secondary, and send requests to the
secondary instead of to the primary proxy.
However, it is possible that the lack of a response to requests
sent to the primary proxy was due not to a failure within the
the primary, but to alternative causes such as a failed link
along the path to the destination server, or the failure of
a downstream proxy or server. In such a situation, it may
be useful for the client to be able to distinguish between
failure causes. For example, if the primary proxy is down,
then quick failover to the secondary proxy would be prudent,
whereas if a downstream failure is the cause, then the value
of failing over to a secondary proxy will depend on whether
packets forwarded by the secondary will utilize independent links,
intermediaries or destination servers.
Since the Status-Server packet is non-forwardable, lack of a
response may only be due to packet loss or the failure of
the server in the destination IP address, not due to faults
in downstream links, proxies or servers. It therefore
provides an unambiguous indication of the status of a
proxy or server.
Sections 2.1-2.2
I find these sections puzzling, because they suggest alternatives to the Status-Server packet
that do not serve the same function. Given that Status-Server packets are not forwardable,
they serve a different purpose than the "test RADIUS requests" which RFC 2865 recommends
against. Given this, talking about "alternatives" in these sections is somewhat confusing.
What might make more sense is to describe the function that Status-Server packets provide
and why this is not provided by alternatives such as the RADIUS Access-Request packet.
Section 2.3
Since the
packet is otherwise undefined, it does not cause interoperability
issues to create implementation-specific definitions for it. The
difficulty until now has been defining an interoperable method of
performing these queries.
While the Status-Server packet format was not defined in RFC 2865, it was implemented by Ascend and
other vendors. As far as I know, a number of deployments did use NAS and RADIUS servers from different
vendors so that "implementation-specific definitions" would indeed have resulted in interoperability
problems.
In any case, as I understand it, the goal of this work item is to document existing implementations of
the Status-Server extension, correct?
Section 2.3.1
Status-Server SHOULD be used instead of Access-Request to query the
responsiveness of a server. In this use case, the protocol exchange
between client and server is similar to the usual exchange of Access-
Request and Access-Accept, as shown below.
NAS RADIUS server
--- -------------
Status-Server/
Message-Authenticator ->
<- Access-Accept/
Reply-Message
The Status-Server packet MUST contain a Message-Authenticator
attribute for security. The response (if any) to a Status-Server
packet sent to an authentication port SHOULD be an Access-Accept
packet. Other response packet codes are NOT RECOMMENDED. The list
of attributes that are permitted in the Access-Accept packet is given
in the Table of Attributes in Section 6, below.
Given that the Status-Server packet is not forwardable, this section is a bit
confusing. Also, I'm not clear how useful the diagram is.
I'd suggest focusing on the basics of the exchange:
Status-Server Exchange
Status-Server packets are typically sent to the destination address and port
of a RADIUS server or proxy. A Message-Authenticator attribute SHOULD be
included so as to provide per-packet authentication and integrity protection.
A single Status-Server packet MUST be included within a UDP datagram. RADIUS
proxies MUST NOT forward Status-Server packets.
A RADIUS server or proxy implementing this specification SHOULD
respond to a Status-Server packet with an Access-Accept. Other response packet
codes (such as Access-Challenge or Access-Reject) are NOT RECOMMENDED. The
list of attributes that are permitted in Status-Server and Access-Accept
packets responding to Status-Server packets are provided in the Section 6.
BTW, I'm curious as to whether a Status-Server packet can be sent to the address
and port (3799) of a DAS, and if so, what the appropriate response is.
Section 2.3.2
The Status-Server packet MUST contain a Message-Authenticator
attribute for security.
Given that implementations exist that did not support Message-Authenticator, my suggestion is that this
become a SHOULD.
Section 3
This method
MUST be used to avoid conflicts between Status-Server and other
packet types.
Given that implementations exist that did not support this, my suggestion is that this
become a SHOULD as well.
In addition to the above requirements, all Status-Server packets MUST
include a Message-Authenticator attribute. Failure to do so would
mean that the packets could be trivially spoofed.
Suggest MUST -> SHOULD here.
Section 4.3When a client fails over from one server to another because of a lack of responsiveness, it SHOULD send periodic Status-Server packets to the unresponsive server, using the timer (Tw) defined above. [BA] Can you provide a section reference for the Tw timer? Once three time periods have passed where Status-Server packets have been sent and responded to, the server should be deemed responsive and RADIUS requests may sent to it again. This determination should be made separately for each server that the client has a relationship with. The same algorithm should be used for both authentication and accounting ports. The client MUST treat each destination (ip, port) combination as a unique server for the purposes of this determination. The above behavior is modelled after [RFC3539] Section 3.4.1. We note that if a reliable transport is used for RADIUS, then the algorithms specified in [RFC3539] MUST be used in preference to the ones given here. [BA] I think a bit more explanation would be helpful here. Traditional "failover" algorithms have depended on use of Access-Request packets. Unfortunately, these techniques can lead a client to failover in circumstances where there is nothing wrong with the primary proxy. So in reading the first paragraph, I'm unclear what is being advocated, precisely. For example, is it being advocated that a Status-Server packet be sent to the primary proxy after a number of Access-Requests do not receive a response? That would help determine whether the primary proxy was the issue in the first place. If it is not the issue (e.g. primary proxy responds), then sending Status-Server packets to the primary proxy would seem pointless. If the primary proxy is responding to Status-Server, then the problem must be downstream, and it might make sense for the client to continue to send Access-Requests for a while longer, under the assumption that those downstream elements are also attempting to diagnose the problem (possibly with Status-Server), so that in the meantime they might also fail-over, restoring end-to-end RADIUS connectivity. Based on the algorithms presented in RFC 5080, one might come up with some recommendations on how long the client might stick with the primary under the circumstance where it is responding to Status-Server packets. Assuming that a failure of the primary proxy is confirmed by Status-Server, then failing over to the secondary proxy quickly would seem to make sense. At this point, it would make sense to continue to send Status-Server packets to the primary to figure out when it comes up again. Section 4.4 The point that Status-Server packets are non-forwardable is quite central to the document, so it would be a good idea to make the point earlier. Section 4.5 4.5. Realm Routing RADIUS servers are commonly used in an environment where Network Access Identifiers (NAIs) are used as routing identifiers [RFC4282]. In this practice, the User-Name attribute is decorated with realm routing information, commonly in the format of "user@realm". Since a particular RADIUS server may act as a proxy for more than one realm, the mechanism outlined above may be inadequate. [BA] What mechanism? Since Status-Server packets are non-forwardable, there no concept of a destination realm, right? Overall, I think this section might be retitled "Limitations of Status-Server" because that is really the main focus. On reading this section, the thought did occur to me that in the cause where Status-Server indicated a downstream failure that "per-realm" failover might make sense. For example, if the primary could reach realm A but not B, there is no point in failing over all Requests to the secondary, just those for realm B. Of course, it is also possible that a fault in a downstream node that prevented reaching realm A (e.g. a failure in a server for realm A) might subsequently be corrected, so that realm A might become reachable again. Section 5 Recommend including a row for User-Name, which presumably would have all 0s in it (e.g. User-Name is not used in Status-Server packets, right?). What is the purpose of VSAs in Status-Server packets or Access-Responses?
Proposed Resolution: Discuss
Issue 310: Review
Submitter name: Bernard Aboba
Submitter email address: bernard_aboba@hotmail.com
Date first submitted: August 9, 2009
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00357.html
Document:
NAI-Discovery
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
This document specifies a means to find authoritative AAA servers for a given NAI realm as defined in [RFC4282]. It can be used in conjunction with RADIUS over TLS and RADIUS over DTLS. [BA] References aren't allowed in the abstract. Also, this is only about RADIUS, not AAA in general, no? 1.2 RadSec node: a RadSec client or server RadSec Client: a RadSec instance which initiates a new connection. RadSec Server: a RadSec instance which listens on a RadSec port and accepts new connections [BA] As we discussed at IETF 75, RadSec is a product name. Can we use "RADIUS over TLS" and "RADIUS over DTLS" (or maybe RAD-TLS and RAD-DTLS) instead? Section 2.1 Dynamic server discovery as defined in this document is only applicable for AAA transactions where a AAA server receives a request with a NAI realm for which no home AAA server is known. I.e. where static server configuration does not contain a known home authentication server, or where the server configuration explicitly states that the realm destination is to be looked up dynamically. Furthermore, it is only applicable for new user sessions, i.e. for the initial Access-Request. [BA] Is this about AAA in general (including Diameter) or just about RADIUS?
Bernard Aboba wrote: > [BA] As we discussed at IETF 75, RadSec is a product name. Can we use "RADIUS over TLS" and "RADIUS over DTLS" > (or maybe RAD-TLS and RAD-DTLS) instead? That's a reasonable idea. I can update the DTLS document to say this. > [BA] Given that RadSec is a product name, what should the SRV prefixes be? > _radtls._tcp? _raddtls._udp? I would say the latter two. However, _radsec._tcp SHOULD also be used for backwards compatibility. > This document contains no actions for IANA. Maybe. Not sure about > the labels "AAAS+RADSECT" and "_radsec._tcp.". > > [BA] What about RADIUS over DTLS? Does this document apply to that as well? I would suggest so, yes.
Proposed Resolution: Discuss
Issue 311: IESG DISCUSS comments
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: May 7, 2009
Reference:
https://datatracker.ietf.org/idtracker/ballot/2883/
Document:
Design-Guidelines
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
Jari Arkko: Discuss [2009-05-07]: Great doc! I will vote Yes on it, but I wanted to discuss two issues first, one is a Discuss-level problem and the other one a Comment that I'd like you to consider.
The first issue is that Section 2.3 suggests 16-bit vendor space
attribute number fields to replace the existing 8-bit recommendation.
There are a couple of problems with this. First, if you really mean
to change the recommendation, then Updates: RFC 2865 header in the
beginning of the document would have been appropriate.
Secondly, while I agree with the advice of going for 16 bits, the
document is silent on some of the issues involved in such a change,
such as:
- Does RADIUS dictionary software support the VSA format for 16 bits, 8
bits, or both?
- How do you cleanly print or report VSAs when you do not know if the
field size is 8 or 16 bits? I realize that this situation already
exists since the format was never required to be followed, but
your new recommendation makes a potential problem much more likely
to appear. Previously, you could print something like Vendor = ACME,
Code = 17, Contents = ABCDEF0011... Now you couldn't do that.
- Can a vendor who moved from 8 bits to 16 bits deal with this?
Comment [2009-05-07]:
I do agree that for functionality FOO, both the functionality itself
and the MIB, RADIUS, etc. work should take place in the same standards
body. However, Section 3.1 could have said a couple of additional things
as well:
The issues of attribute space and choice of forum are distinct; there
is no reason why IETF couldn't use its own vendor code, for instance.
The section also does not mention one of the potential drawbacks of
SDO-driven development model: it is easy to come up with a number of
different solutions to the same generic problem, as opposed to finding
a common solution.
Ralph Droms:
Comment [2009-04-20]:
Trivial: does the "text" data type include a trailing '\0' byte? I ask because
there has been confusion about this point in DHCP options and it might be good
to make the convention explicit.
Lars Eggert:
Comment [2009-04-20]:
Section 2.1.1, paragraph 2:
> The Length field in the RADIUS packet header is defined in [RFC2865]
> Section 3. It is noted there that the maximum length of a RADIUS
> packet is 4096 octets. As a result, attribute designers SHOULD NOT
> assume that a RADIUS implementation can successfully process RADIUS
> packets larger than 4096 octets.
You may want to point out that even with messages less than 4096 but
larger than the PMTU, persistent IP fragmentation will be incurred,
which makes communication much more brittle, and might even want to
suggest that therefore RADIUS messages should be kept as small as
possible. See RFC5405 Section 3.2.
Adrian Farrel:
Comment [2009-04-18]:
Trivial, but...
Section 2.1.1 says that some address data types are in "network
byte order" while others are "most significant octet first". Is there a reason
for this difference?
I wonder if the text in seciton 4 should be stronger. You have...
This document does not require that the IANA update any existing
registry or create any new registry, but includes information that
affects the IANA, for example:
* includes guidelines that recommend against allocation from the
RADIUS standard attribute space in other SDO RADIUS Attribute
specifications.
But, in fact, IANA are bound by the registry rules already laid down and cannot
make allocations except following IETF process as defined by RFC 3575.
Russ Housley:
Comment [2009-04-20]:
The Gen-ART Review by Gonzalo Camarillo on 8 April 2009 provides some
editorial suggestions.
ID nits complains that reference [8] appears in Appendix B.6 but not
in the References.
The Introduction Section should be a non-normative section. However,
Section 1.1 uses normative statements (RECOMMENDED and NOT
RECOMMENDED) before those terms are defined in Section 1.3.
The acronym AAA should be expanded.
When referring to the appendixes, I think the draft should talk about
appendixes, not about sections. For example, it should talk about
Appendix A.5, not about Section A.5.
Alexey Melnikov:
Comment [2009-04-21]:
This is a fine document. Some minor comments:
3.3. RADIUS Operational Model
The RADIUS operational model includes several assumptions:
* The RADIUS protocol is stateless;
* Provisioning of services is not possible within an
Access-Reject;
* Distinction between authorization checks and user
authentication;
* Authentication and integrity protection of RADIUS packets;
* The RADIUS protocol is a Request/Response protocol.
* Packet length restriction.
Half of this list is comprised from full sentences, the other half is not. I
would appreciate if you can make this consistent, otherwise it
is difficult to read/understand.
Tim Polk:
Comment [2009-05-06]:
It might be valuable to supplement the current security considerations section
with a discussion of issues that arise if SDOs do not follow the guidelines
presented here. For example, relying on MTU discovery to support transporting
large amounts of data could fail and result in denial of service, lost
accounting data, etc...
Robert Sparks:
Comment [2009-04-22]:
"the above procedure" in 3.1.1 (page 17) could be hard to follow for some
readers. Recommend providing a more explicit pointer.
[Jari Arkko]
Folks, is this statement is true - I am very concerned about this being ready to be a BCP. Was there a consensus call on this? Does the WG have consensus on this?
[Bernard Aboba]
From what I can tell, Section 3.2 does not make a recommendation on switching from an 8-bit to a 16-bit vendor-type format. It does describe situations in which an 8-bit vendor type field would be inadequate. As noted by Jari, there is a normative recommendation that RADIUS servers support a 16-bit vendor-type (presumably in addition to the 8-bit vendor type). IMHO, that normative recommendation would be more appropriate in the Extended Attributes document, which actually utilizes the 16-bit vendor type. > i.e. the overwhelming majority (> 95%) of the major and minor vendors find the RFC VSA format acceptable. Right. Almost all vendors use the 8-bit vendor-type. This should not be surprising since the issues described in Section 3.2 will typically apply more to SDOs than to vendors. But since the document doesn't recommend against use of the 8-bit vendor-type, this isn't an issue.
[Glen Zorn]
> i.e. the overwhelming majority (> 95%) of the major and minor vendors > find the RFC VSA format acceptable. I wonder, does your survey include only actual vendors or just distinct vendor IDs? I suspect the latter, since 3COM (not on your list) bought USR, inheriting that type space. It also appears that the same weight is given to vendors like Cisco & Lucent as to "Bob's NAS Factory". Is this important? It certainly seems important to me, since small vendors are unlikely to put RADIUS to the number and variety of uses that would push the envelope of the type space. It also ignores the internal structure of those "RFC format" VSAs, in many cases chosen to avoid exhausting the VSA type space (see below). > > This includes Cisco, who uses the RFC format, and then extends it to > encapsulate (almost) free-form text. Perhaps you are unaware of the fact that a major purpose of the encapsulation of "(almost) free-form text" was to extend the inadequate VSA type space. > > I doubt very much that any other RADIUS server will have different > statistics. So do I, which would be damning indeed if these statistics had any meaning at all.
[Alan DeKok]
Suggested changes:
1. Move Terminology and Requirements Language sections prior to Applicability.
2. Change "most significant octet first" to "network byte order".
3. Add the following text: Although [RFC2865] does not mandate it, implementations commonly assume that the Vendor Id can be used as a key to determine the on-the-wire format of a VSA. Vendors therefore SHOULD NOT use multiple formats for VSAs that are associated with a particular Vendor Id. A vendor wishing to use multiple VSA formats, SHOULD request one Vendor Id for each VSA format that they will use. 4. Suggested text in 2.1.1: Even when packets are less than 4096 octets, they may be larger than the Path Maximum Transmission Unit (PMTU). Any packet larger than the PMTU will be fragmented, making communications more brittle. Transport of fragmented UDP packets appears to be a poorly tested code path on network devices. Some devices appear to be incapable of transporting fragmented UDP packets, making it difficult to deploy RADIUS in a network where those devices are deployed. We RECOMMEND that RADIUS messages be kept as small possible. 5. I suggest the following re-write: * The RADIUS protocol is stateless; * Provisioning of services is not possible within an Access-Reject; * There is a distinction between authorization checks and user authentication; * The protocol provices for authentication and integrity protection of packets; * The RADIUS protocol is a Request/Response protocol; * The protocol defines packet length restrictions. 6. Suggested text: Implementations not following the suggestions outlined in this document may be subject to a problems such as ambiguous protocol decoding, packet loss leading to loss of billing information, and denial of service attacks. 7. It should say "IETF process" instead of "the above procedure".
Proposed Resolution: Accept
Issue 312: Normative Reference to
Extended
Attributes Document
Submitter name: Bernard Aboba
Submitter email address: bernard_aboba@hotmail.com
Date first submitted: July 31, 2009
Reference:
Document:
Design-Guidelines
Comment type: Editorial
Priority: S
Section: 2.2, 3, 6.1
Rationale/Explanation of issue:
In Section 2.2 and 3 the Design Guidelines document contains normative language relating to the Extended Attributes document. This has resulted in a normative dependency on that document. Given that the Extended Attributes document is not yet completed, and can contain its own usage guidelines, is the normative reference appropriate?
From Section 3:
Recent extensions to the RADIUS data model such as [EXTEN] make it possible to minimize the use of complex attributes. New specifications seeking to extend the standard RADIUS data model SHOULD examine [EXTEN] to see if their needs fit within the extended RADIUS data model.
From Section A.2.1:
* Complex data structures defined only within RADIUS.
The additional functionality defined in [EXTEN] SHOULD be used
instead. This recommendation does not apply to new attributes
for authentication or security, as described below in Section
A.2.2.
[Alan DeKok] Remove the normative reference to [EXTEN] and all normative language and text referring to it.
Proposed Resolution: Accept
Issue 313: Security Exemption
Submitter name: Alan DeKok
Submitter email address: aland@deployingradius.com
Date first submitted: July 24, 2009
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00340.html
Document:
Design Guidelines
Comment type: Technical
Priority: S
Section: A.2.1
Rationale/Explanation of issue:
Section A.2.1 states:
* Complex data structures defined only within RADIUS.
The additional functionality defined in [EXTEN] SHOULD be used
instead. This recommendation does not apply to new attributes
for authentication or security, as described below in Section
A.2.2.
Should this exemption be removed and/or clarified?
d.b.nelson@comcast.net wrote: > Yeah. I've always been a bit uncomfortable with the "security > functionality" escape clause in the RADIUS Design Guidelines draft. > Lots of things can reasonably be claimed to be "security related". I > would have preferred the exception to be crafted a bit narrower, just > for this reason. But, unless wording of Design Guidelines is changed, > you have a legitimate argument. I believe the intent was "related to RADIUS security". The guidelines document could be updated to address this. RADIUS could transport parameters for *another* protocol. Those attributes are not security related. They either follow the RADIUS data model (int, IP address, etc.), or they are "opaque data" that RADIUS is simply transporting on the behalf of the other protocol.
[David Nelson]
> If the answers to all of the above items are "yes", this data type > SHOULD be replaced > with simpler types, as discussed above in Section A.2.1. Also see > Section 2.1.3 for a discussion of why complex types are problematic. I don't think that the "for purposes other than authentication or security?" text really addresses the inherent ambiguity. My understanding is that the exemption is for authentication or security mechanisms internal to the RADIUS protocol. The revised text does not make that "internal to RADIUS" limitation, and thus remains an open loop-hole, IMO.
My reading of the current, as well as that of others, however, is that *any* security related attribute, whether in support of the RADIUS protocol or some external entity, qualifies for an exemption to be designed as a complex type. In that regard, "security" attributes for any usage are covered by this exemption. [Bernard Aboba] I would agree that this is too broad. I think the idea was to exempt attributes where *computation* was required on the server and client (e.g. Digest Authentication, CHAP, etc.). But if there is no computation occurring, or if the attribute could be construed as opaque, I don't think the exemption is appropriate. For example, consider a complex "Security Policy Attribute" sent from server to client. From the server point of view, there is no computation involved, the server just sends the attribute to the client, who is expected to understand it.
In such a situation, there is no intrinsic reason why server code changes should be required. Does such an attribute deserve an exemption? I would say no.
[Alan DeKok] See http://ops.ietf.org/lists/radiusext/2009/msg00535.html
The following text should be added to the document during the RFC
editor process, as suggested in the call last week:
1) Note on "MUST" and "MUST NOT" in the text. Section 1.3, before the
final paragraph, add the following new sentence:
The suggestions given below specify no mandatory behavior
on new implementations. The uses of "MUST" and "MUST NOT" in this
document are limited to (a) requirements to follow the IETF process
for IETF standards, and (b) quotes from other documents.
The advice in this document applies to attributes used to encode
...
2) Notes on attributes for authentication and security. Section A.2.2.
Current text:
* That a RADIUS server and/or client is expected to parse?
i.e. A type that cannot be treated as opaque data (Section A.1.3)
Replacement text:
* That a RADIUS server and/or client is expected to parse, validate,
or create the contents of via a computation?
i.e. A type that cannot be treated as opaque data (Section A.1.3)
[Bernard Aboba]
" The following text should be added to the document during the RFC
editor process, as suggested in the call last week:
1) Note on "MUST" and "MUST NOT" in the text. Section 1.3, before the
final paragraph, add the following new sentence:
The suggestions given below specify no mandatory behavior
on new implementations. The uses of "MUST" and "MUST NOT" in this
document are limited to (a) requirements to follow the IETF process
for IETF standards, and (b) quotes from other documents.
The advice in this document applies to attributes used to encode
..."
[BA] They don't specify mandatory behavior in existing implementations
either, correct? How about this?
"The uses of "MUST" and "MUST NOT" in this
document are limited to (a) requirements to follow the IETF process
for IETF standards, and (b) quotes from other documents. As a result,
the use of MUST and MUST NOT in this document does not prescribe
mandatory behavior within implementations."
Alan also said:
"2) Notes on attributes for authentication and security. Section A.2.2.
Current text:
* That a RADIUS server and/or client is expected to parse?
i.e. A type that cannot be treated as opaque data (Section A.1.3)
Replacement text:
* That a RADIUS server and/or client is expected to parse, validate,
or create the contents of via a computation?
i.e. A type that cannot be treated as opaque data (Section A.1.3)"
[BA] Doesn't this still leave the broad authentication/security exemption in
place?
The third bullet still says:
" * for purposes other than authentication or security?"
Also, the text in Section 2.1.3 remains unchanged:
" As a
result, the introduction of new complex data types within RADIUS
attribute specifications SHOULD be avoided, except in the case of
complex attributes involving authentication or security
functionality."
My understanding was that the security/authentication exemption was
considered too broad. How about this?
In Section 2.1.3, change the text to the following:
"As a result, the introduction of new complex data types within RADIUS
attribute specifications SHOULD be avoided. A potential exception to
this recommendation occurs for attributes that inherently require
code changes on both the client and server. For example, as described
in Appendix B, complex attributes have been used in situations
involving authentication and security attributes that need to be
dynamically computed and verified."
A suggestion for the text in Section A.2.2:
" A.2.2. Complex Data Types
Does the attribute:
* define a complex data type that a RADIUS server and/or client
is expected to parse? (i.e. a type that cannot be treated as
opaque data (Section A.1.3).
* involve functionality that could be implemented without code
changes on both the client and server? (i.e. a type that
doesn't require dynamic computation and verification, such
as authentication or security attributes)
If so, this data type SHOULD be replaced with simpler types, as
discussed above in Appendix A.2.1. Also see Section 2.1.3 for a
discussion of why complex types are problematic.
"
[Alan DeKok]
> [BA] They don't specify mandatory behavior in existing implementations > either, correct? How about this? Yes, that is correct. > "The uses of "MUST" and "MUST NOT" in this > document are limited to (a) requirements to follow the IETF process > for IETF standards, and (b) quotes from other documents. As a result, > the use of MUST and MUST NOT in this document does not prescribe > mandatory behavior within implementations." OK. Looks good to me. > Alan also said: > > "2) Notes on attributes for authentication and security. Section A.2.2. > Current text: > > * That a RADIUS server and/or client is expected to parse? > i.e. A type that cannot be treated as opaque data (Section A.1.3) > > Replacement text: > > * That a RADIUS server and/or client is expected to parse, validate, > or create the contents of via a computation? > i.e. A type that cannot be treated as opaque data (Section A.1.3)" > > [BA] Doesn't this still leave the broad authentication/security exemption in > place? Hmm... maybe we could simply delete the third bullet. > The third bullet still says: > > " * for purposes other than authentication or security?" Yes. It's probably better to remove that exemption, and instead to rely on the "computation" text above. > Also, the text in Section 2.1.3 remains unchanged: > > " As a > result, the introduction of new complex data types within RADIUS > attribute specifications SHOULD be avoided, except in the case of > complex attributes involving authentication or security > functionality." > > My understanding was that the security/authentication exemption was > considered too broad. How about this? Yes. > In Section 2.1.3, change the text to the following: > > "As a result, the introduction of new complex data types within RADIUS > attribute specifications SHOULD be avoided. A potential exception to > this recommendation occurs for attributes that inherently require > code changes on both the client and server. For example, as described > in Appendix B, complex attributes have been used in situations > involving authentication and security attributes that need to be > dynamically computed and verified." That looks good to me. > A suggestion for the text in Section A.2.2: > > " A.2.2. Complex Data Types > > Does the attribute: > > * define a complex data type that a RADIUS server and/or client > is expected to parse? (i.e. a type that cannot be treated as > opaque data (Section A.1.3). > > * involve functionality that could be implemented without code > changes on both the client and server? (i.e. a type that > doesn't require dynamic computation and verification, such > as authentication or security attributes) > > If so, this data type SHOULD be replaced with simpler types, as > discussed above in Appendix A.2.1. Also see Section 2.1.3 for a > discussion of why complex types are problematic. OK. I think that's clearer.
Proposed Resolution: Accept
Issue 314: My Problem
Submitter name: Hannes Tschofenig
Submitter email address: Hannes.Tschofenig@gmx.net
Date first submitted: May 9, 2009
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00237.html
Document:
Design-Guidelines
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
The document assumes a certain implementation and processing model. This model is not explicitly documented in the draft and unfortunately has implications on the design of attributes particularly when it comes to data types used by RADIUS attributes and for the claimed problems that arise from adding new code to the RADIUS server. In previous mail exchanges on the list I did not agree with certain aspects of the implicitly assumed progressing model. I am, however, OK with documenting the model and to thereby make it explicit to the reader. The understanding of some of the claimed limitations might also be clearer.
PS: FYI, I stated my concerns previously on the RADEXT list.
[Alan DeKok] Do you have suggested text for the document?
[Hannes]
I can compile some text but this is not saying that I agree with the assumed model, i.e. one where essentially no improvement in implementations was made over the last 10 years.
[David Nelson]
Perhaps, but this seems to presume that data-dictionary-driven server implementations are a liability which requires improvement. Like a network management application for SNMP which has the ability to "enroll" a MIB module without code changes, a RADIUS server that can simply add new attributes to its dictionary is a boon to users. We can split hairs about what types of user-added executable scripts are or are not "coding". I still think that the data dictionary architecture is a very powerful concept. Not to mention a very widely deployed one.
[BA] Since specific text was never proposed, and the document has now been approved for publication by the IESG I am closing this issue. Proposed Resolution: Reject
Issue 315: Review
Submitter name: Stig Venaas
Submitter email address: stig@venaas.com
Date first submitted: September 8, 2009
Reference:
Document:
RADTCP
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
Two minor comments.
1. The draft says:
RADIUS clients using RADIUS over TCP MUST NOT decide that a
connection is down until the application layer watchdog algorithm has
marked it DOWN ([RFC3539] Appendix A). RADIUS clients using RADIUS
over TCP MUST NOT decide that a RADIUS server is unresponsive until
all TCP connections to it have been marked DOWN.
I'm a bit confused by that first sentence. The TCP session might be
reset without the watchdog marking it down. Wouldn't that be sufficient
to say that the connection is down?
2. Should the term RadSec be replaced with RADIUS over TLS?
Proposed Resolution: Discuss
Issue 316: Comments
Submitter name: Bernard Aboba
Submitter email address: bernard_aboba@hotmail.com
Date first submitted: September 8, 2009
Reference:
Document:
RADTCP
Comment type: Technical
Priority: S
Section: Abstract, 1, 1.1
Rationale/Explanation of issue:
Here are my comments:
Category: Proposed Standards
[BA] My impression was that this document (like RADIUS over TLS and
RADIUS over
DTLS) was targeted for Experimental status.
Abstract
The Remote Authentication Dial In User Server (RADIUS)
Protocol has
traditionally used the User Datagram Protocol (UDP) as it's
underlying transport layer. This document defines
RADIUS over the
Transmission Control Protocol (TCP).
[BA] It might be worth stating that this specification was developed
primarily
for addressing the transport issues inherent in RADIUS over TLS, and
that it is
not intended for use by itself.
Section 1
* Connectionless transport. Neither
clients nor servers can
reliably detect when the other is
down. This information has to
be deduced instead from the absence of a
reply to a request.
[BA] Determining when a client or server is down is not automatically
solved by
choice of a reliable transport.
For example, without an application layer watchdog, an application
relying on
TCP would typically need to wait
until the connection timed out before trying another server. This
is the
problem identified by RFC 2865, which talks about UDP be
used for
faster failover than would be permitted by TCP without a
watchdog.
However, failover as envisaged by RFC 2865 does not require
deducing that
a server is "down" based on lack of a reply; doing so
would require a much
longer waiting interval than implementations typically provide.
RADIUS over UDP
implementations typically don't care whether the server is "down" or
not; they
only care that it hasn't responded after set time interval or number of
retries. However, none of this is specified in RFC 2865 (or
RFC 5080), so the
quality of the failover algorithm will vary between
implementations. This I
think is the
more relevant point -- lack of a standardized failover algorithm.
Presumably,
this document can address that problem.
As RADIUS is widely deployed, and has been widely deployed
for well
over a decade, these issues are relatively minor.
However, new
systems may be interested in choosing a different set of
trade-offs
than those outlined in
[RFC2865] Section 2.4. For
those systems, we
define RADIUS over TCP.
[BA] I would disagree that the failover problem is necessarily
minor; in
implementations I'm familiar with, developing a stable and reliable
failover
algorithm was a major pain. With respect to the reasoning behind
the
development of RADIUS over TCP, is the issue really the need for a
"different
set of tradeoffs", or is the issue the different set of needs
that manifest
themselves in proxy-proxy transport situations? As described
in RFC 3539,
NAS-proxy scenarios do not really benefit from reliable transport
because the
connection would be likely to run with the minimum
congestion window most of the
time. As a result, using reliable transport just generates a lot
of ACK traffic
without making use of the congestion control/window management benefits
of TCP.
This is not necessarily the case for proxy-proxy transport where the
volume may
be quite a bit higher.
Section 1.1
The intent of this document is to address transport issues
related to
RadSec [RADSEC].
The use of "bare" TCP transport is NOT RECOMMENDED,
as there has been little implementational or operational
experience
with it. Additionally,
[RFC2865] Section 2.4 contains a
list of
reasons why UDP was originally chosen as the transport
protocol for
RADIUS. UDP SHOULD be used as transport protocol in
all cases where
the rationale given in
[RFC2865] Section 2.4 applies.
[BA] I think you might say a bit more about the applicability
of RADIUS over
"bare" TCP. For example, that
it is only useful in proxy-proxy scenarios where the traffic is
protected by
TLS. The reasons given might include both transport as well as
security and
interoperability concerns. For example, we have seen
interoperability problems
result in situations where application layer protocols can be
transported in
multiple ways (e.g. SIP), and proxy-proxy scenarios can benefit from
stronger/more flexible security, as envisaged in RADIUS over TLS.
Proposed Resolution: Discuss
Issue 317: Review
Submitter name: Alan DeKok
Submitter email address: aland@deployingradius.com
Date first submitted: August 21, 2009
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00401.html
Document:
draft-lourdelet-radext-ipv6-access-01.txt
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
IPv6-Address:
I'd suggest giving it a more descriptive name, like
"Uplink-IPv6-Address"
IPv6-Route-Option-Preference:
2 octet signed integers aren't nice. I would suggest using a normal
32-bit integer. This should work, if I understand it correctl.
IPv6-Route-Option-Lifetime:
Auth-IPv6-Prefix-Valid-Lifetime:
Defining a tag field *and* a 32-bit integer means that you're
re-defining the meaning of a tag + integer attribute. See RFC 2868,
Section 3.1 for the historical definition.
It would seem to be OK to have a 24-bit lifetime. That would allow
everyone to use this attribute by simply updating their dictionaries,
rather than writing new code to handle a new format.
Prefix-Lifetime-Service-Type:
This could just be a normal 32-bit integer, rather than a 2-byte
integer.
Other than that, it looks OK to me.
Proposed Resolution: Discuss
Issue 318: Inappropriate Use of RFC
2119
Keywords
Submitter name: Glen Zorn
Submitter email address: glenzorn@net-zen.net
Date first submitted: October 22, 2009
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00550.html
Document:
draft-ietf-radext-design-09
Comment type: T
Priority: S
Section: 2.1.1
Rationale/Explanation of issue:
Section 6 of RFC 2119 states: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. The section of the draft in question says: It is worth noting that since RADIUS only supports unsigned integers of 32 or 64 bits, attributes using signed integer data types or unsigned integer types of other sizes will require code changes, and SHOULD be avoided. It is difficult to see how either harm or interoperability problems could arise from correctly implemented code changes; indeed, this appears to be a classic case of the use of RFC 2119 keywords to "try to impose a particular method on implementers where the method is not required for interoperability". Requested change: Since the only rationale offered for the prohibition is the spurious one of avoiding code changes (something that is certainly implementation-specific), the section should be removed altogether.
[Alan DeKok]
> method on implementors where the method is not required for > interoperability". I welcome suggestions for how implementations can *meaningfully* interoperate when they have different interpretations for an attribute. i.e. one defines an attribute to be "signed 24-bit integer counter, little endian", and the other doesn't support that data type. None of the meanings of the novel integer type (e.g. counter) can be used by the second implementation. It can only treat the field as "string of undistinguished octets". Therefore, they cannot be said to inter-operate according to the definition of the attribute. The alternative is to interpret "inter-operate" as "sends / receives opaque data without agreeing on the format, meaning, or processing of that data". If that is our definition of the word, then we can say that DHCP inter-operates with RADIUS. And the term loses all meaning. > Requested change: > Since the only rationale offered for the prohibition is the spurious one of > avoiding code changes (something that is certainly implementation-specific), > the section should be removed altogether. This issue should be rejected. RADIUS specifications define format, meaning, interpretations, and processing requirements for attributes. Two implementations that disagree about an attribute can inter-operate at the RADIUS level by exchanging RADIUS packets. They cannot be said have interoperable implementations of the attribute.
[Bernard Aboba]
> It is worth noting that since RADIUS only supports unsigned integers > of 32 or 64 bits, attributes using signed integer data types or > unsigned integer types of other sizes will require code changes, and > SHOULD be avoided. > > It is difficult to see how either harm or interoperability problems could > arise from correctly implemented code changes; indeed, this appears to be a > classic case of the use of RFC 2119 keywords to "try to impose a particular > method on implementers where the method is not required for > interoperability". The issue being described here is not one between RADIUS clients and servers that implement the attribute, but rather between a RADIUS client that implements the attribute and a RADIUS server that does not support the attribute or the new type. If instead of using an unsigned 32 bit integer, an 8, 16 or 24 bit integer is used or a signed integer, then existing RADIUS servers will not be able to support the newly defined data type without a code change. While existing RADIUS servers could send the newly defined types as a String, this would force network administrators to enter the attributes in hex form. This would be likely to cause errors in configuration, particularly in the case of signed integers.
Proposed Resolution: Reject
Issue 319: Misleading References
Submitter name: Glen Zorn
Submitter email address: glenzorn@net-zen.net
Date first submitted: October 22, 2009
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00541.html
Document:
draft-ietf-radext-design-09
Comment type: T
Priority: S
Section: 2.1.1
Rationale/Explanation of issue:
The relevant section of the draft in question says:
The integer64 type is used for the ARAP-
Challenge-Response Attribute defined in [RFC2869] Section 5.15, and
the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2.
[RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in
length, but denotes it as type String.
Given that attributes of type IPv6 address, IPv6 prefix, and
integer64 are already in use, it is RECOMMENDED that RADIUS server
implementations include support for these additional basic types, in
addition to the types defined in [RFC2865].
This is what RFC 2869 says about the Value field of the
APAP-Challenge-Response Attribute:
Value
The Value field contains an 8 octet response to the dial-in
client's challenge. The RADIUS server calculates this value by
taking the dial-in client's challenge from the high order 8 octets
of the ARAP-Password attribute and performing DES encryption on
this value with the authenticating user's password as the key. If
the user's password is less than 8 octets in length, the password
is padded at the end with NULL octets to a length of 8 before
using it as a key.
If one takes the word "integer" as having its normal meaning it is obvious
that far from defining a 64-bit integer data type the only thing that the
ARAP-Challenge-Response attribute has in common with a 64-bit integer is its
length. The same is true, in spades, for the Framed-Interface-Id Attribute:
the attribute was designed to carry the Interface-Identifier IPCOv6 option
(RFC 2472). Glancing at section 4.1 of that document (it's too long to
quote here) makes it abundantly clear that the Interface-Id field of the
Framed-Interface-Id attribute was designed not as an integer but as a
specially formatted octet string. Neither RFC 2869 nor RFC 3162 uses the
term "integer64", for good reason; interestingly, RFC 2869 _does_ define
data types, but "integer64" is not among the types defined (again, for good
reason). Therefore, it is technically incorrect to claim that either of the
referenced RFCs defines an "integer64" data type.
Requested change:
Given that the "integer64" data type has never in fact been defined by any
RFC, either all mention of it must be removed from this draft or the text
changed to make clear that it is an invention of the author.
[Bernard Aboba] An issue has been raised about whether RADIUS does in fact support 64-bit integers, or whether the data types used in previous attributes were either special types (e.g. Interface ID) or 64-bit octet strings. If WG consensus is that RADIUS does not today support 64-bit integers, the choices would be as follows: 1. Recommend the addition of the 64-bit integer data type to implementations; 2. Remove the reference to 64-bit integers in the above paragraph.
[BA] How about this? In Section 2.1.1 change:
" IPv6 address 128 bit value, in network byte order.
IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to
128 bits of value, in network byte order.
integer64 64 bit unsigned value, in network byte order
This type has also been used to represent an IPv6
interface identifier.
Examples of the IPv6 address type include NAS-IPv6-Address defined in
[RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162]
Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3,
and in [RFC4818] Section 3. The integer64 type is used for the ARAP-
Challenge-Response Attribute defined in [RFC2869] Section 5.15, and
the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2.
[RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in
length, but denotes it as type String.
Given that attributes of type IPv6 address, IPv6 prefix, and
integer64 are already in use, it is RECOMMENDED that RADIUS server
implementations include support for these additional basic types, in
addition to the types defined in [RFC2865].
"
To:
" IPv6 address 128 bit value, in network byte order.
IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to
128 bits of value, in network byte order.
Interface ID 64 bit octet string, in network byte order,
used to represent an IPv6 Interface identifier.
Examples of the IPv6 address type include NAS-IPv6-Address defined in
[RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162]
Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3,
and in [RFC4818] Section 3. The Interface ID type is used for the
the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2.
[RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in
length, but denotes it as type String.
Given that attributes of type IPv6 address, IPv6 prefix, and
Interface ID are already in use, it is recommended that RADIUS server
implementations include support for these additional basic types, in
addition to the types defined in [RFC2865].
"
[Bernard Aboba] In looking at the text of Sections 2 and 2.1.1, I would propose to make the following changes in Section 2 and 2.1.1 to resolve Issue 319. 2. RADIUS Data Model The Remote Authentication Dial In User Service (RADIUS) defined in [RFC2865] and [RFC2866] uses elements known as attributes in order to represent authentication, authorization and accounting data. Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does not define a formal data definition language. The data type of RADIUS attributes is not transported on the wire. Rather, the data type of a RADIUS attribute is fixed when that attribute is defined. Based on the RADIUS attribute type code, RADIUS clients and servers can determine the data type based on pre- configured entries within a data dictionary. Two distinct attribute spaces are defined: the standard space, and a Vendor-Specific space. Attributes in the standard space generally are composed of a type, length, value (TLV) triplet, although complex attributes have also been defined. The Vendor-Specific space is encapsulated within a single attribute type (Vendor-Specific Attribute). The format of this space is defined by individual vendors, but the same TLV encoding used by the standard space is recommended in [RFC2865] Section 5.26. The similarity between attribute formats has enabled implementations to leverage common parsing functionality, although in some cases the attributes in the Vendor-Specific space have begun to diverge from the common format. 2.1.1. Basic Data Types defined in RFC 2865 [RFC2865] and [RFC2866] utilize data types defined in [RFC2865] Section 5, which states the following: The format of the value field is one of five data types. Note that type "text" is a subset of type "string". text 1-253 octets containing UTF-8 encoded 10646 [RFC3629] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead. string 1-253 octets containing binary data (values 0 through 255 decimal, inclusive). Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead. address 32 bit value, most significant octet first. integer 32 bit unsigned value, most significant octet first. time 32 bit unsigned value, most significant octet first -- seconds since 00:00:00 UTC, January 1, 1970. The standard Attributes do not use this data type but it is presented here for possible use in future attributes. In addition to the data types defined in [RFC2865], subsequent RADIUS specifications defined attributes using additional basic data types. Since these specifications did not explicitly define new data types as was done in [RFC2865], nor did they consistently indicate the format of the value field using the same conventions as [RFC2865], in some cases the intended data type is ambiguous and may not be consistent among different implementations. It is out of the scope of this document to resolve all potential ambiguities within existing RADIUS specifications. However in order to prevent future ambiguities, it is recommended that future RADIUS attribute specifications explicitly define newly created data types at the beginning of the document, and indicate clearly the data type to be used for each attribute. [RFC3162] utilizes but does not explicitly define the following data types: IPv6 address 128 bit value, in network byte order. IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 128 bits of value, in network byte order. Examples of the IPv6 address type include NAS-IPv6-Address defined in [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, and in [RFC4818] Section 3. While the Framed-Interface-Id attribute defined in [RFC3162] Section 2.2 included a value field of 8 octets, the data type was not explicitly indicated, and therefore there is controversy over whether the format of this attribute was intended to be an 8 octet String or whether a special Interface-Id type was intended. Given that attributes of type IPv6 address and IPv6 prefix are already in use, it is RECOMMENDED that RADIUS server implementations include support for these additional basic types, in addition to the types defined in [RFC2865]. Where the intent is to represent a specific IPv6 address, the IPv6 address type SHOULD be used. Although it is possible to use the IPv6 IPv6 Prefix type with a prefix length of 128 to represent an IPv6 address, this usage is NOT RECOMMENDED. Implementations supporting the Framed-Interface-Id attribute may select a data type of their choosing (most likely an 8 octet String or a special Interface-Id data type). It is worth noting that since RADIUS only supports unsigned integers of 32 bits, attributes using signed integer data types or unsigned integer types of other sizes will require code changes, and SHOULD be avoided. For [RFC2865] RADIUS VSAs, the length limitation of the String and Text types is 247 octets instead of 253 octets, due to the additional overhead of the Vendor-Specific Attribute.In looking through Appendix A, there are some sections that are inconsistent with the revisions proposed in Issue 319:
Does the data fit within the existing RADIUS data model, as outlined below? could be clarified by changing it to: Does the data fit within the basic data types described in Section 2.1.1, as outlined below? * Section A.2 says: All data types other than the ones described above in Appendix A.1 SHOULD NOT be used. This section describes in detail a number of data types that are NOT RECOMMENDED in new RADIUS specifications. Where possible, replacement data types are suggested. To make it clear that existing complex types are not being deprecated, the text might be changed to say "described in Appendix A.1 and Appendix B" * Section A.2.1 mentions integer64 data types. * The advice on authentication security attributes needs to be sync'd up with the new proposed text. * The advice on a 16-bit type field is inconsistent with the recently revised text. * Section A.2.2 might say "define a complex type not described in Appendix B which..."
Proposed Resolution: Accept
Issue 320: Definition of RADIUS IPv6
"data
types" arbitrary and unjustified
Submitter name: Glen Zorn
Submitter email address: glenzorn@net-zen.net
Date first submitted: October 22, 2009
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00550.html
Document:
draft-ietf-radext-design-09
Comment type: T
Priority: S
Section: 2.1.1
Rationale/Explanation of issue:
The section in question states:
In addition to these data types, follow-on RADIUS specifications
define attributes using the following additional types:
IPv6 address 128 bit value, in network byte order.
IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to
128 bits of value, in network byte order.
integer64 64 bit unsigned value, in network byte order
This type has also been used to represent an IPv6
interface identifier.
Examples of the IPv6 address type include NAS-IPv6-Address defined in
[RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162]
Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3,
and in [RFC4818] Section 3. The integer64 type is used for the ARAP-
Challenge-Response Attribute defined in [RFC2869] Section 5.15, and
the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2.
[RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in
length, but denotes it as type String.
Given that attributes of type IPv6 address, IPv6 prefix, and
integer64 are already in use, it is RECOMMENDED that RADIUS server
implementations include support for these additional basic types, in
addition to the types defined in [RFC2865].
However, simply examining the references shows that none of the RFCs cited
define _any_ "data types". The claim made is arbitrary and unjustified;
essentially, the author is inventing the "data types" out of thin air.
Requested change:
Either delete the entire section or modify it to be a more reasonable and
justified _description_ o[f formats that have been previously used in RADIUS
to carry quantities related to IPv6, rather than using irrelevant references
to attempt to justify the _prescription_ of future behavior.
[Alan DeKok]
> However, simply examining the references shows that none of the RFCs cited
> define _any_ "data types".
Unfortunately, I know how to use "grep".
$ grep "data type" rfc2865.txt
...
The format of the value field is one of five data types. Note
standard Attributes do not use this data type but it is
...
That was difficult. Now let's read the document in more detail to see
what it says. From RFC 2865 Section 5, Page 25:
The format of the value field is one of five data types. Note
that type "text" is a subset of type "string".
It goes on to name the five data types, and give definitions for each
one. These data types are then used in the attribute definitions in RFC
2865, and in other RADIUS RFCs.
In addition, this text is taken from RFC 2058, which was written over
a decade ago, and says:
The format of the value field is one of four data types.
Of course, that isn't the whole story. To highlight the irony (or
hypocrisy), these data types are used by you in RFCs that you either
authored or co-authored:
RFC 2548
RFC 2867
RFC 2868
RFC 3162
> Requested change:
> Either delete the entire section or modify it to be a more reasonable and
> justified _description_ of formats that have been previously used in RADIUS
> to carry quantities related to IPv6, rather than using irrelevant references
> to attempt to justify the _prescription_ of future behavior.
This issue should be rejected out of hand. The concept of "data
types" goes back to the beginning of RADIUS, and was part of the
original protocol specification.
[Bernard Aboba]
"There is another, less anal-retentive alternative: that the string of octets does, in fact, represent an IPv6 address. That's it, and that's pretty much what the RFC says." If that were the case, why didn't the document use the term "String" in defining the NAS-IPv6-Address and Login-IPv6-Host attributes instead of "Address"?
Proposed Resolution: Reject
Issue 321: Relationship to IPv6
address
allocation models
Submitter name: Joe Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted: November 18, 2008
Reference:
http://www.ietf.org/proceedings/73/minutes/radext.txt
Document:
draft-sarikaya-radext-prefix-authorization
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Excerpts from the discussion of this document at IETF 73 indicated a problem with understanding how this document relates to existing IPv6 address allocation models.
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.
Proposed Resolution: Discuss
Issue 322: Unclear Service Definition
Submitter name: David Nelson
Submitter email address:
d.b.nelson@comcast.net
Date first submitted: November 18, 2008
Reference:
http://www.ietf.org/proceedings/73/minutes/radext.txt
Document:
draft-lourdelet-radext-rfc3162bis-02,
draft-sarikaya-radext-prefix-authorization
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
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: 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.
Proposed Resolution: Discuss
Issue 323: Use of a Product
Name
Submitter name: Bernard Aboba
Submitter email address: bernard_aboba@hotmail.com
Date first submitted: October 30, 2009
Reference: http://ops.ietf.org/lists/radiusext/2009/msg00617.html
Document:
RADSEC, Status-Server, RADIUS over DTLS
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:
"RADSEC" is the name of a commercial product. I would suggest that the term "RADIUS over TLS" or RTLS be used instead to describe the protocol.
Proposed Resolution: Discuss
Issue 324: DDNS Application
Submitter name: Leslie Daigle
Submitter email address: leslie@thinkingcat.com
Date first submitted: November 17, 2009
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00633.html
Document:
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
I came across your RADEXT draft (draft-ietf-radext-dynamic-discovery-01.txt). You need to know that NAPTR records cannot be used "in the wild" (as in, "just retrieve the NAPTR record"), as currently described in your document. NAPTR records are part of the DNS implementation of the Dynamic Delegation Discovery System (DDDS) -- see RFC3403. To use them, you need to define a DDDS application (as outlined in that suite of documents). You may find that S-NAPTR (RFC3958) does the trick for you.
[Stefan Winter] The following text might address the issue:
"2.2. DNS RR definition
DNS definitions of RADIUS/TLS servers can be either S-NAPTR records
(see [RFC3958]) or SRV records. When both are defined, the
resolution algorithm prefers S-NAPTR results (see section Section 2.3
below).
This specification defines two S-NAPTR service tag: a general-purpose
tag "nai-roaming" and a special-purpose tag "eduroam" for the eduroam
roaming consortium. This specification defines two S-NAPTR protocol
tags: "radius.tls" for RADIUS over TLS [I-D.ietf-radext-radsec] and
"radius.dtls" for RADIUS over DTLS [I-D.dekok-radext-dtls].
This specification defines the SRV prefix "_radiustls._tcp" for
RADIUS over TLS [I-D.ietf-radext-radsec] and "_radiustls._udp" for
RADIUS over DTLS [I-D.dekok-radext-dtls]. It is expected that in
most cases, the label used for the records is the DNS representation
(punycode) of the literal realm name for which the server is the AAA
server."
Accompanied by an IANA Consideration section:
"4. IANA Considerations
This document requests IANA registration of the following S-NAPTR
parameters:
o Application Service Tags
* nai-roaming
* eduroam
o Application Protocol Tags
* radius.tls
* radius.dtls"
This is one of three ways how I could see the resolution happen. They are
1) a single "nai-roaming" service tag, and if some consortium needs its
own, use x-<identifier>
2) a generic "nai-roaming" service tag, and further labels allocated per
their own RFC - I define my own one inline in this document
3) a tag+subtag mechanism (see also my mail to Leslie Daigle, forwarded
by Bernard) to allow e.g.:
nai-roaming_eduroam.org
nai-roaming_3gppnetworks.org
nai-roaming_wimaxforum.com
Number 1 is always possible, but a bailout to unregulated space, with
possible clashes due to the freeform x-...
Number 2 is cumbersome for roaming consortia, because they need their
own RFC to describe themselves.
Number 3 would be cool, but would require allocation of a wildcard
"subspace" within the S-NAPTR service tag space. I'm unsure whether this
is foreseen.
I've put number 2 in the draft to have a starting point, but would
prefer 3 if we can sort it out.
Proposed Resolution: Discuss
Issue 325: Review
Submitter name: Joe Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted: December 18, 2009
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00662.html
Document: DESIGN-06
Comment type: Technical
Priority: S
Section: 2.1.3, 2.1.4, 5, A2.1, A2.2
Rationale/Explanation of issue:
I gave the RADIUS Design Guidelines document a "last look". I had not looked at the document for a while and have not really been following discussions on the document. In general I think the document provides some useful information. There are a few places where I had issues with the document. I'm not sure if these are part of the IESG and Last call comments or not. A. Section 2.1.3 I did not find the discussion of complex attributes very compelling. Its not clear to me what the difference between string and complex attribute is. If your RADIUS server supports string then it seems that it would be possible to support a complex attribute without requiring a "code change". B. Section 2.1.4 I'm not really sure what this section is trying to accomplish. It seems to be a lot about deployment guidelines instead of design guidelines. I'm also not convinced that the use of complex attributes makes things less secure. It does not seem this section belongs in this document. C. Section 5 This section references section 2.1.4, however it does not seem there is anything actionable for a protocol document to do with section 2.1.4. D. Section A.2.2 Since I did not agree with the motivation for section 2.1.3, I don't find this section compelling. E. Section A.2.1 I don't see how defining a polymorphic attribute as multiple attributes helps. I'm probably missing something, do you have an example?
[Bernard Aboba]
> A. Section 2.1.3 > > I did not find the discussion of complex attributes very compelling. > Its not clear to me what the difference between string and complex > attribute is. If your RADIUS server supports string then it seems that > it would be possible to support a complex attribute without requiring a > "code change". There are several distinct aspects that are discussed in Section 2.1.3: a. Enabling a RADIUS server to send a complex attribute; b. Enabling a RADIUS server to receive a complex attribute; c. Enabling a RADIUS client to send a complex attribute; d. Enabling a RADIUS client to receive a complex attribute. However, rather than examining each of these aspects separately, the section appears to switch between the aspects, sometimes within the same paragraph. As a result, it is not always clear what aspects are being discussed. Since the arguments made depend on what aspect is being discussed, it can be hard to follow. For example, the second paragraph of Section 2.1.3 seems to focus largely on a). As you say, in this case, a RADIUS server can send a complex attribute without a code change (merely by encoding it as a string). However, while the first bullet appears to apply to aspect a) (e.g. ease of data entry), the second and third bullets appear to relate either to aspect b) or d). On reading the second and third bullets, I'm not sure which aspect is being referred to. In paragraph 4, it is noted that RADIUS clients require code changes to support any attribute, regardless of whether it is complex or not. Therefore one cannot make an argument about additional code changes arising from aspect c) or d), only aspect b). Presumably, with respect to aspect d), a RADIUS client receiving a complex attribute would also implement the required parsing and validation routes for that attribute (if not, then the client would either ignore the attribute, or possibly reject the Access-Response). So on reading this, I'm not sure that the "additional error checking" applies to, exactly. In reading paragraph 3 about server code changes, there does not appear to be a distinction between aspect a (in which code changes are not required) and aspect b (in which a code change would be necessary). Paragraph 4 does make the distinction between aspects c and d. However, paragraph 6 mixes aspects a) and b). Paragraph 4 seems to assert that code changes are not required for aspect a), while this paragraph does seem to say that this is possible, though it is not clear in what circumstances this would be necessary.
[Bernard Aboba] With respect to security vulnerabilities, here are some of the issues:
http://securityvulns.com/Cdocument579.html
http://securityvulns.com/docs2178.html
http://www.vuxml.org/freebsd/96ba2dae-4ab0-11d8-96f2-0020ed76ef5a.html
[Avi Lior]
Section 2.1.4 makes the following assertion. Exchanging information
as a complex
type has potential for introducing more security vulnerabilities.
What?
You mean if i have to send the following information element a b c to
the client
or the server; if i send them concatenated in one attribute as say a
String
foobar containing a+b+c or that will pose more of a security risk the
sending
them as three separate attributes.
Help me understand this.....
=====
I think it would be worth while to define the RADIUS model first. Not
the old
RADIUS model but rather the one that we are all living with today. That
model is
not really different then Diameter.
Where:
we have an Application layer and a Base layer.
Then define the roles of each.
Where is parsing done and what type of parsing is done. Which
layer is
responsible for security and to what extent. It seems that security is
the
responsibility for both layers but not to the same extent.
The role of the dictionary...
The document intermixes these topics .... and I am telling you this will
create
confusion
I want a more formal definition.
BTW on that note....in section 1.1 You define RADIUS proxy but the term
is never
used anywhere!!!! I find that hard to believe - cause I am sure we would
have to
say something about Proxies.
I think if we did talk about RADIUS as an APplication layer and
transport layer
etc then we would have to say something about Proxies.
Original text....
2.1.4. Complex Attributes and Security
The introduction of complex data types brings the potential for the
introduction of new security vulnerabilities. Experience shows that
the common data types have few security vulnerabilities, or else that
all known issues have been found and fixed. New data types require
new code, which may introduce new bugs, and therefore new attack
vectors.
RADIUS servers are highly valued targets, as they control network
access and interact with databases that store usernames and
passwords. An extreme outcome of a vulnerability due to a new,
complex type would be that an attacker is capable of taking complete
control over the RADIUS server.
The use of attributes representing opaque data does not reduce this
threat. The threat merely moves from the RADIUS server to the
application that consumes that opaque data.
The threat is particularly severe when the opaque data originates
from the user, and is not validated by the NAS. In those cases, the
RADIUS server is potentially exposed to attack by malware residing on
an unauthenticated host. Applications consuming opaque data that
reside on the RADIUS server SHOULD be properly isolated from the
RADIUS server, and SHOULD run with minimal privileges. Any potential
vulnerabilities in that application will then have minimal impact on
the security of the system as a whole.
New text..... AND MOVE THIS TO THE SECURITY SECTION....
2.1.4. New Data types and Security
The introduction of NEW data types brings the potential for the
introduction of new security vulnerabilities. Experience shows that
the existing data types have few security vulnerabilities, or else that
all known issues have been found and fixed. New data types require
new code, which may introduce new bugs, and therefore new attack
vectors.
RADIUS servers are highly valued targets, as they control network
access and interact with databases that store usernames and
passwords. An extreme outcome of a vulnerability due to a new attribute
type
would be that an attacker is capable of taking complete
control over the RADIUS server.
""" TAKE THE FOLLOWING TWO PARAGRAPHS OUT SINCE YOU ARE TALKING ABOUT
RADIUS IN
THIS DOCUMENT. """
The use of attributes representing opaque data does not reduce this
threat. The threat merely moves from the RADIUS server to the
application that consumes that opaque data.
The threat is particularly severe when the opaque data originates
from the user, and is not validated by the NAS. In those cases, the
RADIUS server is potentially exposed to attack by malware residing on
an unauthenticated host. Applications consuming opaque data that
reside on the RADIUS server SHOULD be properly isolated from the
RADIUS server, and SHOULD run with minimal privileges. Any potential
vulnerabilities in that application will then have minimal impact on
the security of the system as a whole.
I dont understand how adding a new attribute of an existing type to an
Access-Request does not require code changes in the RADIUS server? The
RADIUS
server has to process this attribute no? It has to make policy decision
based on
this attribute no?
Next you talk about the following:
"On the RADIUS client, code changes are typically required in order to
implement a new attribute. The RADIUS client typically has to
compose the attribute dynamically when sending. When receiving, a
RADIUS client needs to be able to parse the attribute and carry out
the requested service. As a result, a detailed understanding of the
new attribute is required on clients, and data dictionaries are less
useful on clients than on servers."
But this confuses me.... I think that Clients and Servers have to do the
same
work. I think that both require a detailed understanding of a new
attribute.
I do agree that Servers get attributes from a database when composing a
response
and certainly that is true for older generations of server. But today
and going
forward this is not true. More often now servers have to compose their
response
by computing the attributes dynamically.
Proposed Resolution: Discuss
Issue 326: Review
Submitter name: Ignacio Goyret
Submitter email address: igoyret@alcatel-lucent.com
Date first submitted: January 21, 2010
Reference:
http://ops.ietf.org/lists/radiusext/2010/msg00110.html
Document:
Status-Server
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
I don't know why you think
that
Ascend had implemented anything
like this. As far as I have been able to ascertain, neither our
RAS (MAX, TNT or APX) nor any of our RADIUS servers ever implemented
Server-Status. I even checked with the few folks still around
from the old Livingston (the creators of RADIUS) and got the
same story. Do you have any idea which product may have
implemented this? If you have any idea, let me know and
I'll try to find someone that can check the draft.
Anyway, I did a cursory review and have one technical comment
and a few trivial editorial fixes:
1) (tech comment) To be frank, both myself and our RADIUS engineers
were quite surprised that the response to a Server-Status is not
a code+1, or some other code like a fictitiuous "Server-Response".
The overloading of Access-Accept and Accounting-Response for
this purpose (response to a Server-Status command) is a bit
disconcerting and quite dangerous since it opens the door
for potentially bogus authentication.
I know that it is past WGLC so dramatic changes are out of
the question, but if nothing else, you should add some text
explaining the decision for this overloading.
2) page 6, section 2, 4th para:
vv
- [RFC2865] Section 2.6. "Keep-Alives" are sent when
an
downstream
+ [RFC2865] Section 2.6. "Keep-Alives" are sent when a
downstream
^
3) page 6, section 2.1 title:
Consider changing the title from:
"Why Access-Request cannot be used"
to something like:
"Why Access-Request are not
appropriate"
This would make it more consistent with the 2.1.1 title
which is a recommendation against, not a prohibition.
Also, consider a similar change to the title section 2.2
for the same reasons.
4) Page 10, first line:
vvvvvvv
- same method as used for for calculating the Response
Authenticator
of
+ same method as used for calculating the Response
Authenticator of
^^^
5) page 20, section 6.2:
The hex dump of the request is shown as:
0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb
1d b7
ad 38 82 60 80 12 e8 d6 ea bd a9 10 87 5c
d9 1f
da de 26 36 78 58
but it should be:
0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb
1d b7
ad 38 82 60 50 12 e8 d6 ea bd a9 10 87 5c
d9 1f
da de 26 36 78 58
(note change of "80" -> "50" in the 5th byte of the
second line)
Also, the response is wrong. It is shown as:
-----------------------(cut-here)-------------------------
02 b3 00 1a 0f 6f 92 14 5f 10 7e 2f 50 4e
86 0a
48 60 66 9c
1 Code = Accounting-Response (5)
1 ID = 179
2 Length = 20 16 Request
Authenticator
Attributes:
None.
-----------------------(to-here)-------------------------
but should be:
-----------------------(cut-here)-------------------------
02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e
86 0a
48 60 66 9c
1 Code = Accounting-Response (5)
1 ID = 179
2 Length = 20
16 Request Authenticator
Attributes:
None.
-----------------------(to-here)-------------------------
(two changes: "1a" -> "14" in the 4th byte of the first
line,
and a missing newline after "Length = 20").
[Alan DeKok]
> 1) (tech comment) To be frank, both myself and our RADIUS
engineers
> were quite surprised that the response to a Server-Status is not
> a code+1, or some other code like a fictitiuous "Server-Response".
Yes. I think it's because there was no "response" packet
pre-defined.
I suspect that the implementors didn't want to self-allocate.
> The overloading of Access-Accept and Accounting-Response for
> this purpose (response to a Server-Status command) is a bit
> disconcerting and quite dangerous since it opens the door
> for potentially bogus authentication.
I'm not sure why. The response packets are signed with the
Request
Authenticator of the request. i.e. the client *knows* that the
Access-Accept is in response to a Status-Server. So it has no "user
session" to authenticate.
> I know that it is past WGLC so dramatic changes are out of
> the question, but if nothing else, you should add some text
> explaining the decision for this overloading.
OK. I'll put something together.
The rest of your comments are editorial, and will go into the
document
as-is.
[Ignacio Goyret]
> I'm not sure why. The response packets are signed
with the
Request
>Authenticator of the request. i.e. the client *knows* that the
>Access-Accept is in response to a Status-Server. So it has no "user
>session" to authenticate.
That assumes that the client was the one actually sending
the Status-Server. It could have been an attacker.
A client has very little to use to validate an incoming Access-Request
that was generated as a response to an Status-Server.
IOW, a server responding to a Status-Server sent to its auth port
may unintentionally authenticate a bogus session.
That's why I say that using Access-Accept as a response to
anything other than an Access-* is dangerous.
> This requires that the attacker obtain the Request
Authenticator from
>the Access-Request, put it into a Status-Server, and send that to
the
>server before it receives the Access-Request.
>
> It's possible, but hard.
>
>> That's why I say that using Access-Accept as a response to
>> anything other than an Access-* is dangerous.
>
> The use of Message-Authenticator means that the attacker
won't be able
>to sign the Status-Server, meaning the server won't respond.
Which means that the client MUST trust that the server was
properly written and/or configured and will not respond to
bogus Status-Server -- even if the client never generates
them.
A client has *no* reliable way to find out if an incoming
Access-Accept is for an Access-Request it sent or from an
Status-Server sent by an attacker (with a possibly problematic
server).
See why this is a slippery slope?
IMHO, people should be advised to NOT use this method of checking the
servers.
> But this attack is possible in RADIUS without
Status-Server.
Exactly. So, why are we trying to add yet another attack vector?
>> See why this is a slippery slope?
>
> Oh, yes. But the problem is mostly due to
un-authenticated request
>packets, and less so to the use of Access-Accept.
Let's agree to disagree. IMO, the use of Access-Accept for a use
*other* than what it has always been intended for is opening
a can of worms with potentially unintended consequences.
A clean, simple design would call for specialized codes,
specially considering that there is plenty of unused code
points.
However, in the Security section, it should be mentioned that
both servers and clients can be attacked independently when
either one supports Server-Status, even if the other doesn't.
>> IMHO, people should be advised to NOT use this method of
>> checking the servers.
>
> Hmm... even though this attack is already possible in RADIUS?
Yes, because it adds a new and different attack vector.
> The only defense is to require that Access-Request (and
Status-Server)
>packets be signed.
I disagree.
A much better defense (without altering the basic RADIUS paradigm)
would be to use another code for a response, one that cannot be
confused with any possible authentication.
Since the purpose of the Status-Server is to check whether
the server is ok, then the response should be such that
cannot ever be confused *ever* with anything else.
Barring a solution where the server response cannot be confused,
my opinion against using this method stands.
> We can also presume that the RADIUS client && server
will be
>configured by people who communicate. i.e. the "client" is
also
>partially the admin, who knows that the server supports signed
>Status-Server, and therefore can safely enable it on the client.
Think of the case where one of the two parts has to support it
because *part* of your network supports it (say some clients
or some servers), just not all of it. The choice of using an
Access-Accept response opens new doors for attacks.
It would be enough that *part* of the network can't or doesn't
know how to deal with these new sets of Access-Accept and
the admin has a serious problem. Furthermore, in many cases,
servers or clients are usually not under the same admin SOC
which makes the mixed environment very likely.
But, like I mentioned in earlier emails, this is all academic
and it doesn't really matter much because this is just an
informational RFC. It would be a very different story if
it was intended for standards track.
Proposed Resolution: Discuss
Issue 327: Applicability
Submitter name: Avi Lior
Submitter email address: avi@bridgewatersystems.com
Date first submitted: January 22, 2010
Reference:
http://ops.ietf.org/lists/radiusext/2010/msg00068.html
Document:
DESIGN-GUIDELINES
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
> If we were talking about VSAs, this wouldn't be a concern. We're
talking
> about standards-tack attributes.
Okay then we should make sure that the document makes this clear.
The problem is the document talks about SDOs. SDO work on VSAs not
standard
track attributes.
From the abstract we have:
"reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs)."
> If all you have to worry about is the
> class of "enhanced capability" RADIUS servers, then I would agree.
In the
> IETF, we need to take a broader view, I think.
Which is fine but I think you have to document this distinction. That is
a
problem with this BCP only people who read these long email threads will
understand what is really going on.
The problem is the document talks about SDOs. SDO work on VSAs not
standard
track attributes.
From the abstract we have:
"reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs)."
Not only it is not clear but also not true and I want it to be true ...
In
section 3.1.1 there is text that contradicts what you say. Here it is:
"The design and specification of VSAs for multi-vendor usage SHOULD be
undertaken with the same level of care as standard RADIUS attributes.
Specifically, the provisions of this document that apply to standard
RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage."
Please get rid of that text!
Also in 3.1.3 ....
It is RECOMMENDED that SDOs follow the guidelines
outlined here, which are intended to enable maximum interoperability
with minimal changes to existing systems.
Also since you already have an applicability section and you already
make the
recommendations that SDOs and vendors follow this document -- you dont
need to
repeat yourself over and over again. So please get rid of the repeated
text.
So reading the document with respect to SDOs....
In section 3.1.1 please remove the "stuff" related to SDO Specific
Attribute
(SSA).
This is only going to create confusion. Either RADEXT formally adopts
this usage
or not. I would argue that it is too late.
As a side note, [RFC2865] Section 5.26 uses the term "Vendor-Specific
Attribute" to refer to an encoding format which can be used by
individual vendors to define attributes not suitable for general
usage. However, since then VSAs have also become widely used by SDOs
defining attributes intended for multi-vendor interoperability. As
such, these attributes are not specific to any single vendor, and the
term "Vendor-Specific" may be misleading. An alternate term which
better describes this use case is SDO-Specific Attribute (SSA).
Thus in section 3.1.1 the last two paragraphs should go.
Back to applicability section 1.3
"It is RECOMMENDED that SDOs follow the guidelines articulated in this
document. Doing so will ensure the widest possible applicability and
interoperability of the specifications, while requiring minimal
changes to existing systems. ....
This is fine but the rest is problematic...
"
Specifications that do not follow the
guidelines articulated herein are NOT RECOMMENDED. However, we
recognize that there are some situations where SDOs or vendors
require the creation of specifications not following these
guidelines. We do not forbid these specifications, but it is
RECOMMENDED that they are created only if they have a limited scope
of applicability, and all attributes defined in those specifications
are VSAs, as discussed Appendix A.5, below."
By specification i assume that you mean SDO specifications. Right? well
you
should state that.
Assuming that is correct then i have a problem with the text...
I dont think that the IETF has a say on whether they can prohibit or
"not
recommend" or even recommend an SDO specification. I think you have
captured
what needs to be captured in the previous part and also in the following
paragraph.
And also what does it mean that all the attributes are VSA.... you mean i
cant
reuse an attribute such as User-Name as defined by 2865 in my SDO
specification.
I don't agree with that.
[BA] Here is a proposal for addressing this issue:
Section 1
This document provides guidelines for the design of RADIUS attributes
both within the IETF as well as within other SDOs. By articulating
RADIUS design guidelines, it is hoped that this document will
encourage the development and publication of high quality RADIUS
attribute specifications.
However, the advice in this document will not be helpful unless it is
put to use. As with "Guidelines for Authors and Reviewers of MIB
Documents" [RFC4181], it is expected that this document will be used
by authors to check their document against the guidelines prior to
requesting review (such as an "Expert Review" described in
[RFC3575]). Similarly, it is expected that this document will used
by reviewers (such as WG participants or the AAA Doctors [DOCTORS]),
resulting in an improvement in the consistency of reviews.
In order to meet these objectives, this document needs to cover not
only the science of attribute design, but also the art. Therefore,
in addition to covering the most frequently encountered issues, this
document attempts to provide some of the considerations motivating
the guidelines.
In order to characterize current attribute usage, both the basic and
complex data types defined in the existing RADIUS RFCs are reviewed.
[BA] The scope defined above isn't quite right. Suggested change:
"This document provides guidelines for the design of RADIUS attributes
used to encode service-provisioning or authentication data,
based on the data model and attribute formats defined in RFC 2865 and
subsequent RADIUS RFCs. In order to characterize current attribute
usage, both the basic and complex data types defined in the existing
RADIUS RFCs are reviewed. Since the RADEXT WG is currently considering
extensions to the RADIUS data model and attribute formats,
future documents may extend the data model and guidelines provided here.
In order to meet these objectives, this document needs to cover not
only the science of attribute design, but also the art. Therefore,
in addition to covering the most frequently encountered issues, this
document attempts to provide some of the considerations motivating
the guidelines.
RADIUS protocol changes, or specification of attributes
(such as Service-Type) that can be used to, in effect, provide
new RADIUS commands require greater expertise and deeper review,
as do changes to the RADIUS operational model as discussed in Section
3.3. As a result, such changes are outside the scope of this
document and MUST NOT be undertaken outside the IETF. Registration
policies
for RADIUS parameters are discussed in [RFC3575] Section 2.1."
1.3. Applicability
As RADIUS has become more widely accepted as a management protocol,
its usage has become more prevalent, both within the IETF as well as
within other SDOs. Given the expanded utilization of RADIUS, it has
become apparent that requiring SDOs to accomplish all their RADIUS
work within the IETF is inherently inefficient and unscalable. By
articulating guidelines for RADIUS attribute design, this document
enables SDOs out of the IETF to design their own RADIUS attributes
within the Vendor-Specific Attribute (VSA) space.
It is RECOMMENDED that SDOs follow the guidelines articulated in this
document. Doing so will ensure the widest possible applicability and
interoperability of the specifications, while requiring minimal
changes to existing systems. Specifications that do not follow the
guidelines articulated herein are NOT RECOMMENDED. However, we
recognize that there are some situations where SDOs or vendors
require the creation of specifications not following these
guidelines. We do not forbid these specifications, but it is
RECOMMENDED that they are created only if they have a limited scope
of applicability, and all attributes defined in those specifications
are VSAs, as discussed Appendix A.5, below.
It is RECOMMENDED that SDOs and vendors seek review of RADIUS
attribute specifications from the IETF. However, when specifications
are SDO specific, re-use existing data types, and follow these
guidelines, they do not require IETF review.
In order to enable IETF review of such specifications, the authors
recommend that:
* SDOs make their RADIUS attribute specifications publicly
available;
* SDOs request review of RADIUS attribute specifications by
sending email to the AAA Doctors [DOCTORS] or equivalent mailing
list;
* IETF and SDO RADIUS attribute specifications are reviewed
according to the guidelines proposed in this document;
* Reviews of specifications are posted to the RADEXT WG mailing
list, the AAA Doctors mailing list [DOCTORS] or another IETF
mailing list suggested by the Operations & Management Area
Directors of the IETF.
These reviews can assist with creation of specifications that meet
the SDO requirements, and which are also compatible with the
traditional data model and uses of RADIUS. While these reviews
require access to public specifications, the review process does not
require publication of an IETF RFC.
The advice in this document applies to attributes used to encode
service-provisioning or authentication data. RADIUS protocol
changes, or specification of attributes (such as Service-Type) that
can be used to, in effect, provide new RADIUS commands require
greater expertise and deeper review, as do changes to the RADIUS
operational model as discussed below in Section 3.3. Such changes
MUST NOT be undertaken outside the IETF and when handled within the
IETF require "IETF Consensus" for adoption, as noted in [RFC3575]
Section 2.1.
[BA] Suggested change:
" As RADIUS has become more widely accepted as a management protocol,
its usage has become more prevalent, by vendors as well as the IETF and
other SDOs. By articulating RADIUS design guidelines, it is hoped that
this document will encourage the development and publication of
high quality RADIUS attribute specifications. As with "Guidelines
for Authors and Reviewers of MIB Documents" [RFC4181], it is
expected that this document will be used by authors to check their
document against the guidelines prior to requesting review
(such as an "Expert Review" described in
[RFC3575]). Similarly, it is expected that this document will used
by reviewers (such as WG participants or the AAA Doctors [DOCTORS]),
resulting in an improvement in the consistency of reviews.
The guidelines articulated in this document enable the design
of attributes with the widest possible interoperability,
while requiring minimal changes to existing systems.
As a result, they are suitable for application to attributes
designed for general usage. It is RECOMMENDED
that these guidelines be applied to review of documents
requesting allocations within the IETF standard attribute
space defined in [RFC2865].
These guidelines may also prove useful in the design of
attributes within the Vendor-Specific Attribute (VSA)
space. As noted in RFC 2865 Section 5.26, RADIUS VSAs
were created "to allow vendors to support their own extended
Attributes not suitable for general usage."
Rather than requesting allocation of standard attributes
for those uses, [RFC2865] Section 6.2 notes that utilization
of VSAs "should be encouraged instead of allocation of global
attribute types, for functions specific only to one vendor's
implementation of RADIUS, where no interoperability is deemed useful."
However, experience has shown that attributes not originally
designed for general usage can subsequently garner wide-spread
deployment. An example is the vendor-specific attributes
defined in [RFC2548], which have been widely implemented
within IEEE 802.11 Access Points.
As a result, while SDOs and vendors MAY choose to create
specifications not following these guidelines for use in
scenarios within a limited scope of applicability,
where general usage is possible, adhering to the
design guidelines is RECOMMENDED. Discussion of
vendor allocations is provided in Section 3.1.2;
discussion of SDO allocations is provided in Section
3.1.3. SDOs and vendors desiring review of their
specifications by the IETF are encouraged to follow
the advice presented in Section 3.1.4."
3.1.2. Vendor Allocations
Vendor RADIUS Attribute specifications SHOULD allocate attributes
from the vendor space, rather than requesting an allocation from the
RADIUS standard attribute space.
As discussed in [RFC2865] Section 5.26, the vendor space is intended
for vendors to support their own Attributes not suitable for general
use. However, it is RECOMMENDED that vendors follow the guidelines
outlined here, which are intended to enable maximum interoperability
with minimal changes to existing systems.
Following these guidelines means that RADIUS servers can be updated
to support the vendor's equipment by editing a RADIUS dictionary. If
these guidelines are not followed, then the vendor's equipment can
only be supported via code changes in RADIUS server implementations.
Such code changes add complexity and delay to implementations.
[BA] Suggested change:
" As noted in [RFC3575] Section 2.1, vendors are encouraged
to utilize VSAs to define functions "specific only to one vendor's
implementation of RADIUS, where no interoperability is deemed useful.
For functions specific only to one vendor's implementation of RADIUS,
the use of that should be encouraged instead of the allocation of
global attribute types."
Nevertheless, following the guidelines outlined within this document
has several advantages, including maximum interoperability with
minimal changes to existing systems. Following these guidelines
means that RADIUS servers can be updated to support the vendor's
equipment by editing a RADIUS dictionary. If these guidelines are
not followed, then the vendor's equipment can only be supported
via code changes in RADIUS server implementations.
Such code changes add complexity and delay to implementations."
3.1.3. SDO Allocations
SDO RADIUS Attribute specifications SHOULD allocate attributes from
the vendor space, rather than requesting an allocation from the
RADIUS standard attribute space, for attributes matching any of the
following criteria:
* attributes relying on data types not defined within RADIUS
* attributes intended primarily for use within an SDO
* attributes intended primarily for use within a group of SDOs.
Any new RADIUS attributes or values intended for interoperable use
across a broad spectrum of the Internet Community SHOULD follow the
normal IETF process, and SHOULD result in allocations from the RADIUS
standard space.
The recommendation for SDOs to allocate attributes from a vendor
space rather than via the IETF process is a recognition that SDOs may
desire to assert change control over their own RADIUS specifications.
This change control can be obtained by requesting a PEC from the
Internet Assigned Number Authority (IANA), for use as a Vendor-Id
within a Vendor-Specific attribute. Further allocation of attributes
inside of the VSA space defined by that Vendor-Id is subject solely
to the discretion of the SDO. Similarly, the use of data types
(complex or not) within that VSA space is solely under the discretion
of the SDO. It is RECOMMENDED that SDOs follow the guidelines
outlined here, which are intended to enable maximum interoperability
with minimal changes to existing systems.
It should be understood that SDOs do not have to rehost VSAs into the
standards space solely for the purpose of obtaining IETF review.
Rehosting puts pressure on the standards space, and may be harmful to
interoperability, since it can create two ways to provision the same
service. Rehosting may also require changes to the RADIUS data model
which will affect implementations that do not intend to support the
SDO specifications.
[BA] Suggested change:
" Given the expanded utilization of RADIUS, it has
become apparent that requiring SDOs to accomplish all their RADIUS
work within the IETF is inherently inefficient and unscalable.
SDO RADIUS Attribute specifications SHOULD allocate attributes from
the vendor space, rather than requesting an allocation from the
RADIUS standard attribute space, for attributes matching any of the
following criteria:
* attributes relying on data types not defined within RADIUS
* attributes intended primarily for use within an SDO
* attributes intended primarily for use within a group of SDOs.
Allocation of new RADIUS attributes or values intended for interoperable
use
across a broad spectrum of the Internet Community SHOULD follow the
allocation process defined in [RFC3575].
The recommendation for SDOs to allocate attributes from the vendor
space rather than via the IETF process recognizes the need for SDOs
to assert change control over their own RADIUS specifications.
SDOs desiring to define their VSAs are encouraged to
request allocation of a Private Enterprise Code (PEC) from the
Internet Assigned Number Authority (IANA), for use as a Vendor-Id.
The SDO can then allocate attributes within the VSA space defined
by that Vendor-Id, at their sole discretion. Similarly, the use of
data types (complex or otherwise) within that VSA space is solely
under the discretion of the SDO."
3.1.4. Publication of specifications
SDOs are encouraged to seek early review of SSA specifications by the
IETF. This review may be initiated by sending mail to the AAA
Doctors list [DOCTORS], with the understanding that this review is a
voluntary-based service offered on best-effort basis. Since the IETF
is not a membership organization, in order to enable the RADIUS SSA
specification to be reviewed, it is RECOMMENDED that it be made
publicly available; this also encourages interoperability. Where the
RADIUS SSA specification is embedded within a larger document which
cannot be made public, the RADIUS attribute and value definitions
SHOULD be published instead as an Informational RFC, as with
[RFC4679]. This process SHOULD be followed instead of requesting
IANA allocations from within the standard RADIUS attribute space.
Similarly, vendors are encouraged to make their specifications
publicly available, for maximum interoperability. However, it is not
necessary for them to request publication of their VSA specifications
as Informational RFCs by the IETF.
All other specifications, including new authentication,
authorization, and/or security mechanisms SHOULD be allocated via the
standard RADIUS space, as noted in [RFC3575] Section 2.1.
[BA] Suggested change:
" SDOs or vendors desiring review of their RADIUS specifications
by the IETF are encouraged to seek review as early as possible,
so as to avoid potential delays. Since reviews are handled by
volunteers,
responses are provided on a best-effort basis, with no service
level guarantees. In order to provide reviewers with access to the
specification, SDOs and vendors are encouraged to make them publicly
available.
Where the RADIUS specification is embedded within a larger document
which
cannot be made public, the RADIUS attribute and value definitions
can be made available on a public web site or can be published as
an Informational RFC, as with [RFC4679].
Review can be requested by sending email to the AAA Doctors [DOCTORS]
or equivalent mailing list. The IETF Operations & Management
Area Directors will then arrange for the review to be
completed and posted to the AAA Doctors mailing list
[DOCTORS], RADEXT WG mailing list, or other IETF mailing
list.
The review process requires neither allocation of attributes
within the IETF standard attribute space nor publication of an
IETF RFC. Requiring SDOs or vendors to rehost VSAs into the IETF
standards
attribute space solely for the purpose of obtaining review
would put pressure on the standards space, and may be harmful to
interoperability, since it can create two ways to provision the same
service. Rehosting may also require changes to the RADIUS data model
which will affect implementations that do not intend to support the
SDO or vendor specifications."
[Bernard Aboba]
Glancing at -13, there appear to be some inconsistencies within the text:
Section 1.3.1
As RADIUS has become more widely accepted as a management protocol,
its usage has become more prevalent, both within the IETF as well as
within other SDOs. Given the expanded utilization of RADIUS, it has
become apparent that requiring SDOs to accomplish all their RADIUS
work within the IETF is inherently inefficient and unscalable. By
articulating guidelines for RADIUS attribute design, this document
enables SDOs out of the IETF to design their own RADIUS attributes
within the Vendor-Specific Attribute (VSA) space.
It is RECOMMENDED that SDOs follow the guidelines articulated in this
document. However, we recognize that there are some situations where
SDOs or vendors require the creation of specifications not following
these guidelines. We do not forbid these specifications, but it is
RECOMMENDED that they are created only if they have a limited scope
of applicability, and all new attributes defined in those
specifications are VSAs. See Section 3, below, for additional
discussion of this topic.
It is RECOMMENDED that SDOs and vendors seek review of RADIUS
attribute specifications from the IETF. However, specifications do
not require IETF review when they satisfy all of the following
criteria:
* are SDO specific;
* reference attributes from pre-existing IETF or SDO
specifications;
* define new attributes only in the VSA space;
* use only the "basic data types" (see below) for all VSAs;
* follow the guidelines given in this document.
[BA] This text is similar to text in Section 3.3.3, which leads me to
believe that there was an editing problem.
My suggestion is that the text in 3.3.3 be moved to Section 1.3.1.
3.3.3. SDO Allocations
Given the expanded utilization of RADIUS, it has become apparent that
requiring SDOs to accomplish all their RADIUS work within the IETF is
inherently inefficient and unscalable. Is is therefore RECOMMENDED
that SDO RADIUS Attribute specifications allocate attributes from the
vendor space, rather than requesting an allocation from the RADIUS
standard attribute space, for attributes matching any of the
following criteria:
* attributes relying on data types not defined within RADIUS
* attributes intended primarily for use within an SDO
* attributes intended primarily for use within a group of SDOs.
Any new RADIUS attributes or values intended for interoperable use
across a broad spectrum of the Internet Community SHOULD follow the
allocation process defined in [RFC3575].
The recommendation for SDOs to allocate attributes from a vendor
space rather than via the IETF process is a recognition that SDOs
desire to assert change control over their own RADIUS specifications.
This change control can be obtained by requesting a PEC from the
Internet Assigned Number Authority (IANA), for use as a Vendor-Id
within a Vendor-Specific attribute. The SDO can then allocate
attributes within the VSA space defined by that Vendor-Id, at their
sole discretion. Similarly, the use of data types (complex or
otherwise) within that VSA space is solely under the discretion of
the SDO.
Nevertheless, following the guidelines outlined within this document
has many advantages. It is therefore RECOMMENDED that SDOs follow
the guidelines outlined here, which are intended to enable maximum
interoperability with minimal changes to existing systems.
[BA] The last paragraph does not appear to be consistent with Section 1.3,
so I'd
recommend that it be deleted.
3.3.2. Vendor Allocations
Nevertheless, following the guidelines outlined within this document
has many advantages. It is therefore RECOMMENDED that vendors follow
the guidelines outlined here, which are intended to enable maximum
interoperability with minimal changes to existing systems. If these
guidelines are not followed, the result will be increased complexity
with little or no benefit.
[BA] The resolution to Issue 327 recommended the following alternative text:
Nevertheless, following the guidelines outlined within this document
has several advantages, including maximum interoperability with
minimal changes to existing systems. Following these guidelines
means that RADIUS servers can be updated to support the vendor's
equipment by editing a RADIUS dictionary. If these guidelines are
not followed, then the vendor's equipment can only be supported
via code changes in RADIUS server implementations.
Such code changes add complexity and delay to implementations."
3.3.4. Publication of specifications
In order to enable IETF review of SDO specifications, it is
RECOMMENDED that:
* SDOs make their RADIUS attribute specifications publicly
available;
* SDOs request review of RADIUS attribute specifications by
sending email to the AAA Doctors [DOCTORS] or equivalent mailing
list;
* IETF and SDO RADIUS attribute specifications are reviewed
according to the guidelines proposed in this document;
* Reviews of specifications are posted to the RADEXT WG mailing
list,
the AAA Doctors mailing list [DOCTORS] or another IETF mailing
list
suggested by the Operations & Management Area Directors of the
IETF.
It should be understood that SDOs do not have to rehost VSAs into the
standards space solely for the purpose of obtaining IETF review.
Rehosting puts pressure on the standards space, and may be harmful to
interoperability, since it can create two ways to provision the same
service. Rehosting may also require changes to the RADIUS data model
which will affect implementations that do not intend to support the
SDO specifications.
These reviews can assist with creation of specifications that meet
the SDO requirements, and which are also compatible with the
traditional data model and uses of RADIUS. While these reviews
require access to public specifications, the review process does not
require publication of an IETF RFC.
SDOs are encouraged to seek early review of their specifications by
the IETF. It should be understood that reviews are a voluntary-based
service offered on best-effort basis.
Where the RADIUS specification is embedded within a larger document
which cannot be made public, the RADIUS attribute and value
definitions SHOULD be published instead as an Informational RFC, as
with [RFC4679]. This process SHOULD be followed instead of
requesting IANA allocations from within the standard RADIUS attribute
space.
Similarly, vendors are encouraged to make their specifications
publicly available, for maximum interoperability. However, it is not
necessary for them to request publication of their VSA specifications
as Informational RFCs by the IETF.
All other specifications, including new authentication,
authorization, and/or security mechanisms SHOULD follow the
allocation process defined in [RFC3575].
[BA] The resolution to Issue 327 recommended the following alternative text:
SDOs or vendors desiring review of their RADIUS specifications
by the IETF are encouraged to seek review as early as possible,
so as to avoid potential delays. Since reviews are handled by volunteers,
responses are provided on a best-effort basis, with no service
level guarantees. In order to provide reviewers with access to the
specification, SDOs and vendors are encouraged to make them publicly
available.
Where the RADIUS specification is embedded within a larger document which
cannot be made public, the RADIUS attribute and value definitions
can be made available on a public web site or can be published as
an Informational RFC, as with [RFC4679].
Review can be requested by sending email to the AAA Doctors [DOCTORS]
or equivalent mailing list. The IETF Operations & Management
Area Directors will then arrange for the review to be
completed and posted to the AAA Doctors mailing list
[DOCTORS], RADEXT WG mailing list, or other IETF mailing
list.
The review process requires neither allocation of attributes
within the IETF standard attribute space nor publication of an
IETF RFC. Requiring SDOs or vendors to rehost VSAs into the IETF standards
attribute space solely for the purpose of obtaining review
would put pressure on the standards space, and may be harmful to
interoperability, since it can create two ways to provision the same
service. Rehosting may also require changes to the RADIUS data model
which will affect implementations that do not intend to support the
SDO or vendor specifications."
Proposed Resolution: Discuss
Issue 328: Review
Submitter name: Bernard Aboba
Submitter email address: bernard_aboba@hotmail.com
Date first submitted: February 3, 2010
Reference:
http://ops.ietf.org/lists/radiusext/2010/msg00156.html,
http://ops.ietf.org/lists/radiusext/2010/msg00157.html,
http://ops.ietf.org/lists/radiusext/2010/msg00158.html
Document:
RADTCP
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
Section 1
Transport of fragmented UDP packets
appears to be a poorly tested code path on network devices. Some
devices appear to be incapable of transporting fragmented UDP
packets, making it difficult to deploy RADIUS in a network where
those devices are deployed.
[BA] In particular, filters routers and firewalls often drop UDP
fragments,
since otherwise they would need to reassemble them in order to apply the
filter
rules.
However, this is not a “transport” issue, so much as a
forwarding/filtering
issue. Instead of “Transport” you might say “handling”.
* Connectionless transport. Neither clients nor servers receive
positive statements that a "connection" is down. This information
has to be deduced instead from the absence of a reply to a
request.
[BA] The same thing is also true of TCP transport, unless you’re willing
to wait
for a Reset or connection timeout. That’s why the Watchdog timer is
needed.
As RADIUS is widely deployed, and has been widely deployed for well
over a decade, these issues have been minor in some use-cases, and
problematic in others.. New systems may be interested in choosing a
different set of trade-offs than those outlined in [RFC2865] Section
2.4. New systems may also be interested in choosing a more reliable
transport for use-cases such as inter-server proxying. For those
systems, we define RADIUS over TCP
[BA] Note double periods in first sentence, and no period in the last
sentence.
As I read the document, it is really only suggesting a different set of
tradeoffs for inter-server proxying. So you might say “For use-cases
such as
inter-server proxying, [RTLS] suggests an alternative transport and
security
model -- RADIUS over TLS. This document describes the transport
implications of
running RADIUS over TLS/TCP.”
1.1. Applicability of Reliable Transport
The intent of this document is to address transport issues related to
RADIUS over TLS [RTLS]. The use of "bare" TCP transport (i.e.
without TLS) is NOT RECOMMENDED, as there has been little
implementational or operational experience with it. Additionally,
[RFC2865] Section 2.4 contains a list of reasons why UDP was
originally chosen as the transport protocol for RADIUS. UDP SHOULD
be used as transport protocol in all cases where the rationale given
in [RFC2865] Section 2.4 applies.
Deployment experience with RADIUS over TLS indicates that it is most
useful for inter-server communication, such as inter-domain
communication between proxies. These situations benefit from the
confidentiality and ciphersuite negotiation that can be provided by
TLS. Since TLS is already widely available within the operating
systems used by proxies, implementation barriers are low.
RADIUS over TCP has a similar set of use cases. Use of TCP as a
transport between a NAS and RADIUS server is a poor fit, since as
noted in [RFC3539], there is likely to be insufficient traffic for
the congestion window to remain above the minimum value on a long-
term basis. The result is an increase in packets due to ACKs as
compared to UDP, without a corresponding set of benefits.
In server-server communications the traffic levels in both directions
are typically high enough to support a larger congestion window as
well as ACK piggy-backing. Through use of an application-layer
watchdog as described in [RFC3539], it is possible to address the
objections to reliable transport described in [RFC2865] Section 2.4.
However, in these scenarios "bare" TCP does not provide for
confidentiality or enable negotiation of stronger ciphersuites than
are available in RADIUS.
As a result of these considerations, use of RADIUS over TCP SHOULD be
restricted to situations where RADIUS over TLS is employed. RADIUS
over "bare" TCP is NOT RECOMMENDED.
There are still a number of benefits to using a reliable transport.
For example, when RADIUS is used to carry EAP conversions [RFC3579],
the EAP exchanges may involve 5 round trips at the RADIUS application
layer. We may assume a probability P of packet loss in each
direction (with P having a value of 1% or less). Any one
authentication attempt will then have at least one lost packet, with
a probability of approximately (10 * P).
These lost packets require the supplicant and/or the NAS to re-
transmit packets at the application layer. The difficulty with this
approach is that retransmission implementations have historically
been poor. Some implementations retransmit packets, others do not,
and others send new packets rather then performing retransmission.
Some implementations are incapable of detecting EAP retransmissions,
and will instead treat the retransmitted packet as an error.
These retransmissions have a high likelihood of causing the entire
authentication session to fail. For a system with a million logins a
day, and having a packet loss probability of P=0.01%, we expect that
0.1% of connections will experience a lost packet. That is, 1,000
user sessions each day will experience authentication failure.
In addition, transport of fragmented UDP packets is a poorly tested
code path on network devices. Some devices appear to be incapable of
transporting fragmented UDP packets, meaning that the packet loss
rate for fragmented packets approaches 100 percent. The net effect
can be to prevent the deployment of authentication methods such as
EAP-TLS that require large RADIUS packets.
Using a reliable transport method such as TCP means that RADIUS
implementations can remove all application-layer retransmissions, and
instead rely on the Operating System (OS) kernel's well-tested TCP
transport to ensure reliable delivery. In addition, most TCP
implementations discover Path MTU better than RADIUS application
implementations, resulting in significantly fewer fragmented packets.
Modern TCP implementations also implement anti-spoofing provisions,
which is more difficult to do in UDP applications.
Transporting RADIUS over TCP means that the RADIUS applications can
leverage these additional protections offered by TCP.
However, there are also some drawbacks to using TCP. RADIUS over TCP
has some drawbacks, as noted in [RFC2865] Section 2.4. [RFC3539]
Section 2 discusses further issues with using TCP as a transport for
Authentication, Authorization, and/or Accounting (AAA) protocols such
as RADIUS.
Specifically, as noted in [RFC3539] Section 2.1, for systems
originating low numbers of RADIUS request packets, inter-packet
spacing is often larger than the packet RTT. In those situations,
RADIUS over TCP SHOULD NOT be used.
In general, RADIUS clients generating small amounts of RADIUS traffic
SHOULD NOT use TCP. This suggestion will usually apply to most
NASes, and to most clients that originate CoA-Request and Disconnect-
Request packets.
RADIUS over TCP is most applicable to RADIUS proxies that exchange a
large volume of packets with RADIUS clients and servers (10's to
1000's of packets per second). In those situations, RADIUS over TCP
may be a good fit, and may result in increased network stability and
performance.
[BA] Suggested rewrite:
Section 1.1
The intent of this document is to address transport issues related to
RADIUS over TLS [RTLS] in inter-server communications scenarios,
such as inter-domain communication between proxies. These
situations benefit from the confidentiality and ciphersuite
negotiation that can be provided by TLS. Since TLS is already
widely available within the operating systems used by proxies,
implementation barriers are low.
In scenarios where RADIUS proxies exchange a large volume of
packets (10+ packets per second), it is likely that there will be
sufficient
traffic to enable the congestion window to be widened beyond
the minimum value on a long-term basis, enabling ACK piggy-backing.
Through use of an application-layer watchdog as described in [RFC3539],
it is possible to address the objections to reliable transport
described in [RFC2865] Section 2.4 without substantial
watchdog traffic, since regular traffic is expected in both
directions.
In addition, use of RADIUS over TLS/TCP has been found to
improve operational performance when used with multi-round
trip authentication mechanisms such as RADIUS over EAP [RFC3579].
In such exchanges, it is typical for EAP fragmentation to
increase the number of round-trips required. For example, where
EAP-TLS authentication [RFC5216] is attempted and both the EAP
peer and server utilize certificate chains of 8KB, as many as
15 round-trips can be required if RADIUS packets are restricted
to 1500 octets in size. Fragmentation of RADIUS over UDP packets
is generally inadvisable due to lack of fragmentation support
within intermediate devices such as filtering routers, firewalls
and NATs. However, since RADIUS over UDP implementations typically do
not support MTU discovery, fragmentation can occur even when the
maximum RADIUS over UDP packet size is restricted to 1500 octets.
These problems disappear if a 4096 application-layer payload
can be used alongside RADIUS over TLS/TCP. Since most TCP
implementations support MTU discovery, the TCP MSS is automatically
adjusted to account for the MTU, and the larger congestion
window supported by TCP may allow multiple TCP segments to
be sent within a single window. As a result, RADIUS/EAP
traffic required for an EAP-TLS authentication with 8KB
certificate chains may be reduced to 7 round-trips or less,
resulting in substantially reduced authentication times.
In addition, experience indicates that EAP sessions transported
over RTLS are less likely to abort unsuccessfully. Historically,
RADIUS over UDP implementations have exhibited poor retransmission
behavior. Some implementations retransmit packets, others do not,
and others send new packets rather then performing retransmission.
Some implementations are incapable of detecting EAP retransmissions,
and will instead treat the retransmitted packet as an error.
As a result, within RADIUS over UDP implementations, retransmissions
have a high likeilhood of causing an EAP authentication session
to fail. For a system with a million logins a day running EAP-TLS
mutual authentication with 15 round-trips, and having a packet loss
probability of P=0.01%, we expect that 0.3% of connections will
experience
at least one lost packet. That is, 3,000 user sessions each day
will experience authentication failure. This is an unacceptable
failure rate for a mass-market network service.
Using a reliable transport method such as TCP means that RADIUS
implementations can remove all application-layer retransmissions, and
instead rely on the Operating System (OS) kernel's well-tested TCP
transport to ensure reliable delivery. In addition, most TCP
implementations discover Path MTU better than RADIUS application
implementations, resulting in significantly fewer fragmented packets.
Modern TCP implementations also implement anti-spoofing provisions,
which is more difficult to do in UDP applications.
In contrast, use of TLS/TCP as a transport between a NAS and a
RADIUS server is a poor fit. As noted in [RFC3539] Section 2.1,
for systems originating low numbers of RADIUS request packets,
inter-packet spacing is often larger than the packet RTT, and
as a result, the congestion window will t ypically not remain
above the minimum value on a long-term basis. The
result is an increase in packets due to ACKs as compared to UDP,
without a corresponding set of benefits. In addition, the lack
of substantial traffic implies the need for additional watchdog
traffic to confirm reachability.
As a result, the objections to reliable transport indicated in
[RFC2865] Section 2.4 continue to apply to NAS-RADIUS server
communications and UDP SHOULD continue to be used as the transport
protocol in this scenario. In addition, it is recommended that
implementations of "RADIUS Dynamic AUthorization Extensions" [RFC5176]
SHOULD continue to utilize UDP transport, since the volume of
dynamic authorization traffic is usually expected to be small.
Since "bare" TCP does not provide for confidentiality or enable
negotiation of credible ciphersuites, its use is not appropriate for
inter-server communications where strong security is required. As a
result
the use of "bare" TCP transport (i.e. without TLS) is NOT RECOMMENDED
for use in any situation, and there has been little or no
operational experience with it.
Section 2
Adding TCP as a RADIUS transport has a number of impacts on the
protocol, on applications using the protocol, and on networks that
deploy the protocol. In short, RADIUS over TCP is little more than
sending RADIUS formatted messages over a TCP connection.
As always, there are additional details that need to be discussed.
This section outlines the various impacts of using RADIUS over TCP,
and the discusses the proposal in more detail.
[BA] How about this?
RADIUS over TCP involves sending RADIUS formatted messages over a TCP
connection.
In the sections that follow, we discuss the implications for the RADIUS
packet
format
(Section 2.1), port usage (Section 2.2), RADIUS MIBs (Section 2.3) and
RADIUS
proxies
(Section 2.5). TCP-specific issues are discussed in Section 2.6.
Section 2.1
The changes to RADIUS implementations required to implement this
specification are largely limited to the portions that send and
receive packets on the network.
[BA] Is this sentence necessary? What portions of a RADIUS
implementation
*don’t* relate
To sending and receiving packets? I’d recommend that it be deleted.
Section 2.2
These ports are unused by existing RADIUS applications.
Implementations SHOULD use the assigned values as the default ports
for RADIUS over TCP.
[BA] You might say “Since these ports are unused by existing RADIUS
implementations,
the assigned values SHOULD be used as the default ports for RADIUS over
TCP.”
I would merge section 2.4 into this section so that one section can
cover ports
for both RADIUS over TCP and RADIUS over TLS.
Section 2.3
You might revise this section to make it clear that the advice for use
of MIBs
with RADIUS over TCP also applies to RADIUS over TLS.
Section 2.4
I’d merge this with Section 2.2.
Section 2.5
[BA] Suggest this section be renamed “Liveness Detection”.
If a request is proxied through intermediate proxies, it is not
possible to detect which of the later hops is responsible for the
absence of a reply. An intermediate proxy also cannot signal that
the outage lies in a later hop because RADIUS does not have the
ability to carry such signalling information. This issue is further
exacerbated by some proxy implementations that do not reply to a
client if they do not receive a reply to a proxied request.
[BA] This paragraph makes it seem that absence of a response by a proxy
is
incorrect behavior.
Suggest:
“Within RADIUS as defined in [RFC2865], proxies typically only forward
traffic between the NAS and RADIUS server, and do not generate their
own responses. As a result, when a NAS does not receive a response to
a request, this could be the result of packet loss between the NAS
and proxy, a problem on the proxy, loss between the RADIUS proxy and
server, or a problem with the server.”
For RADIUS over TCP, the continued existence of the TCP connection
SHOULD be used to deduce that the service on the other end of the
connection is still responsive. Further, the application layer
watchdog defined in [RFC3539] Section 3.4 enables clients to
determine that the server is "live", even though it may not have
responded recently to non-watchdog requests.
[BA] Suggest the following:
“For RADIUS over TLS/TCP, it is RECOMMENDED that implementations
utilize the existence of a TCP connection along with the
application layer watchdog defined in [RFC3539] Section 3.4 to
determine that the server is "live”.”
Additional issues with RADIUS proxies involve transport protocol
changes where the proxy receives packets on one transport protocol,
and forwards them on a different transport protocol. There are
several situations in which the law of "conservation of packets"
could be violated on an end-to-end basis (e.g. where more packets
could enter the system than could leave it on a short-term basis):
* Where TCP is used between proxies, it is possible that the
bandwidth consumed by incoming UDP packets destined to a given
upstream server could exceed the sending rate of a single TCP
connection to that server, based on the window size/RTT estimate.
* It is possible for the incoming rate of TCP packets destined to
a given realm to exceed the UDP throughput achievable using the
transport guidelines established in [RFC5080]. This could happen,
for example, where the TCP window between proxies has opened, but
packet loss is being experienced on the UDP leg, so that the
effective congestion window on the UDP side is 1.
Intrinsically, proxy systems operate with multiple control loops
instead of one end-to-end loop, and so are less stable. This is true
even for TCP-TCP proxies. As discussed in [RFC3539], the only way to
achieve stability equivalent to a single TCP connection is to mimic
the end-to-end behavior of a single TCP connection. This typically
is not achievable with an application-layer RADIUS implementation,
regardless of transport.
[BA] I suggest this material be put into a different section entitled
“Congestion Control Issues”, since it doesn’t relate to liveness
detection
(the subject of the rest of the section).
Section 2.6
The guidelines defined in [RFC3539] for implementing an AAA protocol
operating over a reliable transport MUST be followed by implementors
of this specification.
[BA] Not sure the MUST adds value here. I suggest:
“The guidelines defined in [RFC3539] for implementing a AAA protocol
over
reliable transport are applicable to RADIUS over TLS/TCP.”
Implementations MUST NOT confuse UDP and TCP transport. That is,
RADIUS clients and servers MUST be treated as unique based on a key
of the three-tuple (IP address, port, transport protocol).
Implementations MUST permit different shared secrets to be used for
UDP and TCP connections to the same destination IP address and
numerical port.
[BA] I’d suggest “RADIUS over TLS/TCP Implementations MUST support
receiving
RADIUS packets over both UDP and TLS/TCP transports originating from the
same
endpoint.
RADIUS packets received over UDP MUST be replied to over UDP; RADIUS
packets
received over TLS/TCP MUST be replied to over TLS/TCP. That is,
RADIUS clients and servers MUST be treated as unique based on a key
of the three-tuple (IP address, port, transport protocol).
Implementations MUST permit different shared secrets to be used for
UDP and TLS/TCP connections to the same destination IP address and
numerical port.
2.6.2. Head of Line Blocking
When using UDP as a transport for RADIUS, there is no ordering of
packets. If a packet sent by a client is lost, that loss has no
effect on subsequent packets sent by that client.
Unlike UDP, TCP is subject to issues related to Head of Line (HoL)
blocking. This occurs when when a TCP segment is lost and a
subsequent TCP segment arrives out of order. While the RADIUS server
can process RADIUS packets out of order, the semantics of TCP makes
this impossible. This limitation can lower the maximum packet
processing rate of RADIUS over TCP.
[BA] Suggest:
When using UDP as a transport for RADIUS, there is no ordering of
packets. If a packet sent by a client is lost, that loss has no
effect on subsequent packets sent by that client.
Unlike UDP, TLS/TCP is subject to issues related to Head of Line (HoL)
blocking. This occurs when when a TLS/TCP segment is lost and a
subsequent TLS/TCP segment arrives out of order. While the RADIUS server
can process RADIUS packets out of order, the semantics of TLS/TCP makes
this impossible. This limitation can lower the maximum packet
processing rate of RADIUS over TLS/TCP.
2.6.3. Shared Secrets
The use of shared secrets in calculating the Response Authenticator,
and other attributes such as User-Password or Message-Authenticator
[RFC3579] MUST be unchanged from previous specifications
[BA] I’d suggest that this text be merged with Section 2.1, and that the
above paragraph be changed to the following:
“The use of TLS/TCP transport does not change the calculation of
security-related
fields (such as the Response-Authenticator) in RADIUS [RFC2865] or
RADIUS
Dynamic
Authorization [RFC5176]. Calculation of attributes such as
User-Password [RFC2865] or Message-Authenticator [RFC3579] also does not
change.”
Section 2.6.4
Implementations of this specification SHOULD treat the "silently
discard" texts referenced above as "silently discard and close the
connection."
[BA] What is the alternative to this behavior? Could this be a MUST?
TCP connections MAY be closed if any of the circumstances outlined
below are seen. Alternatively, the TCP connection MAY remain open if
any of the following circumstances are seen, but the invalid packet
MUST BE silently discarded.
[BA] Not sure how you can do this in practice. Are you assuming that the
Length field remains valid?
Section 2.6.6
Given the discussion in Section 1.1, I’m wondering if this section (or
some
other section)
shouldn’t make a recommendation on the maximum RADIUS message size
applicable to
use with
RADIUS/EAP. It seems to me that using a larger RADIUS message size would
make a
lot of
sense.
Additional comments
I am wondering whether this document should take a position on the
recommendations described in [RFC3539] Section 3, particularly:
3.2. Use of Nagle Algorithm
3.3. Multiple Connections
3.4.2 Primary/Secondary failover
3.4.3 Connection Load Balancing
3.6 Invalidation of Transport Parameter Estimates
3.7 Inability to Use Fast Retransmit
3.8 Head of Line Blocking
3.9 Congestion Avoidance
3.10 Premature Failover
Proposed Resolution: Discuss
Issue 329: Review
Submitter name: Bernard Aboba
Submitter email address:
bernard_aboba@hotmail.com
Date first submitted: February 6, 2010
Reference: http://ops.ietf.org/lists/radiusext/2010/msg00163.html
Document:
STATUS-SERVER
Comment type: Editorial
Priority: 1
Section: Various
Rationale/Explanation of issue:
This specification is also limited to being a "hop by hop" query. When RADIUS packets transition one or more RADIUS Proxies, any information about the status of downstreamservers is unavailable to the client. In addition, it queries only the status of a RADIUS server, cannot carry information about specific realms. These limitations are discussed in more detail below. [BA] My suggestion is that this material be moved to Section 2, since it doesn't relate to the reasons why publication is recommended as an Informational RFC. Section 2 This section includes a statement of the problem and justification for why the Status-Server solution was chosen. My suggestion is to begin this section with an explanation of what Status-Server does, then move on from there. Suggested rewrite: Status-Server packets are sent by a RADIUS client to a RADIUS server in order to test the status of that server. Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy or server, the destination of a Status-Server packet is set to that of the server which is being tested. As a result, the client is provided with an indication of the status of that server only, since no RADIUS proxies are on the path between the RADIUS client and server. Since servers respond to a Status-Server packet without examining the User-Name attribute, the response to a Status-Server packet cannot be used to infer any information about the reachability of specific realms. The "hop by hop" functionality of Status-Server packets is useful to RADIUS clients attempting to determine the status of elements on the path between the client and a server. Since the Status-Server packet is non-forwardable, lack of a response may only be due to packet loss or the failure of the server in the destination IP address, not due to faults in downstream links, proxies or servers. It therefore provides an unambiguous indication of the status of a server. This information may be useful in situations where the RADIUS client does not receive a response to an Access-Request. A client may have multiple proxies configured, with one proxy marked as primary and another marked as secondary. If the client does not receive a response to a request sent to the primary proxy, it can "fail over" to the secondary, and send requests to the secondary instead of to the primary proxy. However, it is possible that the lack of a response to requests sent to the primary proxy was due not to a failure within the the primary, but to alternative causes such as a failed link along the path to the destination server, or the failure of the destination server. In such a situation, it may be useful for the client to be able to distinguish between failure causes so that it does not trigger failover inappropriately. For example, if the primary proxy is down, then quick failover to the secondary proxy would be prudent, whereas if a downstream failure is the cause, then the value of failover to a secondary proxy will depend on whether packets forwarded by the secondary will utilize independent links, intermediaries or destination servers. The Status-Server packet is not a "Keep-Alive" as discussed in [RFC2865] Section 2.6. "Keep-Alives" are Access-Request packets sent to determine whether a downstream server is responsive. These packets are typically sent only when a server is suspected to be down, and are no longer sent as soon as the server is available again.Sections 2.1 and Section 2.2
Response Authenticator
The value of the Authenticator field in Access-Accept, or
Accounting-Response packets is called the Response
Authenticator, and contains a one-way MD5 hash calculated over
a stream of octets consisting of: the RADIUS packet, beginning
with the Code field, including the Identifier, the Length, the
Request Authenticator field from the Status-Server packet, and
the response Attributes (if any), followed by the shared
secret. That is, ResponseAuth =
MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
denotes concatenation.
[BA] Why is this material here? If you need it at all (I don't think so), you can just reference
RFC 2865 and/or 2866.
Status-Server packets MAY include NAS-Identifier, and one of NAS-IP-
Address or NAS-IPv6-Address. These attributes are not necessary for
the operation of Status-Server, but may be useful information to a
server that receives those packets.
[BA] You might say that the server MUST ignore other attributes.
Other attributes SHOULD NOT be included in a Status-Server packet.
User authentication credentials such as User-Password, CHAP-Password,
EAP-Message, etc. MUST NOT appear in a Status-Server packet sent to a
RADIUS authentication port. User or NAS accounting attributes such
as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets, etc. MUST
NOT appear in a Status-Server packet sent to a RADIUS accounting
port.
[BA] Also, presumably User-Name is not included (relevant to the point about realms made earlier).
Section 4.3Proposed Resolution: Discuss
Issue 330: Editorial Issue
Submitter name: Bernard Aboba
Submitter email address: bernard_aboba@hotmail.com
Date first submitted: March 15, 2010
Reference:
http://ops.ietf.org/lists/radiusext/2010/msg00254.html
Document:
STATUS-SERVER
Comment type: Editorial
Priority: 1
Section: 2
Rationale/Explanation of issue:
An editorial comment on Section 2.
Section 2
Status-Server packets are sent by a RADIUS client to a RADIUS server
in order to test the status of that server. A Message-Authenticator
attribute MUST be included so as to provide per-packet authentication
and integrity protection. A single Status-Server packet MUST be
included within a UDP datagram. RADIUS proxies MUST NOT forward
Status-Server packets.
Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy
or server, the destination of a Status-Server packet is set to the IP
address of the server which is being tested. As a result, the client
is provided with an indication of the status of that server only,
since no RADIUS proxies are on the path between the RADIUS client and
server. Since servers respond to a Status-Server packet without
examining the User-Name attribute, the response to a Status-Server
packet cannot be used to infer any information about the reachability
of specific realms.
A RADIUS server or proxy implementing this specification SHOULD
respond to a Status-Server packet with an Access-Accept
(authentication port) or Accounting-Message (accounting port). An
Access-Challenge response is NOT RECOMMENDED. An Access-Reject
response MAY be used. The list of attributes that are permitted in
Status-Server and Access-Accept packets responding to Status-Server
packets are provided in the Section 6.
[BA] These three paragraphs are a bit disjoint. Recommend changing it
to the following:
Status-Server packets are sent by a RADIUS client to a RADIUS server
in order to test the status of that server. The destination of
a Status-Server packet is set to the IP address of the server that
is being tested. A single Status-Server packet MUST be included
within a UDP datagram. A Message-Authenticator attribute MUST be
included so as to provide per-packet authentication and integrity
protection.
RADIUS proxies or servers MUST NOT forward Status-Server packets.
A RADIUS server or proxy implementing this specification SHOULD
respond to a Status-Server packet with an Access-Accept
(authentication port) or Accounting-Response (accounting port). An
Access-Challenge response is NOT RECOMMENDED. An Access-Reject
response MAY be used. The list of attributes that are permitted in
Status-Server and Access-Accept packets responding to Status-Server
packets are provided in the Section 6.
Since a Status-Server packet MUST NOT be forwarded
by a RADIUS proxy or server, the client is provided with an indication
of the status of that server only, since no RADIUS proxies are on the
path between the RADIUS client and server. Since servers respond
to a Status-Server packet without examining the User-Name attribute,
the response to a Status-Server packet cannot be used to infer any
information about the reachability of specific realms.
Proposed Resolution: Discuss
Issue 331: AD Review (Technical)
Submitter name: Dan Romascanu
Submitter email address: dromasca@avaya.com
Date first submitted: March 9, 2010
Reference:
http://ops.ietf.org/lists/radiusext/2010/msg00249.html
Document:
RADTCP
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
Please find below the AD review of AD review of draft-ietf-radext-tcp-transport-05. I believe that the document will be ready for IETF Last Call only after the issues raised in this review are addressed. The issues are divided into Technical (T) and Editorial (E). T1. The document is marked as EXPERIMENTAL. It would be useful if it mentions in one of the introductory sections what are the goals and limitations (if any) of the experimental deployment and what would be the success criteria of the experiment that would allow for taking the document to the standards track later. T2. Section 2.2: > Since these ports are unused by existing RADIUS implementations, the assigned values SHOULD be used as the default ports for RADIUS over TCP. Why is this a SHOULD and not a MUST? T3. Section 2.3 needs a complete re-writing: > The MIB Module definitions in [RFC4668], [RFC4669], [RFC4670], [RFC4671], [RFC4672], and [RFC4673] each contain only one reference to UDP. These references are in the DESCRIPTION field of the MIB Module definition, and are in the form of "The UDP port" or "the UDP destination port". Actually the count is not accurate. 4688 and 4670 have each two MIB objects that refer to UDP ports, 4669 and 4671 have none, 4672 and 4673 have one each, but only in 4672 the port is referred to as UDP port (although it is clear from the context that UDP is assumed). > Implementations of RADIUS over TCP SHOULD re-use these MIB Modules to perform statistics counting for RADIUS over TCP connections. However, implementors are warned that there is no way for these MIB Modules to distinguish between packets sent over UDP or over TCP transport. This does not work. One cannot know what current implementations do. Some may behave as described here, but other may not and could count statistics strictly over UDP as defined in the DESCRIPTION of the MIB objects. You cannot count on that the agent implementations will do, so there is no interoperability. > Implementations of RADIUS over TCP SHOULD include the protocol (UDP) or (TCP) in the radiusAuthServIdent, radiusAuthClientID, radiusAuthClientIdentifier, radiusAccServIdent, radiusAccClientID, or radiusAccClientIdentifier fields of the MIB Module. This information can help the administrator distinguish capabilities of systems in the network. This is also broken. First it is a change in the semantics of the respective objects. This cannot be done even in a MIB document that updates the respective RFCs because of the SMIv2 rules. Then these objects are of a syntax of SnmpAdminString - so including the protocol is based on non-interoperable heuristics. Last, describing the capabilities (UDP, TCP or both) does not indicate what runs and is activated at a certain moment, not to speak cannot indicate anything about specific sessions between clients and servers. The correct solution is for the MIB documents to be updated in the future with new MIB objects of appropriate syntax. For the time being the only thing that this section should say is that the MIB modules do not support RADIUS over TCP and that they will need to be updated in the future. T4. The following section in 2.6.1 is confusing: > Much of the discussion in this section can be summarized by the following requirement. RADIUS requests MAY be re-transmitted verbatim only if the following 5-tuple (Client IP address, Client port, Transport Protocol, Server IP address, Server port) remains the same. Actually this is not a retransmission on the same connection, so I do not know why it needs to be mentioned at all. This aparently contradicts the first paragraph of 2.6.1 which says 'As TCP is a reliable transport, implementations MUST NOT retransmit RADIUS request packets over a given TCP connection.'. T5. The last paragraph in 2.6.1: > The above requirement is necessary, but not sufficient in all cases. Other specifications give additional situations where the packet is to be considered as a new request. Those recommendations MUST also be followed. Having a MUST requirement over undefined 'other specification' is not implementable. I would suggest to either clarify what are these 'other specifications' or take this out.
Proposed Resolution: Discuss
Issue 332: AD Review (Editorial)
Submitter name: Dan Romascanu
Submitter email address: dromasca@avaya.com
Date first submitted: March 9, 2010
Reference: http://ops.ietf.org/lists/radiusext/2010/msg00249.html
Document:
RADTCP
Comment type: Editorial
Priority: 1
Section: Various
Rationale/Explanation of issue:
E1. Please expand TLS at first occurrence.
E2. The Introduction section speaks about 'the default Internet MTU
(576). Strictly speaking this value is not standardized in any place,
and later in section 1.1 reference is made to RADIUS packets being
restricted to 1500 octets in size. Looks like an unnecessary
inconsistency.
E3. Section 1.2 - the syntax in the RADIUS server definition is
inconsistent with the syntax of the rest of the definitions
E4. Section 2.6.7:
> We RECOMMEND that implementors of this specification
familiarize themselves with TCP application programming concepts.
We
RECOMMEND also that existing TCP applications be examined with an
eye
to robustness, performance, scalability, etc.
The use of capitalized (a la 2119) keywords in a personalized phrase
does not make much sense. RECOMMEND is not a keyword actually. I suggest
rephrasing.
Proposed Resolution: Discuss
Issue 333: IESG Review comments
Submitter name: IESG
Submitter email address: iesg@ietf.org
Date first submitted: April 21, 2010
Reference:
http://datatracker.ietf.org/doc/draft-ietf-radext-status-server/
Document:
STATUS-06
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSSes are resolved.
Comment (2010-04-21)
Please consider the comments from the Gen-ART Review by Francis Dupont: - Abstract page 2: there is an explicit reference to a RFC, this is in general forbidden but IMHO we are here in the allowed exception case. - 2.1.1 page 8: a servers policy -> a server policy - 3 page 10 (twice): etc. -> etc., ??? - 4.2 page 13: adminstrators -> administrators - 4.2 page 15 (twice): e.g. -> e.g., - 4.3 page 16: modelled -> modeled - 4.3 page 16: usually the hysteresis against flapping tries to keep the connection (i.e., failover after 3 missed responses), here it is the opposite. IMHO it is very aggressive but it is how RFC 3539 works so I have no concern about it. - 4.5 page 16: Proxyhas -> Proxy has - 4.5 page 17: cannot, -> cannot - 4.5 page 18: i.e. -> i.e., - 5 page 19: EAP-MEssage -> EAP-Message - 8 page 23: synthesise -> synthesize - 8 page 23: in "the suggestion of [RFC5080] Section 2.2.2, which suggests" suggests -> proposes - 8 page 23: configurably is not in my dict? - 9.2 page 23: IMHO the RFC2119 reference should be moved to normative references section (perhaps others too?) - Authors' Addresses -> Author's Address
Comment (2010-04-22)
The document says: The "hop by hop" functionality of Status-Server packets is useful to RADIUS clients attempting to determine the status of elements on the path between the client and a server. This should read: ... determine the status of the first element on the path between ... (because you are not forwarding from the proxy and there are no security associations from a client to proxies beyond the first one, there is no way to test proxies 2 and onwards) The document notes on the discussion of codes and port numbers: However, as the category of [RFC2866] is Informational, this conflict is acceptable. This is merely a statement about the status of various RFCs. Personally, the substantive change is that this new RFC would allow a new code to be used on port 1813. I think it should do an "Updates: RFC 2866" and get it over with.
Discuss (2010-04-19)
Section 4.1., paragraph 2: > The client SHOULD also have a configurable global timer (Tw) that is > used when sending periodic Status-Server queries during server fail- > over. The default value SHOULD be 30 seconds, and the value MUST NOT > be permitted to be set below 6 seconds. If a response has not been > received within the timeout period, the Status-Server packet is > deemed to have received no corresponding Response packet, and MUST be > discarded. DISCUSS: I would like to discuss two issues with this design. First, since it is only RECOMMENDED to implement Tw and not REQUIRED, clients need not do so. How do clients without Tw decide that a server has not responded? Second, there is no discussion on what rate clients should be using when *issuing* Status-Server queries. The current text allows a client to send Status-Server queries to the server at high rates, and does not require the client to reduce its sending rate when it receives no responses. In other words, there currently isn't any sort of congestion control. Has this been discussed by the working group? It seems like all the pieces are already there to implement a simple congestion control scheme: have clients issue at most one request per Tw (already implied by Section 4.3 text but not clearly stated anywhere), double Tw up to some conservative maximum when the server does not respond, restore the initial Tw when it does (Section 4.3 again has some text that goes into that direction).
Comment (2010-04-19)
Section 1812., paragraph 4: > The server MAY prioritize the handling of Status-Server packets over > the handling of other requests, subject to the rate limiting > described above. Without congestion control, implementing this MAY guarantees that the minimum amount of useful (= non-Status-Server) work will be done. Section 4.3., paragraph 3: > If no response is received to Status-Server packets, the RADIUS > client can initiate failover to another proxy. By continuing to send > Status-Server packets to the original proxy at an interval of Tw, the > RADIUS client can determine when the original proxy becomes > responsive again. This uses Status-Server messages as an overload detection mechanism. They need to be sent in a way that will back off the rate under overload, because otherwise the scheme can turn into an overload *generation* mechanism. Section 4.5., paragraph 17: > It is RECOMMENDED, therefore, that implementations desiring the most > benefit from Status-Server also implement server failover. The > combination of these two practices will maximize network reliability > and stability. If Status-Server messages are being sent in a way that is congestion controlled (i.e., the rate is reduced under overload).
Comment (2010-04-22)
I support Lars' and Peter's discuss positions.
Comment (2010-04-22)
Support Lars' discuss re: limiting message rates If there is a reason to perform a major edit on this document, please consider splitting the "documenting what was deployed" and "recommending fixes" into clearly separate sections (if not documents).
Discuss (2010-04-20)
Is the use of MD5 in generating the Response Authenticator subject to collision attacks? If not, it would be helpful to describe why not, and provide a reference to RFC 4270. If so, then the security considerations need to be updated.
Comment (2010-04-20)
Given that the Request Authenticator should be unpredictable and unique, a reference to RFC 4086 would be appropriate. Please add a reference to RFC 1321 for the definition of MD5.
Comment (2010-04-21)
I support Peter's discuss. Additionally, I noted the same thing Peter did wrt to random numbers. Section 3: In the Request Authenticator description the two paragraphs repeat that Request Authentication SHOULD be unpredictable and then says why. Maybe the second paragraph should be tweaked: The Request Authenticator value in a Status-Server packet SHOULD also be unpredictable **because** an attacker **could** trick a server into responding to a predicted future request, and then use the response to masquerade as that server to a future Status-Server request from a client.
Proposed Resolution: Discuss
Issue 334: DTLS Comments
Submitter name: Peter Deacon
Submitter email address:
peterd@iea-software.com
Date first submitted: March 22, 2010
Reference:
http://ops.ietf.org/lists/radiusext/2010/msg00260.html
Document:
DTLS
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
Sec 8.1 - "The previous RADIUS practice of using shared secrets that are minor variations of words is NOT RECOMMENDED, as it would negate nearly all of the security of DTLS."I think any statements WRT secret key strength should to be generalized and take into account the properties of the underlying PSK suite as some systems may or may not be subject to offline attack.
"Any shared secret used for RADIUS MUST NOT be used for DTLS. Reusing a shared secret between RADIUS and DTLS would negate all of the benefits found by using DTLS."I wonder if a more general warning about the possibility of down-negotiation would be a better fit. I can see the same concept applying to administrative selection of cipher-suites.
Sec 4.1.1 - "Where the RADIUS specifications require that a RADIUS packet received via the DTLS session is to be "silently discarded", the entry in the tracking table corresponding to that DTLS session MUST also be deleted, the DTLS session MUST be closed, and any TLS session resumption parameters for that session MUST be discarded."Why is this still done when DTLS is used for a transport? IIRC in the TCP mapped drafts this was done to mitigate possibility of loss of protocol synchronization - not possible WRT DTLS. My concern as with the TCP map is silently discarded messages can take down other unrelated exchanges. The inner RADIUS should speak up while the transport is being established if there is no intention on honoring the established channel. There is an additional concern in that DTLS closure messages have no retransmission timers and are not guaranteed to be delivered. When this occurs future messages will be discarded by the peers DTLS stack until the clients "lifetime" timer expires and the DTLS session is reestablished.
Sec 4.2 - "RDTLS clients SHOULD NOT send both normal RADIUS and RDTLS packets from the same source socket." " and increases the potential for security breaches due to implementation issues."WRT security only it seems to me servers must know better if not explicitly forbidden whether this is done or not. Encouraging (change SHOULD NOT to MAY) can only shine light on the issue and force implementors to address appropriately.
Proposed Resolution: Discuss
Issue 335: Review
Submitter name: Peter Deacon
Submitter email address:
peterd@iea-software.com
Date first submitted: March 1, 2010
Reference:
http://ops.ietf.org/lists/radiusext/2010/msg00227.html
Document:
IPv6-Access
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
3.1.I'm confused on IPv6-Framed-Address and Framed-IPv6-Prefix from RFC 3162. It looks as if both attributes accomplish the same goal. Is there a difference between IPv6-Framed-Address and Framed-IPv6-Prefix of /128?
[Bernard Aboba]
| > DHCPv6 is capable of assignment
of both single addresses and prefixes. Delegation is addressed in RFC 4818. > If the /128 prefix approach is used should I expect that an IP would be assigned to the end user? You should not expect a DHCPv6 address to be assigned. On some NASes I wouldn't expect *any* address to be assigned. |
Proposed Resolution: Discuss
Issue 336:
Submitter name:
Submitter email address:
Date first submitted:
Reference:
Document:
Comment type:
Priority:
Section:
Rationale/Explanation of issue:
Proposed Resolution: Discuss
Issue 337:
Submitter name:
Submitter email address:
Date first submitted:
Reference:
Document:
Comment type:
Priority:
Section:
Rationale/Explanation of issue:
Proposed Resolution: Discuss
Issue 338:
Submitter name:
Submitter email address:
Date first submitted:
Reference:
Document:
Comment type:
Priority:
Section:
Rationale/Explanation of issue:
Proposed Resolution: Discuss
Issue 339:
Submitter name:
Submitter email address:
Date first submitted:
Reference:
Document:
Comment type:
Priority:
Section:
Rationale/Explanation of issue:
Proposed Resolution: Discuss
Issue 340:
Submitter name:
Submitter email address:
Date first submitted:
Reference:
Document:
Comment type:
Priority:
Section:
Rationale/Explanation of issue:
Proposed Resolution: Discuss
Issue 341:
Submitter name:
Submitter email address:
Date first submitted:
Reference:
Document:
Comment type:
Priority:
Section:
Rationale/Explanation of issue:
Proposed Resolution: Discuss
Issue 342:
Submitter name:
Submitter email address:
Date first submitted:
Reference:
Document:
Comment type:
Priority:
Section:
Rationale/Explanation of issue:
Proposed Resolution: Discuss
Issue 343:
Submitter name:
Submitter email address:
Date first submitted:
Reference:
Document:
Comment type:
Priority:
Section:
Rationale/Explanation of issue:
Proposed Resolution: Discuss
Issue 344:
Submitter name:
Submitter email address:
Date first submitted:
Reference:
Document:
Comment type:
Priority:
Section:
Rationale/Explanation of issue:
Proposed Resolution: Discuss
Issue 345:
Submitter name:
Submitter email address:
Date first submitted:
Reference:
Document:
Comment type:
Priority:
Section:
Rationale/Explanation of issue:
Proposed Resolution: Discuss
Issue 346:
Submitter name:
Submitter email address:
Date first submitted:
Reference:
Document:
Comment type:
Priority:
Section:
Rationale/Explanation of issue:
Proposed Resolution: Discuss