Subject: RE: Continued discussion of RADIUS Crypto-Agility
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Date: Tue, 31 Jul 2007 15:13:07 -0400

Glen Zorn writes...

> So did the keywrap draft, it's implementations & even the NIST
> certification of those implementations...

Is information about the implementation(s) and the NIST certification
thereof available to the WG?  That may be interesting and significant
background information.

--
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: Tue, 31 Jul 2007 19:09:21 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Tue, 31 Jul 2007 12:08:23 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

David B. Nelson <> allegedly scribbled on Tuesday, July 31, 2007 11:25
AM:

> Glen Zorn writes...
>=20
>> To 1) ignore our charter (not to mention the (at best) disingenuous
>> '?' regarding it in the presentation)...
>=20
> To be fair, the authors of this ID did indicate they knew it was out
> of charter scope, and therefore not eligible for the Crypto-Agility
> solution, at the time that they requested the presentation slot in
> RADEXT.  The "?" apparently came about as a result of discussions in
> the O&M Area WG earlier in the week. =20

So can we appropriately blame this nonsense (surprise!) on the IESG?=20

>=20
>> ...and 2) ignore the written requirements ...
>=20
> Of course, the implementation of RADSEC predated our requirements
> document.=20

So did the keywrap draft, it's implementations & even the NIST
certification of those implementations (by a matter of years).  So what?

>=20
>> Therefore, I must insist that the RADSEC proposal be treated as only
>> a an informative presentation ...
>=20
> Point noted.

--
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: Tue, 31 Jul 2007 18:24:57 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Tue, 31 Jul 2007 14:25:00 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...

> To 1) ignore our charter (not to mention the (at best) disingenuous
> '?' regarding it in the presentation)...

To be fair, the authors of this ID did indicate they knew it was out of
charter scope, and therefore not eligible for the Crypto-Agility solution,
at the time that they requested the presentation slot in RADEXT.  The "?"
apparently came about as a result of discussions in the O&M Area WG earlier
in the week.

> ...and 2) ignore the written requirements ...

Of course, the implementation of RADSEC predated our requirements document.

> Therefore, I must insist that the RADSEC proposal be treated as 
> only a an informative presentation ...

Point noted.

--
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: Tue, 31 Jul 2007 18:06:56 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Tue, 31 Jul 2007 11:06:17 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

David B. Nelson <> allegedly scribbled on Tuesday, July 31, 2007 9:08
AM:

> I will be working on the minutes for the RADEXT WG session at IETF-69
> in the next week or so.  In the meantime, I would like to very
> briefly summarize the discussion of the RADIUS Crypto-Agility work
> item held during IETF-69 and strongly encourage that discussion to
> continue here on the list.   =20
>=20
> The presentations may be found at:
>=20
> https://datatracker.ietf.org/meeting/69/materials.html
>=20
> Scroll down to the RADEXT section.
>=20
> Three potential solutions were discussed:
>=20
> (a) RADIUS Key-Wrap and RADIUS Encrypted Attributes (Zorn, et. al.)
>=20
> (b) RADIUS over DTLS (DeKok)
>=20
> (c) RADIUS over TLS, a.k.a. RADSEC (Winter, et. al.)
>=20
> The first two proposals are within the scope of the current RADEXT WG
> charter.  The third proposal is currently out of scope, because it
> encompasses a new transport layer protocol for RADIUS (TCP). =20

Not only is it out of scope of the charter, it directly violates a
number of the restrictions placed on the crypto-agility submissions from
the actual members of the WG.  I, for one, have at least been aware of
the RADSEC activities for a couple of years now but for some reason they
have not deigned to inform the radext WG of them until now.  To 1)
ignore our charter (not to mention the (at best) disingenuous '?'
regarding it in the presentation) and 2) ignore the written requirements
that every one else had to follow seems to me at the very least
arrogant.  Note that I am _not_ 'hostile to the idea' -- I am, however,
hostile toward arrogant academics proffering "new" schemes (that have
been around for years in one form or another) in direct contradiction of
the rules the rest of us (who actually participate in the WG, not just
drop by with our works of genius ;-) must follow.  Therefore, I must
insist that the RADSEC proposal be treated as only a an informative
presentation (in the nature of an informative liaison) and not accepted
as a candidate for the crypto-agility solution. =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: Tue, 31 Jul 2007 16:08:30 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: Continued discussion of RADIUS Crypto-Agility
Date: Tue, 31 Jul 2007 12:08:14 -0400
Organization: Elbrys Networks, Inc.

I will be working on the minutes for the RADEXT WG session at IETF-69 in the
next week or so.  In the meantime, I would like to very briefly summarize
the discussion of the RADIUS Crypto-Agility work item held during IETF-69
and strongly encourage that discussion to continue here on the list.

The presentations may be found at:

https://datatracker.ietf.org/meeting/69/materials.html

Scroll down to the RADEXT section.

Three potential solutions were discussed:

(a) RADIUS Key-Wrap and RADIUS Encrypted Attributes (Zorn, et. al.)

(b) RADIUS over DTLS (DeKok)

(c) RADIUS over TLS, a.k.a. RADSEC (Winter, et. al.)

The first two proposals are within the scope of the current RADEXT WG
charter.  The third proposal is currently out of scope, because it
encompasses a new transport layer protocol for RADIUS (TCP).

There were some spirited discussions about the pros and cons of each
approach during the meeting.  I'd like to see those discussions continue on
the list.

In informal straw polls, there seemed to be a slight preference for proposal
(a) over proposal (b).  There was approximately equal support for proposals
(b) and (c), however there were approximately as many in the room who
opposed proposal (c) as who supported it.

Needless to say, this does not constitute consensus.  :-)

I would like to ask all those who participated in the discussion in Chicago,
was well as the rest of the members on the list, to continue this
discussion.  If you have not read the relevant IDs, please read them NOW.
The chairs will be attempting to gauge, over the next few weeks, whether
there is consensus on the list to more forward with one of these proposals
as a Proposed Standard RFC.

I there is not clear consensus to pick one submission, then the chairs will
ask the WG if there is consensus to advance tow or more proposals as
Experimental RFCs, letting the market make the final selection.

We won't be waiting until IETF-70 to make this decision, as this important
charter milestone is very late.  Now that several other WG work items have
been submitted to the IESG for consideration, please turn your attention to
the RADIUS Crypto-Agility work item.

Thank You!!!

Regards,

Dave Nelson

--
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: Tue, 31 Jul 2007 12:06:47 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'Romascanu, Dan \(Dan\)'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Request for publication of Internet Draft draft-ietf-radext-rfc3576bis-08.txt
Date: Tue, 31 Jul 2007 08:06:42 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_0179_01C7D349.C15BA2F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

On behalf of the RADEXT WG, I am requesting the publication of the

Internet Draft described herein as an Informational RFC.  WGLC on

This document concluded on June 27, 2007. All issues have been

addressed.

--------------------------------------------------------------------

Title:

Common Dynamic Authorization Extensions to Remote Authentication Dial

In User Service (RADIUS) I-D:

http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-08.txt

Status: Informational

(1.a) Who is the Document Shepherd for this document? Has the Document

Shepherd personally reviewed this version of the document and, in 

particular, does he or she believe this version is ready for forwarding 

to the IESG for publication?

The Document Shepherd is David Nelson. I have personally reviewed the

document.

(1.b) Has the document had adequate review from both key WG members

And key non-WG members? Does the Document Shepherd have any concerns

about the depth or breadth of the reviews that have been performed?

Yes. This document has been through two RADEXT WG last calls.

(1.c) Does the Document Shepherd have concerns that the document needs

more review from a particular or broader perspective e.g., security, 

operational complexity, someone familiar with AAA, internationalization

or XML?

This document is a revision of RFC 3576, so there is existing 

operational experience.

(1.d) Does the Document Shepherd have any specific concerns or issues

with this document that the Responsible Area Director and/or the IESG

should be aware of?  For example, perhaps he or she is uncomfortable 

with certain parts of the document, or has concerns whether there 

really is a need for it. In any event, if the WG has discussed those

issues and has indicated that it still wishes to advance the document,

detail those concerns here. Has an IPR disclosure related to this

document been filed? If so, please include a reference to the disclosure

and summarize the WG discussion and conclusion on this issue.

No concerns.

(1.e) How solid is the WG consensus behind this document?  Does it

represent the strong concurrence of a few individuals, with others

being silent, or does the WG as a whole understand and agree with

it?

There is consensus behind this document.  At various points,

6 people have posted review comments or made contributions relating

to the document.

The issues raised and the resolutions are available for inspection at

http://www.drizzle.com/~aboba/RADEXT/

(1.f) Has anyone threatened an appeal or otherwise indicated extreme 

discontent? If so, please summarise the areas of conflict in separate 

email messages to the Responsible Area Director. (It should be in a 

separate email because this questionnaire is entered into the ID

Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the document 

satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and

http://tools.ietf.org/tools/idnits/). Boilerplate checks are not 

enough; this check needs to be thorough. Has the document met all

formal review criteria it needs to, such as the MIB Doctor, media 

type and URI type reviews?

Yes. An output of the run on this revision of the ID by the online 

nits checker:

idnits 2.04.09 

tmp/draft-ietf-radext-rfc3576bis-08.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:

----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:

----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:

----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:

----------------------------------------------------------------------------

     No issues found here.

  Checking references for intended status: Informational

----------------------------------------------------------------------------

  == Missing Reference: 'Note 1' is mentioned on line 956, but not

     defined

     '[Note 1] Where NAS or session identification attributes are 

inclu...'

  == Missing Reference: 'Note 3' is mentioned on line 970, but not

     defined

'[Note 3] When included within a CoA-Request, these attributes...'

  == Missing Reference: 'Notes 1' is mentioned on line 908, but not

     defined

'0+        0        0    97   Framed-IPv6-Prefix [Notes 1,6]...'

  -- Looks like a reference, but probably isn't: '6' on line 908

     '0+        0        0    97   Framed-IPv6-Prefix [Notes 1,6]...'

  == Missing Reference: 'Note 2' is mentioned on line 962, but not

     defined

     '[Note 2] The Reply-Message Attribute is used to present a 

display...'

  == Missing Reference: 'Note 7' is mentioned on line 998, but not

     defined

     '[Note 7] Within CoA-Request packets, Vendor-Specific Attributes...'

  == Missing Reference: 'Note 5' is mentioned on line 982, but not

     defined

'[Note 5] When included within a CoA-Request, these attributes...'

  == Missing Reference: 'Note 4' is mentioned on line 976, but not

     defined

     '[Note 4] When included within a successful Disconnect-Request 

(wh...'

  == Missing Reference: 'Note 6' is mentioned on line 987, but not

     defined

     '[Note 6] Since the Framed-IP-Address, Framed-IPv6-Prefix and 

Fram...'

  ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306)

 

     Summary: 1 error (**), 8 warnings (==), 1 comment (--).

(1.h) Has the document split its references into normative and 

informative? Are there normative references to documents that are not 

ready for advancement or are otherwise in an unclear state? If such 

normative references exist, what is the strategy for their completion? 

Are there normative references that are downward references, as 

described in [RFC3967]? If so, list these downward references to 

support the Area Director in the Last Call procedure for them 

[RFC3967].

The document splits normative and informative references.

There are no normative references to IDs.

(1.i) Has the Document Shepherd verified that the document IANA 

consideration section exists and is consistent with the body of the 

document? If the document specifies protocol extensions, are 

reservations requested in appropriate IANA registries? Are the IANA 

registries clearly identified? If the document creates a new registry,

does it define the proposed initial contents of the registry and an

allocation procedure for future registrations? Does it suggest a 

reasonable name for the new registry? See [RFC2434]. If the document 

describes an Expert Review process has Shepherd conferred with the

Responsible Area Director so that the IESG can appoint the needed 

Expert during the IESG Evaluation?

The document only requests assignment of additional values of 

existing attributes, since most parameters were already allocated in

RFC 3575 and 3576.

(1.j) Has the Document Shepherd verified that sections of the document 

that are written in a formal language, such as XML code, BNF rules, MIB 

definitions, etc., validate correctly in an automated checker?

This document does not contain sections written in a formal language.

(1.k) The IESG approval announcement includes a Document Announcement 

Write-Up. Please provide such a Document Announcement Write-Up? Recent 

examples can be found in the "Action" announcements for approved 

documents. The approval announcement contains the following sections:

  - Technical Summary

This document describes a currently deployed extension to the Remote

Authentication Dial In User Service (RADIUS) protocol, allowing

dynamic changes to a user session, as implemented by network access

server products.  This includes support for disconnecting users and

changing authorizations applicable to a user session. 

  - Working Group Summary

This document represents an update to RFC 3576, addressing issues and 

fixes that have been identified since the document was originally 

published. Originally, these issues were included in the RADIUS Issues

and Fixes document, but were sufficient in number and size to require

a revision to RFC 3576. 

  - Document Quality

This document describes issues that were encountered by implementers of 

RFC 3576. As a result, it has been reviewed by implementers as well as 

operators.

  - Personnel

David Nelson is the document shepherd.  The responsible Area Director is

Dan Romascanu. 

 

------=_NextPart_000_0179_01C7D349.C15BA2F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>On behalf of the =
RADEXT WG,
I am requesting the publication of the<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Internet Draft =
described
herein as an Informational RFC.&nbsp; WGLC =
on<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>This document =
concluded on
June 27, 2007. All issues have been<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>addressed.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>-------------------------------------------------------------------=
-<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Title:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Common Dynamic =
Authorization
Extensions to Remote Authentication Dial<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>In User Service =
(RADIUS) I-D:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'><a
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-=
08.txt">http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-=
08.txt</a><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Status: =
Informational<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>(1.a) Who is the =
Document
Shepherd for this document? Has the =
Document<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Shepherd personally =
reviewed
this version of the document and, in <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>particular, does he =
or she
believe this version is ready for forwarding =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>to the IESG for =
publication?<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>The Document =
Shepherd is
David Nelson. I have personally reviewed =
the<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>document.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>(1.b) Has the =
document had
adequate review from both key WG members<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>And key non-WG =
members? Does
the Document Shepherd have any concerns<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>about the depth or =
breadth
of the reviews that have been performed?<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Yes. This document =
has been
through two RADEXT WG last calls.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>(1.c) Does the =
Document
Shepherd have concerns that the document =
needs<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>more review from a
particular or broader perspective e.g., security, =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>operational =
complexity,
someone familiar with AAA, =
internationalization<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>or =
XML?<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>This document is a =
revision
of RFC 3576, so there is existing <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>operational =
experience.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>(1.d) Does the =
Document
Shepherd have any specific concerns or =
issues<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>with this document =
that the
Responsible Area Director and/or the IESG<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>should be aware =
of?&nbsp;
For example, perhaps he or she is uncomfortable =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>with certain parts =
of the document,
or has concerns whether there <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>really is a need =
for it. In
any event, if the WG has discussed those<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>issues and has =
indicated
that it still wishes to advance the =
document,<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>detail those =
concerns here.
Has an IPR disclosure related to this<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>document been =
filed? If so,
please include a reference to the =
disclosure<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>and summarize the =
WG
discussion and conclusion on this issue.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>No =
concerns.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>(1.e) How solid is =
the WG
consensus behind this document?&nbsp; Does =
it<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>represent the =
strong
concurrence of a few individuals, with =
others<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>being silent, or =
does the WG
as a whole understand and agree with<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>it?<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>There is consensus =
behind
this document.&nbsp; At various points,<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>6 people have =
posted review
comments or made contributions relating<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>to the =
document.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>The issues raised =
and the
resolutions are available for inspection at<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'><a
href=3D"http://www.drizzle.com/~aboba/RADEXT/">http://www.drizzle.com/~ab=
oba/RADEXT/</a><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>(1.f) Has anyone =
threatened
an appeal or otherwise indicated extreme <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>discontent? If so, =
please
summarise the areas of conflict in separate =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>email messages to =
the Responsible
Area Director. (It should be in a <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>separate email =
because this questionnaire
is entered into the ID<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Tracker.)<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>No.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>(1.g) Has the =
Document
Shepherd personally verified that the document =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>satisfies all ID =
nits? (See <a
href=3D"http://www.ietf.org/ID-Checklist.html">http://www.ietf.org/ID-Che=
cklist.html</a>
and<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'><a
href=3D"http://tools.ietf.org/tools/idnits/">http://tools.ietf.org/tools/=
idnits/</a>).
Boilerplate checks are not <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>enough; this check =
needs to
be thorough. Has the document met all<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>formal review =
criteria it needs
to, such as the MIB Doctor, media <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>type and URI type =
reviews?<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Yes. An output of =
the run on
this revision of the ID by the online <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>nits =
checker:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>idnits 2.04.09 =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>tmp/draft-ietf-radext-rfc3576bis-08.txt:<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; Checking =
boilerplate
required by RFC 3978 and 3979, updated by RFC =
4748:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>-------------------------------------------------------------------=
---------<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp; No
issues found here.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; Checking =
nits
according to <a =
href=3D"http://www.ietf.org/ietf/1id-guidelines.txt">http://www.ietf.org/=
ietf/1id-guidelines.txt</a>:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>-------------------------------------------------------------------=
---------<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp; No
issues found here.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; Checking =
nits according
to <a =
href=3D"http://www.ietf.org/ID-Checklist.html">http://www.ietf.org/ID-Che=
cklist.html</a>:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>-------------------------------------------------------------------=
---------<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp; No
issues found here.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; =
Miscellaneous
warnings:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>-------------------------------------------------------------------=
---------<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp; No
issues found here.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; Checking =
references
for intended status: Informational<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>-------------------------------------------------------------------=
---------<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; =3D=3D =
Missing Reference:
'Note 1' is mentioned on line 956, but not<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;
defined<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;
'[Note 1] Where NAS or session identification attributes are =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>inclu...'<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; =3D=3D =
Missing Reference:
'Note 3' is mentioned on line 970, but not<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;
defined<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>'[Note 3] When =
included
within a CoA-Request, these attributes...'<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; =3D=3D =
Missing Reference:
'Notes 1' is mentioned on line 908, but not<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;
defined<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>'0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; =
97&nbsp;&nbsp;
Framed-IPv6-Prefix [Notes 1,6]...'<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; -- Looks =
like a
reference, but probably isn't: '6' on line =
908<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;
'0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; =
97&nbsp;&nbsp;
Framed-IPv6-Prefix [Notes 1,6]...'<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; =3D=3D =
Missing Reference:
'Note 2' is mentioned on line 962, but not<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;
defined<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;
'[Note 2] The Reply-Message Attribute is used to present a =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>display...'<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; =3D=3D =
Missing Reference:
'Note 7' is mentioned on line 998, but not<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;
defined<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;
'[Note 7] Within CoA-Request packets, Vendor-Specific =
Attributes...'<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; =3D=3D =
Missing Reference:
'Note 5' is mentioned on line 982, but not<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;
defined<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>'[Note 5] When =
included
within a CoA-Request, these attributes...'<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; =3D=3D =
Missing Reference:
'Note 4' is mentioned on line 976, but not<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;
defined<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;
'[Note 4] When included within a successful Disconnect-Request =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>(wh...'<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; =3D=3D =
Missing Reference:
'Note 6' is mentioned on line 987, but not<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;
defined<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;
'[Note 6] Since the Framed-IP-Address, Framed-IPv6-Prefix and =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Fram...'<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; ** Obsolete =
normative
reference: RFC 2409 (Obsoleted by RFC 4306)<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;
Summary: 1 error (**), 8 warnings (=3D=3D), 1 comment =
(--).<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>(1.h) Has the =
document split
its references into normative and <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>informative? Are =
there
normative references to documents that are not =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>ready for =
advancement or are
otherwise in an unclear state? If such <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>normative =
references exist,
what is the strategy for their completion? <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Are there normative
references that are downward references, as =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>described in =
[RFC3967]? If
so, list these downward references to <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>support the Area =
Director in
the Last Call procedure for them <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>[RFC3967].<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>The document splits
normative and informative references.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>There are no =
normative
references to IDs.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>(1.i) Has the =
Document
Shepherd verified that the document IANA <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>consideration =
section exists
and is consistent with the body of the <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>document? If the =
document
specifies protocol extensions, are <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>reservations =
requested in
appropriate IANA registries? Are the IANA <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>registries clearly
identified? If the document creates a new =
registry,<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>does it define the =
proposed
initial contents of the registry and an<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>allocation =
procedure for
future registrations? Does it suggest a <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>reasonable name for =
the new
registry? See [RFC2434]. If the document <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>describes an Expert =
Review
process has Shepherd conferred with the<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Responsible Area =
Director so
that the IESG can appoint the needed <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Expert during the =
IESG Evaluation?<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>The document only =
requests
assignment of additional values of <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>existing =
attributes, since
most parameters were already allocated in<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>RFC 3575 and =
3576.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>(1.j) Has the =
Document
Shepherd verified that sections of the document =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>that are written in =
a formal
language, such as XML code, BNF rules, MIB <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>definitions, etc., =
validate
correctly in an automated checker?<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>This document does =
not
contain sections written in a formal =
language.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>(1.k) The IESG =
approval
announcement includes a Document Announcement =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Write-Up. Please =
provide
such a Document Announcement Write-Up? Recent =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>examples can be =
found in the
&quot;Action&quot; announcements for approved =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>documents. The =
approval
announcement contains the following =
sections:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; - Technical =
Summary<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>This document =
describes a
currently deployed extension to the Remote<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Authentication Dial =
In User
Service (RADIUS) protocol, allowing<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>dynamic changes to =
a user
session, as implemented by network access<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>server =
products.&nbsp; This
includes support for disconnecting users =
and<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>changing =
authorizations
applicable to a user session. <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; - Working =
Group
Summary<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>This document =
represents an
update to RFC 3576, addressing issues and <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>fixes that have =
been
identified since the document was originally =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>published. =
Originally, these
issues were included in the RADIUS Issues<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>and Fixes document, =
but were
sufficient in number and size to require<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>a revision to RFC =
3576. <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; - Document =
Quality<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>This document =
describes
issues that were encountered by implementers of =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>RFC 3576. As a =
result, it
has been reviewed by implementers as well as =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>operators.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp; - =
Personnel<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>David Nelson is the =
document
shepherd.&nbsp; The responsible Area Director =
is<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Dan Romascanu. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0179_01C7D349.C15BA2F0--

--
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: Sun, 29 Jul 2007 20:46:24 +0000
Content-class: urn:content-classes:message
Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Sun, 29 Jul 2007 13:45:34 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: "Joseph Salowey \(jsalowey\)" <[email-masked]>, <[email-masked]>

Bernard Aboba <> allegedly scribbled on Sunday, July 29, 2007 10:08 AM:

>> [Joe]  The proposal requires the use of new RADIUS attributes.  All
>> other aspects of the RADIUS protocol can remain the same, so backward
>> compatibility is possible.  However it is important to note that if
>> stronger that current security algorithms are required then backwards
>> compatibility is not possible.
>=20
> [BA] Can you expand on this?  Couldn't a RADIUS packet sent by a NAS
> include both existing and new security attributes for backward
> compatibility? =20

Yes.  However, section 3.3 says "Any packet that contains an instance of
the Message-Authentication-Code Attribute SHOULD NOT contain an instance
of the Message-Authenticator Attribute [RFC3579]."  This implies that
any message that contains an EAP-Message attribute must also include an
instance of the Message-Authentication-Code attribute (though I don't
think that that is spelled out).  So, for EAP exchanges over RADIUS at
least, there would be no problem determining whether or not the client
is "legacy" because it would include an instance of the
Message-Authenticator attribute in the Access-Request(s).

>=20
>> 6. 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.=20
>>=20
>> [Joe] Depending upon the selection of the key the new protection can
>> be completely separate from the existing protection.  The selection
>> of the key is currently a deployment choice.
>=20
> [BA] If the existing RADIUS security mechanism is compromised, how
> does this affect the security of the negotiation?  For example, if
> both existing and new attributes are sent, couldn't an attacker strip
> off the new attributes and recalculate the Message-Authenticator
> attribute?=20

As an aside, AFAIK the fact that a secret key algorithm 'provide(s)
little or no security' if the key is compromised has nothing to do with
the strength or weakness of the algorithm itself (as is implied above).
Be that as it may, however, you are correct, I think.  That's why the
"SHOULD NOT" referenced above was included; in fact, it was a MUST NOT
in early versions of the draft (up to -07, I think) & I'd be happy to
return to that usage.  I don't really think that that would affect
backwards compatibility too much (if at all).

...

>> 10. Proposals MUST include a Diameter compatibility section, although
>> it is expected that the work will occur purely within RADIUS or in
>> the transport, and therefore does not affect message data that is
>> exchanged with Diameter.=20
>>=20
>> [Joe] A Diameter compatibility section will need to be added.
>=20
> [BA] In terms of processing wouldn't a RADIUS/Diameter gateway just
> strip off the new attributes?=20

Probably, yes.  Unfortunately: our drafts offer at least the possibility
of end-to-end cryptographic protection of both complete and partial
messages & the standard Diameter gateway processing would defeat that.

> Or are changes to RFC 4072 implementations required?

--
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: Sun, 29 Jul 2007 17:09:14 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Sun, 29 Jul 2007 10:08:08 -0700

>[Joe]  The proposal requires the use of new RADIUS attributes.  All
>other aspects of the RADIUS protocol can remain the same, so backward
>compatibility is possible.  However it is important to note that if
>stronger that current security algorithms are required then backwards
>compatibility is not possible.

[BA] Can you expand on this?  Couldn't a RADIUS packet sent by a NAS include 
both existing and new security attributes for backward compatibility?

>6. 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.
>
>[Joe] Depending upon the selection of the key the new protection can be
>completely separate from the existing protection.  The selection of the
>key is currently a deployment choice.

[BA] If the existing RADIUS security mechanism is compromised, how does this 
affect the security of the negotiation?  For example, if both existing and 
new attributes are sent, couldn't an attacker strip off the new attributes 
and recalculate the Message-Authenticator attribute?

>INTEROPERABILITY AND CHANGE CONTROL
>
>7. Proposals MUST indicate a willingness to cede change control to the
>IETF.
>
>[Joe] Change control can be cede. An informational RFC may be published
>to document existing implementations.

[BA] Do existing implementations use VSAs?

>10. Proposals MUST include a Diameter compatibility section, although it
>is expected that the work will occur purely within RADIUS or in the
>transport, and therefore does not affect message data that is exchanged
>with Diameter.
>
>[Joe] A Diameter compatibility section will need to be added.

[BA] In terms of processing wouldn't a RADIUS/Diameter gateway just strip 
off the new attributes?
Or are changes to RFC 4072 implementations required?

--
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: Wed, 25 Jul 2007 18:15:58 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-fixes-05.txt 
Date: Wed, 25 Jul 2007 14:15:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: Common Remote Authentication Dial In User Service (RADIUS)
	Author(s)	: D. Nelson, A. DeKok
	Filename	: draft-ietf-radext-fixes-05.txt
	Pages		: 26
	Date		: 2007-7-25
	
This document describes common issues seen in RADIUS implementations
   and suggests some fixes.  Where applicable, ambiguities and errors in
   previous RADIUS specifications are clarified.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-fixes-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-fixes-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-fixes-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-fixes-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--
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: Wed, 25 Jul 2007 15:00:00 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Slides for IETF 69
Date: Wed, 25 Jul 2007 07:59:25 -0700

--_93e78b6b-1a04-4596-b14e-492c80f172ed_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is a request for all presenters at the RADEXT session of IETF-69(Thurs=
day, Morning I session, 9:00 AM Salon 2) to send a copy of yourslides to th=
e chairs NOW.  We will ensure that your slidesare posted to the Meeting Mat=
erials web page for both local and remoteparticipants, and will have them s=
taged for expeditious projection duringthe meeting. PowerPoint and PDF form=
ats are preferred.  Please send yourslides as soon as possible.  Thanks! Pl=
ease refer to the RADEXT agenda for details of your presentation slot. http=
://www3.ietf.org/proceedings/07jul/agenda/radext.txt=

--_93e78b6b-1a04-4596-b14e-492c80f172ed_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
This is a request for all presenters at the RADEXT session of IETF-69<BR>(T=
hursday, Morning I session, 9:00 AM Salon 2) to send a copy of your<BR>slid=
es to the chairs NOW.&nbsp; We will ensure that your slides<BR>are posted t=
o the Meeting Materials web page for both local and remote<BR>participants,=
 and will have them staged for expeditious projection during<BR>the meeting=
. PowerPoint and PDF formats are preferred.&nbsp; Please send your<BR>slide=
s as soon as possible.&nbsp; Thanks!<BR>&nbsp;<BR>Please refer to the RADEX=
T agenda for details of your presentation slot.<BR>&nbsp;<BR><A href=3D"htt=
p://www3.ietf.org/proceedings/07jul/agenda/radext.txt" target=3D_blank>http=
://www3.ietf.org/proceedings/07jul/agenda/radext.txt</A></body>
</html>=

--_93e78b6b-1a04-4596-b14e-492c80f172ed_--

--
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: Tue, 24 Jul 2007 16:16:26 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Requests for slides
Date: Tue, 24 Jul 2007 09:15:14 -0700

--_20d3b162-f99f-4e3f-a0ec-17e327011e07_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

If you are presenting at the IETF 69 RADEXT WG meeting, please send slides =
to David and myself. =

--_20d3b162-f99f-4e3f-a0ec-17e327011e07_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
If you are presenting at the IETF 69 RADEXT WG meeting, please send slides =
to David and myself. <br></body>
</html>=

--_20d3b162-f99f-4e3f-a0ec-17e327011e07_--

--
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, 23 Jul 2007 21:23:46 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: FW: RADEXT & DIME review of a MBONED ID
Date: Mon, 23 Jul 2007 14:23:06 -0700

--_3d274919-91cd-4baf-8cdf-52a0e0bed3ef_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> To: [email-masked]; [email-masked]; [email-masked];=
 [email-masked]> Subject: RADEXT & DIME review of a MBONED ID> D=
ate: Thu, 12 Jul 2007 16:25:03 -0400> From: [email-masked]> > > MBONED has=
 been working on "AAA Framework for Multicasting"> (draft-ietf-mboned-multi=
aaa-framework-04.txt) - the topic> seems to overlap the work in both of you=
r WGs> > can you take a quick look to see if it would be reasonable to> hav=
e a working group last call type of review of the document> in both the rad=
ext and dime WGs?> > Tnx> > > Scott> > -------- Forwarded Message -------->=
 Subject: I-D ACTION:draft-ietf-mboned-multiaaa-framework-04.txt> Date: Thu=
, 12 Jul 2007 12:15:18 -0400> From: [email-masked]> Reply-To: int=
[email-masked]> To: [email-masked]> CC: [email-masked]> > > =
> A New Internet-Draft is available from the on-line Internet-Drafts > dire=
ctories.> This draft is a work item of the MBONE Deployment Working Group o=
f the IETF.> > Title : AAA Framework for Multicasting> Author(s) : H. Satou=
, et al.> Filename : draft-ietf-mboned-multiaaa-framework-04.txt> Pages : 2=
0> Date : 2007-7-12> > IP multicast-based services, such as TV broadcasting=
 > or videoconferencing raise the issue of making sure > that potential cus=
tomers are fully entitled to access > the corresponding contents. There is =
indeed a need > for service and content providers to identify (if not > aut=
henticate, especially within the context of > enforcing electronic payment =
schemes) and to invoice > such customers in a reliable and efficient manner=
. > This memo describes the framework for specifying the > Authorization, A=
uthentication and Accounting (AAA) > capabilities that could be activated w=
ithin the > context of the deployment and the operation of IP > multicast-b=
ased services. This framework addresses > the requirements presented in dra=
ft-ietf-mboned-> maccnt-req-04.txt, "Requirements for Accounting, > Authent=
ication and Authorization in Well Managed IP > Multicasting Services". The =
memo provides a basic AAA > enabled model as well as an extended fully enab=
led > model with resource and admission control > coordination.> > A URL fo=
r this Internet-Draft is:> http://www.ietf.org/internet-drafts/draft-ietf-m=
boned-multiaaa-framework-04.txt> > ...=

--_3d274919-91cd-4baf-8cdf-52a0e0bed3ef_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
<BR><BR>&gt; To: [email-masked]; [email-masked]; dave@fr=
ascone.com; [email-masked]<BR>&gt; Subject: RADEXT &amp; DIME re=
view of a MBONED ID<BR>&gt; Date: Thu, 12 Jul 2007 16:25:03 -0400<BR>&gt; F=
rom: [email-masked]<BR>&gt; <BR>&gt; <BR>&gt; MBONED has been working on "=
AAA Framework for Multicasting"<BR>&gt; (draft-ietf-mboned-multiaaa-framewo=
rk-04.txt) - the topic<BR>&gt; seems to overlap the work in both of your WG=
s<BR>&gt; <BR>&gt; can you take a quick look to see if it would be reasonab=
le to<BR>&gt; have a working group last call type of review of the document=
<BR>&gt; in both the radext and dime WGs?<BR>&gt; <BR>&gt; Tnx<BR>&gt; <BR>=
&gt; <BR>&gt; Scott<BR>&gt; <BR>&gt; -------- Forwarded Message --------<BR=
>&gt; Subject: I-D ACTION:draft-ietf-mboned-multiaaa-framework-04.txt<BR>&g=
t; Date: Thu, 12 Jul 2007 12:15:18 -0400<BR>&gt; From: Internet-Drafts@ietf=
.org<BR>&gt; Reply-To: [email-masked]<BR>&gt; To: i-d-announce@ie=
tf.org<BR>&gt; CC: [email-masked]<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; A New=
 Internet-Draft is available from the on-line Internet-Drafts <BR>&gt; dire=
ctories.<BR>&gt; This draft is a work item of the MBONE Deployment Working =
Group of the IETF.<BR>&gt; <BR>&gt; Title : AAA Framework for Multicasting<=
BR>&gt; Author(s) : H. Satou, et al.<BR>&gt; Filename : draft-ietf-mboned-m=
ultiaaa-framework-04.txt<BR>&gt; Pages : 20<BR>&gt; Date : 2007-7-12<BR>&gt=
; <BR>&gt; IP multicast-based services, such as TV broadcasting <BR>&gt; or=
 videoconferencing raise the issue of making sure <BR>&gt; that potential c=
ustomers are fully entitled to access <BR>&gt; the corresponding contents. =
There is indeed a need <BR>&gt; for service and content providers to identi=
fy (if not <BR>&gt; authenticate, especially within the context of <BR>&gt;=
 enforcing electronic payment schemes) and to invoice <BR>&gt; such custome=
rs in a reliable and efficient manner. <BR>&gt; This memo describes the fra=
mework for specifying the <BR>&gt; Authorization, Authentication and Accoun=
ting (AAA) <BR>&gt; capabilities that could be activated within the <BR>&gt=
; context of the deployment and the operation of IP <BR>&gt; multicast-base=
d services. This framework addresses <BR>&gt; the requirements presented in=
 draft-ietf-mboned-<BR>&gt; maccnt-req-04.txt, "Requirements for Accounting=
, <BR>&gt; Authentication and Authorization in Well Managed IP <BR>&gt; Mul=
ticasting Services". The memo provides a basic AAA <BR>&gt; enabled model a=
s well as an extended fully enabled <BR>&gt; model with resource and admiss=
ion control <BR>&gt; coordination.<BR>&gt; <BR>&gt; A URL for this Internet=
-Draft is:<BR>&gt; http://www.ietf.org/internet-drafts/draft-ietf-mboned-mu=
ltiaaa-framework-04.txt<BR>&gt; <BR>&gt; ...<BR></body>
</html>=

--_3d274919-91cd-4baf-8cdf-52a0e0bed3ef_--

--
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, 23 Jul 2007 19:36:29 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: Reminder of RADEXT session at IETF-69
Date: Mon, 23 Jul 2007 15:36:15 -0400
Organization: Elbrys Networks, Inc.

Just a reminder that RADEXT will be meeting at IETF-69 on Thursday, July 26,
2007 at 9:00 AM CDT.  We will post the slides on the IETF Meeting Materials
site https://datatracker.ietf.org/meeting/69/materials.html

You may follow the session remotely using the streaming audio of the session
http://videolab.uoregon.edu/events/ietf/ietf697.m3u

and via a Jabber session [email-masked]

Regards,

Dave Nelson

--
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, 23 Jul 2007 16:06:35 +0000
Content-class: urn:content-classes:message
Subject: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Mon, 23 Jul 2007 09:03:02 -0700
From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
To: <[email-masked]>

SECURITY SERVICES

2. Proposals MUST support the negotiation of cryptographic algorithms
for per-packet integrity/authentication protection. =20
Support for confidentiality of entire RADIUS packets is OPTIONAL. =20
However, proposals MUST support the negotiation of algorithms for
encryption (sometimes referred to as "hiding") of RADIUS attributes.
If possible, it is desirable for proposals to provide for the encryption
of existing attributes.  This includes existing "hidden"
attributes as well as attributes (such as location attributes) that
require confidentiality.

Included in negotiation techniques are "hint and consent" mechanisms
where the NAS provides a list of algorithms and the server selects one.

[Joe] Algorithms within the proposal are identified so they can be
replaced.  The client can specify the algorithm it wishes the server to
use. =20

=20
3. Proposals MUST support replay protection.  The existing mechanisms
for replay protection are considered adequate and should be maintained.

[Joe] Existing replay protection mechanisms are maintained

4. Crypto-agility solutions MUST specify mandatory-to-implement
algorithms for each mechanism.

[Joe] Mandatory to implement algorithms are specified (AES-CBC,
AES-Keywrap, HMAC-SHA1)

BACKWARD COMPATIBILITY

5. 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.

[Joe]  The proposal requires the use of new RADIUS attributes.  All
other aspects of the RADIUS protocol can remain the same, so backward
compatibility is possible.  However it is important to note that if
stronger that current security algorithms are required then backwards
compatibility is not possible.

6. 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.

[Joe] Depending upon the selection of the key the new protection can be
completely separate from the existing protection.  The selection of the
key is currently a deployment choice. =20

INTEROPERABILITY AND CHANGE CONTROL

7. Proposals MUST indicate a willingness to cede change control to the
IETF.

[Joe] Change control can be cede. An informational RFC may be published
to document existing implementations.=20

8. Crypto-agility solutions MUST be interoperable between independent
implementations based purely on the information provided in the
specification.

[Joe] Interoperable implementations exist based on this specification.
These implementations use VSAs instead of standard attributes.=20

SCOPE OF WORK

9. Crypto-agility solutions MUST apply to all RADIUS packet types,
including Access-Request, Challenge, Reject & Accept,
Accounting-Request/Response, and CoA/Disconnect messages.
=20
[Joe] The attributes described can be added to any of these mechanisms.=20

10. Proposals MUST include a Diameter compatibility section, although it
is expected that the work will occur purely within RADIUS or in the
transport, and therefore does not affect message data that is exchanged
with Diameter.

[Joe] A Diameter compatibility section will need to be added.=20
=20
11. Crypto-agility solutions SHOULD NOT require fundamental changes to
The RADIUS operational model, such as the introduction of new commands
Or maintenance of state on the RADIUS server.  Similarly, a proposal
Should focus on the crypto-agility problem and nothing else.  For
example, proposals should not require new attribute formats or include
definition of new RADIUS services.  Unless modified, the restrictions in
the RADEXT WG charter apply.

[Joe] This solution works well with the existing implementations.  It
does not require major changes to the RADIUS protocol.  In particular it
does not necessarily introduce new "session" state maintenance
requirements on the server. =20

Note that for the purposes of this work, the RADEXT WG charter
Restriction against definition of "new security mechanisms" should be
interpreted as prohibiting changes to the basic RADIUS packet format
(e.g. headers), but permits new crypto-algorithms to be substituted For
use in existing security mechanisms.=20

[Joe] This is what the proposal does.  It is very close to existing
RADIUS protection mechanisms requiring minimal change to existing
implementations.=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: Fri, 20 Jul 2007 13:06:37 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: Revised RADEXT Agenda for IETF-69
Date: Fri, 20 Jul 2007 09:06:25 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_008C_01C7CAAD.40E12B80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

IETF 69 RADEXT WG Agenda

Thursday, July 26, 2007

9 AM - 11:30 AM

Chairs:  Bernard Aboba & David Nelson

9 AM - 9:10 AM Preliminaries

    Blue Sheets

    Note Takers

    Jabber Scribe

    Agenda bashing

    Document status

Documents completing IETF last call (10 minutes)

9:10 - 9:20:  Issues & Fixes, Alan DeKok

http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-04.txt

Documents completing RADEXT WG last call (10 minutes)

9:20 - 9:30 Attributes for Filtering & Redirection, Mauricio Sanchez

http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-03.txt

Documents in pre-WG work item review (20 minutes)

9:30 - 9:40 Attribute Type Extension, Avi Lior

http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extensi
on-02.txt

9:40 - 9:50 WLAN Attributes, Bernard Aboba

http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.txt

Design Guidelines (20 minutes)

9:50 - 10:10 Design Guidelines, Bernard Aboba

RADIUS Crypto-Agility (50 minutes)

10:10 - 10:20 RADEXT Crypto-agility Requirements and Selection Process,

David Nelson

10:20 - 10:30 RADIUS + DTLS (Alan DeKoK)

http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-00.txt

10:30 - 10:50 RADIUS Crypto-agility (Joe Salowey)

http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt

http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-06.txt

10:50 - 11:10 Discussion

Miscellaneous (20 minutes)

11:10 - 11:20 RADSEC (Stefan Winter)

http://www.ietf.org/internet-drafts/draft-winter-radsec-00.txt

11:20 - 11:30 RADIUS attributes for Domain-specific Key Request

and Delivery (Lakshminath Dondeti)

http://www.ietf.org/internet-drafts/draft-gaonkar-radext-erp-attrs-00.txt

 

------=_NextPart_000_008C_01C7CAAD.40E12B80
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 65.95pt 1.0in 65.95pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>IETF 69 RADEXT WG Agenda<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Thursday, July 26, 2007<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>9 AM - 11:30 AM<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Chairs:&nbsp; Bernard Aboba &amp; David =
Nelson<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>9 AM - 9:10 AM Preliminaries<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp; Blue Sheets<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp; Note Takers<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp; Jabber Scribe<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp; Agenda bashing<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp; Document status<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Documents completing IETF last call (10 =
minutes)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>9:10 - 9:20:&nbsp; Issues &amp; Fixes, Alan =
DeKok<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-04.tx=
t<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Documents completing RADEXT WG last call (10 =
minutes)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>9:20 - 9:30 Attributes for Filtering &amp; Redirection, Mauricio
Sanchez<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rule=
s-03.txt<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Documents in pre-WG work item review (20 =
minutes)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>9:30 - 9:40 Attribute Type Extension, Avi =
Lior<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-t=
ype-extension-02.txt<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>9:40 - 9:50 WLAN Attributes, Bernard =
Aboba<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.tx=
t<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Design Guidelines (20 minutes)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>9:50 - 10:10 Design Guidelines, Bernard =
Aboba<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>RADIUS Crypto-Agility (50 minutes)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>10:10 - 10:20 RADEXT Crypto-agility Requirements and Selection =
Process,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>David Nelson<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>10:20 - 10:30 RADIUS + DTLS (Alan =
DeKoK)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-00.tx=
t<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>10:30 - 10:50 RADIUS Crypto-agility (Joe =
Salowey)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.=
txt<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-06.=
txt<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>10:50 - 11:10 Discussion<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Miscellaneous (20 minutes)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>11:10 - 11:20 RADSEC (Stefan =
Winter)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-winter-radsec-00.txt<o:=
p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>11:20 &#8211; 11:30 RADIUS attributes for Domain-specific Key =
Request<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>and Delivery (Lakshminath Dondeti)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-gaonkar-radext-erp-attr=
s-00.txt<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_008C_01C7CAAD.40E12B80--

--
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: Wed, 18 Jul 2007 04:11:01 +0000
Content-class: urn:content-classes:message
Subject: RE: comments on draft-gaonkar-radext-erp-attrs-00
Date: Tue, 17 Jul 2007 21:09:38 -0700
From: "Narayanan, Vidya" <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>, "Dondeti, Lakshminath" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

> >=20
> > The point I was making was that evolving link layers can certainly=20
> > include this functionality.
>=20
> If the people evolving those link layers are a) paying any=20
> attention at all to what we're doing, b) are as willing as we=20
> seem to be to depend upon massive layer violations to get=20
> things going and c) actually know what the identity is to be=20
> in all cases.  For example, I can't for the life of me=20
> imagine why L2 would know or care about a specific hostname=20
> (which after all is an L6 identifier). =20

Well, stranger things have been exchanged at L2 for various reasons,
but, that's not important.=20

> In any case, this is=20
> the Internet Engineering Task Force, not the Every Lame=20
> Transport on the Planet Engineering Task Force; we should do=20
> our own engineering in a way that our protocols are (as much=20
> as possible) independent of other folks'. =20

And we are.  The exchange of this data via ERP bootstrapping is totally
independent of the lower layer.=20

> This appears to me=20
> to be one of the cases where any reliance on a lower layer=20
> not under our control is not just unnecessary but detrimental.
>=20

As I agreed, no need to debate that.  We have an independent mechanism
to convey the necessary information and can ensure protocol completeness
via that.=20

Vidya

--
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: Wed, 18 Jul 2007 01:45:46 +0000
Content-class: urn:content-classes:message
Subject: RE: comments on draft-gaonkar-radext-erp-attrs-00
Date: Tue, 17 Jul 2007 18:44:48 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Narayanan, Vidya" <[email-masked]>, "Dondeti, Lakshminath" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Narayanan, Vidya <mailto:[email-masked]> allegedly scribbled on
Tuesday, July 17, 2007 5:59 PM:

>> ...
>>=20
>>> Not sure I understand.  It is very much feasible to provide the
>>> identity (of the domain or the HOKEY server) to the peer via the
>>> lower layer.
>>=20
>> OK, cool.  Please provide a list of 1) all target lower layers and b)
>> how, precisely this identity is provided to the peer _now_.
>>=20
>=20
> The point I was making was that evolving link layers can certainly
> include this functionality. =20

If the people evolving those link layers are a) paying any attention at
all to what we're doing, b) are as willing as we seem to be to depend
upon massive layer violations to get things going and c) actually know
what the identity is to be in all cases.  For example, I can't for the
life of me imagine why L2 would know or care about a specific hostname
(which after all is an L6 identifier).  In any case, this is the
Internet Engineering Task Force, not the Every Lame Transport on the
Planet Engineering Task Force; we should do our own engineering in a way
that our protocols are (as much as possible) independent of other
folks'.  This appears to me to be one of the cases where any reliance on
a lower layer not under our control is not just unnecessary but
detrimental.

...

--
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: Wed, 18 Jul 2007 01:01:48 +0000
Content-class: urn:content-classes:message
Subject: RE: comments on draft-gaonkar-radext-erp-attrs-00
Date: Tue, 17 Jul 2007 17:59:06 -0700
From: "Narayanan, Vidya" <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>, "Dondeti, Lakshminath" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

=20

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]]=20
> Sent: Tuesday, July 17, 2007 4:33 PM
> To: Narayanan, Vidya; Dondeti, Lakshminath
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: comments on draft-gaonkar-radext-erp-attrs-00
>=20
> Narayanan, Vidya <mailto:[email-masked]> allegedly=20
> scribbled on Tuesday, July 17, 2007 4:18 PM:
>=20
> ...
>=20
> > Not sure I understand.  It is very much feasible to provide the=20
> > identity (of the domain or the HOKEY server) to the peer=20
> via the lower=20
> > layer.
>=20
> OK, cool.  Please provide a list of 1) all target lower=20
> layers and b) how, precisely this identity is provided to the=20
> peer _now_.
>  =20

The point I was making was that evolving link layers can certainly
include this functionality.  But, as indicated below, the protocol
doesn't rely on this possibility and hence, for this discussion, we can
avoid focusing on that.=20

> > Also, ERP bootstrapping is capable of providing this=20
> identity to the=20
> > peer - so, a lower layer capability here is not a MUST.
>=20
> OK, if it's not necessary let's not talk about it any more &=20
> simply say that, shall we?
>=20

That's fine :)=20

> > More below
> > on why the peer needs this identity. =20
> >=20
> >>> and via RADIUS protocol to the RADIUS server.
> >>=20
> >> In the case where the DSRK server is separated from the=20
> home RADIUS=20
> >> server by one or more proxies, why should the home server=20
> believe the=20
> >> identity it receives?
> >>=20
> >>> The peer can
> >>> communicate the identity in an end-to-end protected manner to the=20
> >>> server, thus forcing the DSRK server to present the same=20
> identity to=20
> >>> the peer and the server.
> >>=20
> >> I still have problems understanding the utility of this.
> >> Leaving aside the "lying proxy" problem, let's take an=20
> example from=20
> >> real life: suppose that someone introduces himself to a=20
> young woman=20
> >> as "Ted Bundy" and she checks with a trusted friend who=20
> confirms this=20
> >> claimed identity.  If neither the young woman nor her friend knows=20
> >> that "Ted Bundy" is a vicious serial killer, what good does this=20
> >> confirmation do?  If you assume that the DSRK server cannot be=20
> >> trusted (otherwise why force it to do anything?), then why=20
> does the=20
> >> fact that it's not lying about its _name_ magically make it=20
> >> trustworthy?
> >>=20
> >=20
> > I agree with you that channel bindings does not provide for=20
> > correctness in identity, it only provides a consistency check.  In=20
> > this case, however, I don't think channel bindings is the=20
> reason for=20
> > the identity being sent.  The DSRK derivation takes the requesting=20
> > entity's domain name or server ID as input to the PRF. Both parties=20
> > deriving the key (the Home AAA/EAP server and the peer)=20
> need to know=20
> > this identity so that the DSRK can be derived.  I believe=20
> that is the=20
> > reason the identity needs to be provided along with a request for=20
> > DSRK.
>=20
> OK, but that's not what was said above...it seems to me that=20
> for the purpose you mention the name of the local DSRK server=20
> could as or more easily be supplied by the home server to the=20
> peer,=20

Yes, this capability is already in the protocol, as part of
bootstrapping.=20

> rather than relying upon a lower layer (maybe you've=20
> noticed that I don't care for that ;-).
>=20

That seems established :) The point is that we don't need to mandate
that the peer go through the bootstrapping process, IF it happened to
know the identity by means outside the protocol. There's always the
choice that it gets it from the home server as part of bootstrapping, if
the lower layer cannot provide such information.=20

Vidya

> > Unless the peer and the server are given the same value, the DSRK=20
> > cannot be derived correctly at both ends - so, the property=20
> of channel=20
> > bindings may be inherently provided for the DSRK by virtue of
> > that.          =20
> >=20
> > Vidya
>=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: Tue, 17 Jul 2007 23:33:41 +0000
Content-class: urn:content-classes:message
Subject: RE: comments on draft-gaonkar-radext-erp-attrs-00
Date: Tue, 17 Jul 2007 16:32:44 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Narayanan, Vidya" <[email-masked]>, "Dondeti, Lakshminath" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Narayanan, Vidya <mailto:[email-masked]> allegedly scribbled on
Tuesday, July 17, 2007 4:18 PM:

...

> Not sure I understand.  It is very much feasible to provide the
> identity (of the domain or the HOKEY server) to the peer via the
> lower layer.

OK, cool.  Please provide a list of 1) all target lower layers and b)
how, precisely this identity is provided to the peer _now_.
 =20
> Also, ERP bootstrapping is capable of providing this identity to the
> peer - so, a lower layer capability here is not a MUST. =20

OK, if it's not necessary let's not talk about it any more & simply say
that, shall we?

> More below
> on why the peer needs this identity. =20
>=20
>>> and via RADIUS protocol to the RADIUS server.
>>=20
>> In the case where the DSRK server is separated from the home RADIUS
>> server by one or more proxies, why should the home server believe
>> the identity it receives?=20
>>=20
>>> The peer can
>>> communicate the identity in an end-to-end protected manner to the
>>> server, thus forcing the DSRK server to present the same identity to
>>> the peer and the server.
>>=20
>> I still have problems understanding the utility of this.
>> Leaving aside the "lying proxy" problem, let's take an example from
>> real life: suppose that someone introduces himself to a young woman
>> as "Ted Bundy" and she checks with a trusted friend who confirms this
>> claimed identity.  If neither the young woman nor her friend knows
>> that "Ted Bundy" is a vicious serial killer, what good does this
>> confirmation do?  If you assume that the DSRK server cannot be
>> trusted (otherwise why force it to do anything?), then why does the
>> fact that it's not lying about its _name_ magically make it
>> trustworthy?=20
>>=20
>=20
> I agree with you that channel bindings does not provide for
> correctness in identity, it only provides a consistency check.  In
> this case, however, I don't think channel bindings is the reason for
> the identity being sent.  The DSRK derivation takes the requesting
> entity's domain name or server ID as input to the PRF. Both parties
> deriving the key (the Home AAA/EAP server and the peer) need to know
> this identity so that the DSRK can be derived.  I believe that is the
> reason the identity needs to be provided along with a request for
> DSRK. =20

OK, but that's not what was said above...it seems to me that for the
purpose you mention the name of the local DSRK server could as or more
easily be supplied by the home server to the peer, rather than relying
upon a lower layer (maybe you've noticed that I don't care for that ;-).

> Unless the peer and the server are given the same value, the
> DSRK cannot be derived correctly at both ends - so, the property of
> channel bindings may be inherently provided for the DSRK by virtue of
> that.          =20
>=20
> Vidya

--
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: Tue, 17 Jul 2007 23:19:10 +0000
Content-class: urn:content-classes:message
Subject: RE: comments on draft-gaonkar-radext-erp-attrs-00
Date: Tue, 17 Jul 2007 16:17:57 -0700
From: "Narayanan, Vidya" <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>, "Dondeti, Lakshminath" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

<snip>

> >=20
> > The requesting entity might be a DSRK server.
>=20
> What is a "DSRK server"?  Is it the same as a hokey server? =20
>=20

In my mind, that is practically the case.  I guess in theory, one could
say that the entity that holds the DSRK doesn't need to also be the
HOKEY server.  I can't make a practical case for that though.=20

> >=20
> >> believe that the RADIUS server in a remote network would have any=20
> >> knowledge of it, even less so in the case where the=20
> visited and home=20
> >> networks are separated by one or more proxies & thus lack=20
> any direct=20
> >> trust relationship.  If this identity is meant to be used for key=20
> >> binding purposes, I think that this is incredibly=20
> dangerous, imputing=20
> >> trust as it does between the home RADIUS server and an entity of=20
> >> which
> >=20
> > The DSRK server can provide its identity via the lower layer to the=20
> > peer
>=20
> One of the things that bothers me a lot about the proposals=20
> we're seeing is the tendency to rely upon unspecified and=20
> possibly non-existent "lower layer" mechanisms.  I think that=20
> this is unnecessary.
>=20

Not sure I understand.  It is very much feasible to provide the identity
(of the domain or the HOKEY server) to the peer via the lower layer.
Also, ERP bootstrapping is capable of providing this identity to the
peer - so, a lower layer capability here is not a MUST.  More below on
why the peer needs this identity.=20

> > and via RADIUS protocol to the RADIUS server. =20
>=20
> In the case where the DSRK server is separated from the home=20
> RADIUS server by one or more proxies, why should the home=20
> server believe the identity it receives?
>=20
> > The peer can
> > communicate the identity in an end-to-end protected manner to the=20
> > server, thus forcing the DSRK server to present the same=20
> identity to=20
> > the peer and the server.
>=20
> I still have problems understanding the utility of this. =20
> Leaving aside the "lying proxy" problem, let's take an=20
> example from real life: suppose that someone introduces=20
> himself to a young woman as "Ted Bundy" and she checks with a=20
> trusted friend who confirms this claimed identity.  If=20
> neither the young woman nor her friend knows that "Ted Bundy"=20
> is a vicious serial killer, what good does this confirmation=20
> do?  If you assume that the DSRK server cannot be trusted=20
> (otherwise why force it to do anything?), then why does the=20
> fact that it's not lying about its _name_ magically make it=20
> trustworthy? =20
>=20

I agree with you that channel bindings does not provide for correctness
in identity, it only provides a consistency check.  In this case,
however, I don't think channel bindings is the reason for the identity
being sent.  The DSRK derivation takes the requesting entity's domain
name or server ID as input to the PRF. Both parties deriving the key
(the Home AAA/EAP server and the peer) need to know this identity so
that the DSRK can be derived.  I believe that is the reason the identity
needs to be provided along with a request for DSRK.  Unless the peer and
the server are given the same value, the DSRK cannot be derived
correctly at both ends - so, the property of channel bindings may be
inherently provided for the DSRK by virtue of that.=20

Vidya

--
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: Tue, 17 Jul 2007 21:07:45 +0000
Content-class: urn:content-classes:message
Subject: RE: comments on draft-gaonkar-radext-erp-attrs-00
Date: Tue, 17 Jul 2007 14:06:41 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Lakshminath Dondeti" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Lakshminath Dondeti <mailto:[email-masked]> allegedly scribbled
on Monday, July 16, 2007 10:22 PM:

> Glen,
>=20
> Many thanks for your note.  I was somewhat familiar with the keyreq
> and keywrap drafts, although I haven't followed their progress in the
> IETF closely.  I also haven't reviewed them before working on the ERP
> attributes draft; I should have.  =20
>=20
> One of the goals of draft-gaonkar-radext-erp-attrs-00 is to piggyback
> the key request and response on the EAP authentication or the EAP
> reauthentication exchange.  After some reading, I think we can use
> the techniques of keyreq and keywrap within new RADIUS attributes.=20
> So, for instance we can incorporate the Request and Response
> Authenticators of the keyreq draft (although I don't quite like the
> MD5 construction there and would propose to revise it)=20

The constructs were chosen to make the new messages look as much like
existing RADIUS messages as possible (not to minimize code changes
(which would take about 10 minutes) but to minimize whining from IETF
"experts" (that could go on for years ;-)).

> and the keying
> material and other attributes of the keywrap drafts.  If that is
> something the WG might like, Kedar and I can work with the authors of
> keyreq and keywrap offline and revise the draft accordingly.        =20
>=20
> Some notes inline:
>=20
> On 7/15/2007 3:05 PM, Glen Zorn (gwz) wrote:
>> I would like to note that there is pre-existing work in this area
>>
(_http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-07.txt_
>> ,
>>
_http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt_).
>> Be that as it may, however, it's difficult to understand what the
>> purpose of the Requesting Entity's Identity in the express
>> environment=20
>> that is implied by the draft (i.e., a request from a visited network
>> to a home network).  If, as I assume (please correct me if my
>> assumption is incorrect), the requesting entity is a NAS it doesn't
>> seem reasonable to
>=20
> The requesting entity might be a DSRK server.

What is a "DSRK server"?  Is it the same as a hokey server? =20

>=20
>> believe that the RADIUS server in a remote network would have any
>> knowledge of it, even less so in the case where the visited and home
>> networks are separated by one or more proxies & thus lack any direct
>> trust relationship.  If this identity is meant to be used for key
>> binding purposes, I think that this is incredibly dangerous, imputing
>> trust as it does between the home RADIUS server and an entity of
>> which=20
>=20
> The DSRK server can provide its identity via the lower layer to the
> peer=20

One of the things that bothers me a lot about the proposals we're seeing
is the tendency to rely upon unspecified and possibly non-existent
"lower layer" mechanisms.  I think that this is unnecessary.

> and via RADIUS protocol to the RADIUS server. =20

In the case where the DSRK server is separated from the home RADIUS
server by one or more proxies, why should the home server believe the
identity it receives?

> The peer can
> communicate the identity in an end-to-end protected manner to the
> server, thus forcing the DSRK server to present the same identity to
> the peer and the server. =20

I still have problems understanding the utility of this.  Leaving aside
the "lying proxy" problem, let's take an example from real life: suppose
that someone introduces himself to a young woman as "Ted Bundy" and she
checks with a trusted friend who confirms this claimed identity.  If
neither the young woman nor her friend knows that "Ted Bundy" is a
vicious serial killer, what good does this confirmation do?  If you
assume that the DSRK server cannot be trusted (otherwise why force it to
do anything?), then why does the fact that it's not lying about its
_name_ magically make it trustworthy? =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: Tue, 17 Jul 2007 14:32:42 +0000
Date: Tue, 17 Jul 2007 16:31:49 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: RADIUS/DTLS and RADIUS crypto-agility requirements

Bernard Aboba wrote:
>> This method is already recommended in
>> draft-fischl-sipping-media-dtls-03.txt.
> 
> [BA]  This would allow a RADIUS server to automatically determine
> whether a given NAS
> supports RADIUS or RADIUS/DTLS, which would ease the configuration
> effort considerably.
> How do things work on the  RADIUS client side?  Does it attempt
> RADIUS/DTLS first, and if
> it gets no response after suitable timeout, drop back to RADIUS?

  Yes.

>  As you note, a
> RADIUS/DTLS packet can be differentiated from RADIUS unless the client
> or server
> implements RADIUS resource management, so that a RADIUS server not
> supporting
> RADIUS/DTLS would silently discard the DTLS initiation packet.  From
> http://www.iana.org/assignments/radius-types:

  Yes.

  The low byte of the DTLS version and the high byte of the epoch
overlap with the "length" field in RADIUS.  From RFC 4347, the DTLS
version number is 0xfeff, (though OpenSSL has DTLS1_VERSION = 0x0100
http://crypto.stanford.edu/~nagendra/projects/dtls/dtls-0.9.7g.patch)

  Also, the epoch and sequence_number fields in the initial DTLS packet
are always zero.

  The only time there can be a confusion is when the server supports
DTLS and resource management, and the client sends a RADIUS packet with
ID that matches the current DTLS major version, length that matches the
current DTLS minor version * 256, with the first 9 bytes of the
authentication vector being (00 LL 00 00 00 00 00 00 00), where "LL" is
the same as the high byte of the RADIUS length field.

  Since the DTLS minor version number is either 255 (or 0, depending on
who you believe), a RADIUS server will see the RADIUS length field as
either 0xff00, or 0x0000, neither of which are valid for RADIUS.

  For NASes that implement a proper CSPRNG, having that many zeros in
the authentication vector will happen once per 2^128 packets.  Add to
that the coincidence factor that the second byte of the vector matches
the length, and it's even less probable.

  I don't think we need to worry about confusing the packets.

> [BA] Diameter doesn't require DNSSEC because either IPsec or TLS security is
> required for Diameter; the only question is which one is used.  That is
> not the
> case here - it is possible that no DTLS would be used (e.g. drop back to
> normal
> RADIUS).  That enables a forged DNS RR to cause the negotiation to select
> RADIUS when RADIUS/DTLS (or another more secure alternative) is available.

  Yes.  SRV records are not part of this proposal, so I've ignored them
here.  If they are standardized, we should mandate that RADIUS clients
MUST implement DTLS with certain cryptographic checks for any server
found via SRV lookups.

  Alan DeKok.

--
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: Tue, 17 Jul 2007 13:11:06 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: <[email-masked]>
Subject: RE: RADIUS/DTLS and RADIUS crypto-agility requirements
Date: Tue, 17 Jul 2007 06:07:30 -0700

--_f05ae0f3-8e35-4820-9728-cb637ba63f6b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Comments below. >   Both RADIUS and DTLS require at least 16 octets in a pa=
cket, and both> include a "type" as the first octet, and a "length" field w=
ithin the> first 16 octets.  For RADIUS implementations that don't use code=
s> 20..23, there is no overlap between the two protocols.  So the first> oc=
tet could be used as a key to distinguish RADIUS / DTLS.  A little> extra s=
anity checking could check that the length field matched the> length of the=
 UDP data, to further help distinguish the protocols.> >   This would have =
to be done only for the first packet from a NAS.> After that, the existence=
 of the DTLS session mandates that the packets> must be DTLS.> >   This met=
hod is already recommended in> draft-fischl-sipping-media-dtls-03.txt.[BA] =
 This would allow a RADIUS server to automatically determine whether a give=
n NASsupports RADIUS or RADIUS/DTLS, which would ease the configuration eff=
ort considerably.How do things work on the  RADIUS client side?  Does it at=
tempt RADIUS/DTLS first, and ifit gets no response after suitable timeout, =
drop back to RADIUS?  As you note, aRADIUS/DTLS packet can be differentiate=
d from RADIUS unless the client or serverimplements RADIUS resource managem=
ent, so that a RADIUS server not supportingRADIUS/DTLS would silently disca=
rd the DTLS initiation packet.  From http://www.iana.org/assignments/radius=
-types:21       Resource-Free-Request        [RFC3575]22       Resource-Fre=
e-Response       [RFC3575]23       Resource-Query-Request       [RFC3575]24=
       Resource-Query-Response      [RFC3575]25       Alternate-Resource-  =
       Reclaim-Request              [RFC3575]> > As I recall, the solution =
to this was to use a separate port number> > for RADIUS/DTLS, rather than u=
p-negotiating.  Is the idea to use> > DNS SRV to determine if a given serve=
r supports DTLS or not, and if so,> > does this imply a requirement for DNS=
SEC?> >   A DNS SRV record would work, too.  I'm not sure it requires DNSSE=
C.> RFC 3588 (Diameter) permits TLS and SRV lookups, but doesn't mandate DN=
SSEC.> >   If the NASes are configured with a root CA, then DNSSEC doesn't =
matter> as much, because the NAS can validate the server certificate agains=
t its CA.[BA] Diameter doesn't require DNSSEC because either IPsec or TLS s=
ecurity isrequired for Diameter; the only question is which one is used.  T=
hat is not thecase here - it is possible that no DTLS would be used (e.g. d=
rop back to normalRADIUS).  That enables a forged DNS RR to cause the negot=
iation to selectRADIUS when RADIUS/DTLS (or another more secure alternative=
) is available. > > [BA] Does RADIUS/DTLS require a separate port for both =
conventional and> > RFC 3576 RADIUS exchanges?> >   It could use the same p=
ort for both.[BA] OK. > >   "issues & fixes" already mandates state on the =
RADIUS server.  When> > RADIUS servers include EAP, they already maintain s=
tate for TLS sessions.> > > > [BA]  What kind of state is required, and at =
what granularity?> >   A flag that this particular NAS session is TLS, and =
TLS session state,> per NAS.  At the most:>>   (src/dst ip + src/dst port +=
 TLS session data) * Num_sessions=

--_f05ae0f3-8e35-4820-9728-cb637ba63f6b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
Comments below. <br><br>&gt;   Both RADIUS and DTLS require at least 16 oct=
ets in a packet, and both<br>&gt; include a "type" as the first octet, and =
a "length" field within the<br>&gt; first 16 octets.  For RADIUS implementa=
tions that don't use codes<br>&gt; 20..23, there is no overlap between the =
two protocols.  So the first<br>&gt; octet could be used as a key to distin=
guish RADIUS / DTLS.  A little<br>&gt; extra sanity checking could check th=
at the length field matched the<br>&gt; length of the UDP data, to further =
help distinguish the protocols.<br>&gt; <br>&gt;   This would have to be do=
ne only for the first packet from a NAS.<br>&gt; After that, the existence =
of the DTLS session mandates that the packets<br>&gt; must be DTLS.<br>&gt;=
 <br>&gt;   This method is already recommended in<br>&gt; draft-fischl-sipp=
ing-media-dtls-03.txt.<br><br>[BA]&nbsp; This would allow a RADIUS server t=
o automatically determine whether a given NAS<br>supports RADIUS or RADIUS/=
DTLS, which would ease the configuration effort considerably.<br>How do thi=
ngs work on the&nbsp; RADIUS client side?&nbsp; Does it attempt RADIUS/DTLS=
 first, and if<br>it gets no response after suitable timeout, drop back to =
RADIUS?&nbsp; As you note, a<br>RADIUS/DTLS packet can be differentiated fr=
om RADIUS unless the client or server<br>implements RADIUS resource managem=
ent, so that a RADIUS server not supporting<br>RADIUS/DTLS would silently d=
iscard the DTLS initiation packet.&nbsp; From http://www.iana.org/assignmen=
ts/radius-types:<br><pre>21       Resource-Free-Request        [RFC3575]<br=
>22       Resource-Free-Response       [RFC3575]<br>23       Resource-Query=
-Request       [RFC3575]<br>24       Resource-Query-Response      [RFC3575]=
<br>25       Alternate-Resource-<br>         Reclaim-Request              [=
RFC3575]<br></pre>&gt; &gt; As I recall, the solution to this was to use a =
separate port number<br>&gt; &gt; for RADIUS/DTLS, rather than up-negotiati=
ng.  Is the idea to use<br>&gt; &gt; DNS SRV to determine if a given server=
 supports DTLS or not, and if so,<br>&gt; &gt; does this imply a requiremen=
t for DNSSEC?<br>&gt; <br>&gt;   A DNS SRV record would work, too.  I'm not=
 sure it requires DNSSEC.<br>&gt; RFC 3588 (Diameter) permits TLS and SRV l=
ookups, but doesn't mandate DNSSEC.<br>&gt; <br>&gt;   If the NASes are con=
figured with a root CA, then DNSSEC doesn't matter<br>&gt; as much, because=
 the NAS can validate the server certificate against its CA.<br><br>[BA] Di=
ameter doesn't require DNSSEC because either IPsec or TLS security is<br>re=
quired for Diameter; the only question is which one is used.&nbsp; That is =
not the<br>case here - it is possible that no DTLS would be used (e.g. drop=
 back to normal<br>RADIUS).&nbsp; That enables a forged DNS RR to cause the=
 negotiation to select<br>RADIUS when RADIUS/DTLS (or another more secure a=
lternative) is available. <br><br>&gt; &gt; [BA] Does RADIUS/DTLS require a=
 separate port for both conventional and<br>&gt; &gt; RFC 3576 RADIUS excha=
nges?<br>&gt; <br>&gt;   It could use the same port for both.<br><br>[BA] O=
K. <br><br>&gt; &gt;   "issues &amp; fixes" already mandates state on the R=
ADIUS server.  When<br>&gt; &gt; RADIUS servers include EAP, they already m=
aintain state for TLS sessions.<br>&gt; &gt; <br>&gt; &gt; [BA]  What kind =
of state is required, and at what granularity?<br>&gt; <br>&gt;   A flag th=
at this particular NAS session is TLS, and TLS session state,<br>&gt; per N=
AS.  At the most:<br>&gt;<br>&gt;   (src/dst ip + src/dst port + TLS sessio=
n data) * Num_sessions<br></body>
</html>=

--_f05ae0f3-8e35-4820-9728-cb637ba63f6b_--

--
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: Tue, 17 Jul 2007 06:19:04 +0000
Date: Tue, 17 Jul 2007 08:17:05 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: RADIUS/DTLS and RADIUS crypto-agility requirements

Bernard Aboba wrote:
> 4. Crypto-agility solutions MUST specify mandatory-to-implement
> algorithms for each mechanism.
>   --> not specified in the -00 draft, but can be specified
>       easily, as is done with other protocols leveraging TLS.
> 
> [BA] What TLS ciphersuites would be mandatory to implement?  AES-CBC/SHA-1?

  That would be acceptable.

> At IETF 68 we discussed potential attacks on "up-negotiation",
> where an initial (non-DTLS) RADIUS packet is sent, then RADIUS/DTLS
> is negotiated.  If the RADIUS shared secret on the initial RADIUS
> Request is cracked, then the attacker can create a bogus response that
> would impersonate the RADIUS server, implying to the client that DTLS
> is not supported.  Thus, an unprotected session proceeds even though
> a RADIUS/DTLS session would be possible.

  Both RADIUS and DTLS require at least 16 octets in a packet, and both
include a "type" as the first octet, and a "length" field within the
first 16 octets.  For RADIUS implementations that don't use codes
20..23, there is no overlap between the two protocols.  So the first
octet could be used as a key to distinguish RADIUS / DTLS.  A little
extra sanity checking could check that the length field matched the
length of the UDP data, to further help distinguish the protocols.

  This would have to be done only for the first packet from a NAS.
After that, the existence of the DTLS session mandates that the packets
must be DTLS.

  This method is already recommended in
draft-fischl-sipping-media-dtls-03.txt.

> As I recall, the solution to this was to use a separate port number
> for RADIUS/DTLS, rather than up-negotiating.  Is the idea to use
> DNS SRV to determine if a given server supports DTLS or not, and if so,
> does this imply a requirement for DNSSEC?

  A DNS SRV record would work, too.  I'm not sure it requires DNSSEC.
RFC 3588 (Diameter) permits TLS and SRV lookups, but doesn't mandate DNSSEC.

  If the NASes are configured with a root CA, then DNSSEC doesn't matter
as much, because the NAS can validate the server certificate against its CA.

> [BA] Does RADIUS/DTLS require a separate port for both conventional and
> RFC 3576 RADIUS exchanges?

  It could use the same port for both.

>   "issues & fixes" already mandates state on the RADIUS server.  When
> RADIUS servers include EAP, they already maintain state for TLS sessions.
> 
> [BA]  What kind of state is required, and at what granularity?

  A flag that this particular NAS session is TLS, and TLS session state,
per NAS.  At the most:

  (src/dst ip + src/dst port + TLS session data) * Num_sessions

  Alan DeKok.

--
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, 16 Jul 2007 20:04:05 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: RADIUS/DTLS and RADIUS crypto-agility requirements
Date: Mon, 16 Jul 2007 13:02:54 -0700

--_1b825955-d362-4e4c-8d97-7d1cb4c461b8_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Comments below (see [BA]). David B. Nelson wrote:> In preparation for the R=
ADEXT session at the IETF 69 meeting later this> month, I'd like to ask the=
 authors of drafts submitted for WG consideration> as potential WG drafts i=
n this area, to review the requirements we had> agreed upon, and submit, to=
 this mailing list, a brief write-up to of how> their submissions address e=
ach of the items in the requirements description.2. Negotiation & confident=
iality --> satisfied by the TLS negotiation mechanisms.   Encryption of exi=
sting attributes --> satisfied by TLS3. Proposals MUST support replay prote=
ction.  The existing mechanismsfor replay protection are considered adequat=
e and should be maintained.  --> satisifed by TLS replay protection4. Crypt=
o-agility solutions MUST specify mandatory-to-implementalgorithms for each =
mechanism.  --> not specified in the -00 draft, but can be specified      e=
asily, as is done with other protocols leveraging TLS.[BA] What TLS ciphers=
uites would be mandatory to implement?  AES-CBC/SHA-1? 5. Solutions to the =
problem MUST demonstrate backward compatibilitywith existing RADIUS impleme=
ntations.  --> satisfied by not using TLS for a particular client.      Thi=
s can be configured as a per-client item6. Bidding down attacks  --> client=
s can be configured as TLS-only, or legacy RADIUS      No bidding down atta=
ck can occur if the server requires TLS.      No bidding down attack can oc=
cur if the client requires TLS.  i.e. Bidding down attacks can occur only w=
hen neither client norserver knows the capability of the other before they =
communicate.  Sincethe same shared secret has to be configured on both alre=
ady for RADIUS,the information about capabilities is available at the same =
time, andcan be used.[BA] Is there a more automatic method available?  Havi=
ng to configureeach NAS for DTLS support yes/no seems like a management bur=
den, particularly if we end up with several crypto-agility solutions. At IE=
TF 68 we discussed potential attacks on "up-negotiation",
where an initial (non-DTLS) RADIUS packet is sent, then RADIUS/DTLS
is negotiated.  If the RADIUS shared secret on the initial RADIUS
Request is cracked, then the attacker can create a bogus response that
would impersonate the RADIUS server, implying to the client that DTLS
is not supported.  Thus, an unprotected session proceeds even though
a RADIUS/DTLS session would be possible.

As I recall, the solution to this was to use a separate port number
for RADIUS/DTLS, rather than up-negotiating.  Is the idea to use
DNS SRV to determine if a given server supports DTLS or not, and if so,
does this imply a requirement for DNSSEC?7. Proposals MUST indicate a willi=
ngness to cede change control tothe IETF.  --> Yes.8. Crypto-agility soluti=
ons MUST be interoperable between independentimplementations based purely o=
n the information provided in thespecification.  --> There are already DTLS=
 implementations.  Simplistically, this      proposal is simply "DTLS + RAD=
IUS".9. Crypto-agility solutions MUST apply to all RADIUS packet types,incl=
uding Access-Request, Challenge, Reject & Accept,Accounting-Request/Respons=
e, and CoA/Disconnect messages.  --> DTLS is just a wrapper around RADIUS. =
 It is agnostic towards      RADIUS messages.[BA] Does RADIUS/DTLS require =
a separate port for both conventional andRFC 3576 RADIUS exchanges?10. Prop=
osals MUST include a Diameter compatibility section, althoughit is expected=
 that the work will occur purely within RADIUS or in thetransport, and ther=
efore does not affect message data that is exchangedwith Diameter.  --> in =
draft-00.11. Crypto-agility solutions SHOULD NOT require fundamental change=
s toThe RADIUS operational model, such as the introduction of new commandsO=
r maintenance of state on the RADIUS server.  --> No new commands.  "issues=
 & fixes" already mandates state on the RADIUS server.  WhenRADIUS servers =
include EAP, they already maintain state for TLS sessions.[BA]  What kind o=
f state is required, and at what granularity?  My $0.02 here is that we sho=
uld just give up on the idea of RADIUSbeing a stateless protocol.  Server i=
mplementations have beenmaintaining state for a decade.  Recent discussions=
 about rfc3576bisindicate that the most obvious way to implement reverse pr=
oxying is bymaintaining massive amounts of state on the RADIUS server.  (Mo=
re thanwould be required here.)11a.  Similarly, a proposalShould focus on t=
he crypto-agility problem and nothing else.  Forexample, proposals should n=
ot require new attribute formats or includedefinition of new RADIUS service=
s.  --> Yes.  Alan DeKok.=

--_1b825955-d362-4e4c-8d97-7d1cb4c461b8_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
Comments below (see [BA]). <br><br>David B. Nelson wrote:<br>&gt; In prepar=
ation for the RADEXT session at the IETF 69 meeting later this<br>&gt; mont=
h, I'd like to ask the authors of drafts submitted for WG consideration<br>=
&gt; as potential WG drafts in this area, to review the requirements we had=
<br>&gt; agreed upon, and submit, to this mailing list, a brief write-up to=
 of how<br>&gt; their submissions address each of the items in the requirem=
ents description.<br><br>2. Negotiation &amp; confidentiality<br>&nbsp;--&g=
t; satisfied by the TLS negotiation mechanisms.<br>&nbsp;&nbsp; Encryption =
of existing attributes<br>&nbsp;--&gt; satisfied by TLS<br><br>3. Proposals=
 MUST support replay protection.&nbsp; The existing mechanisms<br>for repla=
y protection are considered adequate and should be maintained.<br>&nbsp; --=
&gt; satisifed by TLS replay protection<br><br>4. Crypto-agility solutions =
MUST specify mandatory-to-implement<br>algorithms for each mechanism.<br>&n=
bsp; --&gt; not specified in the -00 draft, but can be specified<br>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; easily, as is done with other protocols leveraging =
TLS.<br><br>[BA] What TLS ciphersuites would be mandatory to implement?&nbs=
p; AES-CBC/SHA-1? <br><br>5. Solutions to the problem MUST demonstrate back=
ward compatibility<br>with existing RADIUS implementations.<br>&nbsp; --&gt=
; satisfied by not using TLS for a particular client.<br>&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; This can be configured as a per-client item<br><br>6. Bidding =
down attacks<br>&nbsp; --&gt; clients can be configured as TLS-only, or leg=
acy RADIUS<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No bidding down attack can occ=
ur if the server requires TLS.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No bidding=
 down attack can occur if the client requires TLS.<br><br>&nbsp; i.e. Biddi=
ng down attacks can occur only when neither client nor<br>server knows the =
capability of the other before they communicate.&nbsp; Since<br>the same sh=
ared secret has to be configured on both already for RADIUS,<br>the informa=
tion about capabilities is available at the same time, and<br>can be used.<=
br><br>[BA] Is there a more automatic method available?&nbsp; Having to con=
figure<br>each NAS for DTLS support yes/no seems like a management burden, =
<br>particularly if we end up with several crypto-agility solutions. <br><b=
r>At IETF 68 we discussed potential attacks on "up-negotiation",<br>
where an initial (non-DTLS) RADIUS packet is sent, then RADIUS/DTLS<br>
is negotiated.&nbsp; If the RADIUS shared secret on the initial RADIUS<br>
Request is cracked, then the attacker can create a bogus response that<br>
would impersonate the RADIUS server, implying to the client that DTLS<br>
is not supported.&nbsp; Thus, an unprotected session proceeds even though<b=
r>
a RADIUS/DTLS session would be possible.<br>
<br>
As I recall, the solution to this was to use a separate port number<br>
for RADIUS/DTLS, rather than up-negotiating.&nbsp; Is the idea to use<br>
DNS SRV to determine if a given server supports DTLS or not, and if so,<br>
does this imply a requirement for DNSSEC?<br><br>7. Proposals MUST indicate=
 a willingness to cede change control to<br>the IETF.<br>&nbsp; --&gt; Yes.=
<br><br>8. Crypto-agility solutions MUST be interoperable between independe=
nt<br>implementations based purely on the information provided in the<br>sp=
ecification.<br>&nbsp; --&gt; There are already DTLS implementations.&nbsp;=
 Simplistically, this<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; proposal is simply =
"DTLS + RADIUS".<br><br>9. Crypto-agility solutions MUST apply to all RADIU=
S packet types,<br>including Access-Request, Challenge, Reject &amp; Accept=
,<br>Accounting-Request/Response, and CoA/Disconnect messages.<br>&nbsp; --=
&gt; DTLS is just a wrapper around RADIUS.&nbsp; It is agnostic towards<br>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RADIUS messages.<br><br>[BA] Does RADIUS/DTL=
S require a separate port for both conventional and<br>RFC 3576 RADIUS exch=
anges?<br><br>10. Proposals MUST include a Diameter compatibility section, =
although<br>it is expected that the work will occur purely within RADIUS or=
 in the<br>transport, and therefore does not affect message data that is ex=
changed<br>with Diameter.<br>&nbsp; --&gt; in draft-00.<br><br>11. Crypto-a=
gility solutions SHOULD NOT require fundamental changes to<br>The RADIUS op=
erational model, such as the introduction of new commands<br>Or maintenance=
 of state on the RADIUS server.<br>&nbsp; --&gt; No new commands.<br>&nbsp;=
 "issues &amp; fixes" already mandates state on the RADIUS server.&nbsp; Wh=
en<br>RADIUS servers include EAP, they already maintain state for TLS sessi=
ons.<br><br>[BA]&nbsp; What kind of state is required, and at what granular=
ity?<br><br>&nbsp; My $0.02 here is that we should just give up on the idea=
 of RADIUS<br>being a stateless protocol.&nbsp; Server implementations have=
 been<br>maintaining state for a decade.&nbsp; Recent discussions about rfc=
3576bis<br>indicate that the most obvious way to implement reverse proxying=
 is by<br>maintaining massive amounts of state on the RADIUS server.&nbsp; =
(More than<br>would be required here.)<br><br>11a.&nbsp; Similarly, a propo=
sal<br>Should focus on the crypto-agility problem and nothing else.&nbsp; F=
or<br>example, proposals should not require new attribute formats or includ=
e<br>definition of new RADIUS services.<br>&nbsp; --&gt; Yes.<br><br>&nbsp;=
 Alan DeKok.<br><br></body>
</html>=

--_1b825955-d362-4e4c-8d97-7d1cb4c461b8_--

--
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, 16 Jul 2007 07:30:16 +0000
Date: Mon, 16 Jul 2007 10:29:55 +0300
From: Christian Vogt <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Consideration of draft-lior-radius-attribute-type-extension-01.txt

I support this document becoming a WG item.

- Christian

--
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, 16 Jul 2007 07:28:19 +0000
Date: Mon, 16 Jul 2007 10:27:24 +0300
From: Christian Vogt <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked],  [email-masked],  [email-masked]
Subject: Re: Consideration of draft-lior-radius-attribute-type-extension-01.txt

Glen:

>> (1)  I was wondering why a RADIUS extended attribute needs its own
>>  length field.
> 
> Because, like standard VSAs, more than one extended sub-attribute can
>  be packed into a single attribute.  We probably need to point this 
> out specifically & include an example.

Yes, making that clear would be good.  Readers might wonder otherwise.

>> (2)  The 3rd requirement listed in section 2, which states that 
>> inappropriate use of extension type codes by vendors should be 
>> eliminated, seems to be an administrative/policy issue.
> 
> Except that it doesn't say that.  What it says is that the extended 
> attribute scheme must be unaffected by this poaching of the standard
>  attribute type space; our proposal achieves that by making the new 
> extended type space a part of the existing VSA space instead of 
> taking one of the (supposedly) unassigned numbers from the standard 
> type space.

Maybe this design decision should be clarified in the document a bit as
well.

>> (3)  The Length field of a RADIUS extended attribute is specified 
>> as
>>> = 4 according to section 4.  I would recommend to relax this to
>>>> =
>> 3, since the relaxation would allow for attributes without a value 
>> -- such as indications that are communicated by only the presence 
>> of an attribute, not a particular attribute value.
> 
> This would violate RFC 2865.

OK.

[...]

> No, the third attribute is a continuation of the second; they are 
> both strings, which have arbitrarily been assigned the extended type 
> of 25 (there are 2 attributes because the string won't fit in one). 
> The example could use a bit of clarification, though.

Yes, thanks.

- Christian

--
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, 16 Jul 2007 04:01:59 +0000
Content-class: urn:content-classes:message
Subject: RE: [HOKEY] comments on draft-gaonkar-radext-erp-attrs-00
Date: Sun, 15 Jul 2007 21:01:26 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Yoshihiro Ohba" <[email-masked]>
Cc: <[email-masked]>, "Lakshminath Dondeti" <[email-masked]>, <[email-masked]>, <[email-masked]>

Yoshihiro Ohba <mailto:[email-masked]> allegedly scribbled on
Sunday, July 15, 2007 7:27 PM:

> I agree with Glen's analysis (except that the entity that requests a
> DSRK from home domain server is a visited domain server, not a NAS in
> my reading of the draft).  Security property of a key management
> mechanism that relies on a particular AAA protocol deployment can
> easily be lost when the AAA protocol is deployed in a wrong way
> (e.g., placing a AAA proxy that can read the key on the key
> distribution path).  The problem with such an approach is there is no
> protocol-level mechanism to prevent mis-deployment of AAA protocol. I
> don't think such a mechanism should survive in the long run. =20

Whether or not it should is a theoretical question: the fact is that it
has & most likely will for the foreseeable future.
    =20
>=20
> A securer and cleaner way to avoid dependency on AAA protocol
> deployment is to use a 3-party key distribution protocol that does
> not rely on underlying transport security.  HOKEY WG is already
> taking that approach: draft-ietf-hokey-key-mgm-00.txt.  =20

I'd just like to reiterate (as co-chair) that if this document is to
survive, it needs to become a lot more protocol specification & a lot
less term paper rather quickly.  There is far too much handwaving going
on for it to be taken seriously: the document needs to clearly &
precisely state how it will work in _existing networks_ (hint: "we
assume green-field deployments" is _not_ acceptable as far as I'm
concerned).  In addition, if a three-party protocol is actually required
from a practical point of view, there need to be very good reasons why
an existing standard (i.e., Kerberos) is not usable.

--
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, 16 Jul 2007 03:12:16 +0000
Date: Sun, 15 Jul 2007 22:26:47 -0400
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: [email-masked], Lakshminath Dondeti <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [HOKEY] comments on draft-gaonkar-radext-erp-attrs-00
From: Yoshihiro Ohba <[email-masked]>

I agree with Glen's analysis (except that the entity that requests a
DSRK from home domain server is a visited domain server, not a NAS in
my reading of the draft).  Security property of a key management
mechanism that relies on a particular AAA protocol deployment can
easily be lost when the AAA protocol is deployed in a wrong way (e.g.,
placing a AAA proxy that can read the key on the key distribution
path).  The problem with such an approach is there is no
protocol-level mechanism to prevent mis-deployment of AAA protocol.  
I don't think such a mechanism should survive in the long run.

A securer and cleaner way to avoid dependency on AAA protocol
deployment is to use a 3-party key distribution protocol that does not
rely on underlying transport security.  HOKEY WG is already taking
that approach: draft-ietf-hokey-key-mgm-00.txt.

Regards,
Yoshihiro Ohba

On Sun, Jul 15, 2007 at 03:05:20PM -0700, Glen Zorn (gwz) wrote:
> I would like to note that there is pre-existing work in this area
> (http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-07.txt,
> http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt).
> Be that as it may, however, it's difficult to understand what the
> purpose of the Requesting Entity's Identity in the express environment
> that is implied by the draft (i.e., a request from a visited network to
> a home network).  If, as I assume (please correct me if my assumption is
> incorrect), the requesting entity is a NAS it doesn't seem reasonable to
> believe that the RADIUS server in a remote network would have any
> knowledge of it, even less so in the case where the visited and home
> networks are separated by one or more proxies & thus lack any direct
> trust relationship.  If this identity is meant to be used for key
> binding purposes, I think that this is incredibly dangerous, imputing
> trust as it does between the home RADIUS server and an entity of which
> it possesses no knowledge.  OTOH, suppose that there _is_ a direct trust
> relationship between the home & visited network, intervening proxies
> notwithstanding (perhaps by means of an OOB WRT RADIUS key exchange);
> further, suppose that this trust is so strong that the home RADIUS
> server is willing to take the visited domain at its word as to the
> identity of the requesting NAS.  In this case, the security of the
> protocol is defeated by the use of IPsec on a hop-by-hop basis since the
> message and key are available in plaintext form at each (less trusted)
> hop.

> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hokey

--
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: Sun, 15 Jul 2007 22:06:34 +0000
Content-class: urn:content-classes:message
Subject: comments on draft-gaonkar-radext-erp-attrs-00
Date: Sun, 15 Jul 2007 15:05:20 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>, "Lakshminath Dondeti" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Glen Zorn \(gwz\)" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7C72C.3C73A939
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I would like to note that there is pre-existing work in this area
(http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-07.txt,
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt).
Be that as it may, however, it's difficult to understand what the
purpose of the Requesting Entity's Identity in the express environment
that is implied by the draft (i.e., a request from a visited network to
a home network).  If, as I assume (please correct me if my assumption is
incorrect), the requesting entity is a NAS it doesn't seem reasonable to
believe that the RADIUS server in a remote network would have any
knowledge of it, even less so in the case where the visited and home
networks are separated by one or more proxies & thus lack any direct
trust relationship.  If this identity is meant to be used for key
binding purposes, I think that this is incredibly dangerous, imputing
trust as it does between the home RADIUS server and an entity of which
it possesses no knowledge.  OTOH, suppose that there _is_ a direct trust
relationship between the home & visited network, intervening proxies
notwithstanding (perhaps by means of an OOB WRT RADIUS key exchange);
further, suppose that this trust is so strong that the home RADIUS
server is willing to take the visited domain at its word as to the
identity of the requesting NAS.  In this case, the security of the
protocol is defeated by the use of IPsec on a hop-by-hop basis since the
message and key are available in plaintext form at each (less trusted)
hop.

------_=_NextPart_001_01C7C72C.3C73A939
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7651.59">
<TITLE>comments on draft-gaonkar-radext-erp-attrs-00</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">I would like to note that there is =
pre-existing work in this area (</FONT><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-07.t=
xt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-zorn-radius-keyr=
eq-07.txt</FONT></U></A><FONT SIZE=3D2 FACE=3D"Arial">, </FONT><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.=
txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-zorn-radius-keyw=
rap-13.txt</FONT></U></A><FONT SIZE=3D2 FACE=3D"Arial">).&nbsp; Be that =
as it may, however, it's difficult to understand what the purpose of the =
Requesting Entity's Identity in the express environment that is implied =
by the draft (i.e., a request from a visited network to a home =
network).&nbsp; If, as I assume (please correct me if my assumption is =
incorrect), the requesting entity is a NAS it doesn't seem reasonable to =
believe that the RADIUS server in a remote network would have any =
knowledge of it, even less so in the case where the visited and home =
networks are separated by one or more proxies &amp; thus lack any direct =
trust relationship.&nbsp; If this identity is meant to be used for key =
binding purposes, I think that this is incredibly dangerous, imputing =
trust as it does between the home RADIUS server and an entity of which =
it possesses no knowledge.&nbsp; OTOH, suppose that there _is_ a direct =
trust relationship between the home &amp; visited network, intervening =
proxies notwithstanding (perhaps by means of an OOB WRT RADIUS key =
exchange); further, suppose that this trust is so strong that the home =
RADIUS server is willing to take the visited domain at its word as to =
the identity of the requesting NAS.&nbsp; In this case, the security of =
the protocol is defeated by the use of IPsec on a hop-by-hop basis since =
the message and key are available in plaintext form at each (less =
trusted) hop.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C7C72C.3C73A939--

--
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: Sun, 15 Jul 2007 18:35:09 +0000
Content-class: urn:content-classes:message
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-01.txt
Date: Sun, 15 Jul 2007 11:33:36 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Christian Vogt" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Christian Vogt <mailto:[email-masked]> allegedly
scribbled on Thursday, July 12, 2007 1:45 AM:

> Bernard Aboba wrote:
>> Given the potential widespread impact of attribute extension, the
>> RADEXT WG Chairs are requesting that the RADEXT WG and all other
>> affected WGs please review the following document:
>>
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-e
>> xtension-01.txt
>=20
> Bernard and authors,
>=20
> I reviewed draft-lior-radius-attribute-type-extension-01.  This
> document should become a WG document IMO.  I have three comments,
> though: =20
>=20
> (1)  I was wondering why a RADIUS extended attribute needs its own
> length field.=20

Because, like standard VSAs, more than one extended sub-attribute can be
packed into a single attribute.  We probably need to point this out
specifically & include an example.

> (2)  The 3rd requirement listed in section 2, which states that
> inappropriate use of extension type codes by vendors should be
> eliminated, seems to be an administrative/policy issue. =20

Except that it doesn't say that.  What it says is that the extended
attribute scheme must be unaffected by this poaching of the standard
attribute type space; our proposal achieves that by making the new
extended type space a part of the existing VSA space instead of taking
one of the (supposedly) unassigned numbers from the standard type space.

> Maybe this
> should be handled separately from the technical requirements -- and
> maybe in a completely different document as it could/should also
> affect the current extension type code space.    =20
>=20
> (3)  The Length field of a RADIUS extended attribute is specified as
> >=3D 4 according to section 4.  I would recommend to relax this to =
>=3D
> 3, since the relaxation would allow for attributes without a value --
> such as indications that are communicated by only the presence of an
> attribute, not a particular attribute value.=20

This would violate RFC 2865.
 =20
>=20
> Editorial remarks:
>=20
> Section 2, 5th paragraph: s/NUST/MUST/

Done.

>=20
> Section 5, 3rd example:  The value of the 3rd Extended Type field
> should be 27 rather than 25.=20

No, the third attribute is a continuation of the second; they are both
strings, which have arbitrarily been assigned the extended type of 25
(there are 2 attributes because the string won't fit in one).  The
example could use a bit of clarification, though.

>=20
> Kind regards,
> - Christian

--
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, 13 Jul 2007 19:35:59 +0000
Content-Class: urn:content-classes:message
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Fri, 13 Jul 2007 15:34:41 -0400
From: "Chowdhury, Kuntal" <[email-masked]>
To: <[email-masked]>

I believe this document should be adopted as WG document.

BR,
Kuntal

________________________________________
From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Bernard Aboba
Sent: Tuesday, July 03, 2007 3:56 PM
To: [email-masked]
Subject: Consideration of =
draft-lior-radius-attribute-type-extension-02.txt

The RADEXT WG has a charter deliverable for extensions to the RADIUS =
attribute=20
space. The apparent consensus in the WG is to solve a very simple set of =

problems, including the pending exhaustion of the standard RADIUS =
attribute=20
space, a consistent mechanism for application layer fragmentation and =
reassembly=20
for Diameter interoperability, and a consistent mechanism for grouping =
of=20
attributes for data structuring, also for Diameter interoperability.=20

The structure of the extended attribute format currently under =
consideration=20
may require changes in various RADIUS extensions drafts in RADEXT and=20
other working groups. This assumes that at least some of these documents =

will ultimately use the RADIUS extended attribute allocations. Given the
potential widespread impact of attribute extension, the RADEXT WG Chairs =

are requesting that the RADEXT WG and all other affected WGs please =
review=20
the following document:=20
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-exte=
nsion-02.txt
=20
This is the third (and last) review request relating to this document. =20
On December 5, 2006 a call for review of the RADIUS extended attribute =
document was=20
issued to the RADEXT WG:  =
http://ops.ietf.org/lists/radiusext/2006/msg01002.html

Unfortunately, no review comments were received relating to this =
document.  Since the call=20
for review occurred during the holiday the call for review as reissued =
on March 20, 2007:
http://ops.ietf.org/lists/radiusext/2007/msg00161.html
=20
This request did not garner much response either, so the call for review =
is being
reissued one last time, in order to gauge whether there is sufficient =
interest in this work item.=20
=20
Please reply to this message indicating whether you believe the document
should be adopted as a RADEXT WG work item.  You need not have any =
comments
on the document in order to respond affirmatively;  however, if you do =
not believe
the document should be adopted, it would be helpful to explain why not.  =

=20
Please send comments to the RADEXT WG mailing list =
([email-masked]), using the
RADEXT Issue Tracker template, which can be found at:
http://www.drizzle.com/~aboba/RADEXT/
=20
This Request for Review will last until July 22, 2007.=20

"This email message and any attachments are confidential information of =
Starent Networks, Corp. The information transmitted may not be used to =
create or change any contractual obligations of Starent Networks, Corp.  =
Any review, retransmission, dissemination or other use of, or taking of =
any action in reliance upon this e-mail and its attachments by persons =
or entities other than the intended recipient is prohibited. If you are =
not the intended recipient, please notify the sender immediately -- by =
replying to this message or by sending an email to =
[email-masked] -- and destroy all copies of this message =
and any attachments without reading or disclosing their contents. Thank =
you."

--
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, 13 Jul 2007 04:12:01 +0000
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Fri, 13 Jul 2007 00:12:56 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7C504.170EB925
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I think this document should be adopted as a wg document.

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Tuesday, July 03, 2007 4:56 PM
To: [email-masked]
Subject: Consideration of
draft-lior-radius-attribute-type-extension-02.txt

The RADEXT WG has a charter deliverable for extensions to the RADIUS
attribute=20
space. The apparent consensus in the WG is to solve a very simple set of

problems, including the pending exhaustion of the standard RADIUS
attribute=20
space, a consistent mechanism for application layer fragmentation and
reassembly=20
for Diameter interoperability, and a consistent mechanism for grouping
of=20
attributes for data structuring, also for Diameter interoperability.=20

The structure of the extended attribute format currently under
consideration=20
may require changes in various RADIUS extensions drafts in RADEXT and=20
other working groups. This assumes that at least some of these documents

will ultimately use the RADIUS extended attribute allocations. Given the
potential widespread impact of attribute extension, the RADEXT WG Chairs

are requesting that the RADEXT WG and all other affected WGs please
review=20
the following document:=20
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-ext
ension-02.txt
<http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-ex
tension-01.txt>=20
=20
This is the third (and last) review request relating to this document. =20
On December 5, 2006 a call for review of the RADIUS extended attribute
document was=20
issued to the RADEXT WG:
http://ops.ietf.org/lists/radiusext/2006/msg01002.html

Unfortunately, no review comments were received relating to this
document.  Since the call=20
for review occurred during the holiday the call for review as reissued
on March 20, 2007:
http://ops.ietf.org/lists/radiusext/2007/msg00161.html
=20
This request did not garner much response either, so the call for review
is being
reissued one last time, in order to gauge whether there is sufficient
interest in this work item.=20
=20
Please reply to this message indicating whether you believe the document
should be adopted as a RADEXT WG work item.  You need not have any
comments
on the document in order to respond affirmatively;  however, if you do
not believe
the document should be adopted, it would be helpful to explain why not.

=20
Please send comments to the RADEXT WG mailing list
([email-masked]), using the
RADEXT Issue Tracker template, which can be found at:
http://www.drizzle.com/~aboba/RADEXT/
=20
This Request for Review will last until July 22, 2007.=20

------_=_NextPart_001_01C7C504.170EB925
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: =
0px; PADDING-TOP: 0px
}
BODY {
	FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>

<META content=3D"MSHTML 6.00.6000.16481" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D324314903-13072007>I think =
this document=20
should be adopted as a wg document.</SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<B>From:</B> [email-masked] =
[mailto:[email-masked]]=20
<B>On Behalf Of </B>Bernard Aboba<BR><B>Sent:</B> Tuesday, July 03, 2007 =
4:56=20
PM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Consideration =
of=20
draft-lior-radius-attribute-type-extension-02.txt<BR><BR></DIV>
<DIV></DIV>The RADEXT WG has a charter deliverable for extensions to the =
RADIUS=20
attribute <BR>space. The apparent consensus in the WG is to solve a very =
simple=20
set of <BR>problems, including the pending exhaustion of the standard =
RADIUS=20
attribute <BR>space, a consistent mechanism for application layer =
fragmentation=20
and reassembly <BR>for Diameter interoperability, and a consistent =
mechanism for=20
grouping of <BR>attributes for data structuring, also for Diameter=20
interoperability. <BR><BR>The structure of the extended attribute format =

currently under consideration <BR>may require changes in various RADIUS=20
extensions drafts in RADEXT and <BR>other working groups. This assumes =
that at=20
least some of these documents <BR>will ultimately use the RADIUS =
extended=20
attribute allocations. Given the<BR>potential widespread impact of =
attribute=20
extension, the RADEXT WG Chairs <BR>are requesting that the RADEXT WG =
and all=20
other affected WGs please review <BR>the following document: <BR><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-t=
ype-extension-02.txt">http://www.ietf.org/internet-drafts/draft-lior-radi=
us-attribute-type-extension-02.txt</A><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-t=
ype-extension-01.txt"></A><BR>&nbsp;<BR>This=20
is the third (and last) review request relating to this document.&nbsp; =
<BR>On=20
December 5, 2006 a call for review of the RADIUS extended attribute =
document was=20
<BR>issued to the RADEXT WG:&nbsp; <A=20
href=3D"http://ops.ietf.org/lists/radiusext/2006/msg01002.html">http://op=
s.ietf.org/lists/radiusext/2006/msg01002.html</A><BR><BR>Unfortunately,=20
no review comments were received relating to this document.&nbsp; Since =
the call=20
<BR>for review occurred during the holiday the call for review as =
reissued on=20
March 20, 2007:<BR><A=20
href=3D"http://ops.ietf.org/lists/radiusext/2007/msg00161.html">http://op=
s.ietf.org/lists/radiusext/2007/msg00161.html</A><BR>&nbsp;<BR>This=20
request did not garner much response either, so the call for review is=20
being<BR>reissued one last time, in order to gauge whether there is =
sufficient=20
interest in this work item. <BR>&nbsp;<BR>Please reply to this message=20
indicating whether you believe the document<BR>should be adopted as a =
RADEXT WG=20
work item.&nbsp; You need not have any comments<BR>on the document in =
order to=20
respond affirmatively;&nbsp; however, if you do not believe<BR>the =
document=20
should be adopted, it would be helpful to explain why not.&nbsp;=20
<BR>&nbsp;<BR>Please send comments to the RADEXT WG mailing list (<A=20
href=3D"mailto:[email-masked]">[email-masked]</A>), =
using=20
the<BR>RADEXT Issue Tracker template, which can be found at:<BR><A=20
href=3D"http://www.drizzle.com/~aboba/RADEXT/">http://www.drizzle.com/~ab=
oba/RADEXT/</A><BR>&nbsp;<BR>This=20
Request for Review will last until July 22, 2007. <BR></BODY></HTML>

------_=_NextPart_001_01C7C504.170EB925--

--
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, 12 Jul 2007 16:07:53 +0000
Date: Thu, 12 Jul 2007 18:06:54 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: RADIUS Crypto-Agility work item

David B. Nelson wrote:
> In preparation for the RADEXT session at the IETF 69 meeting later this
> month, I'd like to ask the authors of drafts submitted for WG consideration
> as potential WG drafts in this area, to review the requirements we had
> agreed upon, and submit, to this mailing list, a brief write-up to of how
> their submissions address each of the items in the requirements description.

2. Negotiation & confidentiality
 --> satisfied by the TLS negotiation mechanisms.
   Encryption of existing attributes
 --> satisfied by TLS

3. Proposals MUST support replay protection.  The existing mechanisms
for replay protection are considered adequate and should be maintained.
  --> satisifed by TLS replay protection

4. Crypto-agility solutions MUST specify mandatory-to-implement
algorithms for each mechanism.
  --> not specified in the -00 draft, but can be specified
      easily, as is done with other protocols leveraging TLS.

5. Solutions to the problem MUST demonstrate backward compatibility
with existing RADIUS implementations.
  --> satisfied by not using TLS for a particular client.
      This can be configured as a per-client item

6. Bidding down attacks
  --> clients can be configured as TLS-only, or legacy RADIUS
      No bidding down attack can occur if the server requires TLS.
      No bidding down attack can occur if the client requires TLS.

  i.e. Bidding down attacks can occur only when neither client nor
server knows the capability of the other before they communicate.  Since
the same shared secret has to be configured on both already for RADIUS,
the information about capabilities is available at the same time, and
can be used.

7. Proposals MUST indicate a willingness to cede change control to
the IETF.
  --> Yes.

8. Crypto-agility solutions MUST be interoperable between independent
implementations based purely on the information provided in the
specification.
  --> There are already DTLS implementations.  Simplistically, this
      proposal is simply "DTLS + RADIUS".

9. Crypto-agility solutions MUST apply to all RADIUS packet types,
including Access-Request, Challenge, Reject & Accept,
Accounting-Request/Response, and CoA/Disconnect messages.
  --> DTLS is just a wrapper around RADIUS.  It is agnostic towards
      RADIUS messages.

10. Proposals MUST include a Diameter compatibility section, although
it is expected that the work will occur purely within RADIUS or in the
transport, and therefore does not affect message data that is exchanged
with Diameter.
  --> in draft-00.

11. Crypto-agility solutions SHOULD NOT require fundamental changes to
The RADIUS operational model, such as the introduction of new commands
Or maintenance of state on the RADIUS server.
  --> No new commands.
  "issues & fixes" already mandates state on the RADIUS server.  When
RADIUS servers include EAP, they already maintain state for TLS sessions.

  My $0.02 here is that we should just give up on the idea of RADIUS
being a stateless protocol.  Server implementations have been
maintaining state for a decade.  Recent discussions about rfc3576bis
indicate that the most obvious way to implement reverse proxying is by
maintaining massive amounts of state on the RADIUS server.  (More than
would be required here.)

11a.  Similarly, a proposal
Should focus on the crypto-agility problem and nothing else.  For
example, proposals should not require new attribute formats or include
definition of new RADIUS services.
  --> Yes.

  Alan DeKok.

--
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, 12 Jul 2007 14:52:48 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RADIUS Crypto-Agility work item
Date: Thu, 12 Jul 2007 10:50:06 -0400
Organization: Elbrys Networks, Inc.

In preparation for the RADEXT session at the IETF 69 meeting later this
month, I'd like to ask the authors of drafts submitted for WG consideration
as potential WG drafts in this area, to review the requirements we had
agreed upon, and submit, to this mailing list, a brief write-up to of how
their submissions address each of the items in the requirements description.
This will facilitate the presentations and discussion of RADIUS
Crypto-Agility at IETF 69.  The requirements are listed at:

https://ops.ietf.org/lists/radiusext/2007/msg00185.html

Thanks!

Regards,

Dave Nelson

--
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, 12 Jul 2007 08:46:00 +0000
Date: Thu, 12 Jul 2007 11:45:11 +0300
From: Christian Vogt <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked],  [email-masked],  [email-masked]
Subject: Re: Consideration of draft-lior-radius-attribute-type-extension-01.txt

Bernard Aboba wrote:
> Given the potential widespread impact of attribute extension, the
> RADEXT WG Chairs are requesting that the RADEXT WG and all other
> affected WGs please review the following document:
> http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-01.txt

Bernard and authors,

I reviewed draft-lior-radius-attribute-type-extension-01.  This document
should become a WG document IMO.  I have three comments, though:

(1)  I was wondering why a RADIUS extended attribute needs its own
length field.

It seems that this inner length field is always 6 bytes less than the
outer length field that already exists in the enclosing attribute.  The
inner length value also cannot exceed the outer length value because (1)
implementations that do not understand the new extended attributes will
only look at the outer length field, and (2) the inner length field
contains the same number of bits as the outer length field anyway.

(2)  The 3rd requirement listed in section 2, which states that
inappropriate use of extension type codes by vendors should be
eliminated, seems to be an administrative/policy issue.  Maybe this
should be handled separately from the technical requirements -- and
maybe in a completely different document as it could/should also affect
the current extension type code space.

(3)  The Length field of a RADIUS extended attribute is specified as >=
4 according to section 4.  I would recommend to relax this to >= 3,
since the relaxation would allow for attributes without a value -- such
as indications that are communicated by only the presence of an
attribute, not a particular attribute value.

Editorial remarks:

Section 2, 5th paragraph: s/NUST/MUST/

Section 5, 3rd example:  The value of the 3rd Extended Type field should
be 27 rather than 25.

Kind regards,
- Christian

--
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, 12 Jul 2007 06:08:52 +0000
To: [email-masked]
From: [email-masked]
Date: Thu, 05 Jul 2007 14:15:01 -0400
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc4590bis-02.txt 
Reply-To: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: RADIUS Extension for Digest Authentication
	Author(s)	: B. Sterman, et al.
	Filename	: draft-ietf-radext-rfc4590bis-02.txt
	Pages		: 34
	Date		: 2007-7-5
	
This document defines an extension to the Remote Authentication Dial-
   In User Service (RADIUS) protocol to enable support of Digest
   Authentication, for use with HTTP-style protocols like the Session
   Initiation Protocol (SIP) and HTTP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-rfc4590bis-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-rfc4590bis-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant ma

--
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: Tue, 10 Jul 2007 03:40:58 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Call for agenda items
Date: Mon, 9 Jul 2007 20:40:00 -0700

--_7d8d716b-2885-4aa1-97dc-111af89580a9_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is a call for agenda items for the IETF 69 RADEXT WG meeting.  A straw=
man agenda is included below.=20
=20
IETF 69 RADEXT WG Agenda
Thursday, July 26, 2007
9 AM - 11:30 AM
=20
9 AM - 9:10 AM Preliminaries
   Blue Sheets
   Note Takers
   Jabber Scribe
   Agenda bashing
   Document status
=20
Documents completing IETF last call (10 minutes)
=20
9:10 - 9:20:  Issues & Fixes, Alan DeKok
http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-04.txt
=20
Documents completing RADEXT WG last call (10 minutes)
=20
9:20 - 9:30 Attributes for Filtering & Redirection, Mauricio Sanchez
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-03.txt
=20
Documents in pre-WG work item review (20 minutes)
=20
9:30 - 9:40 Attribute Type Extension, Avi Lior
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extens=
ion-02.txt
=20
9:40 - 9:50 WLAN Attributes, Bernard Aboba
http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.txt
=20
Design Guidelines (20 minutes)
=20
9:50 - 10:10 Design Guidelines, Bernard Aboba
=20
RADIUS Crypto-Agility (50 minutes)
=20
10:10 - 10:20 RADEXT Crypto-agility Requirements and Selection Process, Dav=
id Nelson
=20
10:20 - 10:30 RADIUS + DTLS (Alan DeKoK)
http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-00.txt
=20
10:30 - 10:50 RADIUS Crypto-agility (Joe Salowey)
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt
http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-06.txt
=20
10:50 - 11:10 Discussion
=20
Miscellaneous (10 minutes)
=20
11:10 - 11:20 RADSEC (Stefan Winter)
http://www.ietf.org/internet-drafts/draft-winter-radsec-00.txt
=20
Discussion & Wrapup (10 minutes)
=20
=20
=20
=20
 =

--_7d8d716b-2885-4aa1-97dc-111af89580a9_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
This is a call for agenda items for the IETF 69 RADEXT WG meeting.&nbsp; A =
strawman agenda is included below. <BR>
&nbsp;<BR>
IETF 69 RADEXT WG Agenda<BR>
Thursday, July 26, 2007<BR>
9 AM - 11:30 AM<BR>
&nbsp;<BR>
9 AM - 9:10 AM Preliminaries<BR>
&nbsp;&nbsp; Blue Sheets<BR>
&nbsp;&nbsp; Note Takers<BR>
&nbsp;&nbsp; Jabber Scribe<BR>
&nbsp;&nbsp; Agenda bashing<BR>
&nbsp;&nbsp; Document status<BR>
&nbsp;<BR>
Documents completing IETF last call (10 minutes)<BR>
&nbsp;<BR>
9:10 - 9:20:&nbsp; Issues &amp; Fixes, Alan DeKok<BR>
<A href=3D"http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.t=
xt">http://www.ietf.org/internet-drafts</A><A href=3D"http://www.watersprin=
gs.org/pub/id/draft-ietf-radext-fixes-04.txt">/draft-ietf-radext-fixes-04.t=
xt</A><BR>
&nbsp;<BR>
Documents completing RADEXT WG last call (10 minutes)<BR>
&nbsp;<BR>
9:20 - 9:30 Attributes for Filtering &amp; Redirection, Mauricio Sanchez<BR=
>
<A href=3D"http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.t=
xt">http://www.ietf.org/internet-drafts</A><A href=3D"http://www.watersprin=
gs.org/pub/id/draft-ietf-radext-filter-rules-03.txt">/draft-ietf-radext-fil=
ter-rules-03.txt</A><BR>
&nbsp;<BR>
Documents in pre-WG work item review (20 minutes)<BR>
&nbsp;<BR>
9:30 - 9:40 Attribute Type Extension, Avi Lior<BR>
<A href=3D"http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-=
type-extension-02.txt">http://www.ietf.org/internet-drafts/draft-lior-radiu=
s-attribute-type-extension-02.txt</A><BR>
&nbsp;<BR>
9:40 - 9:50 WLAN Attributes, Bernard Aboba<BR>
<A href=3D"http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.t=
xt">http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.txt</A><=
BR>
&nbsp;<BR>
Design Guidelines (20 minutes)<BR>
&nbsp;<BR>
9:50 - 10:10 Design Guidelines, Bernard Aboba<BR>
&nbsp;<BR>
RADIUS Crypto-Agility (50 minutes)<BR>
&nbsp;<BR>
10:10 - 10:20 RADEXT Crypto-agility Requirements and Selection Process, Dav=
id Nelson<BR>
&nbsp;<BR>
10:20 - 10:30 RADIUS + DTLS (Alan DeKoK)<BR>
<A href=3D"http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.t=
xt">http://www.ietf.org/internet-drafts</A><A href=3D"http://www.watersprin=
gs.org/pub/id/draft-dekok-radext-dtls-00.txt">/draft-dekok-radext-dtls-00.t=
xt</A><BR>
&nbsp;<BR>
10:30 - 10:50 RADIUS Crypto-agility (Joe Salowey)<BR>
<A href=3D"http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.t=
xt">http://www.ietf.org/internet-drafts</A><A href=3D"http://www.watersprin=
gs.org/pub/id/draft-zorn-radius-keywrap-13.txt">/draft-zorn-radius-keywrap-=
13.txt</A><BR>
<A href=3D"http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-06=
.txt">http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-06.txt<=
/A><BR>
&nbsp;<BR>
10:50 - 11:10 Discussion<BR>
&nbsp;<BR>
Miscellaneous (10 minutes)<BR>
&nbsp;<BR>
11:10 - 11:20 RADSEC (Stefan Winter)<BR>
<A href=3D"http://www.ietf.org/internet-drafts/draft-winter-radsec-00.txt">=
http://www.ietf.org/internet-drafts/draft-winter-radsec-00.txt</A><BR>
&nbsp;<BR>
Discussion &amp; Wrapup (10 minutes)<BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR></body>
</html>=

--_7d8d716b-2885-4aa1-97dc-111af89580a9_--

--
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, 09 Jul 2007 10:21:03 +0000
Date: Mon, 09 Jul 2007 12:20:11 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: IESG review comments on the RADIUS Issues and Fixes draft

David B. Nelson wrote:
> What does "an authentication attribute" mean?

  Hmm... good point.

> I think it might be better to focus on the initiation (or re-initiation) of
> an authentication sequence, rather than focusing on which attributes are
> included.
> 
> For example, if one were to implement a textual challenge method, the
> initial Access-Request may just contain a User-Name.

  Which breaks the current requirements to include User-Password, or
CHAP-Password, State, or EAP-Message.

> In this case the initial Access-Request doesn't have any "authentication
> attributes", which are traditionally User-Password, CHAP-Password, EAP
> Message, and whatever RFC 4590 defines for this purpose.  Given that future
> work may add other authentication methods, attempting to define when the
> State attribute MUST be included in an Access-Request based on the other
> attributes in the message seems problematic.  I think it better to define it
> based on start (or restart) vs. continuation of an authentication sequence.

  Makes sense to me.  We already have some requirements on the use of
the State attribute:

   An Access-Request sent as a result of a new or restarted
   authentication run MUST NOT include the State attribute, even if the
   State attribute has previously been received in an Access-Challenge
   for the same user and port.

   Since a State attribute is always initially provided by the server in
   an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
   Request, a RADIUS client MUST NOT insert a State attribute that it
   has not previously received from the server.

  The goal of the suggested text would seem to be to extend [RFC 2865]
Section 4.1:

      An Access-Request MUST contain either a User-Password or a CHAP-
      Password or a State.

  What I want to say is:

  1) Access-Requests that can be authenticated when the server examines
their contents do not need a State.  e.g. User-Password, CHAP-Password,
or sometimes the final packet in a multi-packet challenge/response scheme.

  2) Access-Requests that are part of an ongoing authentication session
otherwise MUST have State.  The server is responsible for sending State
in an Access-Challenge when it believes it will need State in the next
Access-Request.  The client is responsible for including State in all
Access-Requests that are sent in response to an Access-Challenge.

  I think that covers the scenarios we need, while avoiding the
definition of an "authentication attribute".

  Suggested word-smithing of the above goals?  Do the goals meet
expectations?

  Alan DeKok.

--
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: Sun, 08 Jul 2007 18:01:18 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: FW: rfc4590bis approved
Date: Sun, 8 Jul 2007 11:00:20 -0700

--_7fc865e9-b8fe-450c-90cd-0c99bdda7581_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Date: Sun, 8 Jul 2007 11:00:03 +0200> From: [email-masked]> To: radex=
[email-masked]> Subject: rfc4590bis approved> > > From the 7/5 IES=
G telechat DRAFT minutes:> > o draft-ietf-radext-rfc4590bis-01.txt - 4 of 5=
> RADIUS Extension for Digest Authentication (Proposed Standard)> Token: Da=
n Romascanu> > The document was approved by the IESG pending an RFC Editor =
> Note to be prepared by Dan Romascanu. The Secretariat will > send a worki=
ng group submission Protocol Action Announcement > that includes the RFC Ed=
itor Note.> > Congratulations!> > Dan=

--_7fc865e9-b8fe-450c-90cd-0c99bdda7581_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
<BR><BR>&gt; Date: Sun, 8 Jul 2007 11:00:03 +0200<BR>&gt; From: dromasca@av=
aya.com<BR>&gt; To: [email-masked]<BR>&gt; Subject: rfc4590bi=
s approved<BR>&gt; <BR>&gt; <BR>&gt; From the 7/5 IESG telechat DRAFT minut=
es:<BR>&gt; <BR>&gt; o draft-ietf-radext-rfc4590bis-01.txt - 4 of 5<BR>&gt;=
 RADIUS Extension for Digest Authentication (Proposed Standard)<BR>&gt; Tok=
en: Dan Romascanu<BR>&gt; <BR>&gt; The document was approved by the IESG pe=
nding an RFC Editor <BR>&gt; Note to be prepared by Dan Romascanu. The Secr=
etariat will <BR>&gt; send a working group submission Protocol Action Annou=
ncement <BR>&gt; that includes the RFC Editor Note.<BR>&gt; <BR>&gt; Congra=
tulations!<BR>&gt; <BR>&gt; Dan<BR></body>
</html>=

--_7fc865e9-b8fe-450c-90cd-0c99bdda7581_--

--
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, 06 Jul 2007 17:27:29 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: IESG review comments on the RADIUS Issues and Fixes draft
Date: Fri, 6 Jul 2007 13:25:02 -0400
Organization: Elbrys Networks, Inc.

Following up to my recent post...

> I think it better to define it based on start (or restart) vs.
> continuation of an authentication sequence.

Understanding, of course, that authorize-only uses, as described in RFC 3576
and 3576bis, are a separate case that require the inclusion of a State
attribute in the initial Access-Request message of an authorize-only
sequence.

--
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, 06 Jul 2007 17:19:22 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>, "David B. Nelson" <[email-masked]>
CC: <[email-masked]>
Subject: RE: IESG review comments on the RADIUS Issues and Fixes draft
Date: Fri, 6 Jul 2007 10:19:03 -0700

--_9b39adb5-63f7-4fe8-b6ad-8939997be34d_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

You might define what is meant by an "authentication attribute" (e.g. EAP-M=
essage, User-Password, etc.). > Date: Fri, 6 Jul 2007 14:16:20 +0200> From:=
 [email-masked]> To: [email-masked]> CC: [email-masked].=
org> Subject: Re: IESG review comments on the RADIUS Issues and Fixes draft=
> > David B. Nelson wrote:> >>From the IETF ID-Tracker database:> > > > Dat=
e and Time: 2007-07-03, 11:39:58 > > Document: draft-ietf-radext-fixes > > =
Version: 04 > > Commented by: Tim Polk > > Comment: I personally find this =
text in the last sentence in section 2.1.1> > to be unclear: > > > > "neith=
er including an authentication attribute nor a Service-Type attribute"> > S=
uggested text:> > As defined in [RFC 2865] Table 5.44, Access-Request packe=
ts MAY> contain a State attribute. We extend that definition here, to say> =
that Access-Request packets that contain an authentication attribute> or a =
Service-Type attribute with the value Call Check (10) MAY contain> a State =
attribute. Access-Request packets not matching the above> description MUST =
contain a State attribute.> > Alan DeKok.> > --> to unsubscribe send a mess=
age to [email-masked] with> the word 'unsubscribe' in a sin=
gle line as the message text body.> archive: <http://psg.com/lists/radiusex=
t/>=

--_9b39adb5-63f7-4fe8-b6ad-8939997be34d_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
You might define what is meant by an "authentication attribute" (e.g. EAP-M=
essage, User-Password, etc.). <BR><BR>&gt; Date: Fri, 6 Jul 2007 14:16:20 +=
0200<BR>&gt; From: [email-masked]<BR>&gt; To: [email-masked]=
<BR>&gt; CC: [email-masked]<BR>&gt; Subject: Re: IESG review commen=
ts on the RADIUS Issues and Fixes draft<BR>&gt; <BR>&gt; David B. Nelson wr=
ote:<BR>&gt; &gt;&gt;From the IETF ID-Tracker database:<BR>&gt; &gt; <BR>&g=
t; &gt; Date and Time: 2007-07-03, 11:39:58 <BR>&gt; &gt; Document: draft-i=
etf-radext-fixes <BR>&gt; &gt; Version: 04 <BR>&gt; &gt; Commented by: Tim =
Polk <BR>&gt; &gt; Comment: I personally find this text in the last sentenc=
e in section 2.1.1<BR>&gt; &gt; to be unclear: <BR>&gt; &gt; <BR>&gt; &gt; =
"neither including an authentication attribute nor a Service-Type attribute=
"<BR>&gt; <BR>&gt; Suggested text:<BR>&gt; <BR>&gt; As defined in [RFC 2865=
] Table 5.44, Access-Request packets MAY<BR>&gt; contain a State attribute.=
 We extend that definition here, to say<BR>&gt; that Access-Request packets=
 that contain an authentication attribute<BR>&gt; or a Service-Type attribu=
te with the value Call Check (10) MAY contain<BR>&gt; a State attribute. Ac=
cess-Request packets not matching the above<BR>&gt; description MUST contai=
n a State attribute.<BR>&gt; <BR>&gt; Alan DeKok.<BR>&gt; <BR>&gt; --<BR>&g=
t; to unsubscribe send a message to [email-masked] with<BR>=
&gt; the word 'unsubscribe' in a single line as the message text body.<BR>&=
gt; archive: &lt;http://psg.com/lists/radiusext/&gt;<BR></body>
</html>=

--_9b39adb5-63f7-4fe8-b6ad-8939997be34d_--

--
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, 06 Jul 2007 17:15:39 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: IESG review comments on the RADIUS Issues and Fixes draft
Date: Fri, 6 Jul 2007 13:12:55 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok writes...
 
> As defined in [RFC 2865] Table 5.44, Access-Request packets MAY
> contain a State attribute.  We extend that definition here, to say
> that Access-Request packets that contain an authentication attribute
> or a Service-Type attribute with the value Call Check (10) MAY contain
> a State attribute.  Access-Request packets not matching the above
> description MUST contain a State attribute.

What does "an authentication attribute" mean?

I think it might be better to focus on the initiation (or re-initiation) of
an authentication sequence, rather than focusing on which attributes are
included.

For example, if one were to implement a textual challenge method, the
initial Access-Request may just contain a User-Name.  The Access-Challenge
may come back with a Reply-Message containing a nonce, e.g. 33409126 and a
State attribute.  You type the nonce into your hardware authentication
token, and it comes back with a response, e.g. 992398757.  The next
Access-Request message contains the User-Name, User-Password containing the
response, and the State attribute from the last Access-Challenge.

In this case the initial Access-Request doesn't have any "authentication
attributes", which are traditionally User-Password, CHAP-Password, EAP
Message, and whatever RFC 4590 defines for this purpose.  Given that future
work may add other authentication methods, attempting to define when the
State attribute MUST be included in an Access-Request based on the other
attributes in the message seems problematic.  I think it better to define it
based on start (or restart) vs. continuation of an authentication sequence.

--
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, 06 Jul 2007 12:17:22 +0000
Date: Fri, 06 Jul 2007 14:16:20 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: IESG review comments on the RADIUS Issues and Fixes draft

David B. Nelson wrote:
>>From the IETF ID-Tracker database:
> 
> Date and Time: 2007-07-03, 11:39:58 
> Document: draft-ietf-radext-fixes 
> Version: 04 
> Commented by: Tim Polk 
> Comment: I personally find this text in the last sentence in section 2.1.1
> to be unclear: 
> 
> "neither including an authentication attribute nor a Service-Type attribute"

  Suggested text:

As defined in [RFC 2865] Table 5.44, Access-Request packets MAY
contain a State attribute.  We extend that definition here, to say
that Access-Request packets that contain an authentication attribute
or a Service-Type attribute with the value Call Check (10) MAY contain
a State attribute.  Access-Request packets not matching the above
description MUST contain a State attribute.

  Alan DeKok.

--
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, 06 Jul 2007 06:48:37 +0000
Date: Fri, 06 Jul 2007 08:48:16 +0200
From: Hannes Tschofenig <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: [Fwd: Extensibility of draft-ietf-radext-filter-rules]

Resend since I never got an answer.

We have now written a solution for using the RADIUS filter rule document 
for usage with QoS.
Please take a look at:
http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-00.txt

Ciao
Hannes

-------- Original Message --------
Subject: 	Extensibility of draft-ietf-radext-filter-rules
Date: 	Tue, 05 Jun 2007 21:10:44 +0200
From: 	Hannes Tschofenig <[email-masked]>
To: 	'radext mailing list' <[email-masked]>

Hi all,

I have a question regarding the extensibility of 
draft-ietf-radext-filter-rules.

The document states that there is a version field. Now, there is the 
question when and how you define new versions.

* Does every tiny extension demand a new version number?

* Since a new version number is just a new constant in the rule set and 
does not require a new AVP are there IANA actions associated with the 
definition of new extensions?

* Does an extension (e.g., a new action) then require the document 
author to copy-and-paste the entire ABNF with the enhancements or would 
it be more preferable to just place the modified snippet into a new 
document? What would you suggest?

For example, one could just put the following modified ip-filter-rule 
code snippet into a doc:

        ;IP Filter Rule
        ip-filter-rule =  ("permit" / "deny" / NEW-ACTION ) " "
                                                          ^^^^^^^^^^^^^^^
                          ("in" / "out" / "inout") " "
                          ("ip" / ip-proto) filter-body 
                          [" " ip-option] [" " log-rule]

Wouldn't it be necessary or useful to carry the version number also 
attached to the capability attribute from the NAS to the RADIUS server?

Ciao
Hannes

--
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, 06 Jul 2007 06:48:08 +0000
Date: Fri, 06 Jul 2007 08:46:51 +0200
From: Hannes Tschofenig <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: [Fwd: I-D ACTION:draft-lior-diameter-classifier-00.txt]

Hi all,

in light of the work on the RADIUS filter rules I would like to draw 
your attention to this document.
It defines an alternative encoding format that is
(a) more extensible
(b) simplifies parsing
(c) is compact

Ciao
Hannes

-------- Original Message --------
Subject: 	I-D ACTION:draft-lior-diameter-classifier-00.txt
Date: 	Thu, 05 Jul 2007 11:15:01 -0400
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Diameter Claissifier
	Author(s)	: A. Lior
	Filename	: draft-lior-diameter-classifier-00.txt
	Pages		: 14
	Date		: 2007-7-5

   Many Diameter applications require to classify packets.  Diameter
   base protocols provides an IP Filter Rule type and a QoS Filter Rule
   type that is being used to classify packets.  However, because these
   types were defined for specific uses and defined in ways that are
   hard to extend and therefore are not generally applicable for those
   applications that require packet classifiers.

   This document describes a set of Diameter types that are useful to
   create packet classifiers.  The packet classier type can be used by
   various applications to express packet classifiers that best match
   the application's specific needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lior-diameter-classifier-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-lior-diameter-classifier-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-lior-diameter-classifier-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--
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, 06 Jul 2007 02:01:46 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Restart of RADEXT WG last call on "RADIUS Attributes for Filtering and Redirection"
Date: Thu, 5 Jul 2007 19:00:33 -0700

--_384cdaab-552a-41c1-8124-a43587f9a53a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is an announcement of RADEXT WG last call on "RADIUS Attributes for Fi=
ltering and Redirection" prior to sending the document to the IESG for cons=
ideration as a Proposed Standard. The document is available for inspection =
here:http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-03.=
txt RADEXT WG last call will complete on Monday, July 23, 2007.  Please sen=
d comments to the RADEXT WG mailing list ([email-masked]), using th=
e format described in the RADEXT Issues tracker:http://www.drizzle.com/~abo=
ba/RADEXT/=

--_384cdaab-552a-41c1-8124-a43587f9a53a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
This is an announcement of RADEXT WG last call on "RADIUS Attributes for Fi=
ltering and Redirection" prior to sending the document to the IESG&nbsp;for=
 consideration as a Proposed Standard.&nbsp;The document is available for i=
nspection here:<BR><A href=3D"http://www.ietf.org/internet-drafts/draft-iet=
f-radext-filter-rules-03.txt" rel=3Dnofollow><U><FONT color=3D#0000ff>http:=
//www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-03.txt</FONT>=
</U></A><BR>&nbsp;<BR>RADEXT WG last call will complete on Monday, July 23,=
 2007.&nbsp; Please send comments to the RADEXT WG mailing list (<A href=3D=
"mailto:[email-masked]" rel=3Dnofollow><U><FONT color=3D#0000ff>rad=
[email-masked]</FONT></U></A>), using the format described in the RADE=
XT Issues tracker:<BR><A href=3D"http://www.drizzle.com/~aboba/RADEXT/" rel=
=3Dnofollow><U><FONT color=3D#810081>http://www.drizzle.com/~aboba/RADEXT/<=
/FONT></U></A><BR><!--X-Body-of-Message-End--><!--X-MsgBody-End--><!--X-Fol=
low-Ups--></body>
</html>=

--_384cdaab-552a-41c1-8124-a43587f9a53a_--

--
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, 06 Jul 2007 01:16:48 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-filter-rules-03.txt 
Date: Thu, 05 Jul 2007 21:15:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: RADIUS Attributes for Filtering and Redirection
	Author(s)	: P. Congdon, et al.
	Filename	: draft-ietf-radext-filter-rules-03.txt
	Pages		: 30
	Date		: 2007-7-5
	
This document defines the NAS-Traffic-Rule and Acct-NAS-Traffic-
      Rule attributes within Remote Authentication Dial In User Service 
      (RADIUS) that is based on and extends on the filtering capability 
      defined by Diameter's NAS-Filter-Rule Attribute Value Pair (AVP) 
      described in RFC 4005, and the IPFilterRule syntax defined in RFC 
      3588.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-filter-rules-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-filter-rules-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-filter-rules-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-filter-rules-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--
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, 05 Jul 2007 18:58:41 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: FW: New Version Notification - draft-ietf-radext-rfc4590bis-02.txt
Date: Thu, 5 Jul 2007 11:58:07 -0700

--_b1b42d71-49b1-4219-a57a-06f2f13e09bc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A new version of RFC 4590bis is now available, addressing Issue 230, raised=
 by Frank Ellermann. > To: [email-masked]; [email-masked]=
> CC: > From: [email-masked]> Date: Thu, 5 Jul 2007 14:15:0=
1 -0400> Subject: New Version Notification - draft-ietf-radext-rfc4590bis-0=
2.txt > > New version (-02) has been submitted for draft-ietf-radext-rfc459=
0bis-02.txt.> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590=
bis-02.txt> > > > IETF Secretariat.> =

--_b1b42d71-49b1-4219-a57a-06f2f13e09bc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
A new version of RFC 4590bis is now available, addressing Issue 230, raised=
 by Frank Ellermann. <br><br>&gt; To: [email-masked]; dromasc=
[email-masked]<br>&gt; CC: <br>&gt; From: [email-masked]<br>&g=
t; Date: Thu, 5 Jul 2007 14:15:01 -0400<br>&gt; Subject: New Version Notifi=
cation - draft-ietf-radext-rfc4590bis-02.txt <br>&gt; <br>&gt; New version =
(-02) has been submitted for draft-ietf-radext-rfc4590bis-02.txt.<br>&gt; h=
ttp://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-02.txt<br>&=
gt; <br>&gt; <br>&gt; <br>&gt; IETF Secretariat.<br>&gt; <br></body>
</html>=

--_b1b42d71-49b1-4219-a57a-06f2f13e09bc_--

--
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, 05 Jul 2007 18:15:42 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc4590bis-02.txt 
Date: Thu, 05 Jul 2007 14:15:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: RADIUS Extension for Digest Authentication
	Author(s)	: B. Sterman, et al.
	Filename	: draft-ietf-radext-rfc4590bis-02.txt
	Pages		: 34
	Date		: 2007-7-5
	
This document defines an extension to the Remote Authentication Dial-
   In User Service (RADIUS) protocol to enable support of Digest
   Authentication, for use with HTTP-style protocols like the Session
   Initiation Protocol (SIP) and HTTP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-rfc4590bis-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-rfc4590bis-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc4590bis-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-rfc4590bis-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--
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, 05 Jul 2007 15:48:06 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: IESG review comments on the RADIUS Issues and Fixes draft
Date: Thu, 5 Jul 2007 11:45:04 -0400
Organization: Elbrys Networks, Inc.

>From the IETF ID-Tracker database:

Date and Time: 2007-07-03, 11:39:58 
Document: draft-ietf-radext-fixes 
Version: 04 
Commented by: Tim Polk 
Comment: I personally find this text in the last sentence in section 2.1.1
to be unclear: 

"neither including an authentication attribute nor a Service-Type attribute"

Date and Time: 2007-07-05, 11:09:37 
Document: draft-ietf-radext-fixes 
Version: 04 
Commented by: Sam Hartman 
Comment: I am concerned about how this draft seems to break the ability to 
negotiate future extensions.  In particular the recommendation that 
client should treat access-accept with unknown attributes as 
access-reject seems problematic.  However this issue seems to have 
been discussed sufficiently so this is only a comment.

DBN: (Note that Jari Arkko had a similar comment, and text to address this
has been proposed to inclusion in the -05 draft revision).

--
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, 05 Jul 2007 12:45:55 +0000
Date: Thu, 05 Jul 2007 14:44:53 +0200
From: Jari Arkko <[email-masked]>
To: Alan DeKok <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: DISCUSS and COMMENT: draft-ietf-radext-fixes

Ok for me.

Jari

Alan DeKok kirjoitti:
> Jari Arkko wrote:
> ...
>   
>> This is OK, I think (but it is up to you if you want to add the mitigation
>> feature -- I think at least suggesting Message-Authenticator
>> for every request is a good idea, unless you can see some backwards
>> compatibility issues).
>>     
>
>   I don't see any.  Old RADIUS servers don't validate
> Message-Authenticator, so they will ignore it.  New ones will validate
> it, and will gain from the added security.
>
>   I would prefer that the document says "... clients MUST add a
> Message-Authenticator attribute to every Access-Request".  But I'll
> leave it to the WG for consensus.
>
>   If there's no objection, I'm inclined to change the SHOULD to a MUST.
>
>   Alan DeKok.
>
>
>
>
>   

--
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, 05 Jul 2007 11:02:26 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Jari Arkko'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-fixes
Date: Thu, 5 Jul 2007 07:02:12 -0400

Jari Arkko writes...

> > I've always thought that it would be a good practice for a 
> > RADIUS client implementation to have a configuration parameter
> > to control this behavior, allowing the system administrator
> > to opt for maximum plug-'n'-play behavior (ignore unknown 
> > attributes) or to opt for maximum security (deny service
> > when presented with unknown, non-VSA attributes in an Access-
> > Accept).  I don't think there is one policy that will work 
> > appropriately in all deployment scenarios.
> 
> I think the above makes a lot of sense. I would feel much more
> confident that we are doing the right thing if the document
> said clients should have a configuration knob for this (and then
> the default value of the knob could be what the document
> currently states).

This "fix" would partially address the issue, and would be of the form of an
implementation suggestion.  It would not affect the on-the-wire protocol.
There may still be cases where an operator desires strict policy but needs
NAS capability signaling.  This text would not address that case, but as you
say, may address a sufficient number of cases to be worthy of adding to the
document.  I recommend that we consider adding it.

--
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, 05 Jul 2007 09:34:24 +0000
Date: Thu, 05 Jul 2007 11:33:20 +0200
From: Jari Arkko <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: DISCUSS and COMMENT: draft-ietf-radext-fixes

Dave,

> Capability signaling is an issue that has been addressed in an ad-hoc
> fashion for a couple of recent extensions (e.g. GEOPRIV).  We've discussed
> it in more general terms, but never had consensus to take action.
>   

Reading on...

> I've always though that it would be a good practice for a RADIUS client
> implementation to have a configuration parameter to control this behavior,
> allowing the system administrator to opt for maximum plug-'n'-play behavior
> (ignore unknown attributes) or to opt for maximum security (deny service
> when presented with unknown, non-VSA attributes in an Access-Accept).  I
> don't think there is one policy that will work appropriately in all
> deployment scenarios.
>   

I think the above makes a lot of sense. I would feel much more
confident that we are doing the right thing if the document
said clients should have a configuration knob for this (and then
the default value of the knob could be what the document
currently states).

(Note: this part of my Discuss is not intended to overwrite strong
consensus in the WG, if one exists -- I mainly wanted to know
that you are aware what you are doing.)

>>   Administrators are generally aware of the need to fight with
>> implementations to get client and server to agree on a set of attributes
>> that they both accept.
>>     
>
> That's what happens in the absence of capability signaling or a global
> strict/lax policy configuration feature.
>   

Right -- can we improve on this somehow? I think giving the
admins a tool (the knob) to deal with this would be useful.

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, 05 Jul 2007 09:34:17 +0000
Date: Thu, 05 Jul 2007 11:33:14 +0200
From: Jari Arkko <[email-masked]>
To: Alan DeKok <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: DISCUSS and COMMENT: draft-ietf-radext-fixes

Alan,

>   The packet MUST be validated.  The proposed change is:
>
> <-
> Cache entries MUST also be purged if the server receives a valid Access-
> Request packet that matches a cached Access-Request packet in source
> address, source port, RADIUS Identifier, and receiving socket, but
> where the Request Authenticator field is different from the one in
> the cached packet.  If the request contains a Message-Authenticator
> attribute, the request MUST be processed as described in [RFC3580]
> Section 3.2.  Packets with invalid Message-Authenticators MUST NOT
> affect the cache in any way.
> ->
>   

Sounds good.

>   We could probably also make a suggestion to mitigate a possible attack:
>
> <-
> However, Access-Request packets not containing a Message-Authenticator
> attribute always affect the cache, even though they may be trivially
> forged.  To avoid this issue, server implementations may be configured
> to require the presence of a Message-Authenticator attribute in
> Access-Request packets.  Requests not containing a Message-Authenticator
> attribute MAY then be silently discarded.
>
> Client implementations SHOULD include a Message-Authenticator attribute
> in every Access-Request, to further help mitigate this issue.
> ->
>
>   It's probably worth adding a note to the Security section:
>
> <-
> The cache mechanism described in Section 2.2.2 is vulnerable to attacks
> when Access-Requests do not contain a Message-Authenticator attribute.
> If the server accepts requests without a Message-Authenticator, then
> RADIUS packets can be trivially forged by an attacker.  Cache entries
> can then be forcibly expired, negating the utility of the cache.  This
> attack can be mitigated by following the suggestions in [RFC3579]
> Section 4, or by requiring the presence of Message-Authenticator, as
> described in Section 2.2.2.
> -->
>   

This is OK, I think (but it is up to you if you want to add the mitigation
feature -- I think at least suggesting Message-Authenticator
for every request is a good idea, unless you can see some backwards
compatibility issues).

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: Wed, 04 Jul 2007 18:57:13 +0000
Content-class: urn:content-classes:message
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Wed, 4 Jul 2007 18:55:59 -0000
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This is a multipart message in MIME format.

------=_NextPart_000_008E_01C7BE32.494F8960
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_008F_01C7BE32.494F8960"

------=_NextPart_001_008F_01C7BE32.494F8960
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I believe this should be accepted as a WG item.

MS

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bernard Aboba
Sent: Tuesday, July 03, 2007 1:56 PM
To: [email-masked]
Subject: Consideration of draft-lior-radius-attribute-type-extension-02.txt

The RADEXT WG has a charter deliverable for extensions to the RADIUS
attribute 
space. The apparent consensus in the WG is to solve a very simple set of 
problems, including the pending exhaustion of the standard RADIUS attribute 
space, a consistent mechanism for application layer fragmentation and
reassembly 
for Diameter interoperability, and a consistent mechanism for grouping of 
attributes for data structuring, also for Diameter interoperability. 

The structure of the extended attribute format currently under consideration

may require changes in various RADIUS extensions drafts in RADEXT and 
other working groups. This assumes that at least some of these documents 
will ultimately use the RADIUS extended attribute allocations. Given the
potential widespread impact of attribute extension, the RADEXT WG Chairs 
are requesting that the RADEXT WG and all other affected WGs please review 
the following document: 
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extensi
on-02.txt
 
This is the third (and last) review request relating to this document.  
On December 5, 2006 a call for review of the RADIUS extended attribute
document was 
issued to the RADEXT WG:
http://ops.ietf.org/lists/radiusext/2006/msg01002.html

Unfortunately, no review comments were received relating to this document.
Since the call 
for review occurred during the holiday the call for review as reissued on
March 20, 2007:
http://ops.ietf.org/lists/radiusext/2007/msg00161.html
 
This request did not garner much response either, so the call for review is
being
reissued one last time, in order to gauge whether there is sufficient
interest in this work item. 
 
Please reply to this message indicating whether you believe the document
should be adopted as a RADEXT WG work item.  You need not have any comments
on the document in order to respond affirmatively;  however, if you do not
believe
the document should be adopted, it would be helpful to explain why not.  
 
Please send comments to the RADEXT WG mailing list ([email-masked]),
using the
RADEXT Issue Tracker template, which can be found at:
http://www.drizzle.com/~aboba/RADEXT/
 
This Request for Review will last until July 22, 2007. 

------=_NextPart_001_008F_01C7BE32.494F8960
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I believe this should be accepted as a WG =
item.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>MS<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On =
Behalf
Of </b>Bernard Aboba<br>
<b>Sent:</b> Tuesday, July 03, 2007 1:56 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> Consideration of
draft-lior-radius-attribute-type-extension-02.txt<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>The
RADEXT WG has a charter deliverable for extensions to the RADIUS =
attribute <br>
space. The apparent consensus in the WG is to solve a very simple set of =
<br>
problems, including the pending exhaustion of the standard RADIUS =
attribute <br>
space, a consistent mechanism for application layer fragmentation and
reassembly <br>
for Diameter interoperability, and a consistent mechanism for grouping =
of <br>
attributes for data structuring, also for Diameter interoperability. =
<br>
<br>
The structure of the extended attribute format currently under =
consideration <br>
may require changes in various RADIUS extensions drafts in RADEXT and =
<br>
other working groups. This assumes that at least some of these documents =
<br>
will ultimately use the RADIUS extended attribute allocations. Given =
the<br>
potential widespread impact of attribute extension, the RADEXT WG Chairs =
<br>
are requesting that the RADEXT WG and all other affected WGs please =
review <br>
the following document: <br>
<a
href=3D"http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-t=
ype-extension-02.txt">http://www.ietf.org/internet-drafts/draft-lior-radi=
us-attribute-type-extension-02.txt</a><br>
&nbsp;<br>
This is the third (and last) review request relating to this =
document.&nbsp; <br>
On December 5, 2006 a call for review of the RADIUS extended attribute =
document
was <br>
issued to the RADEXT WG:&nbsp; <a
href=3D"http://ops.ietf.org/lists/radiusext/2006/msg01002.html">http://op=
s.ietf.org/lists/radiusext/2006/msg01002.html</a><br>
<br>
Unfortunately, no review comments were received relating to this
document.&nbsp; Since the call <br>
for review occurred during the holiday the call for review as reissued =
on March
20, 2007:<br>
<a =
href=3D"http://ops.ietf.org/lists/radiusext/2007/msg00161.html">http://op=
s.ietf.org/lists/radiusext/2007/msg00161.html</a><br>
&nbsp;<br>
This request did not garner much response either, so the call for review =
is
being<br>
reissued one last time, in order to gauge whether there is sufficient =
interest
in this work item. <br>
&nbsp;<br>
Please reply to this message indicating whether you believe the =
document<br>
should be adopted as a RADEXT WG work item.&nbsp; You need not have any
comments<br>
on the document in order to respond affirmatively;&nbsp; however, if you =
do not
believe<br>
the document should be adopted, it would be helpful to explain why =
not.&nbsp; <br>
&nbsp;<br>
Please send comments to the RADEXT WG mailing list (<a
href=3D"mailto:[email-masked]">[email-masked]</a>), =
using the<br>
RADEXT Issue Tracker template, which can be found at:<br>
<a =
href=3D"http://www.drizzle.com/~aboba/RADEXT/">http://www.drizzle.com/~ab=
oba/RADEXT/</a><br>
&nbsp;<br>
This Request for Review will last until July 22, 2007. =
<o:p></o:p></span></p>

</div>

</div>

</body>

</html>

------=_NextPart_001_008F_01C7BE32.494F8960--

------=_NextPart_000_008E_01C7BE32.494F8960
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_008E_01C7BE32.494F8960--

--
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: Wed, 04 Jul 2007 16:32:18 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Review of GEOPRIV Location Specification: -14
Date: Wed, 4 Jul 2007 09:32:00 -0700

--_c28b3784-86ec-4f4a-bb34-eb43f0d67b44_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A revision to the GEOPRIV RADIUS location document is in preparation:http:/=
/www.tschofenig.com/svn/draft-ietf-geopriv-radius-lo/draft-ietf-geopriv-rad=
ius-lo-14.txtThis version will probably be the last, so if there are any is=
sues left, please speak up or "forever hold your piece." =

--_c28b3784-86ec-4f4a-bb34-eb43f0d67b44_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
A revision to the GEOPRIV RADIUS location document is in preparation:<br>ht=
tp://www.tschofenig.com/svn/draft-ietf-geopriv-radius-lo/draft-ietf-geopriv=
-radius-lo-14.txt<br><br>This version will probably be the last, so if ther=
e are any issues left, please speak up or "forever hold your piece." <br></=
body>
</html>=

--_c28b3784-86ec-4f4a-bb34-eb43f0d67b44_--

--
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: Wed, 04 Jul 2007 16:29:56 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Lars Eggert'" <[email-masked]>
Cc: <[email-masked]>, "'Alan DeKok'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Wed, 4 Jul 2007 12:29:23 -0400

Lars Eggert writes...

>... or maybe rephrase as "inducing jitter."

That would be fine with me.

> The key piece of the DISCUSS is "please specify how a random factor
> is to be incorporated into the computation - see Section 9 of draft-
> ietf-pana-pana for an example"....

The text that Alan DeKok proposed will appear on the -05 revision.  We'll
give the RADEXT WG a little time to review all the proposed changes in -05,
and then check that all the DISCUSSes are cleared.

Thanks.

--
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: Wed, 04 Jul 2007 15:12:05 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-fixes
Date: Wed, 4 Jul 2007 11:11:26 -0400

Alan DeKok writes...

>   [RFC 2865] Section 1.1 already states:
> 
>    A NAS that does not implement a given service MUST NOT 
>    implement the RADIUS attributes for that service.  For example,
>    a NAS that is unable to offer ARAP service MUST NOT implement the
>    RADIUS attributes for ARAP.  A NAS MUST treat a RADIUS access-
>    accept authorizing an unavailable service as an access-reject
>    instead.
> 
>   The WG has discussed this, and related issues a fair bit.  The 
>   problem is that RADIUS doesn't have capability negotiations or
>   signaling.

Capability signaling is an issue that has been addressed in an ad-hoc
fashion for a couple of recent extensions (e.g. GEOPRIV).  We've discussed
it in more general terms, but never had consensus to take action.

> This makes it very difficult for servers to know client 
> capabilities.  There is no real good solution.  The text was place
> there to warn people of possible issues, and to suggest the safest
> behavior.

I've always though that it would be a good practice for a RADIUS client
implementation to have a configuration parameter to control this behavior,
allowing the system administrator to opt for maximum plug-'n'-play behavior
(ignore unknown attributes) or to opt for maximum security (deny service
when presented with unknown, non-VSA attributes in an Access-Accept).  I
don't think there is one policy that will work appropriately in all
deployment scenarios.

>   Administrators are generally aware of the need to fight with
> implementations to get client and server to agree on a set of attributes
> that they both accept.

That's what happens in the absence of capability signaling or a global
strict/lax policy configuration feature.

>   Note also that the recommendation is a SHOULD, not a MUST.

Should the keyword be RECOMMENDED instead?

--
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: Wed, 04 Jul 2007 06:32:15 +0000
Date: Wed, 04 Jul 2007 08:31:22 +0200
From: Alan DeKok <[email-masked]>
To: Jari Arkko <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: DISCUSS and COMMENT: draft-ietf-radext-fixes

Jari Arkko wrote:
> Discuss:
> This is an overall great document, long overdue, and I will
> move to a Yes vote once the below issues have been properly
> handled.

  Thanks.

> Section 2.2.2 states:
> 
...
> This got me thinking about the way that duplicates are
> detected and the cache entries managed. I re-read RFC 2865 and
> the draft under consideration, but I did not find clear
> guidance on this issue.  Specifically, what exactly are the
> requirements for such purging?  Do you check for validity of
> the packet before purging? Check the User-Password attribute
> which contains the message authentication?

  The packet MUST be validated.  The proposed change is:

<-
Cache entries MUST also be purged if the server receives a valid Access-
Request packet that matches a cached Access-Request packet in source
address, source port, RADIUS Identifier, and receiving socket, but
where the Request Authenticator field is different from the one in
the cached packet.  If the request contains a Message-Authenticator
attribute, the request MUST be processed as described in [RFC3580]
Section 3.2.  Packets with invalid Message-Authenticators MUST NOT
affect the cache in any way.
->

  We could probably also make a suggestion to mitigate a possible attack:

<-
However, Access-Request packets not containing a Message-Authenticator
attribute always affect the cache, even though they may be trivially
forged.  To avoid this issue, server implementations may be configured
to require the presence of a Message-Authenticator attribute in
Access-Request packets.  Requests not containing a Message-Authenticator
attribute MAY then be silently discarded.

Client implementations SHOULD include a Message-Authenticator attribute
in every Access-Request, to further help mitigate this issue.
->

  It's probably worth adding a note to the Security section:

<-
The cache mechanism described in Section 2.2.2 is vulnerable to attacks
when Access-Requests do not contain a Message-Authenticator attribute.
If the server accepts requests without a Message-Authenticator, then
RADIUS packets can be trivially forged by an attacker.  Cache entries
can then be forcibly expired, negating the utility of the cache.  This
attack can be mitigated by following the suggestions in [RFC3579]
Section 4, or by requiring the presence of Message-Authenticator, as
described in Section 2.2.2.
-->

>> In general, it is best for RADIUS clients to err on the side of
>> caution.  On receiving an Access-Accept including an attribute of
>> unknown Type, a RADIUS client SHOULD assume that it is a potential
>> service definition, and treat it as an Access-Reject.  Unknown VSAs
>> SHOULD be ignored by RADIUS clients.
> 
> This is a major change and can have significant
> negative effects to interoperability. Has this
> been discussed in the WG and have you found
> convincing arguments that taking on this rule
> will not lead to major problems?

  [RFC 2865] Section 1.1 already states:

   A NAS that does not implement a given service MUST NOT implement the
   RADIUS attributes for that service.  For example, a NAS that is
   unable to offer ARAP service MUST NOT implement the RADIUS attributes
   for ARAP.  A NAS MUST treat a RADIUS access-accept authorizing an
   unavailable service as an access-reject instead.

  The WG has discussed this, and related issues a fair bit.  The problem
is that RADIUS doesn't have capability negotiations or signaling.  This
makes it very difficult for servers to know client capabilities.  There
is no real good solution.  The text was place there to warn people of
possible issues, and to suggest the safest behavior.

  Administrators are generally aware of the need to fight with
implementations to get client and server to agree on a set of attributes
that they both accept.  Given that, and the existing recommendations in
RFC 2865, I do not see this text as being a major change, or having
significant affects on interoperability.

  Note also that the recommendation is a SHOULD, not a MUST.

> Comment:
>> This suggests that the User-Name attribute may be ommitted if it is
> 
> s/ommitted/omitted/

  Fixed, thanks.

> Time To Live is called Hop Limit in IPv6, and since this is
> an IPv6 specific Section, perhaps this is the name that you
> should use.

  Thanks.

  Alan DeKok.

--
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: Wed, 04 Jul 2007 05:30:58 +0000
Date: Wed, 04 Jul 2007 07:29:48 +0200
From: Alan DeKok <[email-masked]>
To:  [email-masked]
Subject: Re: Consideration of draft-lior-radius-attribute-type-extension-01.txt

Bernard Aboba wrote:
> Please reply to this message indicating whether you believe the document
> should be adopted as a RADEXT WG work item.  You need not have any comments
> on the document in order to respond affirmatively;  however, if you do
> not believe
> the document should be adopted, it would be helpful to explain why not. 

  The document should be accepted as a WG item.

  Alan DeKok.

--
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: Tue, 03 Jul 2007 23:30:21 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: DISCUSS and COMMENT: draft-ietf-radext-fixes
Date: Tue, 3 Jul 2007 16:29:40 -0700

--_1e684fee-f783-4e86-9151-a6e529382dd1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> To: [email-masked]> CC: [email-masked]; radext-cha=
[email-masked]> From: [email-masked]> Date: Tue, 3 Jul 2007 14:11=
:09 -0400> Subject: DISCUSS and COMMENT: draft-ietf-radext-fixes > > Discus=
s:> This is an overall great document, long overdue, and I will> move to a =
Yes vote once the below issues have been properly> handled.> > Section 2.2.=
2 states:> > > Cache entries MUST also be purged if the server receives an>=
 > Access- Request packet that matches a cached Access-Request> > packet in=
 source address, source port, RADIUS Identifier,> > and receiving socket, b=
ut where the Request Authenticator> > field is different from the one in th=
e cached packet.> > This got me thinking about the way that duplicates are>=
 detected and the cache entries managed. I re-read RFC 2865 and> the draft =
under consideration, but I did not find clear> guidance on this issue. Spec=
ifically, what exactly are the> requirements for such purging? Do you check=
 for validity of> the packet before purging? Check the User-Password attrib=
ute> which contains the message authentication?> > It seems inappropriate t=
o purge cache entries before the> cryptographic message authentication has =
been verified. If you> do it before verification, it means that an attacker=
 could> send a message that purges the cache, and if a real duplicate> arri=
ves after this the server will erroneously process> the duplicate.> > But m=
aybe I'm missing something.> > > In general, it is best for RADIUS clients =
to err on the side of> > caution. On receiving an Access-Accept including a=
n attribute of> > unknown Type, a RADIUS client SHOULD assume that it is a =
potential> > service definition, and treat it as an Access-Reject. Unknown =
VSAs> > SHOULD be ignored by RADIUS clients.> > This is a major change and =
can have significant> negative effects to interoperability. Has this> been =
discussed in the WG and have you found> convincing arguments that taking on=
 this rule> will not lead to major problems?> > Comment:> > This suggests t=
hat the User-Name attribute may be ommitted if it is> > s/ommitted/omitted/=
> > > The CPE may also require a delegated prefix for its own use, if it is=
> > decrementing the Time To Live (TTL) field of IP headers. In that> > cas=
e, it should be delegated a prefix by the NAS via the Delegated-> > IPv6-Pr=
efix attribute. [RFC4818]. If the CPE is not decrementing> > TTL, it does n=
ot require a delegated prefix.> > Time To Live is called Hop Limit in IPv6,=
 and since this is> an IPv6 specific Section, perhaps this is the name that=
 you> should use.> =

--_1e684fee-f783-4e86-9151-a6e529382dd1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
&gt; To: [email-masked]<BR>&gt; CC: [email-masked]; =
[email-masked]<BR>&gt; From: [email-masked]<BR>&gt; Dat=
e: Tue, 3 Jul 2007 14:11:09 -0400<BR>&gt; Subject: DISCUSS and COMMENT: dra=
ft-ietf-radext-fixes <BR>&gt; <BR>&gt; Discuss:<BR>&gt; This is an overall =
great document, long overdue, and I will<BR>&gt; move to a Yes vote once th=
e below issues have been properly<BR>&gt; handled.<BR>&gt; <BR>&gt; Section=
 2.2.2 states:<BR>&gt; <BR>&gt; &gt; Cache entries MUST also be purged if t=
he server receives an<BR>&gt; &gt; Access- Request packet that matches a ca=
ched Access-Request<BR>&gt; &gt; packet in source address, source port, RAD=
IUS Identifier,<BR>&gt; &gt; and receiving socket, but where the Request Au=
thenticator<BR>&gt; &gt; field is different from the one in the cached pack=
et.<BR>&gt; <BR>&gt; This got me thinking about the way that duplicates are=
<BR>&gt; detected and the cache entries managed. I re-read RFC 2865 and<BR>=
&gt; the draft under consideration, but I did not find clear<BR>&gt; guidan=
ce on this issue. Specifically, what exactly are the<BR>&gt; requirements f=
or such purging? Do you check for validity of<BR>&gt; the packet before pur=
ging? Check the User-Password attribute<BR>&gt; which contains the message =
authentication?<BR>&gt; <BR>&gt; It seems inappropriate to purge cache entr=
ies before the<BR>&gt; cryptographic message authentication has been verifi=
ed. If you<BR>&gt; do it before verification, it means that an attacker cou=
ld<BR>&gt; send a message that purges the cache, and if a real duplicate<BR=
>&gt; arrives after this the server will erroneously process<BR>&gt; the du=
plicate.<BR>&gt; <BR>&gt; But maybe I'm missing something.<BR>&gt; <BR>&gt;=
 &gt; In general, it is best for RADIUS clients to err on the side of<BR>&g=
t; &gt; caution. On receiving an Access-Accept including an attribute of<BR=
>&gt; &gt; unknown Type, a RADIUS client SHOULD assume that it is a potenti=
al<BR>&gt; &gt; service definition, and treat it as an Access-Reject. Unkno=
wn VSAs<BR>&gt; &gt; SHOULD be ignored by RADIUS clients.<BR>&gt; <BR>&gt; =
This is a major change and can have significant<BR>&gt; negative effects to=
 interoperability. Has this<BR>&gt; been discussed in the WG and have you f=
ound<BR>&gt; convincing arguments that taking on this rule<BR>&gt; will not=
 lead to major problems?<BR>&gt; <BR>&gt; Comment:<BR>&gt; &gt; This sugges=
ts that the User-Name attribute may be ommitted if it is<BR>&gt; <BR>&gt; s=
/ommitted/omitted/<BR>&gt; <BR>&gt; &gt; The CPE may also require a delegat=
ed prefix for its own use, if it is<BR>&gt; &gt; decrementing the Time To L=
ive (TTL) field of IP headers. In that<BR>&gt; &gt; case, it should be dele=
gated a prefix by the NAS via the Delegated-<BR>&gt; &gt; IPv6-Prefix attri=
bute. [RFC4818]. If the CPE is not decrementing<BR>&gt; &gt; TTL, it does n=
ot require a delegated prefix.<BR>&gt; <BR>&gt; Time To Live is called Hop =
Limit in IPv6, and since this is<BR>&gt; an IPv6 specific Section, perhaps =
this is the name that you<BR>&gt; should use.<BR>&gt; <BR></body>
</html>=

--_1e684fee-f783-4e86-9151-a6e529382dd1_--

--
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: Tue, 03 Jul 2007 22:06:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-01.txt
Date: Tue, 3 Jul 2007 15:04:37 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7BDBE.265358AA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I think it should be adopted as a WG document.

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Tuesday, July 03, 2007 1:55 PM
To: [email-masked]
Subject: Consideration of
draft-lior-radius-attribute-type-extension-01.txt

The RADEXT WG has a charter deliverable for extensions to the RADIUS
attribute=20
space. The apparent consensus in the WG is to solve a very simple set of

problems, including the pending exhaustion of the standard RADIUS
attribute=20
space, a consistent mechanism for application layer fragmentation and
reassembly=20
for Diameter interoperability, and a consistent mechanism for grouping
of=20
attributes for data structuring, also for Diameter interoperability.=20

The structure of the extended attribute format currently under
consideration=20
may require changes in various RADIUS extensions drafts in RADEXT and=20
other working groups. This assumes that at least some of these documents

will ultimately use the RADIUS extended attribute allocations. Given the
potential widespread impact of attribute extension, the RADEXT WG Chairs

are requesting that the RADEXT WG and all other affected WGs please
review=20
the following document:=20
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-ext
ension-01.txt
=20
This is the third (and last) review request relating to this document. =20
On December 5, 2006 a call for review of the RADIUS extended attribute
document was=20
issued to the RADEXT WG:
http://ops.ietf.org/lists/radiusext/2006/msg01002.html

Unfortunately, no review comments were received relating to this
document.  Since the call=20
for review occurred during the holiday the call for review as reissued
on March 20, 2007:
http://ops.ietf.org/lists/radiusext/2007/msg00161.html
=20
This request did not garner much response either, so the call for review
is being
reissued one last time, in order to gauge whether there is sufficient
interest in this work item.=20
=20
Please reply to this message indicating whether you believe the document
should be adopted as a RADEXT WG work item.  You need not have any
comments
on the document in order to respond affirmatively;  however, if you do
not believe
the document should be adopted, it would be helpful to explain why not.

=20
Please send comments to the RADEXT WG mailing list
([email-masked]), using the
RADEXT Issue Tracker template, which can be found at:
http://www.drizzle.com/~aboba/RADEXT/
=20
This Request for Review will last until July 22, 2007.=20

------_=_NextPart_001_01C7BDBE.265358AA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: =
0px; PADDING-TOP: 0px
}
BODY {
	FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.3132" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D765440322-03072007><FONT =
face=3DArial=20
color=3D#0000ff>I think it should be adopted as a WG=20
document.</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Bernard=20
Aboba<BR><B>Sent:</B> Tuesday, July 03, 2007 1:55 PM<BR><B>To:</B>=20
[email-masked]<BR><B>Subject:</B> Consideration of=20
draft-lior-radius-attribute-type-extension-01.txt<BR></FONT><BR></DIV>
<DIV></DIV>The RADEXT WG has a charter deliverable for extensions to the =
RADIUS=20
attribute <BR>space. The apparent consensus in the WG is to solve a very =
simple=20
set of <BR>problems, including the pending exhaustion of the standard =
RADIUS=20
attribute <BR>space, a consistent mechanism for application layer =
fragmentation=20
and reassembly <BR>for Diameter interoperability, and a consistent =
mechanism for=20
grouping of <BR>attributes for data structuring, also for Diameter=20
interoperability. <BR><BR>The structure of the extended attribute format =

currently under consideration <BR>may require changes in various RADIUS=20
extensions drafts in RADEXT and <BR>other working groups. This assumes =
that at=20
least some of these documents <BR>will ultimately use the RADIUS =
extended=20
attribute allocations. Given the<BR>potential widespread impact of =
attribute=20
extension, the RADEXT WG Chairs <BR>are requesting that the RADEXT WG =
and all=20
other affected WGs please review <BR>the following document: <BR><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-t=
ype-extension-01.txt">http://www.ietf.org/internet-drafts/draft-lior-radi=
us-attribute-type-extension-01.txt</A><BR>&nbsp;<BR>This=20
is the third (and last) review request relating to this document.&nbsp; =
<BR>On=20
December 5, 2006 a call for review of the RADIUS extended attribute =
document was=20
<BR>issued to the RADEXT WG:&nbsp; <A=20
href=3D"http://ops.ietf.org/lists/radiusext/2006/msg01002.html">http://op=
s.ietf.org/lists/radiusext/2006/msg01002.html</A><BR><BR>Unfortunately,=20
no review comments were received relating to this document.&nbsp; Since =
the call=20
<BR>for review occurred during the holiday the call for review as =
reissued on=20
March 20, 2007:<BR><A=20
href=3D"http://ops.ietf.org/lists/radiusext/2007/msg00161.html">http://op=
s.ietf.org/lists/radiusext/2007/msg00161.html</A><BR>&nbsp;<BR>This=20
request did not garner much response either, so the call for review is=20
being<BR>reissued one last time, in order to gauge whether there is =
sufficient=20
interest in this work item. <BR>&nbsp;<BR>Please reply to this message=20
indicating whether you believe the document<BR>should be adopted as a =
RADEXT WG=20
work item.&nbsp; You need not have any comments<BR>on the document in =
order to=20
respond affirmatively;&nbsp; however, if you do not believe<BR>the =
document=20
should be adopted, it would be helpful to explain why not.&nbsp;=20
<BR>&nbsp;<BR>Please send comments to the RADEXT WG mailing list (<A=20
href=3D"mailto:[email-masked]">[email-masked]</A>), =
using=20
the<BR>RADEXT Issue Tracker template, which can be found at:<BR><A=20
href=3D"http://www.drizzle.com/~aboba/RADEXT/">http://www.drizzle.com/~ab=
oba/RADEXT/</A><BR>&nbsp;<BR>This=20
Request for Review will last until July 22, 2007. <BR></BODY></HTML>

------_=_NextPart_001_01C7BDBE.265358AA--

--
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: Tue, 03 Jul 2007 20:56:18 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Tue, 3 Jul 2007 13:55:55 -0700

--_a2a0cf09-4748-41e4-ac6d-5483c94a1263_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The RADEXT WG has a charter deliverable for extensions to the RADIUS attrib=
ute=20
space. The apparent consensus in the WG is to solve a very simple set of=20
problems, including the pending exhaustion of the standard RADIUS attribute=
=20
space, a consistent mechanism for application layer fragmentation and reass=
embly=20
for Diameter interoperability, and a consistent mechanism for grouping of=20
attributes for data structuring, also for Diameter interoperability.=20
The structure of the extended attribute format currently under consideratio=
n=20
may require changes in various RADIUS extensions drafts in RADEXT and=20
other working groups. This assumes that at least some of these documents=20
will ultimately use the RADIUS extended attribute allocations. Given the
potential widespread impact of attribute extension, the RADEXT WG Chairs=20
are requesting that the RADEXT WG and all other affected WGs please review=
=20
the following document:=20
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extens=
ion-02.txt
=20
This is the third (and last) review request relating to this document. =20
On December 5, 2006 a call for review of the RADIUS extended attribute docu=
ment was issued to the RADEXT WG:  http://ops.ietf.org/lists/radiusext/2006=
/msg01002.html
Unfortunately, no review comments were received relating to this document. =
 Since the call for review occurred during the holiday the call for review =
as reissued on March 20, 2007:http://ops.ietf.org/lists/radiusext/2007/msg0=
0161.html
=20
This request did not garner much response either, so the call for review is=
 being
reissued one last time, in order to gauge whether there is sufficient inter=
est in this work item.=20
=20
Please reply to this message indicating whether you believe the document
should be adopted as a RADEXT WG work item.  You need not have any comments
on the document in order to respond affirmatively;  however, if you do not =
believe
the document should be adopted, it would be helpful to explain why not. =20
=20
Please send comments to the RADEXT WG mailing list ([email-masked])=
, using the
RADEXT Issue Tracker template, which can be found at:
http://www.drizzle.com/~aboba/RADEXT/
=20
This Request for Review will last until July 22, 2007. =

--_a2a0cf09-4748-41e4-ac6d-5483c94a1263_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
The RADEXT WG has a charter deliverable for extensions to the RADIUS attrib=
ute <BR>
space. The apparent consensus in the WG is to solve a very simple set of <B=
R>
problems, including the pending exhaustion of the standard RADIUS attribute=
 <BR>
space, a consistent mechanism for application layer fragmentation and reass=
embly <BR>
for Diameter interoperability, and a consistent mechanism for grouping of <=
BR>
attributes for data structuring, also for Diameter interoperability. <BR>
<BR>The structure of the extended attribute format currently under consider=
ation <BR>
may require changes in various RADIUS extensions drafts in RADEXT and <BR>
other working groups. This assumes that at least some of these documents <B=
R>
will ultimately use the RADIUS extended attribute allocations. Given the<BR=
>
potential widespread impact of attribute extension, the RADEXT WG Chairs <B=
R>
are requesting that the RADEXT WG and all other affected WGs please review =
<BR>
the following document: <BR>
<A href=3D"http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-=
type-extension-02.txt">http://www.ietf.org/internet-drafts/draft-lior-radiu=
s-attribute-type-extension-02.txt</A><A href=3D"http://www.ietf.org/interne=
t-drafts/draft-lior-radius-attribute-type-extension-01.txt"></A><BR>
&nbsp;<BR>
This is the third (and last) review request relating to this document.&nbsp=
; <BR>
On December 5, 2006 a call for review of the RADIUS extended attribute docu=
ment was <BR>issued to the RADEXT WG:&nbsp; <A href=3D"http://ops.ietf.org/=
lists/radiusext/2006/msg01002.html">http://ops.ietf.org/lists/radiusext/200=
6/msg01002.html</A><BR>
<BR>Unfortunately, no review comments were received relating to this docume=
nt.&nbsp; Since the call <BR>for review occurred during the holiday the cal=
l for review as reissued on March 20, 2007:<BR><A href=3D"http://ops.ietf.o=
rg/lists/radiusext/2007/msg00161.html">http://ops.ietf.org/lists/radiusext/=
2007/msg00161.html</A><BR>
&nbsp;<BR>
This request did not garner much response either, so the call for review is=
 being<BR>
reissued one last time, in order to gauge whether there is sufficient inter=
est in this work item. <BR>
&nbsp;<BR>
Please reply to this message indicating whether you believe the document<BR=
>
should be adopted as a RADEXT WG work item.&nbsp; You need not have any com=
ments<BR>
on the document in order to respond affirmatively;&nbsp; however, if you do=
 not believe<BR>
the document should be adopted, it would be helpful to explain why not.&nbs=
p; <BR>
&nbsp;<BR>
Please send comments to the RADEXT WG mailing list (<A href=3D"mailto:radiu=
[email-masked]">[email-masked]</A>), using the<BR>
RADEXT Issue Tracker template, which can be found at:<BR>
<A href=3D"http://www.drizzle.com/~aboba/RADEXT/">http://www.drizzle.com/~a=
boba/RADEXT/</A><BR>
&nbsp;<BR>
This Request for Review will last until July 22, 2007. <BR></body>
</html>=

--_a2a0cf09-4748-41e4-ac6d-5483c94a1263_--

--
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: Tue, 03 Jul 2007 20:55:04 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Consideration of draft-lior-radius-attribute-type-extension-01.txt
Date: Tue, 3 Jul 2007 13:54:32 -0700

--_14a9f33e-dd9e-4b04-804a-67db72d1a9b7_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The RADEXT WG has a charter deliverable for extensions to the RADIUS attrib=
ute=20
space. The apparent consensus in the WG is to solve a very simple set of=20
problems, including the pending exhaustion of the standard RADIUS attribute=
=20
space, a consistent mechanism for application layer fragmentation and reass=
embly=20
for Diameter interoperability, and a consistent mechanism for grouping of=20
attributes for data structuring, also for Diameter interoperability.=20
The structure of the extended attribute format currently under consideratio=
n=20
may require changes in various RADIUS extensions drafts in RADEXT and=20
other working groups. This assumes that at least some of these documents=20
will ultimately use the RADIUS extended attribute allocations. Given the
potential widespread impact of attribute extension, the RADEXT WG Chairs=20
are requesting that the RADEXT WG and all other affected WGs please review=
=20
the following document:=20
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extens=
ion-01.txt
=20
This is the third (and last) review request relating to this document. =20
On December 5, 2006 a call for review of the RADIUS extended attribute docu=
ment was issued to the RADEXT WG:  http://ops.ietf.org/lists/radiusext/2006=
/msg01002.html
Unfortunately, no review comments were received relating to this document. =
 Since the call for review occurred during the holiday the call for review =
as reissued on March 20, 2007:http://ops.ietf.org/lists/radiusext/2007/msg0=
0161.html
=20
This request did not garner much response either, so the call for review is=
 being
reissued one last time, in order to gauge whether there is sufficient inter=
est in this work item.=20
=20
Please reply to this message indicating whether you believe the document
should be adopted as a RADEXT WG work item.  You need not have any comments
on the document in order to respond affirmatively;  however, if you do not =
believe
the document should be adopted, it would be helpful to explain why not. =20
=20
Please send comments to the RADEXT WG mailing list ([email-masked])=
, using the
RADEXT Issue Tracker template, which can be found at:
http://www.drizzle.com/~aboba/RADEXT/
=20
This Request for Review will last until July 22, 2007. =

--_14a9f33e-dd9e-4b04-804a-67db72d1a9b7_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
The RADEXT WG has a charter deliverable for extensions to the RADIUS attrib=
ute <BR>
space. The apparent consensus in the WG is to solve a very simple set of <B=
R>
problems, including the pending exhaustion of the standard RADIUS attribute=
 <BR>
space, a consistent mechanism for application layer fragmentation and reass=
embly <BR>
for Diameter interoperability, and a consistent mechanism for grouping of <=
BR>
attributes for data structuring, also for Diameter interoperability. <BR>
<BR>The structure of the extended attribute format currently under consider=
ation <BR>
may require changes in various RADIUS extensions drafts in RADEXT and <BR>
other working groups. This assumes that at least some of these documents <B=
R>
will ultimately use the RADIUS extended attribute allocations. Given the<BR=
>
potential widespread impact of attribute extension, the RADEXT WG Chairs <B=
R>
are requesting that the RADEXT WG and all other affected WGs please review =
<BR>
the following document: <BR>
<A href=3D"http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-=
type-extension-01.txt">http://www.ietf.org/internet-drafts/draft-lior-radiu=
s-attribute-type-extension-01.txt</A><BR>
&nbsp;<BR>
This is the third (and last) review request relating to this document.&nbsp=
; <BR>
On December 5, 2006 a call for review of the RADIUS extended attribute docu=
ment was <BR>issued to the RADEXT WG:&nbsp; <A href=3D"http://ops.ietf.org/=
lists/radiusext/2006/msg01002.html">http://ops.ietf.org/lists/radiusext/200=
6/msg01002.html</A><BR>
<BR>Unfortunately, no review comments were received relating to this docume=
nt.&nbsp; Since the call <BR>for review occurred during the holiday the cal=
l for review as reissued on March 20, 2007:<BR><A href=3D"http://ops.ietf.o=
rg/lists/radiusext/2007/msg00161.html">http://ops.ietf.org/lists/radiusext/=
2007/msg00161.html</A><BR>
&nbsp;<BR>
This request did not garner much response either, so the call for review is=
 being<BR>
reissued one last time, in order to gauge whether there is sufficient inter=
est in this work item. <BR>
&nbsp;<BR>
Please reply to this message indicating whether you believe the document<BR=
>
should be adopted as a RADEXT WG work item.&nbsp; You need not have any com=
ments<BR>
on the document in order to respond affirmatively;&nbsp; however, if you do=
 not believe<BR>
the document should be adopted, it would be helpful to explain why not.&nbs=
p; <BR>
&nbsp;<BR>
Please send comments to the RADEXT WG mailing list (<A href=3D"mailto:radiu=
[email-masked]">[email-masked]</A>), using the<BR>
RADEXT Issue Tracker template, which can be found at:<BR>
<A href=3D"http://www.drizzle.com/~aboba/RADEXT/">http://www.drizzle.com/~a=
boba/RADEXT/</A><BR>
&nbsp;<BR>
This Request for Review will last until July 22, 2007. <BR></body>
</html>=

--_14a9f33e-dd9e-4b04-804a-67db72d1a9b7_--

--
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: Tue, 03 Jul 2007 20:35:31 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: RADEXT WG last call on RADIUS Attributes for Filtering and Redirection 
Date: Tue, 3 Jul 2007 13:34:32 -0700

--_da794ddc-5ee5-4499-a291-143731d96213_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is an announcement of RADEXT WG last call on "RADIUS Attributes for Fi=
ltering and Redirection" prior to sending the document to the IESG for cons=
ideration as a Proposed Standard. The document is available for inspection =
here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-02.txt
=20
RADEXT WG last call will complete on Monday, July 23, 2007.  Please send co=
mments to the RADEXT WG mailing list ([email-masked]), using the fo=
rmat described in the RADEXT Issues tracker:
http://www.drizzle.com/~aboba/RADEXT/=

--_da794ddc-5ee5-4499-a291-143731d96213_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
This is an announcement of RADEXT WG last call on "RADIUS Attributes for Fi=
ltering and Redirection" prior to sending the document to the IESG&nbsp;for=
 consideration as a Proposed Standard.&nbsp;The document is available for i=
nspection here:<BR>
<A href=3D"http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rul=
es-02.txt">http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rul=
es-02.txt</A><BR>
&nbsp;<BR>
RADEXT WG last call will complete on Monday, July 23, 2007.&nbsp; Please se=
nd comments to the RADEXT WG mailing list (<A href=3D"mailto:radiusext@ops.=
ietf.org">[email-masked]</A>), using the format described in the RA=
DEXT Issues tracker:<BR>
<A href=3D"http://www.drizzle.com/~aboba/RADEXT/">http://www.drizzle.com/~a=
boba/RADEXT/</A><BR></body>
</html>=

--_da794ddc-5ee5-4499-a291-143731d96213_--

--
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: Tue, 03 Jul 2007 11:31:40 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Tue, 3 Jul 2007 07:31:49 -0400

Barney Wolff writes...

> In other words, I don't see how the server can avoid keeping a cache
> of requests/responses, so I don't see what requiring monotonicity can
> gain.

I was expounding on what I thought the posters had in mind rather than
vouching for the validity of the assertions, so maybe I've added some
confusion to the discussion.  If so, I'm sorry.

If you allow for UDP datagrams to go missing, which is a required assumption
in the general case, the server does need to cache some reasonable number of
recently used Identifier values.  If the client always sends monotonically
increasing values, the size of the required cache is fairly small.  If the
Identifier value can be random, then you might well need to cache 256 values
for each NAS IP/UDP Src Port tuple.

I didn't follow the discussion (referred to earlier in this thread) about
the need to cache the entire request message, so I'll not comment on that.

It might be that Glen is optimizing for a class of well behaved LANs in
which dropped datagrams and out of order deliver rarely if ever occur.  I
agree that the concept of the server performs duplicate detection by keeping
only the last received Identifier value, in a monotonically increasing
sequence, works only when the network provides reliable, in-order packet
delivery, e.g. what you might expect with TCP.

--
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: Tue, 03 Jul 2007 10:51:20 +0000
Content-class: urn:content-classes:message
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Tue, 3 Jul 2007 12:49:44 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Lars Eggert" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7BD5F.DDFB10C6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thant's fine, I inserted a note in the tracker on this respect. I guess
that Lars will hold his DISCUSS anyway until a revised version of the
I-D is available.=20
=20
Dan
=20
=20
=20
=20

________________________________

	From: Bernard Aboba [mailto:[email-masked]]=20
	Sent: Tuesday, July 03, 2007 1:09 AM
	To: Alan DeKok; Romascanu, Dan (Dan)
	Cc: [email-masked]; [email-masked]; Lars Eggert;
[email-masked]
	Subject: RE: DISCUSS: draft-ietf-radext-fixes
=09
=09
	I would agree that a revised ID is needed.  However, I'd like to
leave some time for the RADEXT WG to review the changes before bringing
the new document to the IESG for approval.   This probably can't happen
before Thursday.=20
=09
	> Date: Mon, 2 Jul 2007 23:38:42 +0200
	> From: [email-masked]
	> To: [email-masked]
	> CC: [email-masked]; [email-masked];
[email-masked]; [email-masked]
	> Subject: Re: DISCUSS: draft-ietf-radext-fixes
	>=20
	> Romascanu, Dan (Dan) wrote:
	> > The quantity and the quality of the edits seem to indicate
that a
	> > Revised ID is Needed. Do the editors believe that they can
submit this
	> > ID before the submission cut-off next week, or - dare I? -
before this
	> > Thursday telechat?=20
	>=20
	> If there's we can get acceptable terminology for the
jitter/randomness
	> issue, a revised draft can be submitted.
	>=20
	> The issue of monotonically increasing Id's is a protocol
change, and
	> it would appear to be out of the scope of the charter.
	>=20
	> Alan DeKok.
	>=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/>
=09
=09

------_=_NextPart_001_01C7BD5F.DDFB10C6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: =
0px; PADDING-TOP: 0px
}
BODY {
	FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.3132" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D112454710-03072007><FONT face=3DArial=20
color=3D#0000ff><STRONG><EM>Thant's fine, I inserted a note in the =
tracker on this=20
respect. I guess that Lars will hold his DISCUSS anyway until a revised =
version=20
of the I-D is available. </EM></STRONG></FONT></SPAN></DIV>
<DIV><SPAN class=3D112454710-03072007><STRONG><EM><FONT face=3DArial=20
color=3D#0000ff></FONT></EM></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D112454710-03072007><STRONG><EM><FONT face=3DArial=20
color=3D#0000ff>Dan</FONT></EM></STRONG></SPAN></DIV>
<DIV><SPAN class=3D112454710-03072007></SPAN>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma><B>From:</B> Bernard Aboba=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Tuesday, July 03, =
2007=20
  1:09 AM<BR><B>To:</B> Alan DeKok; Romascanu, Dan (Dan)<BR><B>Cc:</B>=20
  [email-masked]; [email-masked]; Lars Eggert;=20
  [email-masked]<BR><B>Subject:</B> RE: DISCUSS:=20
  draft-ietf-radext-fixes<BR></FONT><BR></DIV>
  <DIV></DIV>I would agree that a revised ID is needed.&nbsp; =
However,&nbsp;I'd=20
  like to&nbsp;leave some time for&nbsp;the&nbsp;RADEXT WG to review the =
changes=20
  before bringing the new document to the IESG for approval.&nbsp;&nbsp; =
This=20
  probably can't happen before Thursday. <BR><BR>&gt; Date: Mon, 2 Jul =
2007=20
  23:38:42 +0200<BR>&gt; From: [email-masked]<BR>&gt; To:=20
  [email-masked]<BR>&gt; CC: [email-masked];=20
  [email-masked]; [email-masked]; =
[email-masked]<BR>&gt;=20
  Subject: Re: DISCUSS: draft-ietf-radext-fixes<BR>&gt; <BR>&gt; =
Romascanu, Dan=20
  (Dan) wrote:<BR>&gt; &gt; The quantity and the quality of the edits =
seem to=20
  indicate that a<BR>&gt; &gt; Revised ID is Needed. Do the editors =
believe that=20
  they can submit this<BR>&gt; &gt; ID before the submission cut-off =
next week,=20
  or - dare I? - before this<BR>&gt; &gt; Thursday telechat? <BR>&gt; =
<BR>&gt;=20
  If there's we can get acceptable terminology for the =
jitter/randomness<BR>&gt;=20
  issue, a revised draft can be submitted.<BR>&gt; <BR>&gt; The issue of =

  monotonically increasing Id's is a protocol change, and<BR>&gt; it =
would=20
  appear to be out of the scope of the charter.<BR>&gt; <BR>&gt; Alan=20
  DeKok.<BR>&gt; <BR>&gt; --<BR>&gt; to unsubscribe send a message to=20
  [email-masked] with<BR>&gt; the word 'unsubscribe' in =
a single=20
  line as the message text body.<BR>&gt; archive:=20
  =
&lt;http://psg.com/lists/radiusext/&gt;<BR><BR></BLOCKQUOTE></BODY></HTML=
>

------_=_NextPart_001_01C7BD5F.DDFB10C6--

--
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: Tue, 03 Jul 2007 05:37:33 +0000
Date: Tue, 3 Jul 2007 01:36:36 -0400
From: Barney Wolff <[email-masked]>
To: "David B. Nelson" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: DISCUSS: draft-ietf-radext-fixes

On Mon, Jul 02, 2007 at 03:10:30PM -0400, David B. Nelson wrote:
> Barney Wolff writes...
> 
> > At the risk of exposing my own lack of imagination, would someone
> > please explain how monotonically increasing ids would actually help
> > duplicate detection?  Specifically, just how does it avoid the cache?
> 
> I believe it means that the server only needs to remember the last value of
> Identifier seen in a successfully processed request, for each NAS IP/UDP
> scope.  Any lower value in a newly received request is a duplicate.  The
> server obviously needs to understand the wrap behavior at the 255 --> 0
> transition, of course.

But what if the request had been lost the first time sent?  Then the
request would be new to the server, despite being a retransmission from
the client.  And in any case, the server is supposed to respond to the
request, unless it is still working on the first instance.

In other words, I don't see how the server can avoid keeping a cache
of requests/responses, so I don't see what requiring monotonicity can gain.
What am I missing?

Regards,
Barney

--
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, 02 Jul 2007 22:39:27 +0000
Content-class: urn:content-classes:message
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 15:38:55 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "David B. Nelson" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Lars Eggert" <[email-masked]>

Alan DeKok <mailto:[email-masked]> allegedly scribbled on Monday,
July 02, 2007 2:15 PM:

> Glen Zorn (gwz) wrote:
>>> Not enforcing the monotonic requirement means that servers would
>>> need to keep a cache of recently used Identifiers for each NAS
>>> IP/UDP.=20

I didn't actually write this, David did.

...

>> Only if we assume that a) there is no capabilities exchange between
>> clients & servers or b) that RADIUS servers have virtually no
>> intelligence.  If a server noticed that every single identifier
>> coming from a given client was 1 greater than the last over an hour
>> or so, couldn't it reasonably assume that the client was behaving in
>> the recommended fashion & process that client's requests in the more
>> efficient manner?
>=20
>   As opposed to caching packets keyed by (source IP, source port, Id)
> for no more than 30 seconds?=20
>=20
>   You're proposing keeping long-lived state to track Identifiers as a
> way to avoid keeping short-lived state to track Identifiers.  It's an
> novell idea, but I don't see the benefit.=20

Your cache takes a minimum of 7 bytes/client/request.  My flag can be a
bit set to 0 at start up -- if an non-increasing Identifier is ever
seen, flip the bit & fall back to the more expensive method. =20
=20
>=20
>   Alan DeKok.

--
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, 02 Jul 2007 22:10:06 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>, "Romascanu, Dan (Dan)" <[email-masked]>
CC: Lars Eggert <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 15:09:29 -0700

--_bb204ef1-b0a4-4eb4-a77e-1ef1e52bfada_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I would agree that a revised ID is needed.  However, I'd like to leave some=
 time for the RADEXT WG to review the changes before bringing the new docum=
ent to the IESG for approval.   This probably can't happen before Thursday.=
=20
> Date: Mon, 2 Jul 2007 23:38:42 +0200> From: [email-masked]> To: dromas=
[email-masked]> CC: [email-masked]; [email-masked]; radi=
[email-masked]; [email-masked]> Subject: Re: DISCUSS: draft-ietf-radext-=
fixes> > Romascanu, Dan (Dan) wrote:> > The quantity and the quality of the=
 edits seem to indicate that a> > Revised ID is Needed. Do the editors beli=
eve that they can submit this> > ID before the submission cut-off next week=
, or - dare I? - before this> > Thursday telechat? > > If there's we can ge=
t acceptable terminology for the jitter/randomness> issue, a revised draft =
can be submitted.> > The issue of monotonically increasing Id's is a protoc=
ol change, and> it would appear to be out of the scope of the charter.> > A=
lan DeKok.> > --> to unsubscribe send a message to [email-masked]=
tf.org with> the word 'unsubscribe' in a single line as the message text bo=
dy.> archive: <http://psg.com/lists/radiusext/>=

--_bb204ef1-b0a4-4eb4-a77e-1ef1e52bfada_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
I would agree that a revised ID is needed.&nbsp; However,&nbsp;I'd like to&=
nbsp;leave some time for&nbsp;the&nbsp;RADEXT WG to review the changes befo=
re bringing the new document to the IESG for approval.&nbsp;&nbsp; This pro=
bably can't happen before Thursday. <BR>
<BR>&gt; Date: Mon, 2 Jul 2007 23:38:42 +0200<BR>&gt; From: [email-masked]=
rg<BR>&gt; To: [email-masked]<BR>&gt; CC: [email-masked]; radext=
[email-masked]; [email-masked]; [email-masked]<BR>&gt; Subje=
ct: Re: DISCUSS: draft-ietf-radext-fixes<BR>&gt; <BR>&gt; Romascanu, Dan (D=
an) wrote:<BR>&gt; &gt; The quantity and the quality of the edits seem to i=
ndicate that a<BR>&gt; &gt; Revised ID is Needed. Do the editors believe th=
at they can submit this<BR>&gt; &gt; ID before the submission cut-off next =
week, or - dare I? - before this<BR>&gt; &gt; Thursday telechat? <BR>&gt; <=
BR>&gt; If there's we can get acceptable terminology for the jitter/randomn=
ess<BR>&gt; issue, a revised draft can be submitted.<BR>&gt; <BR>&gt; The i=
ssue of monotonically increasing Id's is a protocol change, and<BR>&gt; it =
would appear to be out of the scope of the charter.<BR>&gt; <BR>&gt; Alan D=
eKok.<BR>&gt; <BR>&gt; --<BR>&gt; to unsubscribe send a message to radiusex=
[email-masked] with<BR>&gt; the word 'unsubscribe' in a single line=
 as the message text body.<BR>&gt; archive: &lt;http://psg.com/lists/radius=
ext/&gt;<BR><BR></body>
</html>=

--_bb204ef1-b0a4-4eb4-a77e-1ef1e52bfada_--

--
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, 02 Jul 2007 21:39:15 +0000
Date: Mon, 02 Jul 2007 23:38:42 +0200
From: Alan DeKok <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
CC: Lars Eggert <[email-masked]>,  [email-masked],  [email-masked],  [email-masked]
Subject: Re: DISCUSS: draft-ietf-radext-fixes

Romascanu, Dan (Dan) wrote:
> The quantity and the quality of the edits seem to indicate that a
> Revised ID is Needed. Do the editors believe that they can submit this
> ID before the submission cut-off next week, or - dare I? - before this
> Thursday telechat? 

  If there's we can get acceptable terminology for the jitter/randomness
issue, a revised draft can be submitted.

  The issue of monotonically increasing Id's is a protocol change, and
it would appear to be out of the scope of the charter.

  Alan DeKok.

--
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, 02 Jul 2007 21:15:52 +0000
Date: Mon, 02 Jul 2007 23:15:25 +0200
From: Alan DeKok <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  [email-masked],  [email-masked],  [email-masked],  [email-masked],  Lars Eggert <[email-masked]>, Alan DeKok <[email-masked]>
Subject: Re: DISCUSS: draft-ietf-radext-fixes

Glen Zorn (gwz) wrote:
>> Not enforcing the monotonic requirement means that servers would need
>> to keep a cache of recently used Identifiers for each NAS IP/UDP. 

  Yes.  This is what RADIUS servers do.  The text in Section 2.2.2 of
the "fixes" document was added after a previous discussion on the RADEXT
list.  The consensus at that time was that mandating a cache was useful,
and reflected existing practices.

> Only if we assume that a) there is no capabilities exchange between
> clients & servers or b) that RADIUS servers have virtually no
> intelligence.  If a server noticed that every single identifier coming
> from a given client was 1 greater than the last over an hour or so,
> couldn't it reasonably assume that the client was behaving in the
> recommended fashion & process that client's requests in the more
> efficient manner?

  As opposed to caching packets keyed by (source IP, source port, Id)
for no more than 30 seconds?

  You're proposing keeping long-lived state to track Identifiers as a
way to avoid keeping short-lived state to track Identifiers.  It's an
novell idea, but I don't see the benefit.

  Alan DeKok.

--
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, 02 Jul 2007 21:10:02 +0000
Date: Mon, 02 Jul 2007 23:08:59 +0200
From: Alan DeKok <[email-masked]>
To: Barney Wolff <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  [email-masked]
Subject: Re: DISCUSS: draft-ietf-radext-fixes

Barney Wolff wrote:
> At the risk of exposing my own lack of imagination, would someone
> please explain how monotonically increasing ids would actually help
> duplicate detection?  Specifically, just how does it avoid the cache?

  It doesn't.

  I am unaware of any client that behaves this way.  I am unaware of any
server that requires monotonically increasing id's.

  Monotonically increasing id's are not necessary in EAP.  They are not
necessary in RADIUS.

  Alan DeKok.

--
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, 02 Jul 2007 19:22:17 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Glen Zorn \(gwz\)'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Lars Eggert'" <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 15:19:55 -0400
Organization: Elbrys Networks, Inc.

> Only if we assume that a) there is no capabilities exchange between
> clients & servers...

Which has not been specified.

> ... or b) that RADIUS servers have virtually no
> intelligence.  If a server noticed that every single identifier coming
> from a given client was 1 greater than the last over an hour or so,
> couldn't it reasonably assume that the client was behaving in the
> recommended fashion & process that client's requests in the more
> efficient manner?  For that matter, it could be a flag in the clients
> file.

That sounds like it would work, except in rare corner cases, such a client
version downgrade.

--
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, 02 Jul 2007 19:13:27 +0000
Content-class: urn:content-classes:message
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 12:13:06 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Lars Eggert" <[email-masked]>, "Alan DeKok" <[email-masked]>

David B. Nelson <mailto:[email-masked]> allegedly scribbled
on Monday, July 02, 2007 10:52 AM:

>> I was referring to server-side duplicate detection, as was the
>> original comment, I believe.
>=20
> Ah, so it was.
>=20
> Yes, it would be nice if Identifiers were monotonically increasing
> (within the scope of a NAS IP address and NAS source UDP port).  It
> is likely that many implementations behave that way -- it's the most
> straightforward thing to do.  =20
>=20
> Not enforcing the monotonic requirement means that servers would need
> to keep a cache of recently used Identifiers for each NAS IP/UDP.=20
>=20
> What do you propose to do about implementations that don't implement
> monotonically increasing Identifiers?  For the server to rely on
> monotonically increasing Identifiers in it's supplicate detection,
> this would have to be a MUST for the clients, effectively deprecating
> any implementation that uses a different scheme. =20

Only if we assume that a) there is no capabilities exchange between
clients & servers or b) that RADIUS servers have virtually no
intelligence.  If a server noticed that every single identifier coming
from a given client was 1 greater than the last over an hour or so,
couldn't it reasonably assume that the client was behaving in the
recommended fashion & process that client's requests in the more
efficient manner?  For that matter, it could be a flag in the clients
file.  I don't really see anything here that spells "mandatory".

> It would seem that
> this would at least require a protocol version field, to make it
> work, ignoring for the moment the fact that non-backwards compatible
> changes are prohibited in our charter.      =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: Mon, 02 Jul 2007 19:12:44 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Barney Wolff'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 15:10:30 -0400
Organization: Elbrys Networks, Inc.

Barney Wolff writes...

> At the risk of exposing my own lack of imagination, would someone
> please explain how monotonically increasing ids would actually help
> duplicate detection?  Specifically, just how does it avoid the cache?

I believe it means that the server only needs to remember the last value of
Identifier seen in a successfully processed request, for each NAS IP/UDP
scope.  Any lower value in a newly received request is a duplicate.  The
server obviously needs to understand the wrap behavior at the 255 --> 0
transition, of course.

--
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, 02 Jul 2007 19:08:19 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Glen Zorn \(gwz\)'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Alan DeKok'" <[email-masked]>, "'Lars Eggert'" <[email-masked]>
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 15:06:07 -0400
Organization: Elbrys Networks, Inc.

Glen writes...

> Anyway, this could be easily accomplished w/o modifying legacy 
> clients or servers while nevertheless future-proofing the protocol...

How would a "modified" server decide if a newly received request message,
with a lower Identifier value than the most recently processed request, was
(a) a duplicate or (b) a different request, from a legacy client that
doesn't enforce monotonically increasing Identifier values?

--
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, 02 Jul 2007 19:04:21 +0000
Date: Mon, 2 Jul 2007 15:03:57 -0400
From: Barney Wolff <[email-masked]>
To: "David B. Nelson" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: DISCUSS: draft-ietf-radext-fixes

At the risk of exposing my own lack of imagination, would someone
please explain how monotonically increasing ids would actually help
duplicate detection?  Specifically, just how does it avoid the cache?
Thanks,
Barney

On Mon, Jul 02, 2007 at 01:51:55PM -0400, David B. Nelson wrote:
> > I was referring to server-side duplicate detection, as was the original
> > comment, I believe.
> 
> Ah, so it was.
> 
> Yes, it would be nice if Identifiers were monotonically increasing (within
> the scope of a NAS IP address and NAS source UDP port).  It is likely that
> many implementations behave that way -- it's the most straightforward thing
> to do.
> 
> Not enforcing the monotonic requirement means that servers would need to
> keep a cache of recently used Identifiers for each NAS IP/UDP.

--
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, 02 Jul 2007 18:59:29 +0000
Content-class: urn:content-classes:message
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 11:58:30 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Alan DeKok" <[email-masked]>, "Lars Eggert" <[email-masked]>

David B. Nelson <mailto:[email-masked]> allegedly scribbled
on Monday, July 02, 2007 10:38 AM:

> Glen Zorn writes...
>=20
>> I've never actually understood this contention.  If these are
>> actually issues with and fixes for the RADIUS protocol, then it
>> would seem to me that the last thing you would want is to be
>> backwards compatible with something that's broken.  If the behavior
>> is broken, then change the behavior.
>=20
> Is it broken?  Or just sub-optimal?  Years of interoperability in the
> field tend to indicate that it's not "broken" in terms of
> interoperability.  I guess it depends on how one defines "broken".=20
> I've often found that to be a subjective assessment.=20

OK, I'll bite: if nothing's broken, what are we fixing? =20
 =20
>=20
> Assuming the RADEXT charter allowed us to make non-backwards
> compatible changes, wouldn't that require some sort of protocol
> version field in order to promote interoperability? =20

I guess that depends upon how you define "interoperability".  Anyway,
this could be easily accomplished w/o modifying legacy clients or
servers while nevertheless futureproofing the protocol (a good idea
unless we really believe that this is the last work that will ever be
needed).

--
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, 02 Jul 2007 18:09:17 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Lars Eggert'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 14:07:02 -0400
Organization: Elbrys Networks, Inc.

> The issue with the original text above is that if sounds like it is a
> clarification of RFC2865, but RFC2865 (in my reading) doesn't contain
> anything substantial on the issue of retransmission timer management.

Correct.

> If the WG has consensus to more clearly specify this mechanism (which
> I assume it does, because the issue included in the -fixes draft)
> what's currently there isn't sufficient.

OK. I think that the text proposed to resolve this DISCUSS is fine using the
RECCOMMENDED keyword.  This is an issue with deployments, and as a
recommended practice it would be useful to provide a complete specification.

--
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, 02 Jul 2007 18:03:34 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Lars Eggert'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 14:01:16 -0400
Organization: Elbrys Networks, Inc.

> I'm open for a better term, but not jitter.

Hmmm...  How about "retry synchronization avoidance"?

--
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, 02 Jul 2007 17:54:11 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Glen Zorn \(gwz\)'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Lars Eggert'" <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 13:51:55 -0400
Organization: Elbrys Networks, Inc.

> I was referring to server-side duplicate detection, as was the original
> comment, I believe.

Ah, so it was.

Yes, it would be nice if Identifiers were monotonically increasing (within
the scope of a NAS IP address and NAS source UDP port).  It is likely that
many implementations behave that way -- it's the most straightforward thing
to do.

Not enforcing the monotonic requirement means that servers would need to
keep a cache of recently used Identifiers for each NAS IP/UDP.

What do you propose to do about implementations that don't implement
monotonically increasing Identifiers?  For the server to rely on
monotonically increasing Identifiers in it's supplicate detection, this
would have to be a MUST for the clients, effectively deprecating any
implementation that uses a different scheme.  It would seem that this would
at least require a protocol version field, to make it work, ignoring for the
moment the fact that non-backwards compatible changes are prohibited in our
charter.

--
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, 02 Jul 2007 17:40:03 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Glen Zorn \(gwz\)'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Alan DeKok'" <[email-masked]>, "'Lars Eggert'" <[email-masked]>
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 13:37:51 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...
 
> I've never actually understood this contention.  If these are actually
> issues with and fixes for the RADIUS protocol, then it would seem to me
> that the last thing you would want is to be backwards compatible with
> something that's broken.  If the behavior is broken, then change the
> behavior.

Is it broken?  Or just sub-optimal?  Years of interoperability in the field
tend to indicate that it's not "broken" in terms of interoperability.  I
guess it depends on how one defines "broken".  I've often found that to be a
subjective assessment.

Assuming the RADEXT charter allowed us to make non-backwards compatible
changes, wouldn't that require some sort of protocol version field in order
to promote interoperability?

--
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, 02 Jul 2007 17:35:55 +0000
Content-class: urn:content-classes:message
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 10:35:07 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Lars Eggert" <[email-masked]>, "Alan DeKok" <[email-masked]>

David B. Nelson <mailto:[email-masked]> allegedly scribbled
on Monday, July 02, 2007 10:12 AM:

> Glen Zorn writes...
>=20
>> This paragraph sound self-contradictory to me: how can a client
>> silently discard duplicate responses if it doesn't detect that they
>> _are_ duplicate responses?
>=20
> It merely needs to determine that the response is related to a
> request that is no longer pending.  That's a form of duplicate
> detection, I suppose, but it does not require that the response is
> literally a duplicate, only that it is not expected or needed. =20

I don't know why we're dancing around this; why not just say that the
client must discard responses with unrecognized values in the Identifier
field?
=20
>=20
>> This doesn't see to address the issue of the Identifier being
>> essentially useless for duplicate detection if not monotonically
>> increasing...
>=20
> Monotonically increasing Identifiers would be nice, as it makes the
> detection algorithm much more efficient.  As above, all that is
> _required_ is that the client can tell that the response is related
> to a request that is no longer pending. =20

I was referring to server-side duplicate detection, as was the original
comment, I believe.

> Adding a new normative
> requirement for monotonically increasing Identifiers would seem to me
> to be a non-backward compatible change to RADIUS, and thus likely out
> of scope.     =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: Mon, 02 Jul 2007 17:27:21 +0000
Content-class: urn:content-classes:message
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 10:26:41 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>, "Lars Eggert" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Alan DeKok" <[email-masked]>

David B. Nelson <> allegedly scribbled on Monday, July 02, 2007 10:05
AM:

...

>=20
>>>   DISCUSS: RFC2865 Section 2.4 does not suggests any timer
>>>   management scheme or timer limits, and I couldn't find this
>>>   anywhere else in RFC2865, either. Consequently, this document
>>>   needs to specify the desired mechanism. See RFC2988 for an
>>> example of such a mechanism.=20
>>=20
>>   Proposal:  Delete the last two sentences (For example...)  Then,
>> use text similar to that in Section 9 of draft-pana-pana.  It seems
>> to cover the RADIUS requirements pretty well.  Some RADIUS
>> implementations behave this way already.  Also add an informative
>> reference to RFC 3315, and note in the acknowledgements that the
>> following text is adapted from draft-ietf-pana-pana.
>=20
> Adding a RECOMMENDED method for achieving the desired
> jitter/randomization of retry times is probably a good thing.  I
> think we need to be careful to avoid adding normative requirements in
> this area, however.  Out charter is to extend RADIUS, and clarify
> some documentation errors.  We don't have leave to introduce
> non-backwards compatible normative requirements.  While new protocols
> would have a higher barrier to publication, we need to recall that
> RADIUS is a widely deployed, legacy protocol.  Some of the behaviors
> are "grandfathered". =20

I've never actually understood this contention.  If these are actually
issues with and fixes for the RADIUS protocol, then it would seem to me
that the last thing you would want is to be backwards compatible with
something that's broken.  If the behavior is broken, then change the
behavior. =20
     =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: Mon, 02 Jul 2007 17:22:27 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Romascanu, Dan \(Dan\)'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "'ext Alan DeKok'" <[email-masked]>, "'Lars Eggert'" <[email-masked]>
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 13:20:16 -0400
Organization: Elbrys Networks, Inc.

> The quantity and the quality of the edits seem to indicate that a
> Revised ID is Needed. Do the editors believe that they can submit this
> ID before the submission cut-off next week, or - dare I? - before this
> Thursday telechat?

Given that there has been some discussion of the proposed text on the RADEXT
WG list, maybe this Thursday is a bit aggressive. 

--
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, 02 Jul 2007 17:13:58 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Glen Zorn \(gwz\)'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Lars Eggert'" <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 13:11:30 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...
 
> This paragraph sound self-contradictory to me: how can a client 
> silently discard duplicate responses if it doesn't detect that 
> they _are_ duplicate responses?

It merely needs to determine that the response is related to a request that
is no longer pending.  That's a form of duplicate detection, I suppose, but
it does not require that the response is literally a duplicate, only that it
is not expected or needed.

> This doesn't see to address the issue of the Identifier being
> essentially useless for duplicate detection if not monotonically
> increasing...

Monotonically increasing Identifiers would be nice, as it makes the
detection algorithm much more efficient.  As above, all that is _required_
is that the client can tell that the response is related to a request that
is no longer pending.  Adding a new normative requirement for monotonically
increasing Identifiers would seem to me to be a non-backward compatible
change to RADIUS, and thus likely out of scope.

--
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, 02 Jul 2007 17:07:10 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Lars Eggert'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 13:04:57 -0400
Organization: Elbrys Networks, Inc.

> Lars Eggert wrote:

> >   DISCUSS: "Jitter" is not the correct term.

I have no investment is this particular word, but I disagree that it is
incorrect.  "Jitter" has been used in the industry to describe this kind of
behavior for decades, and I think it is well understood.
 
>   Proposed replacement text:
> 
> [a] Randomization. 

I like this work less than "Jitter".  The retry times are not random, they
are merely random within a small delta.  I don't know that this is an
improvement.

> >   DISCUSS: RFC2865 Section 2.4 does not suggests any timer management
> >   scheme or timer limits, and I couldn't find this anywhere else in
> >   RFC2865, either. Consequently, this document needs to specify the
> >   desired mechanism. See RFC2988 for an example of such a mechanism.
> 
>   Proposal:  Delete the last two sentences (For example...)  Then, use
> text similar to that in Section 9 of draft-pana-pana.  It seems to cover
> the RADIUS requirements pretty well.  Some RADIUS implementations behave
> this way already.  Also add an informative reference to RFC 3315, and
> note in the acknowledgements that the following text is adapted from
> draft-ietf-pana-pana.

Adding a RECOMMENDED method for achieving the desired jitter/randomization
of retry times is probably a good thing.  I think we need to be careful to
avoid adding normative requirements in this area, however.  Out charter is
to extend RADIUS, and clarify some documentation errors.  We don't have
leave to introduce non-backwards compatible normative requirements.  While
new protocols would have a higher barrier to publication, we need to recall
that RADIUS is a widely deployed, legacy protocol.  Some of the behaviors
are "grandfathered".

> >   DISCUSS: This section is all about duplicate detection at the server
> >   due to client retransmissions. But any UDP packet can be duplicated in
> >   the network. This section should hence also discuss detection of
> >   duplicate responses at the client.
> 
>   Proposed added text:
> 
>   RADIUS clients do not have to perform duplicate detection.  When a
> client sends a request, it processes the first response that has a valid
> Response Authenticator as defined in Section 3 of [RFC2865].  Any
> duplicate responses MUST be silently discarded.

This seems OK, to me, as this is the behavior of all of the RADIUS clients
I'm aware of.

> >   DISCUSS: I could not find a discussion in RFC2865 on how the
> >   Identifier field is to be managed. For duplicate detection, it should
> >   be monotonically increasing or similar. If RFC2865 doesn't specify how
> >   the Identifier fields is to be used, this document needs to do so if
> >   it wants to base duplicate detection  on it.
> 
>   In general, Identifier management hasn't been an issue.  Clients don't
> re-use Identifiers that have not yet received responses.  That's simple
> enough that almost everybody gets it right.  Clients re-use Identifiers
> that have received responses.  The order in which they re-use
> identifiers matters only for requests that have timed out.
> 
>   Proposed text:
> 
>   When sending requests, RADIUS clients MUST NOT re-use Identifiers for
> a source IP address and source UDP port until either a valid response
> has been received, or the request has timed out.  Clients SHOULD
> allocate Identifiers via a least recently used (LRU) method for a
> particular source IP address and source UDP port.

I'm, OK with this.

> >   DISCUSS: The Internet MSL is 2 minutes - choosing this as a lower
> >   bound will prevent late duplicates from remaining undetected.
> 
>   RFC 2865 Section 2.4 notes that TCP's reliable delivery of data 2
> minutes late is not useful.  The timeout of 30 seconds is based on
> partially on that, on NAS implementations, and on user patience.  Most
> NAS implementations will give up on a request after 30 seconds, as will
> most users.  Therefore, caching duplicates after 30 seconds is
> unproductive.

Agreed.

--
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, 02 Jul 2007 16:58:58 +0000
Content-class: urn:content-classes:message
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 09:58:20 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Lars Eggert" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Alan DeKok <> allegedly scribbled on Monday, July 02, 2007 6:20 AM:

...

>> Section 2.2.2., paragraph 0:
>>> 2.2.2.  Duplicate detection and orderly delivery.
>>=20
>>   DISCUSS: This section is all about duplicate detection at the
>>   server due to client retransmissions. But any UDP packet can be
>>   duplicated in the network. This section should hence also discuss
>>   detection of duplicate responses at the client.
>=20
>   Proposed added text:
>=20
>   RADIUS clients do not have to perform duplicate detection.  When a
> client sends a request, it processes the first reponse that has a
> valid Response Authenticator as defined in Section 3 of [RFC2865].=20
> Any duplicate responses MUST be silently discarded. =20

This paragraph sound self-contradictory to me: haw can a client silently
discard duplicate responses if it doesn't detect that they _are_
duplicate responses?
=20
>=20
>>=20
>> Section 2.2.2., paragraph 2:
>>>       The RADIUS server can detect a duplicate request if it has the
>>>       same client source IP address and source UDP port and
>>>       Identifier within a short span of time.
>>=20
>>   DISCUSS: I could not find a discussion in RFC2865 on how the
>>   Identifier field is to be managed. For duplicate detection, it
>>   should be monotonically increasing or similar. If RFC2865 doesn't
>>   specify how the Identifier fields is to be used, this document
>>   needs to do so if it wants to base duplicate detection  on it.
>=20
>   In general, Identifier management hasn't been an issue.  Clients
> don't re-use Identifiers that have not yet received responses.=20
> That's simple enough that almost everybody gets it right.  Clients
> re-use Identifiers that have received responses.  The order in which
> they re-use identifiers matters only for requests that have timed
> out.    =20
>=20
>   Proposed text:
>=20
>   When sending requests, RADIUS clients MUST NOT re-use Identifiers
> for a source IP address and source UDP port until either a valid
> response has been received, or the request has timed out.  Clients
> SHOULD allocate Identifiers via a least recently used (LRU) method
> for a particular source IP address and source UDP port.=20

This doesn't seem to address the issue of the Identifier being
essentially useless for duplicate detection if not monotonically
increasing...
  =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: Mon, 02 Jul 2007 16:25:47 +0000
Content-class: urn:content-classes:message
Subject: RE: DISCUSS: draft-ietf-radext-fixes
Date: Mon, 2 Jul 2007 18:24:48 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Lars Eggert" <[email-masked]>, "ext Alan DeKok" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

The quantity and the quality of the edits seem to indicate that a
Revised ID is Needed. Do the editors believe that they can submit this
ID before the submission cut-off next week, or - dare I? - before this
Thursday telechat?=20

Dan

=20
=20

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]]=20
>=20
> I think we now have agreed on resolutions for the different=20
> items in my DISCUSS. This was the fastest DISCUSS-resolution=20
> ever - thanks!
>=20
> Lars
>=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: Mon, 02 Jul 2007 14:10:11 +0000
Date: Mon, 02 Jul 2007 16:09:20 +0200
From: Alan DeKok <[email-masked]>
To: Lars Eggert <[email-masked]>
CC: Alan DeKok <[email-masked]>,  [email-masked],  [email-masked],  [email-masked],  [email-masked]
Subject: Re: DISCUSS: draft-ietf-radext-fixes

Lars Eggert wrote:
...
>>   RADIUS clients do not have to perform duplicate detection.  When a
>> client sends a request, it processes the first reponse that has a valid
>> Response Authenticator as defined in Section 3 of [RFC2865].  Any
>> duplicate responses MUST be silently discarded.
> 
> If clients need not perform duplicate detection, how can they discard
> duplicates? We seem to have a misunderstanding here.

  As network designers, we know that the packets are duplicates.  The
client implementations, however, simply track requests & responses.  If
they have a response to a request, they stop tracking the request.  Any
packet that they receive after that is either a duplicate and can be
dropped, or is an attacker trying to spoof the server, and can be dropped.

  Perhaps the text should be "Any later responses MUST be silently
discarded", which avoids the "duplicate" issue.
...
> Works for me, but let me point out that because the Identifier field is
> only 8 bits long, this may prevent the client from issuing new requests
> if 256 requests are waiting to be retransmitted. I'm not sure how likely
> this is, but it might occur for example after a longer network disruption.

  Yes.  This issue is covered in Section 2.5 of RFC 2865:

   A NAS MAY use the same ID across all servers, or MAY keep track of
   IDs separately for each server, it is up to the implementer.  If a
   NAS needs more than 256 IDs for outstanding requests, it MAY use
   additional source ports to send requests from, and keep track of IDs
   for each source port.  This allows up to 16 million or so outstanding
   requests at one time to a single server.

  All major implementations will open multiple source ports if the 8-bit
Identifier space has been exhausted.

> Choosing 2 minutes as the cache lifetime means that you are guaranteed
> that all duplicated requests will be answered with a cached copy of the
> original reply, whereas any shorter cache lifetime means that late
> duplicate requests will be re-processed as if they were new. That seems
> to goes against the "(the sever) MUST resend its original Response
> without reprocessing the request" statement in the document.

  That's all true, except that after 30 seconds, the client will give
up.  The issue for the server is more about inter-packet spacing than
MSL.  The MSL matters really only to the NAS, who sees the entire
network in the packet round trip time.  The NAS either accepts the first
valid response within that 30 second window, OR gives up on the request.
 Any later retransmits of cached requests by the server are ignored by
the NAS.

  Unless the network drastically changes inter-packet spacing, the
server will see packets spread over approximately 30 seconds.  So if the
server responds to the first request, it must cache the reply for long
enough to ensure that it can send a cached response to all re-transmits
from the NAS.  So 30 seconds plus a little bit is sufficient for server
cache timeout.

  If retransmits from the NAS have an inter-packet spread of more than
30 seconds, then either the network is sitting on the packets for 30+
seconds, OR the packets are being routed via drastically different
routes.  I'm not sure those cases are anything we can solve by extending
the server cache time.

  Note I'm not completely opposed to suggesting a maximum cache time of
2 minutes.  Most NASes will re-use Identifiers, which means that the
real-world cache times are usually on the order of seconds.  So server
implementations aren't drastically affected by the 2 minutes versus 30
seconds.

  Alan DeKok.

--
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, 02 Jul 2007 13:20:48 +0000
Date: Mon, 02 Jul 2007 15:20:08 +0200
From: Alan DeKok <[email-masked]>
To: Lars Eggert <[email-masked]>,  [email-masked]
CC:  [email-masked],  [email-masked],  [email-masked]
Subject: Re: DISCUSS: draft-ietf-radext-fixes

Lars Eggert wrote:
> Discuss:
> Section 2.2.1., paragraph 6:
>> [a]  Jitter.  To avoid synchronization, a RADIUS client SHOULD
>>      incorporate jitter within its retransmission algorithm.
> 
>   DISCUSS: "Jitter" is not the correct term. What is suggested here is
>   to incorporate a random factor into the retransmission timer
>   calculation. This will prevent synchronization, but won't help against
>   congestion collapse, because it doesn't reduce the number of
>   retransmissions over time. Only [b] will address that. Also, please
>   specify how a random factor is to be incorporated into the computation
>   - see Section 9 of draft-ietf-pana-pana for an example.

  Proposed replacement text:

[a] Randomization.  To avoid synchronization, a RADIUS client SHOULD
incorporate a randomization factor within its retransmission algorithm,
as specified below.

> Section 2.2.1., paragraph 7:
>> [b]  Congestive backoff.  While it is not necessary for RADIUS client
>>      implementations to implement complex retransmission algorithms,
>>      implementations SHOULD support congestive backoff within the limits
>>      suggested by [RFC2865] Section 2.4.  For example, an implementation
>>      SHOULD double the initial retransmission timer until a maximum
>>      retransmission time is reached, after which the client will
>>      failover to another RADIUS server.  For example, if the initial
>>      retransmission timer is one second, a maximum retransmission timer
>>      of 16 seconds might be used.
> 
>   DISCUSS: RFC2865 Section 2.4 does not suggests any timer management
>   scheme or timer limits, and I couldn't find this anywhere else in
>   RFC2865, either. Consequently, this document needs to specify the
>   desired mechanism. See RFC2988 for an example of such a mechanism.

  Proposal:  Delete the last two sentences (For example...)  Then, use
text similar to that in Section 9 of draft-pana-pana.  It seems to cover
the RADIUS requirements pretty well.  Some RADIUS implementations behave
this way already.  Also add an informative reference to RFC 3315, and
note in the acknowledgements that the following text is adapted from
draft-ietf-pana-pana.

...
     RADIUS retransmission timers are based on the model used in DHCPv6
     [RFC3315].  Variables used here are also borrowed from this
     specification.  RADIUS is a request/response-based protocol.  The
     message exchange terminates when the requester successfully
     receives the answer or the message exchange is considered to have
     failed according to the retransmission mechanism described below.

     The retransmission behavior is controlled and described by the
     following variables:

           RT     Retransmission timeout

           IRT    Initial retransmission time  (default 2 seconds)

           MRC    Maximum retransmission count (default 10 attempts)

           MRT    Maximum retransmission time (default 16 seconds)

           MRD    Maximum retransmission duration (default 30 seconds)

           RAND   Randomization factor

     With each message transmission or retransmission, the sender sets
     RT according to the rules given below.  If RT expires before the
     message exchange terminates, the sender recomputes RT and
     retransmits the message.

     Each of the computations of a new RT include a randomization factor
     (RAND), which is a random number chosen with a uniform distribution
     between -0.1 and +0.1.  The randomization factor is included to
     minimize synchronization of messages.

     The algorithm for choosing a random number does not need to be
     cryptographically sound.  The algorithm SHOULD produce a different
     sequence of random numbers from each invocation.

     RT for the first message transmission is based on IRT:

           RT = IRT + RAND*IRT

     RT for each subsequent message retransmission is based on the
     previous value of RT:

           RT = 2*RTprev + RAND*RTprev

     MRT specifies an upper bound on the value of RT (disregarding the
     randomization added by the use of RAND).  If MRT has a value of 0,
     there is no upper limit on the value of RT.  Otherwise:

           if (RT > MRT)
              RT = MRT + RAND*MRT

     MRD specifies an upper bound on the length of time a sender may
     retransmit a message.  The message exchange fails once MRD seconds
     have elapsed since the client first transmitted the message.  MRD
     MUST be set, and SHOULD have a value between 5 and 30 seconds.
     These values mirror the values for a servers duplicate detection
     cache, as described in the next section.

     MRC specifies an upper bound on the number of times a sender may
     retransmit a message.  if MRC is zero, the message exchange fails
     once MRD seconds have elapsed since the client first transmitted
     the message.  If MRC is non-zero, the message exchange fails when
     the either the sender has transmitted the message MRC times, or
     when MRD seconds have elapsed since the client first transmitted
     the message.
...

> Section 2.2.2., paragraph 0:
>> 2.2.2.  Duplicate detection and orderly delivery.
> 
>   DISCUSS: This section is all about duplicate detection at the server
>   due to client retransmissions. But any UDP packet can be duplicated in
>   the network. This section should hence also discuss detection of
>   duplicate responses at the client.

  Proposed added text:

  RADIUS clients do not have to perform duplicate detection.  When a
client sends a request, it processes the first reponse that has a valid
Response Authenticator as defined in Section 3 of [RFC2865].  Any
duplicate responses MUST be silently discarded.

> 
> Section 2.2.2., paragraph 2:
>>       The RADIUS server can detect a duplicate request if it has the
>>       same client source IP address and source UDP port and Identifier
>>       within a short span of time.
> 
>   DISCUSS: I could not find a discussion in RFC2865 on how the
>   Identifier field is to be managed. For duplicate detection, it should
>   be monotonically increasing or similar. If RFC2865 doesn't specify how
>   the Identifier fields is to be used, this document needs to do so if
>   it wants to base duplicate detection  on it.

  In general, Identifier management hasn't been an issue.  Clients don't
re-use Identifiers that have not yet received responses.  That's simple
enough that almost everybody gets it right.  Clients re-use Identifiers
that have received responses.  The order in which they re-use
identifiers matters only for requests that have timed out.

  Proposed text:

  When sending requests, RADIUS clients MUST NOT re-use Identifiers for
a source IP address and source UDP port until either a valid response
has been received, or the request has timed out.  Clients SHOULD
allocate Identifiers via a least recently used (LRU) method for a
particular source IP address and source UDP port.

> Section 2.2.2., paragraph 8:
>>    Each cache entry SHOULD be purged after a period of time.  This time
>>    SHOULD be no less than 5 seconds, and no more than 30 seconds.
> 
>   DISCUSS: The Internet MSL is 2 minutes - choosing this as a lower
>   bound will prevent late duplicates from remaining undetected.

  RFC 2865 Section 2.4 notes that TCP's reliable delivery of data 2
minutes late is not useful.  The timeout of 30 seconds is based on
partially on that, on NAS implementations, and on user patience.  Most
NAS implementations will give up on a request after 30 seconds, as will
most users.  Therefore, caching duplicates after 30 seconds is unproductive.

  Alan DeKok.

--
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, 02 Jul 2007 12:52:12 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: FW: DISCUSS: draft-ietf-radext-fixes 
Date: Mon, 2 Jul 2007 08:51:55 -0400

IESG review comment:

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]]
> Sent: Monday, July 02, 2007 7:49 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: DISCUSS: draft-ietf-radext-fixes
> 
> Discuss:
> Section 2.2.1., paragraph 6:
> > [a]  Jitter.  To avoid synchronization, a RADIUS client SHOULD
> >      incorporate jitter within its retransmission algorithm.
> 
>   DISCUSS: "Jitter" is not the correct term. What is suggested here is
>   to incorporate a random factor into the retransmission timer
>   calculation. This will prevent synchronization, but won't help against
>   congestion collapse, because it doesn't reduce the number of
>   retransmissions over time. Only [b] will address that. Also, please
>   specify how a random factor is to be incorporated into the computation
>   - see Section 9 of draft-ietf-pana-pana for an example.
> 
> 
> Section 2.2.1., paragraph 7:
> > [b]  Congestive backoff.  While it is not necessary for RADIUS client
> >      implementations to implement complex retransmission algorithms,
> >      implementations SHOULD support congestive backoff within the limits
> >      suggested by [RFC2865] Section 2.4.  For example, an implementation
> >      SHOULD double the initial retransmission timer until a maximum
> >      retransmission time is reached, after which the client will
> >      failover to another RADIUS server.  For example, if the initial
> >      retransmission timer is one second, a maximum retransmission timer
> >      of 16 seconds might be used.
> 
>   DISCUSS: RFC2865 Section 2.4 does not suggests any timer management
>   scheme or timer limits, and I couldn't find this anywhere else in
>   RFC2865, either. Consequently, this document needs to specify the
>   desired mechanism. See RFC2988 for an example of such a mechanism.
> 
> 
> Section 2.2.2., paragraph 0:
> > 2.2.2.  Duplicate detection and orderly delivery.
> 
>   DISCUSS: This section is all about duplicate detection at the server
>   due to client retransmissions. But any UDP packet can be duplicated in
>   the network. This section should hence also discuss detection of
>   duplicate responses at the client.
> 
> 
> Section 2.2.2., paragraph 2:
> >       The RADIUS server can detect a duplicate request if it has the
> >       same client source IP address and source UDP port and Identifier
> >       within a short span of time.
> 
>   DISCUSS: I could not find a discussion in RFC2865 on how the
>   Identifier field is to be managed. For duplicate detection, it should
>   be monotonically increasing or similar. If RFC2865 doesn't specify how
>   the Identifier fields is to be used, this document needs to do so if
>   it wants to base duplicate detection  on it.
> 
> 
> Section 2.2.2., paragraph 8:
> >    Each cache entry SHOULD be purged after a period of time.  This time
> >    SHOULD be no less than 5 seconds, and no more than 30 seconds.
> 
>   DISCUSS: The Internet MSL is 2 minutes - choosing this as a lower
>   bound will prevent late duplicates from remaining undetected.
> 

--
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/>