Subject: Re: RADEXT WG Charter, Take 10
From: Jari Arkko <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Date: Wed, 21 Apr 2004 12:56:16 +0300

Hi Dave,

>>c. Delete separate item for R/D compatibility and
>>    handle that per application, in the work items.
>>    Add specific text to this effect.
> 
> 
> I'm not sure why a general compatibility requirement is not sufficient.
> While the exact nature of the compatibility provisions in each draft may
> vary by application, it would not seem to be necessary to "outline" the
> specific form in the charter -- only to require its presence.  The
> specific form of the compatibility provisions, to meet the general
> requirement, ought to be part of the WG's work product. Or so it seems
> to me, anyway.

I think we agree on the general requirement. I guess
how specific the charter gets in this matter is a matter
of taste and judgement. My opinion of making it very
specific was based on technical and process views that
I explain below.

The technical views are that application translation is best
handled in an application specific way rather than as
a generic translation document, and that attribute-only
applications should work as-is. The process view is that
I'd like to have the translation available at the time
when the RADIUS application is published rather than
later (which also implies that translation design can
have an effect in the application design.)

Of course, most of this can take place even if the
charter just includes the general statement. But if the
charter includes a specific work item for translation,
however, it seems to imply a separate document rather
than a section.

>>d. Add a requirement that when plain attributes are
>>    added (as in LAN), they should be directly R/D
>>    compatible.
> 
> 
> Hmm...  Can you give an example of a "plain" attribute that would not
> automatically be directly compatible (unless, of course it conflicted
> with an existing Diameter AVP)?

Yes. (Indeed, this is not a very hard requirement.)
Conflicts with existing AVPs are one possible problem.
I can't list other problems, but I can't guarantee
that there aren't any.

>>e. Change the description of 2486bis a bit to
>>    include fixing errors and handling privacy.
> 
> 
> This seems reasonable.

Ok.

>>f. Specify what the Digest work has to be compatible
>>    with (RFC 2617/3261/3310).
> 
> 
> Could you please elaborate a little on this?

Digest has been originally defined in RFC 2617
for HTTP. It has since then applied in SIP context
in RFC 3261, and in addition to the original MD5
algorithm, a new algorithm was defined in RFC 3310.
In some cases products have to support all of them.
I think whatever RFC we make for RADIUS SIP/Digest
support, it should be compatible with these RFCs.

>>So where does that leave us? None of my proposals
>>got into version 10 of the charter, except point
>>c sort of half-way: R/D item was deleted from the
>>charter but not replaced by a requirement to have
>>a Diameter Translation Considerations section :-(
> 
> 
> I tend to think that some general level of Diameter compatibility
> requirement should be added back into the charter.

Yes.

Btw, I think charter 10 had a general compatibility
*requirement*:

> - All RADIUS work MUST be compatible with equivalent facilities in
>   Diameter.

But it lacks the *work item*, from charter 8:

> - RADIUS/Diameter translation.  This document will describe the
>   best current practices for RADIUS/Diameter translation.

Personally, I think per-application (e.g. prepaid) translation
discussion would be more appropriate. But it may also be
that I have misunderstood the item, and the specific translation
discussion is still in the applications and this is just some
general discussion & guidelines document?

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 17 Apr 2004 17:26:40 +0000
Date: Sat, 17 Apr 2004 13:25:57 -0400
From: John Vollbrecht <[email-masked]>
To: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: RADEXT WG Charter, Take 10

This sounds good to me. I think the item "- All RADIUS work MUST be 
compatible with equivalent facilities in Diameter"  is good to keep the 
work in sync with Diameter without having to deal with Diameter issues when 
extending RADIUS capabilities not in Diameter.

Is there - or will there be - and issues list for this?

-- John

--On Thursday, April 15, 2004 4:52 PM -0700 Bernard Aboba 
<[email-masked]> wrote:

> Just thought I'd post the most recent charter text, so that folks could
> have a last look at it.  Based on the previous discussion, it did not
> appear that there was a concensus to change the focus to handling both
> RADIUS & Diameter in a single charter.
>
> ---------------------------------------------------------------------
> RADIUS Extensions Working Group (RADEXT) Charter
> Last Modified: 2004-04-12
>
> Chair(s):
> David Nelson <[email-masked]>
> Bernard Aboba <[email-masked]>
>
> Operations and Management Area Director(s):
> David Kessens <[email-masked]>
> Bert Wijnen <[email-masked]>
>
> Operations and Management Area Advisor:
> David Kessens <[email-masked]>
>
> Technical Advisor:
> Paul Congdon <[email-masked]>
>
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: [email-masked], In Body: subscribe
> Archive: http://ops.ietf.org/lists/radiusext
>
> Description of Working Group:
>
> The RADIUS Extensions Working Group will focus on extensions to the
> RADIUS protocol required to enable its use in applications
> such as IP telephony and Local Area Network authentication, authorization
> and accounting.
>
> In order to ensure backward compatibility with existing RADIUS
> implementations, as well as compatibility between RADIUS and Diameter, the
> following restrictions are imposed on extensions considered by the RADEXT
> WG:
>
> - All RADIUS work MUST be backward compatible with existing RADIUS RFCs,
>   including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580.
>
> - The RADIUS maximum packet size (4K) will not be increased.
> - No new RADIUS transports (e.g. TCP, SCTP) will be defined.
>
> Work Items
>
> The immediate goals of the RADEXT working group are to address the
> following issues:
>
> - RADIUS design guidelines.  This document will provide guidelines
>   for design of RADIUS attributes, including discussion of the
>   appropriate use of RADIUS SDO-Specific Attributes (SSAs). This
>   document will also review RADIUS data types and associated
>   backwards compatibility issues, and may address common
>   RADIUS implementation errors and fixes.
>
> - Revised NAI specification.  This document, known as "RFC 2486bis"
>   will revise the NAI specification to provide more details on
>   routing as well as handling internationalization.
>
> - Pre-paid support.  Prepaid services are contemplated in a number
>   of potential applications, including wireless LAN access and IP
>   telephony.  In order to enable support of pre-paid services in an
>   interoperable way, the WG will provide definitions of the
>   attributes required to support operator service models for
>   pre-paid, as documented in liaison communications.
>   This document will be compatible with Diameter Credit Control.
>
> - SIP support.  RADIUS is currently used for SIP authentication,
>   authorization and accounting.  Standardization of these attributes
>   will enable improved interoperability.
>
> - LAN attributes.  New attributes have been proposed to enable use of
>   authentication, authorization and accounting in wired and
>   wireless LANs.  Standardization of these attributes will enable
>   improved interoperability.
>
> - RADIUS MIB update.  RFC 2618-2621 lack IPv6 compatiblity, and modest
>   changes are required to address this issue.
>
> Goals and Milestones:
>
> Dec 04  Updated RADIUS MIBs submitted for publication.
> Dec 04  RADIUS design guidelines submitted as an Informational RFC.
> Dec 04  SIP RADIUS authentication draft submitted as a Proposed Standard
>         RFC.
> Feb 05  WLAN attributes draft submitted as a Proposed Standard RFC.
> Feb 05  RFC 2486bis submitted as a Proposed Standard.
> Dec 05  LAN attributes draft submitted as a Proposed Standard RFC.
> Dec 05  RADIUS Prepaid draft submitted as a Proposed Standard RFC.
>
> Quality Control Plan
>
> In order to ensure quality of work:
>
> * This WG will not be chartered until sufficient resources can be
>   demonstrated to be available to guarantee a high probability of
>   success.  This includes recruitment of a core of editors and
>   reviewers with significant IETF experience and demonstrated time
>   commitment.
>
> * All drafts will need to undergo review prior to acceptance as WG work
>   items, which includes demonstration that the drafts are backward
>   compatible with RADIUS RFCs and are compatible with equivalent
>   facilities in Diameter.  Given the backwards compatibility issues, no
>   document including sub-attributes will be considered for publication as
>   an RFC before the RADIUS design guidelines and RADIUS/Diameter
>   translation work items are completed, analyzing the issues in
>   a comprehensive way.
>
> * The WG will utilize an automated issue tracking system.
>
> * XML to RFC will be used in production of documents.  This enables
>   production of HTML and text files from a single source file as
>   well as automated production of difference files.
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 16 Apr 2004 19:04:20 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Charter, Take 10
Date: Fri, 16 Apr 2004 15:04:00 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Jari Arkko writes...

> ... But the original proposal from
> me was not exactly that. It was a group of things:
>=20
> a. Have the name reflect the already agreed scope.

It appears that there is no consensus to change the name, because the
current proposed name, RADEXT, does reflect the agreed scope.  While
there are constraints on the RADIUS work items, to address Diameter
compatibility, there does not seem to be consensus to do any
Diameter-only work in the proposed WG.  Does that sound right?

> c. Delete separate item for R/D compatibility and
>     handle that per application, in the work items.
>     Add specific text to this effect.

I'm not sure why a general compatibility requirement is not sufficient.
While the exact nature of the compatibility provisions in each draft may
vary by application, it would not seem to be necessary to "outline" the
specific form in the charter -- only to require its presence.  The
specific form of the compatibility provisions, to meet the general
requirement, ought to be part of the WG's work product. Or so it seems
to me, anyway.

> d. Add a requirement that when plain attributes are
>     added (as in LAN), they should be directly R/D
>     compatible.

Hmm...  Can you give an example of a "plain" attribute that would not
automatically be directly compatible (unless, of course it conflicted
with an existing Diameter AVP)?

> e. Change the description of 2486bis a bit to
>     include fixing errors and handling privacy.

This seems reasonable.

> f. Specify what the Digest work has to be compatible
>     with (RFC 2617/3261/3310).

Could you please elaborate a little on this?

<snip>

> So where does that leave us? None of my proposals
> got into version 10 of the charter, except point
> c sort of half-way: R/D item was deleted from the
> charter but not replaced by a requirement to have
> a Diameter Translation Considerations section :-(

I tend to think that some general level of Diameter compatibility
requirement should be added back into the charter.

> I still do believe points c through f are important
> technical requirements to state in the charter, and
> I did not see an opposition for these points -- can
> we include at least them in the version 11?

See comments, above.

> Regarding points a and b I don't know what to
> do. I still think its important, but I'm getting
> tired of arguing. Would it help to ask the issue
> again, making it clearer what the proposal is
> (i.e. no scope extension)?

I think that the focus is clear from the discussion on the list, and the
name probably appropriate, given that the scope of work does not include
new Diameter work.  Diameter compatibility is required (in some
appropriate fashion) and the WG name doesn't change that, IMHO.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 16 Apr 2004 09:16:27 +0000
Date: Fri, 16 Apr 2004 12:13:07 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Beck01, Wolfgang" <[email-masked]>
Cc: [email-masked]
Subject: Re: Questions about RfC3310 and RADIUS HTTP-Digest

Beck01, Wolfgang wrote:
> Jari,
> 
> while preparing the -02 version of the sterman draft, I discovered that
> it would take an additional message exchange to handle AKA. In the
> previous versions of the draft, nonces where only generated by the RADIUS
> client. Assuming that authentication vectors are user-specific, this would
> not work with AKA. So I included an optional message exchange. However,
> after re-reading my changes, the word "optional" turned up quite frequently.
> A bad thing in a standard.
> 
> - Do we need RADIUS server generated nonces in other scenarios than AKA?

Right now, the only algorithms defined and in use
with Digest are MD5 and AKA. Its kind of hard
to say what other things will come in the future.

It seems that there's another general situation,
however, that may require the same roundtrip:
parameters. RFC 2617 defines the parameters (nonce
is one but there can be others), and those can
appear already in the challenge. Perhaps some
future algorithm or Digest extension would utilize
the parameters in a user-specific way, which would
lead to the same additional roundtrip.

> - Would it be better to put RADIUS AKA Digest into a separate
>   (informational) document?

I'd really like to see the RADIUS Digest work be
able to handle all existing Digest algorithms,
and full RFC 2617 syntax. I'm sorry that Digest
AKA gives you additional things to worry about.
If you don't see other way than an optional
additional roundtrip, then we probably need it.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 16 Apr 2004 08:16:24 +0000
content-class: urn:content-classes:message
Subject: RE: Questions about RfC3310 and RADIUS HTTP-Digest
Date: Fri, 16 Apr 2004 11:11:56 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi,

One advantage of RADIUS-server-generated nonces is that the
RADIUS client (SIP server/NAS/whatever) can't replay old
exchanges to the AAA server.

That might be useful for normal Digest authentication too,
especially in roaming situations (i.e., RADIUS client and=20
server don't belong to the same operator). But it does
add a roundtrip, which might be bad..

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Beck01, Wolfgang
> Sent: Friday, April 16, 2004 10:32 AM
> To: [email-masked]; [email-masked]
> Subject: Questions about RfC3310 and RADIUS HTTP-Digest
>=20
>=20
> Jari,
>=20
> while preparing the -02 version of the sterman draft, I=20
> discovered that it would take an additional message exchange=20
> to handle AKA. In the previous versions of the draft, nonces=20
> where only generated by the RADIUS client. Assuming that=20
> authentication vectors are user-specific, this would
> not work with AKA. So I included an optional message=20
> exchange. However, after re-reading my changes, the=20
> word "optional" turned up quite frequently.
> A bad thing in a standard.
>=20
> - Do we need RADIUS server generated nonces in other=20
> scenarios than AKA?
> - Would it be better to put RADIUS AKA Digest into a separate
>   (informational) document?
>=20
> Wolfgang

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 16 Apr 2004 07:32:54 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Questions about RfC3310 and RADIUS HTTP-Digest
Date: Fri, 16 Apr 2004 09:32:26 +0200

Jari,

while preparing the -02 version of the sterman draft, I discovered that
it would take an additional message exchange to handle AKA. In the
previous versions of the draft, nonces where only generated by the RADIUS
client. Assuming that authentication vectors are user-specific, this would
not work with AKA. So I included an optional message exchange. However,
after re-reading my changes, the word "optional" turned up quite frequently.
A bad thing in a standard.

- Do we need RADIUS server generated nonces in other scenarios than AKA?
- Would it be better to put RADIUS AKA Digest into a separate
  (informational) document?

Wolfgang

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 16 Apr 2004 05:11:30 +0000
Date: Fri, 16 Apr 2004 08:08:05 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: RADEXT WG Charter, Take 10

Bernard Aboba wrote:
> Just thought I'd post the most recent charter text, so that folks could
> have a last look at it.  Based on the previous discussion, it did not
> appear that there was a concensus to change the focus to handling both
> RADIUS & Diameter in a single charter.

I hate to be the one who complains all the time,
but... I think the question was more complex than
changing the focus to handle both protocols. I
think the question you asked from the group was
whether there needs to be a re-orient to handle
both protocols. But the original proposal from
me was not exactly that. It was a group of things:

a. Have the name reflect the already agreed scope.
b. Reword the intro too.
c. Delete separate item for R/D compatibility and
    handle that per application, in the work items.
    Add specific text to this effect.
d. Add a requirement that when plain attributes are
    added (as in LAN), they should be directly R/D
    compatible.
e. Change the description of 2486bis a bit to
    include fixing errors and handling privacy.
f. Specify what the Digest work has to be compatible
    with (RFC 2617/3261/3310).

Note that there's no "merge with AAA WG" or
"add a lot of Diameter work into the charter".
Now, in the discussion on the list the following
comments were made:

o  Suggestion was supported by John, Greg, David
    (and me of course).

o  Parviz and Farid said that the set of work
    items should stay roughly the same, that
    the name change is a different issue (they
    didn't say what they thought of it), and
    that R/D compatibility issues can be considered.

o  Richard, Kuntal and Avi didn't want to have
    a common focus. (Though I judging from Avi's
    e-mail he seemed to be responding to a proposal
    to merge the AAA and RADEXT WGs, which I don't
    think anyone was proposing.)

o  Wolfgang seemed to be OK with my suggested
    formulation of Digest charter entry.

o  Lionel had a question on what my proposal was.
    Not sure if he got an answer to it.

Its kind of hard to determine what the consensus for
all of my items was based on this information. I think
it is clear that everyone, including me, agreed that the
set of work items should stay the same (with the
possible exception of the R/D compatibility item).

I think there was support for doing the R/D compatibility
stuff the way that I proposed (my points c and d).
Wolfgang seemed to be OK with point f. No one responded
about point e, but I'm the current document author for
that, so can we assume that the if there were no complaints
then its acceptable?

Points a and b are harder. Its kind of hard to tell
whether the people who said no said so because they
didn't want to add new work items or because they
didn't agree that the current set of items justifies
the name.

So where does that leave us? None of my proposals
got into version 10 of the charter, except point
c sort of half-way: R/D item was deleted from the
charter but not replaced by a requirement to have
a Diameter Translation Considerations section :-(
I still do believe points c through f are important
technical requirements to state in the charter, and
I did not see an opposition for these points -- can
we include at least them in the version 11?

Regarding points a and b I don't know what to
do. I still think its important, but I'm getting
tired of arguing. Would it help to ask the issue
again, making it clearer what the proposal is
(i.e. no scope extension)?

--Jari

> ---------------------------------------------------------------------
> RADIUS Extensions Working Group (RADEXT) Charter
> Last Modified: 2004-04-12
> 
> Chair(s):
> David Nelson <[email-masked]>
> Bernard Aboba <[email-masked]>
> 
> Operations and Management Area Director(s):
> David Kessens <[email-masked]>
> Bert Wijnen <[email-masked]>
> 
> Operations and Management Area Advisor:
> David Kessens <[email-masked]>
> 
> Technical Advisor:
> Paul Congdon <[email-masked]>
> 
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: [email-masked], In Body: subscribe
> Archive: http://ops.ietf.org/lists/radiusext
> 
> Description of Working Group:
> 
> The RADIUS Extensions Working Group will focus on extensions to the
> RADIUS protocol required to enable its use in applications
> such as IP telephony and Local Area Network authentication, authorization
> and accounting.
> 
> In order to ensure backward compatibility with existing RADIUS
> implementations, as well as compatibility between RADIUS and Diameter, the
> following restrictions are imposed on extensions considered by the RADEXT
> WG:
> 
> - All RADIUS work MUST be backward compatible with existing RADIUS RFCs,
>   including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580.
> - All RADIUS work MUST be compatible with equivalent facilities in
>   Diameter.
> - The RADIUS maximum packet size (4K) will not be increased.
> - No new RADIUS transports (e.g. TCP, SCTP) will be defined.
> 
> Work Items
> 
> The immediate goals of the RADEXT working group are to address the
> following issues:
> 
> - RADIUS design guidelines.  This document will provide guidelines
>   for design of RADIUS attributes, including discussion of the
>   appropriate use of RADIUS SDO-Specific Attributes (SSAs). This
>   document will also review RADIUS data types and associated
>   backwards compatibility issues, and may address common
>   RADIUS implementation errors and fixes.
> 
> - Revised NAI specification.  This document, known as "RFC 2486bis"
>   will revise the NAI specification to provide more details on
>   routing as well as handling internationalization.
> 
> - Pre-paid support.  Prepaid services are contemplated in a number
>   of potential applications, including wireless LAN access and IP
>   telephony.  In order to enable support of pre-paid services in an
>   interoperable way, the WG will provide definitions of the
>   attributes required to support operator service models for
>   pre-paid, as documented in liaison communications.
>   This document will be compatible with Diameter Credit Control.
> 
> - SIP support.  RADIUS is currently used for SIP authentication,
>   authorization and accounting.  Standardization of these attributes
>   will enable improved interoperability.
> 
> - LAN attributes.  New attributes have been proposed to enable use of
>   authentication, authorization and accounting in wired and
>   wireless LANs.  Standardization of these attributes will enable
>   improved interoperability.
> 
> - RADIUS MIB update.  RFC 2618-2621 lack IPv6 compatiblity, and modest
>   changes are required to address this issue.
> 
> Goals and Milestones:
> 
> Dec 04  Updated RADIUS MIBs submitted for publication.
> Dec 04  RADIUS design guidelines submitted as an Informational RFC.
> Dec 04  SIP RADIUS authentication draft submitted as a Proposed Standard
>         RFC.
> Feb 05  WLAN attributes draft submitted as a Proposed Standard RFC.
> Feb 05  RFC 2486bis submitted as a Proposed Standard.
> Dec 05  LAN attributes draft submitted as a Proposed Standard RFC.
> Dec 05  RADIUS Prepaid draft submitted as a Proposed Standard RFC.
> 
> Quality Control Plan
> 
> In order to ensure quality of work:
> 
> * This WG will not be chartered until sufficient resources can be
>   demonstrated to be available to guarantee a high probability of
>   success.  This includes recruitment of a core of editors and
>   reviewers with significant IETF experience and demonstrated time
>   commitment.
> 
> * All drafts will need to undergo review prior to acceptance as WG work
>   items, which includes demonstration that the drafts are backward
>   compatible with RADIUS RFCs and are compatible with equivalent
>   facilities in Diameter.  Given the backwards compatibility issues, no
>   document including sub-attributes will be considered for publication as
>   an RFC before the RADIUS design guidelines and RADIUS/Diameter
>   translation work items are completed, analyzing the issues in
>   a comprehensive way.
> 
> * The WG will utilize an automated issue tracking system.
> 
> * XML to RFC will be used in production of documents.  This enables
>   production of HTML and text files from a single source file as
>   well as automated production of difference files.
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Apr 2004 23:46:37 +0000
Date: Thu, 15 Apr 2004 16:52:27 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG Charter, Take 10

Just thought I'd post the most recent charter text, so that folks could
have a last look at it.  Based on the previous discussion, it did not
appear that there was a concensus to change the focus to handling both
RADIUS & Diameter in a single charter.

---------------------------------------------------------------------
RADIUS Extensions Working Group (RADEXT) Charter
Last Modified: 2004-04-12

Chair(s):
David Nelson <[email-masked]>
Bernard Aboba <[email-masked]>

Operations and Management Area Director(s):
David Kessens <[email-masked]>
Bert Wijnen <[email-masked]>

Operations and Management Area Advisor:
David Kessens <[email-masked]>

Technical Advisor:
Paul Congdon <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked], In Body: subscribe
Archive: http://ops.ietf.org/lists/radiusext

Description of Working Group:

The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol required to enable its use in applications
such as IP telephony and Local Area Network authentication, authorization
and accounting.

In order to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter, the
following restrictions are imposed on extensions considered by the RADEXT
WG:

- All RADIUS work MUST be backward compatible with existing RADIUS RFCs,
  including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580.
- All RADIUS work MUST be compatible with equivalent facilities in
  Diameter.
- The RADIUS maximum packet size (4K) will not be increased.
- No new RADIUS transports (e.g. TCP, SCTP) will be defined.

Work Items

The immediate goals of the RADEXT working group are to address the
following issues:

- RADIUS design guidelines.  This document will provide guidelines
  for design of RADIUS attributes, including discussion of the
  appropriate use of RADIUS SDO-Specific Attributes (SSAs). This
  document will also review RADIUS data types and associated
  backwards compatibility issues, and may address common
  RADIUS implementation errors and fixes.

- Revised NAI specification.  This document, known as "RFC 2486bis"
  will revise the NAI specification to provide more details on
  routing as well as handling internationalization.

- Pre-paid support.  Prepaid services are contemplated in a number
  of potential applications, including wireless LAN access and IP
  telephony.  In order to enable support of pre-paid services in an
  interoperable way, the WG will provide definitions of the
  attributes required to support operator service models for
  pre-paid, as documented in liaison communications.
  This document will be compatible with Diameter Credit Control.

- SIP support.  RADIUS is currently used for SIP authentication,
  authorization and accounting.  Standardization of these attributes
  will enable improved interoperability.

- LAN attributes.  New attributes have been proposed to enable use of
  authentication, authorization and accounting in wired and
  wireless LANs.  Standardization of these attributes will enable
  improved interoperability.

- RADIUS MIB update.  RFC 2618-2621 lack IPv6 compatiblity, and modest
  changes are required to address this issue.

Goals and Milestones:

Dec 04  Updated RADIUS MIBs submitted for publication.
Dec 04  RADIUS design guidelines submitted as an Informational RFC.
Dec 04  SIP RADIUS authentication draft submitted as a Proposed Standard
        RFC.
Feb 05  WLAN attributes draft submitted as a Proposed Standard RFC.
Feb 05  RFC 2486bis submitted as a Proposed Standard.
Dec 05  LAN attributes draft submitted as a Proposed Standard RFC.
Dec 05  RADIUS Prepaid draft submitted as a Proposed Standard RFC.

Quality Control Plan

In order to ensure quality of work:

* This WG will not be chartered until sufficient resources can be
  demonstrated to be available to guarantee a high probability of
  success.  This includes recruitment of a core of editors and
  reviewers with significant IETF experience and demonstrated time
  commitment.

* All drafts will need to undergo review prior to acceptance as WG work
  items, which includes demonstration that the drafts are backward
  compatible with RADIUS RFCs and are compatible with equivalent
  facilities in Diameter.  Given the backwards compatibility issues, no
  document including sub-attributes will be considered for publication as
  an RFC before the RADIUS design guidelines and RADIUS/Diameter
  translation work items are completed, analyzing the issues in
  a comprehensive way.

* The WG will utilize an automated issue tracking system.

* XML to RFC will be used in production of documents.  This enables
  production of HTML and text files from a single source file as
  well as automated production of difference files.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 05 Apr 2004 13:43:42 +0000
Date: Mon, 5 Apr 2004 06:50:02 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked]
Subject: Re: Review of RFC 2486bis

Section 1.3:

Change:

"For use in romaing, this function is accomplished via the Network Access
Identifier (NAI) submitted by the user to the NAS in the initial PPP
authentication."

To:

"For use in romaing, this function is accomplished via the Network Access
Identifier (NAI) submitted by the user to the NAS in the initial network
access authentication."

Section 2.1:

It appears to me that the grammar doesn't match the examples. For
example, [email-masked] is a valid NAI but it's not
permitted by the grammar.  Neither is [email-masked], since
"eng" is not a valid realm.

Section 2.1:

It looks like [email-masked] and foo!example.com are valid NAIs based on
this grammar. I think this is not right.

I'd suggest:

nai = username / ([realm "!"] naibase ) / ("@" realm)

naibase = username "@" realm

Section 2.1:

"  The grammar for the NAI is given below, described in ABNF as
   documented in [3].  The grammar for the username is based on [6], and
   the grammar for the realm is an updated version of [1]."

Have we run this grammar through the ABNF checker?

I'm not sure whether the grammar described really is based on [6] for the
username. The way the ichar and istring are defined, they can contain all
128 ASCII characters, using the "\x" format. This is compatible with
IDN for the realm. But is it compatible with SASLPREP or IEN? At one point
IEN was talking about using UTF-8. Time to bring in the experts...

Section 2.3:

Change:

"As a result, realm  portion is typically required in order for the
authentication exchange to be routed to the appropriate server."

To:

"As a result, the realm  portion is typically required in order for the
authentication exchange to be routed to the appropriate server."

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 05 Apr 2004 13:15:26 +0000
Date: Mon, 5 Apr 2004 06:21:48 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked]
Subject: Re: Review of RFC 2486bis

> Another thing that we still need to work on is the international
> NAI support. I do not know the answer to your questions,
> and we have also a design decision of SASLPrep+IDN vs. IEN
> to make. But I think I can get someone who knows about this
> to help out... or input from the list would also be
> appreciated.

My suggestion would be to ask Harald or Patrik Falstrom.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 05 Apr 2004 07:32:40 +0000
Date: Mon, 05 Apr 2004 10:29:19 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Review of RFC 2486bis

Thanks for your review Bernard. I have adopted your
suggestions and placed an editor's revision of the
draft at

   http://www.arkko.com/publications/nai/naibis.txt
   http://www.arkko.com/publications/nai/naibisdiff.txt

Can you check if you like the text that I provided
for the "authoritative" realm issue?

Another thing that we still need to work on is the international
NAI support. I do not know the answer to your questions,
and we have also a design decision of SASLPrep+IDN vs. IEN
to make. But I think I can get someone who knows about this
to help out... or input from the list would also be
appreciated.

Some more comments inline:

Bernard Aboba wrote:

> The original RFC 2486 contained the following text:
> 
> "In order to enhance the interoperability of roaming and tunneling
> services, it is desirable to have a standardized method for
> identifying users.  This document proposes syntax for the Network
> Access Identifier (NAI), the userID submitted by the client during
> PPP authentication. It is expected that this will be of interest for
> support of roaming as well as tunneling."
> 
> In RFC 2486bis, this was changed to:
> 
> "In order to provide roaming services, it is necessary to have a
> standardized method for identifying users.  This document defines the
> syntax for the Network Access Identifier (NAI), the user identity
> submitted by the client during, for instance,  PPP and wireless LAN
> authentication.
> 
> This paragraph appears to deprecate use of the NAI in tunneling
> services as well as to generalize the use of the NAI beyond network
> access.  Recommend changing to:
> 
> "In order to provide roaming services, it is necessary to have a
> standardized method for identifying users.  This document defines the
> syntax for the Network Access Identifier (NAI), the user identity
> submitted by the client during network authentication."

Your text sounds good, thanks. I changed
the draft.

> Section 1 says:
> 
> "   Considerable interest exists for a set of features that fit within
>    the general category of "roaming capability" for dialup Internet
>    users, wireless LAN authentication, and other applications."
> 
> Propose changing to:
> 
> "   Considerable interest exists for a set of features that fit within
>    the general category of "roaming capability" for network access,
>    including dialup Internet users, VPN usage, wireless LAN
>    authentication, and other applications."

Ok. Changed.

> In Section 1.1, change:
> 
> "The Network Access Identifier (NAI) is the userID submitted by the
> client during PPP authentication.  In roaming, the purpose of the
> NAI is to identify the user as well as to assist in the routing of
> the authentication request.  Please note that the NAI may not
> necessarily be the same as the user's e-mail address or the userID
> submitted in an application layer authentication.
> 
>    Network Access Server
>              The Network Access Server (NAS) is the device that clients
>              dial in order to get access to the network. In PPTP
>              terminology this is referred to as the PPTP Access
>              Concentrator (PAC), and in L2TP terminology, it is referred
>              to as the L2TP Access Concentrator (LAC).
> "
> 
> To:
> 
> "The Network Access Identifier (NAI) is the user identity submitted by the
> client during network access authentication.  In roaming, the purpose of
> the NAI is to identify the user as well as to assist in the routing of
> the authentication request.  Please note that the NAI may not
> necessarily be the same as the user's e-mail address or the user identity
> submitted in an application layer authentication.
> 
> Network Access Server
> The Network Access Server (NAS) is the device that clients
> connect to in order to get access to the network. In PPTP
> terminology this is referred to as the PPTP Access
> Concentrator (PAC), and in L2TP terminology, it is referred
> to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it
> is referred to as an Access Point."

Right.

> Change "IPSEC tunnel mode" to "IPsec tunnel mode."

Done.

> In Section 1.2, change:
> 
> "   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
>    "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
>    described in [3]."
> 
> To:
> 
> "   In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
>    "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
>    described in [3]."

Yes.

> In Section 1.3, change:
> 
> "   As described in [8], there are a number of services implementing
>    dialup roaming, and the number of Internet Service Providers involved
>    in roaming consortia is increasing rapidly."
> 
> To:
> 
> "As described in [8], there are a number of providers offering
> network access services, and the number of Internet Service Providers
> involved in roaming consortia is increasing rapidly."

Sounds better.

> In Section 2.1, change:
> 
> "   c           = < a character as specified in
>    Section 2.4
>     >"
> 
> To:
> 
> "   c           = < a character as specified in Section 2.4 >"

Hmm... a bug in xml2rfc. Oh well, substituting with
hardcoded section number text...

> Section 2.2 states:
> 
> "   Devices handling NAIs MUST support an NAI length of at least 253
>    octets.  However, the following interoperability considerations
>    should be noted:
> 
>    o  RFC 2486 required the support of NAIs only up to the length of 72
>       octets.  As a result, it can generally not be assumed that all
>       devices can support 253 octets.
> 
>    o  NAIs are often transported in the User-Name attribute of RADIUS
>       [10].  Unfortunately, RADIUS requires devices to support content
>       lengths of only 63 octets for this attribute.  As a result, it may
>       not be possible to transfer NAIs beyond 63 octets through all
>       devices.  In addition, due to its message structure, RADIUS is
>       unable to support content lengths beyond 253 octets"
> 
> Effectively, this section admits that RFC 2486bis renders existing devices
> non-compliant;  moreover, due to a variety of limitations it is not clear
> that devices could be compliant even if they wanted to.  This seems
> problematic.
> 
> It might make more sense to say:
> 
> "   Devices handling NAIs MUST support an NAI length of at least 72
>    octets.  Support for an NAI length of 253 octets is RECOMMENDED.
>    However, the following implementation issues should be considered:
> 
>    o  NAIs are often transported in the User-Name attribute of RADIUS
>       [10].  Unfortunately, [RFC2865] Section 5.1 states that
>       "the ability to handle at least 63 octets is recommended."
>       As a result, it may not be possible to transfer NAIs
>       beyond 63 octets through all devices.  In addition, since
>       only a single User-Name attribute may be included in a RADIUS
>       message and the maximum attribute length is 253 octets,
>       RADIUS is unable to support NAI lengths beyond 253 octets."

This is better, and makes it possible to retain conformance
in older devices while at the same time recommending a longer
length to be supported.

> Section 2.3 states:
> 
> "  Interpretation of the "username" part of the NAI depends on the realm
>    in question.  Therefore, the "username" part SHOULD be treated as
>    opaque data when processed by nodes that are not authoritative (in
>    some sense) for that realm."
> 
> I am not sure what "authoritative for that realm" means here.  This is
> DNS terminology.  Does it imply that the NAS or RADIUS server supports
> dynamic DNS client udpate or is running a DNS server itself?

I don't think it means that. It simply means that if you are the
RADIUS proxy for FOO.COM you shouldn't mess with the username part
if the domain part is BAR.COM. But I'm not sure how to express this
in exact technical terms. How about this:

    Interpretation of the "username" part of the NAI depends on the realm
    in question. Therefore, the "username" part SHOULD be treated as
    opaque data when processed by nodes that are not a part of the
    authoritative domain (in the sense of Section 4) for that realm.

> Section 2.4 says:
> 
> "
>    Characters of the username portion in a NAI MUST fulfill the
>    requirements specified in [6]."
> 
> Is SASL-Prep the relevant authority here, or is this IEN?  In the

The intention was to have the SASL-Prep be the authority for the
username part and IDN handle the domain part. The other option is
of course to make the whole thing an IEN. This is an open
issue. See also below...

> same vein:
>
> Section 2.5 states:
> 
> "   As proposed in this document, the Network Access Identifier is of the
>    form user@realm.  Please note that while the user portion of the NAI
>    is based on the BNF described in [7], it has been extended for
>    internationalization support as well as for purposes of Section 2.7,
>    and is not necessarily compatible with the usernames used in e-mail.
>    Note also that the internationalization requirements for NAIs and
>    e-mail addresses are different, since the former need to be typed in
>    only by the user himself and his own operator, not by others."
> 
> On the other hand, RFC 2486 states:
> 
> "Please note that while the user portion of the NAI conforms to the
> BNF described in [5]"
> 
> [5] References RFC 822, the SMTP specification.  At the same time,
> Section 4 indicates that there is no requirement that the NAI
> represent a valid email address.  Perhaps we need to get a technical
> advisor to assist us relating to these internationalization issues?

We probably do. I certainly don't know enough about the matter.
In fact, I have some one in mind who knows and has promised to
assist... I'll register this as an issue.

> Section 2.8 does not list "[email-masked]" as a valid NAI, and
> lists "@howard.edu" as an invalid NAI.  I'd restore the former example,
> and given the privacy issues, the latter looks like it should be
> valid now.

Yes. Others have reported these as well. Due to the need to
use official example DNS names, it doesn't say @howard.edu
etc anymore, but my editor's version has these examples as
valid NAIs:

         @privatecorp.example.net
         [email-masked]

> Author's addresses:  for this purpose my email should be:
> [email-masked].

Done.

> Section 4 says:
> 
> "   Note that the use of an FQDN as the realm name does not imply use of
>    the DNS for location of the authentication server or for
>    authentication routing.  Since to date roaming has been implemented
>    on a relatively small scale, existing implementations typically
>    handle location of authentication servers within a domain and perform
>    authentication routing based on local knowledge expressed in proxy
>    configuration files.  The implementations described in [8] have not
>    found a need for use of DNS for location of the authentication server
>    within a domain, although this can be accomplished via use of the DNS
>    SRV record, described in [2].  Similarly, existing implementations
>    have not found a need for dynamic routing protocols, or propagation
>    of global routing information.  Note also that there is no
>    requirement that the NAI represent a valid email address."
> 
> Note that roaming has been widely implemented at this point. I'd revise
> this to say:
> 
> "  Note that the use of an FQDN as the realm name does not imply use of
>    the DNS for location of the authentication server or for
>    authentication routing.  Existing implementations typically
>    handle location of authentication servers within a domain and perform
>    authentication routing based on local knowledge expressed in proxy
>    configuration files.  The implementations described in [8] have not
>    found a need for use of DNS for location of the authentication server
>    within a domain, although this can be accomplished via use of the DNS
>    as described in [13].  Similarly, existing implementations
>    have not found a need for dynamic routing protocols, or propagation
>    of global routing information.  Note also that there is no
>    requirement that that the NAI represent a valid email address."
> 
> Delete reference 2.

Very good. Thanks.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 01 Apr 2004 01:14:16 +0000
Content-Class: urn:content-classes:message
Subject: RE: RE: AAAEXT charter, Take 1
Date: Wed, 31 Mar 2004 17:12:44 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Parviz Yegani" <[email-masked]>, "Kuntal Chowdhury" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

I do agree with you, Parviz.  This is pretty much aligned with what we
discussed/agreed during the last BoF. =20
BR,
FArid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Parviz Yegani
> Sent: Wednesday, March 31, 2004 4:29 PM
> To: Kuntal Chowdhury; [email-masked]
> Cc: [email-masked]
> Subject: RE: RE: AAAEXT charter, Take 1
>=20
>=20
> Kuntal, John,
>=20
> I think we should bring our focus back to the main question=20
> that Bernard asked:
>=20
> "How do other participants feel about a "AAAEXT" charter?=20
> Should we rename the potential WG and re-orient towards=20
> handling both RADIUS and Diameter in a single WG?"
>=20
> I agree that the charter should largely remain the same. The=20
> name change is not the main issue here. If there is a general=20
> agreement on the work items currently included in the charter=20
> then we should go ahead and start the=20
> real work.
>=20
> It seems that John wants to add a new item to address Radius=20
> and Diameter=20
> compatibility.
> Given that there is already R/D compatibility for prepaid and=20
> SIP I'm not=20
> sure what else
> we need to add. Maybe support for common NAI and LAN/WLAN=20
> attributes. If so, let's consider adding these items and move=20
> on. If adequate resources are=20
> available
> to the WG to work on these new items (which seems to be the=20
> case) we should=20
> go ahead
> and finalize the charter and start deliberating on the drafts=20
> that have=20
> been submitted so far.
>=20
> -Parviz
>=20
> At 03:06 PM 3/31/2004 -0600, Kuntal Chowdhury wrote:
> >John,
> >
> > >MIPv6 was not designed to interwork with MIPv4, so if=20
> someone tries=20
> > >to mix them, I am sure they will find problems.
> > >
> >
> >Not sure why you think "simultaneous deployment" means mixing two=20
> >protocols! This is not a MIP thread, therefore I would not=20
> debate over=20
> >MIP issues anymore.
> >
> > >> I don't want to see a repeat of what happened in MIP WG in this=20
> > >> planned WG for RADIUS.
> > >
> > >But I am concerned because Diameter was designed to interwork with=20
> > >RADIUS. If the WG goes of and extends RADIUS in ways that destroys=20
> > >the interworking, then we have a big problem.
> > >
> >
> >I will be perfectly alright to add a sentence in RADEXT=20
> charter to say=20
> >that the work done in this WG shall not destroy interworking with=20
> >DIAMETER. I believe that will address your concern.
> >
> >-Kuntal
> >
> >--
> >to unsubscribe send a message to [email-masked] with=20
> >the word 'unsubscribe' in a single line as the message text body.
> >archive: <http://psg.com/lists/radiusext/>
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 01 Apr 2004 00:29:52 +0000
Date: Wed, 31 Mar 2004 16:29:22 -0800
To: "Kuntal Chowdhury" <[email-masked]>, [email-masked]
From: Parviz Yegani <[email-masked]>
Subject: RE: RE: AAAEXT charter, Take 1
Cc: [email-masked]

Kuntal, John,

I think we should bring our focus back to the main question that Bernard asked:

"How do other participants feel about a "AAAEXT" charter?
Should we rename the potential WG and re-orient towards handling both
RADIUS and Diameter in a single WG?"

I agree that the charter should largely remain the same. The name change is
not the main issue here. If there is a general agreement on the work items
currently included in the charter then we should go ahead and start the 
real work.

It seems that John wants to add a new item to address Radius and Diameter 
compatibility.
Given that there is already R/D compatibility for prepaid and SIP I'm not 
sure what else
we need to add. Maybe support for common NAI and LAN/WLAN attributes. If so,
let's consider adding these items and move on. If adequate resources are 
available
to the WG to work on these new items (which seems to be the case) we should 
go ahead
and finalize the charter and start deliberating on the drafts that have 
been submitted so far.

-Parviz

At 03:06 PM 3/31/2004 -0600, Kuntal Chowdhury wrote:
>John,
>
> >MIPv6 was not designed to interwork with MIPv4, so if someone
> >tries to mix them, I am sure they will find problems.
> >
>
>Not sure why you think "simultaneous deployment" means mixing two protocols!
>This is not a MIP thread, therefore I would not debate over MIP issues
>anymore.
>
> >> I don't want to see a repeat of what happened in MIP WG in this
> >> planned WG for RADIUS.
> >
> >But I am concerned because Diameter was designed to interwork
> >with RADIUS. If the WG goes of and extends RADIUS in ways that
> >destroys the interworking, then we have a big problem.
> >
>
>I will be perfectly alright to add a sentence in RADEXT charter to say that
>the work done in this WG shall not destroy interworking with DIAMETER. I
>believe that will address your concern.
>
>-Kuntal
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>