Subject: RE: RFC 3576bis Question: DAC and RADIUS server not co-located
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Date: Sun, 30 Sep 2007 14:52:42 +0700

I have always assumed that "DAC" was just another name for "RADIUS server",
i.e., the same entity acting in two different roles.

[gwz] ...

--
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, 30 Sep 2007 07:28:42 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: Vendor-Id for radext extended attributes
Date: Sun, 30 Sep 2007 14:27:32 +0700

[gwz] ...
[gwz] 
I would agree that there is a namespace management issue, not only for the 
extensions, but also for VSAs in general.  If we are looking to enable SDOs 
to manage their own RADIUS attribute space much as as they manage their OID 
space (e.g. virtually unlimited space, not gated by IANA), then I don't 
think you can get there via use of a single Vendor-Id and an 8 bit 
Vendor-Type space.
[gwz] I don't know -- it seems to have worked out OK so far...

The question in my mind is whether it is better to go with multiple 
Vendor-Ids, or instead, to expand the Vendor-Type space to 16 bits.   While 
there is more work involved in supporting a 16-bit Vendor-Type space, it 
seems like a cleaner solution long term, particularly from the IANA point of

view.  Asking IANA to track Vendor-Id allocations for individual WGs, and 
individual RADIUS attribute allocations within those Vendor-Ids, seems like 
it could quickly become complex.
[gwz] 
[gwz] Not sure why we wouldn't let the "vendors" manage their own 8-bit
areas; in any case, though we're talking about a 2-level hierarchy which I
can't imagine anyone (esp. the efficient folks @ IANA) considering
complex...

--
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, 28 Sep 2007 20:27:16 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: RFC 3576bis Question: DAC and RADIUS server not co-located
Date: Fri, 28 Sep 2007 13:26:29 -0700

>Bernard Aboba wrote:
> > What happens if the DAC and RADIUS server are not co-located?
>
>   The simplest thing to do is to have the DAC send the CoA to the RADIUS
>server, which then sends it to the NAS.  The RADIUS server can add
>information such as State.
>
> >  Is that
> > viable in situations where a Service-Type="Authorize Only" is used on a
> > CoA-Request?
>
>   I can see it being useful.  The issue for me is that RADIUS is
>normally controlling the users session information.  If a DAC sends
>requests directly to the NAS, then it is out of the normal AAA policy.
>By proxying through the RADIUS server, it gains capabilities (i.e.
>adding State), and works through the normal AAA process.

This also solves the problem of allowing the RPF check to function.

> > However, the Access-Request is received by the RADIUS server, not the
> > DAC that sent the State Attribute.  Are we assuming that the RADIUS
> > server is able to validate a State Attribute sent by the DAC?
>
>   If that is possible, how this is done is out of scope.
>
> > Or perhaps that the DAC will provide the NAS with a State Attribute
> > obtained from the RADIUS server?
>
>   It would be easier to have the DAC proxy through the RADIUS server,
>which would in turn supply a State in the CoA packet.

Yes, I think this makes sense.  Can you suggest some text that would make 
this clear?

> > Since the DAC needs access to a database of State in order to track
> > sessions, that database could contain the required State attribute.
>
>   The RADIUS server already tracks sessions.  I would recommend against
>DACs re-implementing that.

Some how the DAC needs to know which NAS to send the CoA/Disconnect-Request 
to, correct?

>   I understand that this proposed architecture may limit certain
>implementations, but it should make implementations much easier, too.

That would be good.

--
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, 28 Sep 2007 06:44:59 +0000
Date: Fri, 28 Sep 2007 08:43:57 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: RFC 3576bis Question:  DAC and RADIUS server not co-located

Bernard Aboba wrote:
> What happens if the DAC and RADIUS server are not co-located?

  The simplest thing to do is to have the DAC send the CoA to the RADIUS
server, which then sends it to the NAS.  The RADIUS server can add
information such as State.

>  Is that
> viable in situations where a Service-Type="Authorize Only" is used on a
> CoA-Request?

  I can see it being useful.  The issue for me is that RADIUS is
normally controlling the users session information.  If a DAC sends
requests directly to the NAS, then it is out of the normal AAA policy.
By proxying through the RADIUS server, it gains capabilities (i.e.
adding State), and works through the normal AAA process.

> However, the Access-Request is received by the RADIUS server, not the
> DAC that sent the State Attribute.  Are we assuming that the RADIUS
> server is able to validate a State Attribute sent by the DAC?

  If that is possible, how this is done is out of scope.

> Or perhaps that the DAC will provide the NAS with a State Attribute
> obtained from the RADIUS server?

  It would be easier to have the DAC proxy through the RADIUS server,
which would in turn supply a State in the CoA packet.

> Since the DAC needs access to a database of State in order to track
> sessions, that database could contain the required State attribute.

  The RADIUS server already tracks sessions.  I would recommend against
DACs re-implementing that.

  I understand that this proposed architecture may limit certain
implementations, but it should make implementations much easier, too.

  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, 28 Sep 2007 05:49:11 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RFC 3576bis Question:  DAC and RADIUS server not co-located
Date: Thu, 27 Sep 2007 22:48:52 -0700

A while back, we had a question about how RFC 3576bis works in the situation 
where the DAC and RADIUS server are not co-located.  Before RFC 3576bis goes 
to final IESG review, I just wanted to make sure that we haven't missed 
something.

Section 3.3 states:

   "In order to satisfy the requirements of [RFC2865] Section 5.44, an
   Access-Request with Service-Type="Authorize-Only" MUST contain a
   State attribute.

   In order to provide a State attribute to the NAS, a Dynamic
   Authorization Client sending a CoA-Request with a Service-Type value
   of "Authorize-Only" MUST include a State Attribute, and the NAS MUST
   send the State Attribute unmodified to the RADIUS server in the
   resulting Access-Request, if any. "

What happens if the DAC and RADIUS server are not co-located?  Is that 
viable in situations where a Service-Type="Authorize Only" is used on a 
CoA-Request?

Let us assume that the DAC sends a State Attribute as specified above, and 
that the NAS sends an Access-Request with Service-Type="Authorize-Only" 
containing that State Attribute.

However, the Access-Request is received by the RADIUS server, not the DAC 
that sent the State Attribute.  Are we assuming that the RADIUS server is 
able to validate a State Attribute sent by the DAC?
Or perhaps that the DAC will provide the NAS with a State Attribute obtained 
from the RADIUS server?

Since the DAC needs access to a database of State in order to track 
sessions, that database could contain the required State attribute.

--
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, 28 Sep 2007 05:43:59 +0000
Date: Fri, 28 Sep 2007 07:42:56 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Vendor-Id for radext extended attributes

Bernard Aboba wrote:
> The question in my mind is whether it is better to go with multiple
> Vendor-Ids, or instead, to expand the Vendor-Type space to 16 bits.  

  I am wary of defining yet another VSA format.  Existing 16-bit VSAs do
not support grouping, which is supported by the current extended
attribute format.  Modifying the current proposal to support 16-bit VSAs
would mean incompatibilities with WiMAX, which uses a similar format.

> While there is more work involved in supporting a 16-bit Vendor-Type
> space, it seems like a cleaner solution long term, particularly from the
> IANA point of view.  Asking IANA to track Vendor-Id allocations for
> individual WGs, and individual RADIUS attribute allocations within those
> Vendor-Ids, seems like it could quickly become complex.

  Agreed.  A flat 16-bit name space would be simpler.

  On the other hand, the WiMAX standard supports sub-AVPs inside of a
WiMAX VSA.  i.e. RADIUS attribute 26, WiMAX attribute X, sub-AVP Y, all
nested inside one another.

  Allowing that would extend the attribute space significantly.  It
would also easily permit grouping of logically related items, such as
with the filter draft.  The individual filter elements could be
converted from the current proposal (text) to AVPs inside of a filter
VSA.  That would also allow easy addition of new filter elements.

  To prioritize the choices, I'd prefer modifying the current proposal
to use 16-bit VSAs before I would add sub-AVPs.

  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, 28 Sep 2007 03:38:47 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Vendor-Id for radext extended attributes
Date: Thu, 27 Sep 2007 20:38:02 -0700

>I think that it might be a better idea instead of using the (already
>assigned to IANA, as David has pointed out) Vendor-Id of zero (0)  for the
>radext extended attributes to instead request a separate Vendor-Id for the
>radext WG & encourage other WGs that need new attributes to do the same.
>For example, the hokey WG is likely to need at least one new RADIUS
>attribute, so it would get its own ID (& therefore its own namespace).  
>This
>has the advantage of expanding the standard attribute space by leaps rather
>than baby steps ;-) & provides a fairly automatic & orderly method of
>namespace management.  Thoughts?

I would agree that there is a namespace management issue, not only for the 
extensions, but also for VSAs in general.  If we are looking to enable SDOs 
to manage their own RADIUS attribute space much as as they manage their OID 
space (e.g. virtually unlimited space, not gated by IANA), then I don't 
think you can get there via use of a single Vendor-Id and an 8 bit 
Vendor-Type space.

The question in my mind is whether it is better to go with multiple 
Vendor-Ids, or instead, to expand the Vendor-Type space to 16 bits.   While 
there is more work involved in supporting a 16-bit Vendor-Type space, it 
seems like a cleaner solution long term, particularly from the IANA point of 
view.  Asking IANA to track Vendor-Id allocations for individual WGs, and 
individual RADIUS attribute allocations within those Vendor-Ids, seems like 
it could quickly become complex.

--
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, 27 Sep 2007 09:56:17 +0000
Date: Thu, 27 Sep 2007 11:55:22 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC:  [email-masked]
Subject: Re: Vendor-Id for radext extended attributes

Glen Zorn wrote:
> I think that it might be a better idea instead of using the (already
> assigned to IANA, as David has pointed out) Vendor-Id of zero (0)  for
> the radext extended attributes to instead request a separate Vendor-Id
> for the radext WG & encourage other WGs that need new attributes to do
> the same.

  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, 27 Sep 2007 08:28:55 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>
Cc: "'Glen Zorn'" <[email-masked]>
Subject: Vendor-Id for radext extended attributes
Date: Thu, 27 Sep 2007 15:27:38 +0700

This is a multipart message in MIME format.

------=_NextPart_000_0002_01C8011A.F0086A80
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

I think that it might be a better idea instead of using the (already
assigned to IANA, as David has pointed out) Vendor-Id of zero (0)  for the
radext extended attributes to instead request a separate Vendor-Id for the
radext WG & encourage other WGs that need new attributes to do the same.
For example, the hokey WG is likely to need at least one new RADIUS
attribute, so it would get its own ID (& therefore its own namespace).  This
has the advantage of expanding the standard attribute space by leaps rather
than baby steps ;-) & provides a fairly automatic & orderly method of
namespace management.  Thoughts?

------=_NextPart_000_0002_01C8011A.F0086A80
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=3DContent-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:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-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;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@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>I think that it might be a better idea instead of =
using the
(already assigned to IANA, as David has pointed out) Vendor-Id of zero =
(0) &nbsp;for
the radext extended attributes to instead request a separate Vendor-Id =
for the
radext WG &amp; encourage other WGs that need new attributes to do the
same.&nbsp; For example, the hokey WG is likely to need at least one new =
RADIUS
attribute, so it would get its own ID (&amp; therefore its own =
namespace).&nbsp;
This has the advantage of expanding the standard attribute space by =
leaps
rather than baby steps ;-) &amp; provides a fairly automatic &amp; =
orderly
method of namespace management.&nbsp; Thoughts?<o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0002_01C8011A.F0086A80--

--
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, 20 Sep 2007 21:19:23 +0000
From: "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>
Subject: RADEXT WG Last Call on "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management"
Date: Thu, 20 Sep 2007 17:17:46 -0400
Organization: Elbrys Networks, Inc.

This is an announcement of RADEXT WG last call on "Remote Authentication
Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS)
Management" prior to sending the document to the IESG for consideration as a
Proposed Standard. The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorizati
on-00.txt

RADEXT WG last call will complete on Friday, October 19, 2007.  Please send
comments to the RADEXT WG mailing list ([email-masked]), using the
format described in the RADEXT Issues tracker:
http://www.drizzle.com/~aboba/RADEXT/

A call for general WG review of this draft was posted on August 24, 2007,
asking the WG whether this document was ready for WGLC.
http://ops.ietf.org/lists/radiusext/2007/msg00684.html

A reminder was posted on September 5, 2007.
http://ops.ietf.org/lists/radiusext/2007/msg00759.html

The deadline for comments was September 14, 2007.  One comment was received,
indicating the document was ready for WGLC.  No issues were raised.
http://ops.ietf.org/lists/radiusext/2007/msg00762.html

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/>

Envelope-to: [email-masked]
Delivery-date: Wed, 19 Sep 2007 14:21:23 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>
Subject: Protocol Action: 'Common Remote Authentication Dial In  User Service (RADIUS) Implementation Issues and Suggested Fixes'  to Proposed Standard 
Message-Id: <[email-masked]>
Date: Wed, 19 Sep 2007 10:20:12 -0400

The IESG has approved the following document:

- 'Common Remote Authentication Dial In User Service (RADIUS) 
   Implementation Issues and Suggested Fixes '
   <draft-ietf-radext-fixes-08.txt> as a Proposed Standard

This document is the product of the RADIUS EXTensions Working Group. 

The IESG contact persons are Dan Romascanu and Ron Bonica.

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

Technical Summary

   This document describes common issues seen in RADIUS implementations
   and suggests some fixes.  Where applicable, ambiguities and errors in
   previous RADIUS specifications are clarified.

Working Group Summary
 
   This document originally included issues and fixes relating to RFC
3576, but it was decided that handling that in a separate document (RFC
3576bis) would be more appropriate.  During the development of this
document, a number of issues required extended discussion, most recently
text relating to handling of duplicate detection within RADIUS.   

Protocol Quality
 
 This document describes issues that have been raised as a result of the
widespread deployment of RADIUS for authentication, authorization and
accounting. The document was reviewed by Dan Romascanu for the IESG and by
Joseph Saloway for the Security Directorate.

--
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, 17 Sep 2007 17:35:34 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: FW: Review of draft-ietf-radext-rfc3576bis-09.txt
Date: Mon, 17 Sep 2007 10:34:44 -0700

>From: Paul Hoffman <[email-masked]>
>To: [email-masked]
>CC: [email-masked], [email-masked], [email-masked],        
>[email-masked], [email-masked],        
>[email-masked], [email-masked], [email-masked]
>Subject: Review of draft-ietf-radext-rfc3576bis-09.txt
>Date: Mon, 17 Sep 2007 10:19:50 -0700
>
>I am reviewing this document as part of the security directorate's ongoing 
>effort to review all IETF documents being processed by the IESG.  These 
>comments were written primarily for the benefit of the security area 
>directors.  Document editors and WG chairs should treat these comments just 
>like any other last call comments. Feel free to forward to any appropriate 
>forum.
>
>This document is a revision of RFC 3576, an Informational RFC describing a 
>protocol to allow unsolicited messages sent from a RADIUS server to a 
>Network Access Server.
>
>The protocol is Informational because there were existing implementations 
>before RFC 3576 was published that would not work with the published spec. 
>This new document inherits that status, although I question the need to do 
>that four years later, particularly because some of the changes made in the 
>earlier RFC and in this revision are for better security. I do not know 
>whether or not this was discussed in the WG.
>
>This revision consists mostly of terminology changes and clarifications, 
>all of which seemed fine. The few protocol changes all seem to enhance 
>security or at least be security-neutral. The changes to the Security 
>Considerations section (Section 6) are good. One note is that Section 6.3 
>gives SHOULD-level recommendations to IKEv1 but doesn't mention IKEv2. 
>Section 6.4, on replay protection, is significantly expanded.
>
>On a stylistic note, Section 6 contains many MUSTs and SHOULDs. Doing this 
>in the Security Considerations section instead of the body of the protocol 
>makes it seem like these are "only for security", not really for the 
>protocol. It would be nice if protocols would put security-related MUSTs 
>and SHOULDs in the body of the protocol to give them equal footing in the 
>mind of developers.
>
>--Paul Hoffman, Director
>--VPN Consortium

--
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, 17 Sep 2007 09:18:36 +0000
To: [email-masked]
From: [email-masked]
Date: Thu, 13 Sep 2007 11:15:02 -0400
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-fixes-08.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		: Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes
	Author(s)	: D. Nelson, A. DeKok
	Filename	: draft-ietf-radext-fixes-08.txt
	Pages		: 28
	Date		: 2007-9-13
	
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-08.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-08.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-08.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-08.txt

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

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

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--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: Sun, 16 Sep 2007 20:01:38 +0000
Date: Sun, 16 Sep 2007 22:01:01 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC:  [email-masked]
Subject: Re: Frag & Tag questions

Glen Zorn wrote:
> */[gwz] To answer my own question, I think that it would be better to
> make fragmentation & grouping apply to entire extended attributes,
> rather than sub-attributes.  This reduces flexibility, but simplifies
> the semantics considerably, I think.  /*

  Yes.

  That was my understanding from reading the document.

  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, 16 Sep 2007 19:33:54 +0000
Date: Sun, 16 Sep 2007 12:33:28 -0700
From: "Clint Chaplin" <[email-masked]>
To: [email-masked]
Subject: Re: Frag & Tag questions

------=_Part_8201_15706124.1189971208216
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Frag and Tag: sounds like something a squad of soldiers would do.

On 9/16/07, Glen Zorn <[email-masked]> wrote:
>
>  Right now the scope of both the F & Tag fields is the sub-attribute,
> since they occur to the right of the Extended Type.  This allows 1) very
> long sub-attributes and 2) the grouping of sub-attributes within a larger
> extended attribute.  Do we want to leave it this way or enlarge the scope of
> one or both fields to encompass the entire extended attribute?
>
> *[gwz] *
>
> *[gwz] To answer my own question, I think that it would be better to make
> fragmentation & grouping apply to entire extended attributes, rather than
> sub-attributes.  This reduces flexibility, but simplifies the semantics
> considerably, I think.  *
>

-- 
Clint (JOATMON) Chaplin
Principal Engineer
Corporate Standardization (US)
SISA

------=_Part_8201_15706124.1189971208216
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Frag and Tag: sounds like something a squad of soldiers would do.<br><br><div><span class="gmail_quote">On 9/16/07, <b class="gmail_sendername">Glen Zorn</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>
&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div link="blue" vlink="purple" lang="EN-US">

<div><span class="q">

<p>Right now the scope of both the F &amp; Tag fields is the
sub-attribute, since they occur to the right of the Extended Type.&nbsp; This
allows 1) very long sub-attributes and 2) the grouping of sub-attributes within
a larger extended attribute.&nbsp; Do we want to leave it this way or enlarge
the scope of one or both fields to encompass the entire extended attribute?</p></span>

<p><b><i><span style="color: rgb(31, 73, 125);">[gwz] </span></i></b><span style="color: rgb(31, 73, 125);"></span></p>

<p><b><i><span style="color: rgb(31, 73, 125);">[gwz] To answer my own
question, I think that it would be better to make fragmentation &amp; grouping
apply to entire extended attributes, rather than sub-attributes.&nbsp; This
reduces flexibility, but simplifies the semantics considerably, I think.&nbsp; </span></i></b><span style="color: rgb(31, 73, 125);"></span></p>

</div>

</div>

</blockquote></div><br><br clear="all"><br>-- <br>Clint (JOATMON) Chaplin<br>Principal Engineer<br>Corporate Standardization (US)<br>SISA

------=_Part_8201_15706124.1189971208216--

--
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, 16 Sep 2007 19:06:54 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>
Cc: "'Glen Zorn'" <[email-masked]>
Subject: RE: Frag & Tag questions
Date: Sun, 16 Sep 2007 12:06:28 -0700

This is a multipart message in MIME format.

------=_NextPart_000_0028_01C7F85A.036DA190
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Right now the scope of both the F & Tag fields is the sub-attribute, since
they occur to the right of the Extended Type.  This allows 1) very long
sub-attributes and 2) the grouping of sub-attributes within a larger
extended attribute.  Do we want to leave it this way or enlarge the scope of
one or both fields to encompass the entire extended attribute?

[gwz] 

[gwz] To answer my own question, I think that it would be better to make
fragmentation & grouping apply to entire extended attributes, rather than
sub-attributes.  This reduces flexibility, but simplifies the semantics
considerably, I think.  

------=_NextPart_000_0028_01C7F85A.036DA190
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=3DContent-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:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-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;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
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>Right now the scope of both the F &amp; Tag fields =
is the
sub-attribute, since they occur to the right of the Extended Type.&nbsp; =
This
allows 1) very long sub-attributes and 2) the grouping of sub-attributes =
within
a larger extended attribute.&nbsp; Do we want to leave it this way or =
enlarge
the scope of one or both fields to encompass the entire extended =
attribute?<o:p></o:p></p>

<p class=3DMsoNormal><b><i><span style=3D'color:#1F497D'>[gwz] =
</span></i></b><span
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><b><i><span style=3D'color:#1F497D'>[gwz] To answer =
my own
question, I think that it would be better to make fragmentation &amp; =
grouping
apply to entire extended attributes, rather than sub-attributes.&nbsp; =
This
reduces flexibility, but simplifies the semantics considerably, I =
think.&nbsp; </span></i></b><span
style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

</body>

</html>

------=_NextPart_000_0028_01C7F85A.036DA190--

--
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, 16 Sep 2007 18:56:28 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'David B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Sun, 16 Sep 2007 10:48:38 -0700

Glen Zorn wrote:
> [ David Nelson ]
>   The *extended* attributes can be larger than 256 octets, due to the
> continuation flag.  Inside of the extended attributes, any
> sub-attributes do not have a continuation flag, and their "length" field
> is still 8 bits.  So they can be a few octets longer than an RFC 2865 VSA.
> [gwz] 
> [gwz] I'm not sure where you got that idea, but I don't think it's really
> accurate.

  VSA's can currently only contain 247 octets of data, not 253.  This is
because they must be encapsulated inside of Vendor-Specific, which holds
253 octets, MINUS the 4 byte Vendor ID, and one byte each of Type and
Length.

  The extended attribute draft allows sub-vsa's, which have no such
restriction.  I can have a sub-vsa of (say) type 1, and 253 octets of
data.  It will need 255 bytes of room in the packet, and will thus be
split across two extended attribute VSA's.  The first extended-attribute
VSA will have "F" set, and will have length 255, and extended-length of
246.  It will include the two-byte header for the sub-vsa (with sub-vsa
length 1), and 244 bytes of the sub-vsa data.

  The second extended-attribute VSA will have "F" clear, 
[gwz] 
[gwz] OK, my point is that the scope of the 'F' bit as currently defined is
_not_ the extended attribute, it is the sub-attribute.

and will
contain the rest of the sub-vsa data (9 bytes).  It will have
Vendor-Specific length of 18, and extended-length of 12.

  At least, that's the way I read it.

  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, 16 Sep 2007 18:27:41 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>
Subject: Frag & Tag questions
Date: Sun, 16 Sep 2007 11:26:49 -0700

This is a multipart message in MIME format.

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

Right now the scope of both the F & Tag fields is the sub-attribute, since
they occur to the right of the Extended Type.  This allows 1) very long
sub-attributes and 2) the grouping of sub-attributes within a larger
extended attribute.  Do we want to leave it this way or enlarge the scope of
one or both fields to encompass the entire extended attribute?

------=_NextPart_000_001D_01C7F854.79883760
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=3DContent-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:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-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;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@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>Right now the scope of both the F &amp; Tag fields =
is the
sub-attribute, since they occur to the right of the Extended Type.&nbsp; =
This
allows 1) very long sub-attributes and 2) the grouping of sub-attributes =
within
a larger extended attribute.&nbsp; Do we want to leave it this way or =
enlarge the
scope of one or both fields to encompass the entire extended =
attribute?<o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_001D_01C7F854.79883760--

--
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, 16 Sep 2007 13:38:27 +0000
Date: Sun, 16 Sep 2007 15:37:57 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: "'David B. Nelson'" <[email-masked]>,  [email-masked]
Subject: Re: Consideration of draft-lior-radius-attribute-type-extension-02.txt

Glen Zorn wrote:
> [ David Nelson ]
>   The *extended* attributes can be larger than 256 octets, due to the
> continuation flag.  Inside of the extended attributes, any
> sub-attributes do not have a continuation flag, and their "length" field
> is still 8 bits.  So they can be a few octets longer than an RFC 2865 VSA.
> [gwz] 
> [gwz] I'm not sure where you got that idea, but I don't think it's really
> accurate.

  VSA's can currently only contain 247 octets of data, not 253.  This is
because they must be encapsulated inside of Vendor-Specific, which holds
253 octets, MINUS the 4 byte Vendor ID, and one byte each of Type and
Length.

  The extended attribute draft allows sub-vsa's, which have no such
restriction.  I can have a sub-vsa of (say) type 1, and 253 octets of
data.  It will need 255 bytes of room in the packet, and will thus be
split across two extended attribute VSA's.  The first extended-attribute
VSA will have "F" set, and will have length 255, and extended-length of
246.  It will include the two-byte header for the sub-vsa (with sub-vsa
length 1), and 244 bytes of the sub-vsa data.

  The second extended-attribute VSA will have "F" clear, and will
contain the rest of the sub-vsa data (9 bytes).  It will have
Vendor-Specific length of 18, and extended-length of 12.

  At least, that's the way I read it.

  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, 16 Sep 2007 13:31:10 +0000
Date: Sun, 16 Sep 2007 15:30:02 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC:  [email-masked]
Subject: Re: Fragmentation flag in extended attributed

Glen Zorn wrote:
> It appears to me that this means that /all/ of the fragments are marked
> as such.  If so, suppose that 2 extended attributes of the same extended
> type are adjacent in a packet & both are fragmented.  How can you tell
> where the first ends & the second starts?  I can think of 2 easy ways to
> fix this: either specify that the flag is cleared in the attribute
> containing the first fragment or in the attribute containing the last
> fragment.  Note that the latter option basically turns the bit into a
> "more" flag, which has some precedent in IETF protocols ;-).  Any
> opinions/other suggestions?

  I think the last fragment should have the F bit clear.

  The document should also say that attributes with length less than 246
octets (for VSA content) MUST NOT have the F bit set.  Otherwise, the
fragments could all be 1 byte, giving a bad ratio of overhead to data.

  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, 16 Sep 2007 06:38:02 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>
Cc: "'Glen Zorn'" <[email-masked]>
Subject: Fragmentation flag in extended attributed
Date: Sat, 15 Sep 2007 23:37:13 -0700

This is a multipart message in MIME format.

------=_NextPart_000_0043_01C7F7F1.5879BA20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

It seems to me that there is a problem with the current scheme for marking
fragment.  This is what the existing draft says:

   Fragmentation (F):

   When set(1) the attribute is fragmented.  When clear (0), the

   attribute is not fragmented.  When the value portion of an extended

   attribute exceeds 246 octets the value is fragmented over one or more

   extended attribute.  In this case the Fragmentation Flag is set on

   the attribute(s) that contain the value fragments.

It appears to me that this means that all of the fragments are marked as
such.  If so, suppose that 2 extended attributes of the same extended type
are adjacent in a packet & both are fragmented.  How can you tell where the
first ends & the second starts?  I can think of 2 easy ways to fix this:
either specify that the flag is cleared in the attribute containing the
first fragment or in the attribute containing the last fragment.  Note that
the latter option basically turns the bit into a "more" flag, which has some
precedent in IETF protocols ;-).  Any opinions/other suggestions?

------=_NextPart_000_0043_01C7F7F1.5879BA20
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=3DContent-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:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-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;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;}
@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>It seems to me that there is a problem with the =
current
scheme for marking fragment.&nbsp; This is what the existing draft =
says:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
Fragmentation (F):<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
When set(1) the attribute is fragmented.&nbsp; When clear (0), =
the<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
attribute is not fragmented.&nbsp; When the value portion of an =
extended<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
attribute exceeds 246 octets the value is fragmented over one or =
more<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
extended attribute.&nbsp; In this case the Fragmentation Flag is set =
on<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
the attribute(s) that contain the value fragments.<o:p></o:p></span></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>It appears to me that this means that <i>all</i> of =
the
fragments are marked as such.&nbsp; If so, suppose that 2 extended =
attributes
of the same extended type are adjacent in a packet &amp; both are
fragmented.&nbsp; How can you tell where the first ends &amp; the second
starts?&nbsp; I can think of 2 easy ways to fix this: either specify =
that the
flag is cleared in the attribute containing the first fragment or in the
attribute containing the last fragment.&nbsp; Note that the latter =
option
basically turns the bit into a &quot;more&quot; flag, which has some =
precedent
in IETF protocols ;-).&nbsp; Any opinions/other =
suggestions?<o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0043_01C7F7F1.5879BA20--

--
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, 16 Sep 2007 05:33:11 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'David B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Sat, 15 Sep 2007 22:32:08 -0700

Glen Zorn wrote:
> [gwz] It is -- the problem with "subattributes" as described in RFC 2865
is
> that they must fit in a single VSA.  With this draft, we open up the
> possibility (with the "continuation" bit) of having really huge attributes
> containing subattributes that themselves are larger than a single VSA.  It
> seems like we either need to restrict the usage of subattributes or decide
> on one or the other.

  The *extended* attributes can be larger than 256 octets, due to the
continuation flag.  Inside of the extended attributes, any
sub-attributes do not have a continuation flag, and their "length" field
is still 8 bits.  So they can be a few octets longer than an RFC 2865 VSA.
[gwz] 
[gwz] I'm not sure where you got that idea, but I don't think it's really
accurate.  Here's a picture of the extended attributes as they stand right
now:

   +---------------------------------------------------------------+
   |                    1                   2                   3  |
   |0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
   +---------------+---------------+-------------------------------+
   |   Type (26)   |  Length       |      Vendor-Id (0)            |
   +---------------+---------------+-------------------------------+
   |          Vendor-Id(0)         | Extended-Type |  Length       |
   +---------------+---------------+---------------+---------------+
   |F|   TAG       |   Value
   +---------------+---------------

[gwz] As you can see, both the Fragment flag and the Tag are included in the
sub-attribute if we follow the convention established in RFC 2865 that
sub-attributes include everything after the Vendor-/Extended-Type field.

...

--
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, 13 Sep 2007 15:15:47 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-fixes-08.txt 
Date: Thu, 13 Sep 2007 11:15:02 -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) Implementation Issues and Suggested Fixes
	Author(s)	: D. Nelson, A. DeKok
	Filename	: draft-ietf-radext-fixes-08.txt
	Pages		: 28
	Date		: 2007-9-13
	
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-08.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-08.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-08.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-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-fixes-08.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, 13 Sep 2007 09:35:01 +0000
Date: Thu, 13 Sep 2007 11:34:07 +0200
From: Alan DeKok <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  radext mailing list <[email-masked]>
Subject: Re: More comments on draft-ietf-radext-fixes-06.txt

Romascanu, Dan (Dan) wrote:
> Note that the document has now all DISCUSSes cleared, so it is approved
> by the IESG and could be sent to the RFC Editor. You have the option of
> making these changes in a new version, or writing them in a Note to the
> RFC Editor and let the RFC Editor perform them. I am holding the
> announcement of the approval, please let me know what path you wanna
> take. 

  I have just submitted -08, which addresses all final comments and
DISCUSS issues.

  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, 12 Sep 2007 18:55:38 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: IETF last call on RFC 3576bis
Date: Wed, 12 Sep 2007 11:54:59 -0700

Has been announced:
http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg04068.html

Please read the document one last time to make sure there are no remaining 
issues.  If you do find issues, please post your review to [email-masked], 
CC:'ing the RADEXT WG mailing list.

--
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, 11 Sep 2007 16:29:08 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Guidelines suggested text for checklist:
Date: Tue, 11 Sep 2007 09:28:51 -0700

>We want to be careful that the service being provisioned isn't being 
>_defined_ in a RADIUS
>document.  Define it elsewhere, and provision it in RADIUS.

This is a good point; it may belong in the checklist:

"Does the document provide a reference to the service that is being 
provisioned?"

--
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, 11 Sep 2007 16:24:04 +0000
Date: Tue, 11 Sep 2007 18:23:24 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: Guidelines suggested text for checklist:

David B. Nelson wrote:
> I think this text is problematic.  I agree that VSAs should be used for
> attributes not requiring [any | very much] interoperability, and as
> specified in the RADIUS Extended Attributes draft.  Saying that attributes
> defined for use in an SDO, or in a group of SDOs, fall into this category
> bothers me very much.

  SDOs will do whatever they want within their attribute space.  This
text is trying to recognize that reality.

>  After all, what is the IETF but yet another SDO?  I
> presume that _all_ SDOs produce specifications that expect a significant
> level of multi-vendor interoperability.  Otherwise, why would they bother?
> I don't think we want to say that multi-vendor interoperability is a concept
> that is unique to the IETF.

  SDO inter-operability is an issue strictly for the SDOs, not for the IETF.

  Text can be added to the document to clarify it.

  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, 11 Sep 2007 16:04:27 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Guidelines suggested text for checklist:
Date: Tue, 11 Sep 2007 12:03:49 -0400
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

> I think that the issue is that there is no inherent interoperability
> benefit from rehosting VSAs that already conform to the criteria 
> expressed in the document into the RADIUS standard attribute space.

Agreed.  The section I commented upon seems to address new designs.  I
wasn't thinking about re-hosting.

> As long as a VSA conforms to the checklist, it can be added to 
> existing RADIUS servers, so that there is no reason for the IETF to 
> force the SDO to use the RADIUS standard space solely in order to 
> get the document reviewed.

Sure, but that still doesn't tell me as a reader of this guideline when to
use a VSA allocation and when to use an IANA allocation.  Do I use an IANA
allocation only when publishing my new attribute via the IETF?

--
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, 11 Sep 2007 15:57:14 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: RE: Guidelines suggested text for checklist:
Date: Tue, 11 Sep 2007 11:56:36 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok Writes...

>       * string (i.e. binary data), totalling 253 octets or less in
>         length. This includes the opaque encapsulation of data
>         structures defined outside of RADIUS.

I think it might make sense to add some text in the body of the document to
expand on the notion of "opaque encapsulation of data structures defined
outside of RADIUS".

The current text on this issue is limited to the following:

   The exception to this recommendation are attributes which can be
   treated as opaque data, such as the EAP-Message attribute, defined in
   [RFC3579] Section 3.1.

I think that EAP-Message is a good example of an "opaque encapsulation".
The format of the EAP message is completely defined elsewhere.  Even if you
consider the EAP peer as part of a RADIUS Server implementation, as a matter
of packaging, it is clearly a distinct entity from a logical perspective.

I think some of the attributes in the recent GEOPRIV document come close,
but fall short.  In those examples, the referenced format is not _exactly_
correct for encapsulation in a RADIUS attribute, so the GEOPRIV RADIUS
document defines a derivative format, based on the reference.

What should clearly be avoided is defining message formats for services
inside a RADIUS document.  RADIUS attributes are for (a) authenticating
users, (b) service provisioning and (c) accounting logging.  We want to be
careful that the service being provisioned isn't being _defined_ in a RADIUS
document.  Define it elsewhere, and provision it in RADIUS.

At one point we had come to consensus on the list about some criteria for
the use of "opaque encapsulations".  IIRC, the criteria hinged on whether
the RADIUS Server would need to take any action based on the purportedly
opaque information.  If it would, then the information didn't qualify for
treatment as an "opaque encapsulation".  If the RADIUS Server simply passed
the data to some "plug-in" module, and relied on a result from the "plug-in"
module to make a decision, then the data is opaque.  A concrete way of
judging this is whether the attribute definition in the RADIUS document
contains delineated fields for sub-parts of the data.  If fields need to be
delineated, then the data is not opaque.

--
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, 11 Sep 2007 15:48:19 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Guidelines suggested text for checklist:
Date: Tue, 11 Sep 2007 08:47:39 -0700

>I think this text is problematic.  I agree that VSAs should be used for
>attributes not requiring [any | very much] interoperability, and as
>specified in the RADIUS Extended Attributes draft.  Saying that attributes
>defined for use in an SDO, or in a group of SDOs, fall into this category
>bothers me very much.  After all, what is the IETF but yet another SDO?  I
>presume that _all_ SDOs produce specifications that expect a significant
>level of multi-vendor interoperability.  Otherwise, why would they bother?
>I don't think we want to say that multi-vendor interoperability is a 
>concept
>that is unique to the IETF.

I think that the issue is that there is no inherent interoperability benefit 
from rehosting VSAs that already conform to the criteria expressed in the 
document into the RADIUS standard attribute space.
Creating two ways to express the same attribute does not help 
interoperability -- it hurts it.  As long as a VSA conforms to the 
checklist, it can be added to existing RADIUS servers, so that there is no 
reason for the IETF to force the SDO to use the RADIUS standard space solely 
in order to get the document reviewed.

In a similar vein, we do not require IEEE 802 MIBs to be rehosted in the 
IETF standards space before we will review them or recognize them as 
standards.

--
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, 11 Sep 2007 15:06:57 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Guidelines suggested text for checklist:
Date: Tue, 11 Sep 2007 08:06:48 -0700

>Appendix A - Design Guidelines
>
>    The following text provides guidelines for the design of attributes
>    used by the RADIUS protocol.
>
>A.1. Transport of simple data
>
>    The following kinds of data fit within the existing RADIUS data
>    model, and can be encapsulated in a [RFC2865] format RADIUS
>    attribute, or in a [RFC2865] format RADIUS VSA:
>
>       * 32-bit unsigned integer, most significant octet first.
>       * Enumerated data types, represented as a 32-bit unsigned integer
>         with a list of name to value mappings.  (e.g. Service-Type)
>       * 64-bit unsigned integer, most significant octet first.
>       * IPv4 address in network byte order.
>       * IPv6 address in network byte order.
>       * IPv6 prefix.
>       * time as 32 bit unsigned value, most significant octet first, in
>         seconds since 00:00:00 UTC, January 1, 1970.
>       * string (i.e. binary data), totalling 253 octets or less in
>         length. This includes the opaque encapsulation of data
>         structures defined outside of RADIUS.
>       * UTF-8 text, totalling 253 octets or less in length.

For a checklist, I was think of a list of questions, with references to the 
document itself.  So I'd prefer that this list not be repeated twice.  
Instead you could say "Does the attribute match a type described in Section 
X?"

>    For [RFC2865] RADIUS VSAs, the length limitation of the "string" and
>    "text" types is 247 octets instead of 253 octets, due to the
>    additional information included in the Vendor-Specific attribute.

This sentence should probably be in the main text.

>A.2. Transport of new authentication protocols
>
>    New authentication or security functionality in RADIUS requires
>    require code changes on both the RADIUS client and server, regardless
>    of the attribute format.  As a result, in most cases the use of
>    complex attributes to represent these methods is acceptable.

This statement should be moved to the main text.  Here you could put the 
question "Does the attribute define a complex data type for purposes other 
than authentication or security?  See Section Y for a description of why 
this is problematic."

>A.3. Improper data types
>
>    The following kinds of data do not fit within the RADIUS data model,
>    and should be replaced with the suggested alternatives, or should not
>    be used at all.

I'd consolidate this with the previous data type section, and rephrase as a 
question:
"Does the attribute use any of the following data types?"

Example:

* Signed integers of any size?  These SHOULD NOT be used.

>
>       * Signed integers of any size.
>         SHOULD NOT be used.
>       * 8 bit unsigned integers.
>         SHOULD be replaced with 32-bit unsigned integer.  There is
>         insufficient justification to save three bytes.
>       * 16 bit unsigned integers.
>         SHOULD be replaced with 32-bit unsigned integer.  There is
>         insufficient justification to save two bytes.
>       * Tagged data types as in [RFC2868].
>         These data types SHOULD NOT be used in new specifications.  The
>         attribute grouping method defined in [EXTEN] SHOULD be used
>         instead.
>       * Complex data structures defined only within RADIUS.
>         The additional functionality defined in [EXTEN] SHOULD be used
>         instead.  This recommendation does not apply to new
>         authentication or security functionality, as described above in
>         Section A.2.
>       * Multi-field text strings.
>         Each field SHOULD be encapsulated in a separate attribute.
>         Where grouping of fields is desired, the additional
>         functionality defined in [EXTEN] SHOULD be used instead.
>       * Polymorphic attributes.
>         Multiple attributes, each with a fixed data type SHOULD be
>         defined instead.
>
>A.4. Vendor-Specific formats
>
>    Vendor-Specific attributes SHOULD follow the [RFC2865] suggested
>    format, or the [EXTEN] format if more functionality or a larger
>    attribute space is necessary.  Vendor-Specific attributes matching
>    any of the following formats SHOULD NOT be used.

Large SDOs with multiple groups would probably do better with a 16-bit 
attribute space.  Given this, is the suggested format still a SHOULD, or do 
we say "suggested format, using an 8 or 16-bit attribute space."

>
>       * Vendor types of more than 16 bits.
>       * Vendor lengths of less than 8 bits.  (i.e. zero bits)
>       * Vendor lengths of more than 8 bits.
>       * Vendor-Specific contents that are not in Type-Length-Value
>         format.
>
>A.5. New functionality in RADIUS.
>
>    Some implementations have extended RADIUS by a number of methods.
>    The following practices are NOT RECOMMENDED:
>
>       * Defining new commands in RADIUS.
>         This restriction includes new commands created by overloading
>         the Service-Type attribute to define new values that modify
>         the functionality of Access-Request packets.

Since the document is about attributes, I think this should say "Defining 
new RADIUS commands using attributes."  We're not talking about restricting 
new standards-track documents defining new commands (e.g. RFC 3576).

>       * Using RADIUS as a transport protocol.
>         This restriction is partially a subset of the previous one.
>         Note that using RADIUS to transport authentication methods
>         (e.g. EAP) is explicitly permitted, even if those methods
>         require the transport of relatively large amounts of data.

Since the focus is on attributes, I'm not sure what this refers to.  Would 
this apply to the GEOPRIV document, for example?

>       * Extending the RADIUS packet length limitation past 4096 octets.
>         A multi-packet sequence of Access-Request / Access-Challenge
>         SHOULD be used instead.  If that is not possible, then a method
>         other than RADIUS SHOULD be used to transport the data.
>
>A.6. Allocation of attributes
>
>    RADIUS attribute specifications SHOULD allocate attributes from the
>    vendor space, rather than requesting an allocation from the RADIUS
>    standard attribute space, for attributes matching any of the
>    following criteria:
>
>       * attributes relying on data types not defined within RADIUS
>       * attributes intended primarily for use within an SDO
>       * attributes intended primarily for use within a group of SDOs.

This duplicates existing text, so I'd rephrase as a question:  "Does the 
attribute match any of the following critiera?  If so, then...."

>    Even if attributes are allocated from the vendor space, it is often
>    useful for SDOs to publish the specification as an informational RFC,
>    as with [RFC4679].
>
>    Note that the first bullet point above relaxes many of the previous
>    guidelines on data types, but only within a narrowly defined scope.
>    Extensions to RADIUS that may not be appropriate for widespread use
>    may be acceptable within a limited context.

--
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, 11 Sep 2007 15:06:53 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: RE: Guidelines suggested text for checklist:
Date: Tue, 11 Sep 2007 11:06:12 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

> A.6. Allocation of attributes
> 
>    RADIUS attribute specifications SHOULD allocate attributes from the
>    vendor space, rather than requesting an allocation from the RADIUS
>    standard attribute space, for attributes matching any of the
>    following criteria:
> 
>       * attributes relying on data types not defined within RADIUS
>       * attributes intended primarily for use within an SDO
>       * attributes intended primarily for use within a group of SDOs.
> 
>    Even if attributes are allocated from the vendor space, it is often
>    useful for SDOs to publish the specification as an informational RFC,
>    as with [RFC4679].
> 
>    Note that the first bullet point above relaxes many of the previous
>    guidelines on data types, but only within a narrowly defined scope.
>    Extensions to RADIUS that may not be appropriate for widespread use
>    may be acceptable within a limited context.

I think this text is problematic.  I agree that VSAs should be used for
attributes not requiring [any | very much] interoperability, and as
specified in the RADIUS Extended Attributes draft.  Saying that attributes
defined for use in an SDO, or in a group of SDOs, fall into this category
bothers me very much.  After all, what is the IETF but yet another SDO?  I
presume that _all_ SDOs produce specifications that expect a significant
level of multi-vendor interoperability.  Otherwise, why would they bother?
I don't think we want to say that multi-vendor interoperability is a concept
that is unique to the IETF.

What is it we are trying to say here?

--
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, 11 Sep 2007 14:44:17 +0000
Date: Tue, 11 Sep 2007 16:43:01 +0200
From: Alan DeKok <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: Guidelines suggested text for checklist:

  The following text is a first draft of a checklist-style outline for
guidelines.  It re-iterates some of the text in the rest of the
document, but in a shorter format.

---
Appendix A - Design Guidelines

   The following text provides guidelines for the design of attributes
   used by the RADIUS protocol.

A.1. Transport of simple data

   The following kinds of data fit within the existing RADIUS data
   model, and can be encapsulated in a [RFC2865] format RADIUS
   attribute, or in a [RFC2865] format RADIUS VSA:

      * 32-bit unsigned integer, most significant octet first.
      * Enumerated data types, represented as a 32-bit unsigned integer
        with a list of name to value mappings.  (e.g. Service-Type)
      * 64-bit unsigned integer, most significant octet first.
      * IPv4 address in network byte order.
      * IPv6 address in network byte order.
      * IPv6 prefix.
      * time as 32 bit unsigned value, most significant octet first, in
        seconds since 00:00:00 UTC, January 1, 1970.
      * string (i.e. binary data), totalling 253 octets or less in
        length. This includes the opaque encapsulation of data
        structures defined outside of RADIUS.
      * UTF-8 text, totalling 253 octets or less in length.

   For [RFC2865] RADIUS VSAs, the length limitation of the "string" and
   "text" types is 247 octets instead of 253 octets, due to the
   additional information included in the Vendor-Specific attribute.

A.2. Transport of new authentication protocols

   New authentication or security functionality in RADIUS requires
   require code changes on both the RADIUS client and server, regardless
   of the attribute format.  As a result, in most cases the use of
   complex attributes to represent these methods is acceptable.

A.3. Improper data types

   The following kinds of data do not fit within the RADIUS data model,
   and should be replaced with the suggested alternatives, or should not
   be used at all.

      * Signed integers of any size.
        SHOULD NOT be used.
      * 8 bit unsigned integers.
        SHOULD be replaced with 32-bit unsigned integer.  There is
        insufficient justification to save three bytes.
      * 16 bit unsigned integers.
        SHOULD be replaced with 32-bit unsigned integer.  There is
        insufficient justification to save two bytes.
      * Tagged data types as in [RFC2868].
        These data types SHOULD NOT be used in new specifications.  The
        attribute grouping method defined in [EXTEN] SHOULD be used
        instead.
      * Complex data structures defined only within RADIUS.
        The additional functionality defined in [EXTEN] SHOULD be used
        instead.  This recommendation does not apply to new
        authentication or security functionality, as described above in
        Section A.2.
      * Multi-field text strings.
        Each field SHOULD be encapsulated in a separate attribute.
        Where grouping of fields is desired, the additional
        functionality defined in [EXTEN] SHOULD be used instead.
      * Polymorphic attributes.
        Multiple attributes, each with a fixed data type SHOULD be
        defined instead.

A.4. Vendor-Specific formats

   Vendor-Specific attributes SHOULD follow the [RFC2865] suggested
   format, or the [EXTEN] format if more functionality or a larger
   attribute space is necessary.  Vendor-Specific attributes matching
   any of the following formats SHOULD NOT be used.

      * Vendor types of more than 16 bits.
      * Vendor lengths of less than 8 bits.  (i.e. zero bits)
      * Vendor lengths of more than 8 bits.
      * Vendor-Specific contents that are not in Type-Length-Value
        format.

A.5. New functionality in RADIUS.

   Some implementations have extended RADIUS by a number of methods.
   The following practices are NOT RECOMMENDED:

      * Defining new commands in RADIUS.
        This restriction includes new commands created by overloading
        the Service-Type attribute to define new values that modify
        the functionality of Access-Request packets.
      * Using RADIUS as a transport protocol.
        This restriction is partially a subset of the previous one.
        Note that using RADIUS to transport authentication methods
        (e.g. EAP) is explicitly permitted, even if those methods
        require the transport of relatively large amounts of data.
      * Extending the RADIUS packet length limitation past 4096 octets.
        A multi-packet sequence of Access-Request / Access-Challenge
        SHOULD be used instead.  If that is not possible, then a method
        other than RADIUS SHOULD be used to transport the data.

A.6. Allocation of attributes

   RADIUS attribute specifications SHOULD allocate attributes from the
   vendor space, rather than requesting an allocation from the RADIUS
   standard attribute space, for attributes matching any of the
   following criteria:

      * attributes relying on data types not defined within RADIUS
      * attributes intended primarily for use within an SDO
      * attributes intended primarily for use within a group of SDOs.

   Even if attributes are allocated from the vendor space, it is often
   useful for SDOs to publish the specification as an informational RFC,
   as with [RFC4679].

   Note that the first bullet point above relaxes many of the previous
   guidelines on data types, but only within a narrowly defined scope.
   Extensions to RADIUS that may not be appropriate for widespread use
   may be acceptable within a limited context.

--
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, 11 Sep 2007 10:26:20 +0000
Date: Tue, 11 Sep 2007 12:25:49 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: I-D ACTION:draft-ietf-radext-design-00.txt

David B. Nelson wrote:
>>   The advice in this document applies to attributes used to encode
>>   data.  RADIUS protocol changes, or specification of attributes that
>>   can be used to provide new RADIUS commands (such as Service-Type) are
>>   out of scope.
> 
> I think some further explanation of how values of the Service-Type
> attribute, in particular, could be used to effectively create commands may
> be in order.  More specifically, could we provide some guidance as to when
> one has crossed the line into defining a "command" within an "attribute"?

  Suggested text?

  Most new "commands" would be strongly discouraged, I think.

>> 2.1.3.  Complex Attribute Usage
> 
> This section explains why packing complex attributes into conventional
> attributes (e.g. into sub-fields of a string data type) is disadvantageous.
> It gives no advice to those who really want to do this, however.

  "Don't".  Unless, of course, you're packing an existing data structure
as-is.  i.e. using RADIUS as a transport.

>  What is
> the "party line" here?  I know we have features in the Extended RADIUS
> Attributes draft to address this.  Do we want to reference that document
> here? 

  Yes.

>  Do we have recommendations for those that want complex attributes
> and don't want to use Extended Attributes?

  They should stop trying to create hacks.

>  Or is using the Extended
> Attribute format the only recommended option?

  If the extended attribute format is insufficient, the strong
recommendation is that you're doing something wrong.

  i.e. trying to pack existing complex data structures into RADIUS
attributes.  Trying to use RADIUS as an application-aware transport, etc.

  I'll send another message with a proposed checklist of what to do, and
what not to do.

  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, 11 Sep 2007 10:22:11 +0000
Date: Tue, 11 Sep 2007 12:20:48 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Review of draft-ietf-radext-design-00.txt

Bernard Aboba wrote:
> There are some extra spaces in the boilerplate above.  Also, the
> document is a BCP, not Standards Track.

  Thanks.

> The material on type 26 attribute translation has been removed, no?

  Yes.

> Section 2.1.1
...
> Note the alignment problem in the above entries.

  Extraneous tab.  Fixed.

> Section 2.1.2
> 
> Given the limitations of the existing tagging schemes, is there a
> recommendation to be made (e.g. don't use the existing tagging schemes
> for new attributes?)

  Suggested text:

   New attributes SHOULD NOT use this tagging method due to the above
   limitations.  New attributes SHOULD use the grouping method described
   in [EXTEN].

  i.e. the extended attributes document.

> Section 2.2
...
> You need to add a space between this paragraph and the previous figure.

  Fixed.

> Section 3
...
> I think you're referring to the extension draft, no?  If so, you might
> as well reference it non-normatively, such as by saying  "Extensions to
> the RADIUS data model such as [EXTEN] make it possible to minimize the
> use of complex attributes."

  Yes.  I'll add that text.

> Section 3.1
...
> I think there is a formatting issue here.

  Fixed.

> 4.  IANA Considerations
...
> Given that type 26 translation is not included any more, I think you can
> instead say:
> 
> "   This draft requires no action by IANA."

  Added, thanks.

> Appendices
> 
> I think that this document needs a "checklist" that a reviewer can go
> through to look for issues.  You might consider including this as
> Appendix A and moving the existing Appendix A to Appendix B.

  Yes.  I'll address the checklist in a separate message.

  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/>

Envelope-to: [email-masked]
Delivery-date: Mon, 10 Sep 2007 22:00:42 +0000
To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-radext-rfc3576bis (Dynamic Authorization  Extensions to Remote Authentication Dial In User Service  (RADIUS)) to Informational RFC 
Reply-To: [email-masked]
Cc: <[email-masked]>
Message-Id: <[email-masked]>
Date: Mon, 10 Sep 2007 17:59:45 -0400

The IESG has received a request from the RADIUS EXTensions WG (radext) 
to consider the following document:

- 'Dynamic Authorization Extensions to Remote Authentication Dial In 
User Service (RADIUS) '
   <draft-ietf-radext-rfc3576bis-09.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-09-24. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-09.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15614&rfc_flag=0

--
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, 10 Sep 2007 15:45:50 +0000
Date: Mon, 10 Sep 2007 11:44:48 -0400
From: "Greg Weber" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Subject: Re: Request for review: Design Guidelines Document
Cc: [email-masked]

Went through the current version of the doc.  Looks pretty clean to me.
No substantive comments to add to those from Bernard, Dave & Glen.

I did like Bernard's suggestion of adding a 'checklist' appendix.  Of
course, the danger being that people would *only* read the checklist -
so, I think it would need to be fairly thorough.  I also like the new
organization of the text.

Greg

On 9/6/07, Bernard Aboba <[email-masked]> wrote:
> An updated version of the Design Guidelines document has been posted to the
> IETF archive:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-design-00.txt
>
> Pease formally review the document to determine if it is ready or WGLC.
> Comments should be sent to this list using the format described in the
> RADEXT Issues tracker: http://www.drizzle.com/~aboba/RADEXT/
>
> This review period will last until October 5, 2007.  At that time issues
> raised on the list will be resolved.  Once all issues are addressed we will
> start WGLC on the document.
>
>
>
>
> --
> 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: Mon, 10 Sep 2007 13:07:09 +0000
Date: Mon, 10 Sep 2007 15:06:29 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Comment on draft-ietf-radext-fixes-06.txt

David B. Nelson wrote:
>> 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 
>> case, it should be delegated a prefix by the NAS via the Delegated- 
>> IPv6-Prefix attribute.  [RFC4818].  If the CPE is not decrementing 
>> TTL, it does not 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.

  Yes.  Fixed.

  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, 10 Sep 2007 12:51:52 +0000
Date: Mon, 10 Sep 2007 14:51:25 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: "'Romascanu, Dan \(Dan\)'" <[email-masked]>,  'Alan DeKok' <[email-masked]>, 'radext mailing list' <[email-masked]>
Subject: Re: More comments on draft-ietf-radext-fixes-06.txt

David B. Nelson wrote:
> Speaking as a co-author, I think we should take one final pass through the
> COMMENTS from the IESG in the ID-Tracker tool, as well as the recent
> discussion on the list, and issue a -08 that address all of those comments.

  Yes.

> As you say, the DISCUSSes have been cleared, and I think we had addressed
> the non-blocking COMMENTS, but we should double check.

  Yes.

  We may be able to get a -08 out by Wednesday.  If not, I'm away the
rest of the week.

  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, 10 Sep 2007 12:49:51 +0000
Content-class: urn:content-classes:message
Subject: RE: More comments on draft-ietf-radext-fixes-06.txt
Date: Mon, 10 Sep 2007 14:48:54 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>, "Alan DeKok" <[email-masked]>
Cc: "radext mailing list" <[email-masked]>

Fine with me, I will be waiting for the 08 version.=20

Thanks and Regards,

Dan

=20
=20

> -----Original Message-----
> From: David B. Nelson [mailto:[email-masked]]=20
> Sent: Monday, September 10, 2007 3:47 PM
> To: Romascanu, Dan (Dan); 'Alan DeKok'
> Cc: 'radext mailing list'
> Subject: RE: More comments on draft-ietf-radext-fixes-06.txt
>=20
> Dan Romascanu writes...
>=20
> > Note that the document has now all DISCUSSes cleared, so it is=20
> > approved by the IESG and could be sent to the RFC Editor.=20
> You have the=20
> > option of making these changes in a new version, or writing=20
> them in a=20
> > Note to the RFC Editor and let the RFC Editor perform them. I am=20
> > holding the announcement of the approval, please let me=20
> know what path=20
> > you wanna take.
>=20
> Speaking as a co-author, I think we should take one final=20
> pass through the COMMENTS from the IESG in the ID-Tracker=20
> tool, as well as the recent discussion on the list, and issue=20
> a -08 that address all of those comments.
>=20
> As you say, the DISCUSSes have been cleared, and I think we=20
> had addressed the non-blocking COMMENTS, but we should double check.
>=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, 10 Sep 2007 12:46:39 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Romascanu, Dan \(Dan\)'" <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Cc: "'radext mailing list'" <[email-masked]>
Subject: RE: More comments on draft-ietf-radext-fixes-06.txt
Date: Mon, 10 Sep 2007 08:46:47 -0400

Dan Romascanu writes...

> Note that the document has now all DISCUSSes cleared, so it is approved
> by the IESG and could be sent to the RFC Editor. You have the option of
> making these changes in a new version, or writing them in a Note to the
> RFC Editor and let the RFC Editor perform them. I am holding the
> announcement of the approval, please let me know what path you wanna
> take.

Speaking as a co-author, I think we should take one final pass through the
COMMENTS from the IESG in the ID-Tracker tool, as well as the recent
discussion on the list, and issue a -08 that address all of those comments.

As you say, the DISCUSSes have been cleared, and I think we had addressed
the non-blocking COMMENTS, but we should double check.

--
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, 10 Sep 2007 12:04:48 +0000
Content-class: urn:content-classes:message
Subject: RE: More comments on draft-ietf-radext-fixes-06.txt
Date: Mon, 10 Sep 2007 14:04:01 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "David B. Nelson" <[email-masked]>
Cc: "radext mailing list" <[email-masked]>

Note that the document has now all DISCUSSes cleared, so it is approved
by the IESG and could be sent to the RFC Editor. You have the option of
making these changes in a new version, or writing them in a Note to the
RFC Editor and let the RFC Editor perform them. I am holding the
announcement of the approval, please let me know what path you wanna
take.=20

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Thursday, September 06, 2007 8:28 AM
> To: David B. Nelson
> Cc: 'radext mailing list'
> Subject: Re: More comments on draft-ietf-radext-fixes-06.txt
>=20
> David B. Nelson wrote:
> > So, does that mean we can expect a -08 revision?
>=20
>   Yes.
>=20
>   If there are no more comments...
>=20
>   Alan DeKok.
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Sun, 09 Sep 2007 02:38:15 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Sat, 8 Sep 2007 19:37:05 -0700

>[gwz] You must be a better fortuneteller than I, because I usually find it
>difficult to predict the future uses of a new thing (e.g., whether it would
>be useful someday to add a certain attribute to a group).  I would prefer 
>to
>say that if you _know_ for a fact that the new attribute a) is standalone &
>will never be included in a group and b) it is not possible for it ever to
>take a value that would be longer than 253 octets (i.e., an integer), then
>use the existing standard attribute space, otherwise use the extended 
>space.

Wouldn't the ability to be placed within a group need to be deifned at the 
time that the attribute is defined?  
[gwz] 
[gwz] Why?

If the attribute isn't defined to use 
grouping, why would it be allocated within the extended space?

>[gwz] Apparently you guys know what you're talking about but I sure don't:
>AFAIK, Prrivate Enterprise Numbers have nothing to do with standard RADIUS
>attributes.  Are you suggesting that there should be _two_ new attribute
>formats, one w/a Tag, etc. & the other without?  Why?

If an attribute is one which doesn't satisfy the above criteria (e.g. a 
uint32 or uint64), and therefore doesn't need to be grouped, why should the 
attribute be forced to take on the additional overhead?
[gwz] 
[gwz] What overhead?  We're talking about 8 bits here...

--
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, 09 Sep 2007 02:23:02 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Nomcom 2007 - 2008: Nominations Close on September 10, 2007
Date: Sat, 08 Sep 2007 19:22:50 -0700

See:

http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg04056.html

--
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, 09 Sep 2007 02:14:55 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Sat, 08 Sep 2007 19:13:53 -0700

>[gwz] You must be a better fortuneteller than I, because I usually find it
>difficult to predict the future uses of a new thing (e.g., whether it would
>be useful someday to add a certain attribute to a group).  I would prefer 
>to
>say that if you _know_ for a fact that the new attribute a) is standalone &
>will never be included in a group and b) it is not possible for it ever to
>take a value that would be longer than 253 octets (i.e., an integer), then
>use the existing standard attribute space, otherwise use the extended 
>space.

Wouldn't the ability to be placed within a group need to be deifned at the 
time that the attribute is defined?  If the attribute isn't defined to use 
grouping, why would it be allocated within the extended space?

>[gwz] Apparently you guys know what you're talking about but I sure don't:
>AFAIK, Prrivate Enterprise Numbers have nothing to do with standard RADIUS
>attributes.  Are you suggesting that there should be _two_ new attribute
>formats, one w/a Tag, etc. & the other without?  Why?

If an attribute is one which doesn't satisfy the above criteria (e.g. a 
uint32 or uint64), and therefore doesn't need to be grouped, why should the 
attribute be forced to take on the additional overhead?

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

Delivery-date: Sat, 08 Sep 2007 01:12:38 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Fri, 7 Sep 2007 18:11:01 -0700

Bernard Aboba wrote:
> One question I have is whether the Extended Attributes are only to be
> allocated once the existing Standards space has been exhausted, or
> whether allocation in the extended space can be requested before that. 
> It seems that some specifications could benefit from the extended
> functionality, prior to exhaustion of the standard space.

  I agree.  Anything *needing* the new functionality should use it.
Everything else should use the existing attribute space.
[gwz] 
[gwz] You must be a better fortuneteller than I, because I usually find it
difficult to predict the future uses of a new thing (e.g., whether it would
be useful someday to add a certain attribute to a group).  I would prefer to
say that if you _know_ for a fact that the new attribute a) is standalone &
will never be included in a group and b) it is not possible for it ever to
take a value that would be longer than 253 octets (i.e., an integer), then
use the existing standard attribute space, otherwise use the extended space.

> It seems to me like there might be reason to request allocation of a PEN
> for the Extended Attribute space, as well as another PEN for additional
> standard attributes.

  Yes, and yes.
[gwz] 
[gwz] Apparently you guys know what you're talking about but I sure don't:
AFAIK, Prrivate Enterprise Numbers have nothing to do with standard RADIUS
attributes.  Are you suggesting that there should be _two_ new attribute
formats, one w/a Tag, etc. & the other without?  Why?

--
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, 07 Sep 2007 21:29:42 +0000
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Fri, 7 Sep 2007 17:28:54 -0400
From: "Avi Lior" <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>

> The Extended Attribute scheme provides an essentially=20
> unlimited type range.

The extended-type is 8 bits.  Hardly "essentially unlimited"

Unlimited in the sense that we can use new Vendor-Ids.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David B. Nelson
Sent: Thursday, September 06, 2007 4:51 PM
To: [email-masked]
Subject: RE: Consideration of
draft-lior-radius-attribute-type-extension-02.txt

Glen Zorn writes...

> [gwz] Everything it says is specific to the existing standard=20
> attributes.  For example: "Attribute Types have a range from 1 to 255,

> and are the scarcest resource in RADIUS, thus must be allocated with=20
> care."  The Extended Attribute scheme provides an essentially=20
> unlimited type range.  Similarly, I can't think of any good reason why

> Extended Attributes need to be allocated by "IETF Consensus"
> instead of "Specification Required".

On first consideration, that seems reasonable.

That being the case, this draft needs to include an IANA Considerations
section that specifies the code-point allocation policy for Extended
RADIUS Attributes that we expect IANA to use going forward.

--

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, 07 Sep 2007 08:49:44 +0000
Date: Fri, 07 Sep 2007 10:48:45 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Consideration of draft-lior-radius-attribute-type-extension-02.txt

Bernard Aboba wrote:
> One question I have is whether the Extended Attributes are only to be
> allocated once the existing Standards space has been exhausted, or
> whether allocation in the extended space can be requested before that. 
> It seems that some specifications could benefit from the extended
> functionality, prior to exhaustion of the standard space.

  I agree.  Anything *needing* the new functionality should use it.
Everything else should use the existing attribute space.

> It seems to me like there might be reason to request allocation of a PEN
> for the Extended Attribute space, as well as another PEN for additional
> standard attributes.

  Yes, and 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: Fri, 07 Sep 2007 04:28:11 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Thu, 06 Sep 2007 21:28:01 -0700

>That being the case, this draft needs to include an IANA Considerations
>section that specifies the code-point allocation policy for Extended RADIUS
>Attributes that we expect IANA to use going forward.

One question I have is whether the Extended Attributes are only to be 
allocated once the existing Standards space has been exhausted, or whether 
allocation in the extended space can be requested before that.  It seems 
that some specifications could benefit from the extended functionality, 
prior to exhaustion of the standard space.

Also, what if a RADIUS specification does not make use of the extended 
features?  For example, an attribute might not want to use tagging.  Could 
it request allocation of a standard attribute instead?  What if the standard 
space was exhausted?

It seems to me like there might be reason to request allocation of a PEN for 
the Extended Attribute space, as well as another PEN for additional standard 
attributes.

--
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, 07 Sep 2007 04:25:23 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Review of draft-ietf-radext-design-00.txt
Date: Thu, 06 Sep 2007 21:24:34 -0700

Network Working Group                                           G. Weber
INTERNET-DRAFT                                             Cisco Systems
Category: Standards Track                               Alan DeKok (ed.)
                                                              FreeRADIUS
Expires: March 4, 2008

                                                        4 September 2007

There are some extra spaces in the boilerplate above.  Also, the document is 
a BCP, not Standards Track.

Section 1

   In addition,
   recommendations are made with respect to recommended VSA formats as
   well as handling of RADIUS type 26 attributes within Diameter.

The material on type 26 attribute translation has been removed, no?

Section 2.1.1

   In addition to these data types, follow-on RADIUS specifications
   define attributes using the following additional types:

   IPv6 address   128 bit value, most significant octet first.
   IPv6 prefix    8 bits of reserved, 8 bits of prefix length, up to
               128 bits of value, most significant octet first.
   integer64      64 bit unsigned value, most significant octet first.

Note the alignment problem in the above entries.

Section 2.1.2

Given the limitations of the existing tagging schemes, is there a 
recommendation to be made (e.g. don't use the existing tagging schemes for 
new attributes?)

Section 2.2

   Other attribute formats are NOT RECOMMENDED.  Examples of NOT
   RECOMMENDED formats include Vendor types of more than 16 bits, Vendor
   lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
   Vendor-Specific contents that are not in Type-Length-Value format.

You need to add a space between this paragraph and the previous figure.

Section 3

   For future work, any extensions to the RADIUS data model should be
   used to minimize the use of complex attributes.

I think you're referring to the extension draft, no?  If so, you might as 
well reference it non-normatively, such as by saying  "Extensions to the 
RADIUS data model such as [EXTEN] make it possible to minimize the use of 
complex attributes."

Section 3.1

   In particular, it is RECOMMENDED that RADIUS Attribute specifications
   allocate attributes from the vendor space, rather than requesting an
   allocation from the RADIUS standard attribute space, for attributes
   matching any of the following criteria:
      * attributes relying on data types not defined within RADIUS *
      attributes intended primarily for use within an SDO * attributes
      intended primarily for use within a group of SDOs.

I think there is a formatting issue here.

4.  IANA Considerations

   This document defines the use of a RADIUS type 26 attribute code in
   the Diameter Protocol space as defined in [RFC3588] and [RFC4005].

Given that type 26 translation is not included any more, I think you can 
instead say:

"   This draft requires no action by IANA."

Appendices

I think that this document needs a "checklist" that a reviewer can go 
through to look for issues.  You might consider including this as Appendix A 
and moving the existing Appendix A to Appendix B.

--
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, 06 Sep 2007 20:51:22 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Thu, 6 Sep 2007 16:50:56 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...

> [gwz] Everything it says is specific to the existing standard 
> attributes.  For example: "Attribute Types have a range from 1 to 
> 255, and are the scarcest resource in RADIUS, thus must be allocated
> with care."  The Extended Attribute scheme provides an essentially 
> unlimited type range.  Similarly, I can't think of any good reason
> why Extended Attributes need to be allocated by "IETF Consensus" 
> instead of "Specification Required".

On first consideration, that seems reasonable.

That being the case, this draft needs to include an IANA Considerations
section that specifies the code-point allocation policy for Extended RADIUS
Attributes that we expect IANA to use going forward.

--
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, 06 Sep 2007 20:37:43 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Thu, 6 Sep 2007 13:36:42 -0700

[gwz] ...

> Does this mean to reference RFC 3575?
> [gwz]
> [gwz] Possibly; if so, I don't think it's really appropriate here since
> virtually nothing 3575 has to say about attributes seems to apply here.

I believe that if RFC 3575 does not sufficiently cover the allocation
procedures for the Extended RADIUS Attribute registry (which may be a
sub-section of the existing RADIUS Registry), then this draft needs to
contain RFC 3575 like instructions to IANA for a code-point allocation
policy.

Could you please elaborate on why what RFC 3575 has to say about the ongoing
allocation policy does not apply here?
[gwz] Everything it says is specific to the existing standard attributes.
For example: "Attribute Types have a range from 1 to 255, and are the
scarcest resource in RADIUS, thus must be allocated with care."  The
Extended Attribute scheme provides an essentially unlimited type range.
Similarly, I can't think of any good reason why Extended Attributes need to
be allocated by "IETF Consensus" instead of "Specification 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/>

--
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, 06 Sep 2007 20:29:20 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-radext-design-00.txt 
Date: Thu, 6 Sep 2007 13:28:19 -0700

[gwz] ...
> 2.1.3.  Complex Attribute Usage

This section explains why packing complex attributes into conventional
attributes (e.g. into sub-fields of a string data type) is disadvantageous.
It gives no advice to those who really want to do this, however.  What is
the "party line" here?  I know we have features in the Extended RADIUS
Attributes draft to address this.  Do we want to reference that document
here? 
[gwz] I think so.
[gwz] 
Do we have recommendations for those that want complex attributes
and don't want to use Extended Attributes?  Or is using the Extended
Attribute format the only recommended option?
[gwz] 
[gwz] I would suggest that the extended attribute format be the recommended
option, but nevertheless to provide guidance to those who don't want to use
it (if we have any thing useful to say on the subject).

--
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, 06 Sep 2007 20:24:03 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Thu, 6 Sep 2007 16:23:34 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...

> [gwz] Actually, I think that a better idea than using 0 would be for
> the radext WG to request a PEN of its own.

OK.  That's why I kept asking if using 0 was really the value to use.  OTOH,
maybe the distinction between "Reserved for IANA" and "Reserved for IETF" is
to fine to make a significant difference.

> Does this mean to reference RFC 3575?
> [gwz]
> [gwz] Possibly; if so, I don't think it's really appropriate here since
> virtually nothing 3575 has to say about attributes seems to apply here.

I believe that if RFC 3575 does not sufficiently cover the allocation
procedures for the Extended RADIUS Attribute registry (which may be a
sub-section of the existing RADIUS Registry), then this draft needs to
contain RFC 3575 like instructions to IANA for a code-point allocation
policy.

Could you please elaborate on why what RFC 3575 has to say about the ongoing
allocation policy does not apply here?

--
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, 06 Sep 2007 20:09:30 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-radext-design-00.txt 
Date: Thu, 6 Sep 2007 16:09:03 -0400
Organization: Elbrys Networks, Inc.

I think this version is a step forward.  Thanks!  A couple of nits:

> Network Working Group                                     G. Weber
> INTERNET-DRAFT                                       Cisco Systems
> Category: Standards Track                         Alan DeKok (ed.)
>                                                         FreeRADIUS

Please note that this document is not Standards Track, it is intended as a
BCP (Best Current Practices).

>   The advice in this document applies to attributes used to encode
>   data.  RADIUS protocol changes, or specification of attributes that
>   can be used to provide new RADIUS commands (such as Service-Type) are
>   out of scope.

I think some further explanation of how values of the Service-Type
attribute, in particular, could be used to effectively create commands may
be in order.  More specifically, could we provide some guidance as to when
one has crossed the line into defining a "command" within an "attribute"?

> 2.1.3.  Complex Attribute Usage

This section explains why packing complex attributes into conventional
attributes (e.g. into sub-fields of a string data type) is disadvantageous.
It gives no advice to those who really want to do this, however.  What is
the "party line" here?  I know we have features in the Extended RADIUS
Attributes draft to address this.  Do we want to reference that document
here?   Do we have recommendations for those that want complex attributes
and don't want to use Extended Attributes?  Or is using the Extended
Attribute format the only recommended option?

--
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, 06 Sep 2007 19:41:56 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Thu, 6 Sep 2007 12:40:36 -0700

Further comments on the draft:

Section 2.

   Although according to the specification the allocation of RADIUS
   attribute type codes has been controlled by IANA, this has not been
   the case in reality.  In the real world, certain vendors have grabbed
   attribute type codes that they shouldn't have.  The result is that
   many RADIUS deployments have had to work around these attribute
   collisions.  Therefore, each time a new attribute type is introduced
   it raises the possibility that something will break.  The proposed
   scheme must be impervious to this artifact.

I suggest deleting this paragraph.  It duplicates some content of RFC 3575
and adds nothing to the purpose of this document, going forward.
[gwz] 
[gwz] Done.

Section 7.

   This solution requires that the IETF be allocated Vendor-Type of zero
   to the IETF.

RFC 2865, Section 5.26 says, in part:

    Vendor-Id

      The high-order octet is 0 and the low-order 3 octets are the SMI
      Network Management Private Enterprise Code of the Vendor in
      network byte order, as defined in the "Assigned Numbers" RFC [6].

Taken together, these sections of text might be interpreted to mean that the
IETF is assigning a Private Enterprise Code of 0 to itself.  The PEN
Registry at the following URL:
http://www.iana.org/assignments/enterprise-numbers indicates:

0
  Reserved
    Internet Assigned Numbers Authority
      iana&iana.org

that 0 is reserved for IANA.  Is that the same as reserved for IETF use?
Should we add clarifying text to indicate that the Vendor-Id of 0 is not
strictly a PEN?
[gwz] 
[gwz] Actually, I think that a better idea than using 0 would be for the
radext WG to request a PEN of its own.

   It also requires that IANA be set up to manage the RADIUS Extended
   Attributes.

This means that there would be a new section in the existing RADIUS Registry
dealing with IETF VSA Extended-Type field.
[gwz] 
[gwz] Yup.

   The allocation rules for extended RADIUS attributes align with the
   rules for allocation of the standard RADIUS attributes.

Does this mean to reference RFC 3575?
[gwz]
[gwz] Possibly; if so, I don't think it's really appropriate here since
virtually nothing 3575 has to say about attributes seems to apply here.

--
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, 06 Sep 2007 19:15:29 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-design-00.txt 
Date: Thu, 06 Sep 2007 15: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 Design Guidelines
	Author(s)	: G. Weber, A. DeKok
	Filename	: draft-ietf-radext-design-00.txt
	Pages		: 22
	Date		: 2007-9-6

   This document provides guidelines for the design of attributes used
   by the Remote Authentication Dial In User Service (RADIUS) protocol.
   It is expected that these guidelines will prove useful to authors and
   reviewers of future RADIUS attribute specifications, both within the
   IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-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-ietf-radext-design-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-ietf-radext-design-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.

--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-design-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-design-00.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, 06 Sep 2007 05:44:49 +0000
Date: Thu, 06 Sep 2007 07:44:06 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Request for formal review of draft-ietf-radext-management-authorization-00.txt

David B. Nelson wrote:
> This review period will last until September 14, 2007.  At that time issues
> raised on the list will be resolved.  Once all issues are addressed we will
> start WGLC on the document.

  The document looks fine to me.

  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, 06 Sep 2007 05:28:08 +0000
Date: Thu, 06 Sep 2007 07:27:45 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: More comments on draft-ietf-radext-fixes-06.txt

David B. Nelson wrote:
> So, does that mean we can expect a -08 revision?

  Yes.

  If there are no more comments...

  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, 06 Sep 2007 04:35:24 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Request for review:  Design Guidelines Document
Date: Wed, 05 Sep 2007 21:35:13 -0700

An updated version of the Design Guidelines document has been posted to the 
IETF archive:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-00.txt

Pease formally review the document to determine if it is ready or WGLC. 
Comments should be sent to this list using the format described in the 
RADEXT Issues tracker: http://www.drizzle.com/~aboba/RADEXT/

This review period will last until October 5, 2007.  At that time issues 
raised on the list will be resolved.  Once all issues are addressed we will 
start WGLC on the document.

--
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, 06 Sep 2007 04:30:28 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: REMINDER:  Open Review Requests
Date: Wed, 05 Sep 2007 21:29:09 -0700

The RADEXT WG has two outstanding review requests:

AAA Framework for Multicasting
Deadline: September 5, 2007 (only one comments so far)
Review Request: http://ops.ietf.org/lists/radiusext/2007/msg00636.html
Document: 
http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-04.txt

Management Authorization
Deadline: September 14, 2007
Review Request:  http://ops.ietf.org/lists/radiusext/2007/msg00684.html
Document:  
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-00.txt

--
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, 05 Sep 2007 19:24:56 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: RE: More comments on draft-ietf-radext-fixes-06.txt
Date: Wed, 5 Sep 2007 15:23:42 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

>   OK...

So, does that mean we can expect a -08 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: Wed, 05 Sep 2007 19:15:55 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-fixes-07.txt 
Date: Wed, 05 Sep 2007 15: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) Implementation Issues and Suggested Fixes
	Author(s)	: D. Nelson, A. DeKok
	Filename	: draft-ietf-radext-fixes-07.txt
	Pages		: 28
	Date		: 2007-9-5
	
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-07.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-07.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-07.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-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-fixes-07.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, 05 Sep 2007 05:43:39 +0000
Date: Wed, 05 Sep 2007 07:42:12 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>,  'radext mailing list' <[email-masked]>
Subject: Re: More comments on draft-ietf-radext-fixes-06.txt

Bernard Aboba wrote:
> Expires:  February 27, 2007
> 
> Shouldn't this be 2008?

  Yes.  I saw that just after the draft went out.

> Section 2.1.1
> 
>   In contrast, Access-Requests which are intended to perform
>   authorization checks MUST contain a State attribute in order to tie
>   the authorization check to a previous authentication session.  This
>   last requirement often means that an Access-Accept needs to contain a
>   State attribute, which is then used in a later Access-Request that
>   performs authorization checks.
> 
> [BA] The MUST here seems to be contradicted by text below relating to
> Call Check.  My advice is to i ntegrate the last sentence into one of the
> paragraphs below and delete the first sentence.

  OK...

   The standard use case for Call-Check is pre-screening authentication
>   based solely on the end-point identifier information, such as phone
>   number or MAC address in Calling-Station-ID and optionally Called-
>   Station-ID.  In that use case there is no source of the State
>   attribute in the NAS.
> 
> [BA] Suggest changing to "In this use case, the NAS has no way to obtain
> a State Attribute suitable for inclusion in an Access-Request."

  OK.

>   Other, non-standard, uses of Call-Check may
>   require or permit the use of a State Attribute, but are beyond the
>   scope of this document.
> 
>   Implementing Call Check functionality via requests where the User-
>   Name and User-Password contain the same information (e.g. MAC
>   address) is NOT RECOMMENDED.
> 
> [BA] Suggest rewriting to:  "In an Access-Request with a Service-Type
> Attribute with value "Call Check", it is NOT RECOMMENDED for the User-Name
> and User-Password attributes to contain the same values (e.g. a MAC
> address)."

  Except that the MAC address checks don't set Service-Type = Call-Check
in many cases.  The paragraph tries to talk about Call Check
functionality where requests *don't* claim to be call check...

>   This practice gives an attacker both
>   the clear-text and cipher-text of the User-Password field, which
>   permits many additional attacks on the security of the RADIUS
>   protocol.  For example, if the Request Authenticator does not satisfy
>   the [RFC2865] requirements on global and temporal uniqueness, the
>   practice described above may lead to the compromise of the User-
>   Password attribute in other Access-Requests for unrelated users.
>   Access to the cipher-text also greatly simplifies offline dictionary
>   attacks, potentially exposing the shared secret, and compromising the
>   entire RADIUS protocol.
> 
> [BA] I think you mean "Access to the cleartext", no?  BTW, how does this
> simplify offline dictionary attacks?  Seems like an attack on the Response
> Authenticator or Message-Authenticator attributes remains the weak link.

  OK.  Maybe "greatly simplifies" is an overstatement.  The
User-Password ciphertext is over only (S + RA), so that's less data to
hash than the Response Authenticator (packet + S).  But, the Response
Authenticator calculation can be pre-calculated for the packet, and only
the "secret" hash space searched.

> [BA] Given that Call Check is defined in RFC 2865, which does not require
> Message-Authenticator this appears to be imposing requirements on legacy
> implementations.  Today Call Check can return any attribute that is
> configured; I am not sure how this would modify that.

  OK.  The MUST can be changed to a SHOULD, to match the other
suggestions for Message-Authenticator.

> Rather than talking about "confidential information" (which is somewhat
> vague), it probably makes more sense to recommend how a RADIUS server
> should response to an Access-Request implementing an authorization check
> that does not include a State attribute.  Since earlier it is stated
> that an "Authorize Only" Access-Request MUST contain a State attribute,
> it would seem that the RADIUS server should send an Access-Reject, no?

  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: Tue, 04 Sep 2007 19:48:04 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: More comments on draft-ietf-radext-fixes-06.txt 
Date: Tue, 04 Sep 2007 12:47:40 -0700

Expires:  February 27, 2007

Shouldn't this be 2008?

Section 2.1.1

   In contrast, Access-Requests which are intended to perform
   authorization checks MUST contain a State attribute in order to tie
   the authorization check to a previous authentication session.  This
   last requirement often means that an Access-Accept needs to contain a
   State attribute, which is then used in a later Access-Request that
   performs authorization checks.

[BA] The MUST here seems to be contradicted by text below relating to
Call Check.  My advice is to i ntegrate the last sentence into one of the
paragraphs below and delete the first sentence.

   Access-Request packets that contain a Service-Type attribute with
   value Authorize Only (17) MUST contain a State attribute.  Access-
   Request packets that contain a Service-Type attribute with value Call
   Check (10) SHOULD NOT contain a State attribute.  Any other Access-
   Request packet that performs authorization checks MUST contain a
   State attribute.

[BA] This paragraph seems to state the requirement more clearly.

   The standard use case for Call-Check is pre-screening authentication
   based solely on the end-point identifier information, such as phone
   number or MAC address in Calling-Station-ID and optionally Called-
   Station-ID.  In that use case there is no source of the State
   attribute in the NAS.

[BA] Suggest changing to "In this use case, the NAS has no way to obtain
a State Attribute suitable for inclusion in an Access-Request."

   Other, non-standard, uses of Call-Check may
   require or permit the use of a State Attribute, but are beyond the
   scope of this document.

   Implementing Call Check functionality via requests where the User-
   Name and User-Password contain the same information (e.g. MAC
   address) is NOT RECOMMENDED.

[BA] Suggest rewriting to:  "In an Access-Request with a Service-Type
Attribute with value "Call Check", it is NOT RECOMMENDED for the User-Name
and User-Password attributes to contain the same values (e.g. a MAC
address)."

   This practice gives an attacker both
   the clear-text and cipher-text of the User-Password field, which
   permits many additional attacks on the security of the RADIUS
   protocol.  For example, if the Request Authenticator does not satisfy
   the [RFC2865] requirements on global and temporal uniqueness, the
   practice described above may lead to the compromise of the User-
   Password attribute in other Access-Requests for unrelated users.
   Access to the cipher-text also greatly simplifies offline dictionary
   attacks, potentially exposing the shared secret, and compromising the
   entire RADIUS protocol.

[BA] I think you mean "Access to the cleartext", no?  BTW, how does this
simplify offline dictionary attacks?  Seems like an attack on the Response
Authenticator or Message-Authenticator attributes remains the weak link.

   Any Access-Request packet that performs authorization checks,
   including Call Check, MUST contain a Message-Authenticator attribute.
   Any response to an Access-Request performing an authorization check
   MUST NOT contain confidential information about any user (such as
   Tunnel-Password), unless that Access-Request contains a State
   attribute.  The use of State here permits the authorization check to
   be tied to an earlier user authentication.  In that case, the server
   MAY respond to the NAS with confidential information about that user.
   The server MUST NOT respond to that authorization check with
   confidential information about any other user.

[BA] Given that Call Check is defined in RFC 2865, which does not require
Message-Authenticator this appears to be imposing requirements on legacy
implementations.  Today Call Check can return any attribute that is
configured; I am not sure how this would modify that.

Rather than talking about "confidential information" (which is somewhat
vague), it probably makes more sense to recommend how a RADIUS server
should response to an Access-Request implementing an authorization check
that does not include a State attribute.  Since earlier it is stated
that an "Authorize Only" Access-Request MUST contain a State attribute,
it would seem that the RADIUS server should send an Access-Reject, no?

--
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, 04 Sep 2007 19:46:29 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: More comments on draft-ietf-radext-fixes-06.txt
Date: Tue, 04 Sep 2007 12:34:00 -0700

Section 2.1.1

   In contrast, Access-Requests which are intended to perform
   authorization checks MUST contain a State attribute in order to tie
   the authorization check to a previous authentication session.  This
   last requirement often means that an Access-Accept needs to contain a
   State attribute, which is then used in a later Access-Request that
   performs authorization checks.

[BA] The MUST here seems to be contradicted by text below relating to
Call Check.  My advice is to i ntegrate the last sentence into one of the
paragraphs below and delete the first sentence.

   Access-Request packets that contain a Service-Type attribute with
   value Authorize Only (17) MUST contain a State attribute.  Access-
   Request packets that contain a Service-Type attribute with value Call
   Check (10) SHOULD NOT contain a State attribute.  Any other Access-
   Request packet that performs authorization checks MUST contain a
   State attribute.

[BA] This paragraph seems to state the requirement more clearly.

   The standard use case for Call-Check is pre-screening authentication
   based solely on the end-point identifier information, such as phone
   number or MAC address in Calling-Station-ID and optionally Called-
   Station-ID.  In that use case there is no source of the State
   attribute in the NAS.

[BA] Suggest changing to "In this use case, the NAS has no way to obtain
a State Attribute suitable for inclusion in an Access-Request."

   Other, non-standard, uses of Call-Check may
   require or permit the use of a State Attribute, but are beyond the
   scope of this document.

   Implementing Call Check functionality via requests where the User-
   Name and User-Password contain the same information (e.g. MAC
   address) is NOT RECOMMENDED.

[BA] Suggest rewriting to:  "In an Access-Request with a Service-Type
Attribute with value "Call Check", it is NOT RECOMMENDED for the User-Name
and User-Password attributes to contain the same values (e.g. a MAC
address)."

   This practice gives an attacker both
   the clear-text and cipher-text of the User-Password field, which
   permits many additional attacks on the security of the RADIUS
   protocol.  For example, if the Request Authenticator does not satisfy
   the [RFC2865] requirements on global and temporal uniqueness, the
   practice described above may lead to the compromise of the User-
   Password attribute in other Access-Requests for unrelated users.
   Access to the cipher-text also greatly simplifies offline dictionary
   attacks, potentially exposing the shared secret, and compromising the
   entire RADIUS protocol.

[BA] I think you mean "Access to the cleartext", no?  BTW, how does this
simplify offline dictionary attacks?  Seems like an attack on the Response
Authenticator or Message-Authenticator attributes remains the weak link.

   Any Access-Request packet that performs authorization checks,
   including Call Check, MUST contain a Message-Authenticator attribute.
   Any response to an Access-Request performing an authorization check
   MUST NOT contain confidential information about any user (such as
   Tunnel-Password), unless that Access-Request contains a State
   attribute.  The use of State here permits the authorization check to
   be tied to an earlier user authentication.  In that case, the server
   MAY respond to the NAS with confidential information about that user.
   The server MUST NOT respond to that authorization check with
   confidential information about any other user.

[BA] Given that Call Check is defined in RFC 2865, which does not require
Message-Authenticator this appears to be imposing requirements on legacy
implementations.  Today Call Check can return any attribute that is
configured; I am not sure how this would modify that.

Rather than talking about "confidential information" (which is somewhat
vague), it probably makes more sense to recommend how a RADIUS server
should response to an Access-Request implementing an authorization check
that does not include a State attribute.  Since earlier it is stated
that an "Authorize Only" Access-Request MUST contain a State attribute,
it would seem that the RADIUS server should send an Access-Reject, no?

--
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, 04 Sep 2007 18:46:54 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: Comment on draft-ietf-radext-fixes-06.txt
Date: Tue, 4 Sep 2007 14:45:56 -0400
Organization: Elbrys Networks, Inc.

Comment from Jari Arkko during IESG review of
draft-ietf-radext-fixes-06.txt:

> 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 
> case, it should be delegated a prefix by the NAS via the Delegated- 
> IPv6-Prefix attribute.  [RFC4818].  If the CPE is not decrementing 
> TTL, it does not 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.

--
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, 04 Sep 2007 12:07:21 +0000
Date: Tue, 04 Sep 2007 14:07:03 +0200
From: Alan DeKok <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: draft-ietf-radext-design-00.txt

  I've just submitted a draft of the design guidelines document, as
reviewed at the last IETF.

  It's been re-organized a bit since Greg's draft.  Hopefully the
changes are all positive.

  There are no Diameter considerations, though the current text refers
to them.  Based on WG discussion, that text belongs in another document.

  The other change is Appendix A, which talks about the "odd" attributes
in detail.  i.e. ones which don't meet the RADIUS data model.

  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, 04 Sep 2007 11:59:09 +0000
Date: Tue, 04 Sep 2007 13:58:32 +0200
From: Alan DeKok <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: draft-ietf-radext-fixes-07.txt

  I've just submitted draft-ietf-radext-fixes-07.txt, which contains a
few minor changes suggested by IESG review.

  I think the document is OK to submit to the IESG.

  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, 04 Sep 2007 10:29:02 +0000
Date: Tue, 04 Sep 2007 08:28:07 +0200
From: Hannes Tschofenig <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Minutes of the RADEXT session at IETF-69

I just noticed in the meeting minutes that I have to send Avi's draft 
around. I guess I haven't done it yet.
Here is the link to it:
http://www.ietf.org/internet-drafts/draft-lior-diameter-classifier-00.txt

Ciao
Hannes

David B. Nelson wrote:
> Minutes of the RADIUS Extensions (RADEXT) WG
>
> IETF-69, Chicago, IL, USA
>
> Thursday, July 26, 2007
>
> 9 AM - 11:30 AM
>
>  
>
> Note takers: Alan DeKok and Mauricio Sanchez.  Edited by Dave Nelson.
>
>  
>
> Call for revision to agenda items... none
>
>  
>
> Documents completing IETF last call (10 minutes)
>
>  
>
> RFC4690bis.  Problems caught in the examples.  Will be fixed in AUTH48.
> Hopes no others are found.
>
>  
>
> Documents completing RADEXT WG last call (10 minutes)
>
>  
>
> Two documents completed WGLC
>
>  
>
>       RADIUS Issues & Fixes
>
>       RADIUS Location Attributes (GEOPRIV WG)
>
>  
>
> Two documents completing WGLC 
>
>  
>
>       RFC3576bis
>
>       RADIUS attributes for filtering and redirection
>
>  
>
> Several individual submissions are currently under review.
>
>  
>
> Hannes: Asks about how extensibility will work in the filter document, for
> Diameter interoperability?
>
>  
>
> The current approach is to add grouped AVP around it.  Maybe it could be
> handled via IANA considerations?  Request Hannes to submit this as a formal
> ISSUE.
>
>  
>
> 9:10 - 9:20:  Issues & Fixes, Alan DeKok
>
> http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-04.txt
>
>  
>
> Draft -03 sent to IESG for comments, lots of comments and -04 came out.
> Mostly  clarifications; Retransmit timers had not been discussed in -03 and
> discussion added to -04
>
>  
>
> Draft -05 published, yet more comments streaming in.  Discussion around
> invalidation of cache and why.  Suggest usage of client authenticator to
> protect against forging.
>
>  
>
> Bernard question on how.
>
>  
>
> Backwards compatibility a concern. Many vendors have done strange thing with
> their implementations.
>
>  
>
> Bernard asked group to read group document and comment.  If only one
> document should be reviewed. It's this one. 
>
>  
>
> Dave asks whether Alan picked up the post-resolution text from the PANA
> document?  Grab updated timer text from PANA.
>
>  
>
> 9:20 - 9:30 Attributes for Filtering & Redirection, Mauricio Sanchez
>
> http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-03.txt
>
>  
>
>  
>
> This is a new version draft -03.
>
>  
>
> No comments, on the list.
>
>  
>
> Open issue: 172, suggested text looks good.
>
>       
>
> In response to Hannes' comment: use a version number.
>
>       
>
> Hannes: Version capability negotiation? Copy whole ABNF into new document?
>
>       
>
> Yes, it is a monolithic approach.
>
>       
>
> Hannes: In Dime, create grouped AVP, and associate the two.
>
>  
>
> Alan D: Add "chain" actions?
>
>       
>
> Glen Z: Get rid of the goofy BSD syntax, and put it into an extended
> attribute.  String parsing is very unpopular on the NAS.  Parsing strings is
> not good.
>
>       
>
> Hannes: Avi submitted document to DIME on that issue. Do encoding as
> different attributes, which simplifies the extensibility.
>
>       
>
> Mauricio: Send link, and take it to the list.
>
>       
>
> Glen: It looks just like Diameter which is good, but the Diameter way is
> broken.  We shouldn't continue this approach.
>
>       
>
> Bernard: is DIME going to change document?
>
>  
>
> Hannes: Not really.
>
>  
>
> Post issues to list.
>
>       
>
> Hannes: Encoding isn't a minor issue.
>
>       
>
> Glen: Is there a forgotten issue?
>
>       
>
> Bernard: We decided to do whatever DIME is doing.
>
>       
>
> Hannes: DIME is following RADEXT.
>
>       
>
> Bernard: We're chasing tails.
>
>       
>
> Hannes: People who care are in both groups. Multiple encodings are bad...
> but we have them. Suggest to talk to AD.  Ask both WG's what to do.
>
>       
>
> Mauricio: Document presented to both groups, with little argument.  It's
> tradition... no better way.
>
>       
>
> Alan D: Might as well wait to do it right.
>
>       
>
> Dan: Decisions need to be validated by list; wait a week, and confirm
> decision.
>
>       
>
> David: If we change encodings, do simultaneous last calls in both DIME &
> RADEXT
>
>  
>
> 9:30 - 9:40 Attribute Type Extension, Glen Zorn
>
> http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extensi
> on-02.txt
>
>  
>
> Extend attribute ID space, extend the length, support sub-attributes and
> grouped attributes.  Described how type values are extended.  Uses VSAs with
> a vendor code of 0.  Described how large attributes are to be supported. Use
> a fragmentation bit in the header.  Described how attribute grouping is to
> be supported. Uses a tag field in header similar to RFC 2868.
>
>       
>
> Alan D: MUST have similar attributes next to each other. Would like the
> draft to strengthen the usage of fragmentation to prevent implementers
> fragmenting attributes throughout the packet. Would like some usage rules
> defined.
>
>  
>
> Bernard: Questions whether we are setting up two different ways of treating
> "standard" attributes as specified by this draft and the RADIUS Issues and
> Fixes draft. Must be able to ignore something you don't understand.
>
>       
>
> Glen: good question.
>
>       
>
> Bernard: Behavior is different...
>
>       
>
> Glen: We're defining a standard attribute here.  Should be handled the same
> way as standards.
>
>       
>
> Bernard: This can become WG work item.
>
>       
>
> David: Is zero a special value for VSA's?
>
>       
>
> Glen / Bernard: Nope.  It seems to work in implementations.
>
>  
>
> 9:40 - 9:50 WLAN Attributes, Bernard Aboba
>
> http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.txt
>
>  
>
> Recently completed IEEE 802.11 review. Removed Allowed-SSID and SSID. Added
> EAP-Lower-Layer. Might want to change policy based on lower layer or
> pre-authentication. Ask folks in 802.1af to look at this.
>
>  
>
> Alan D: Asks what is done with EAP fragments?  The issue is with TLS. Apps
> may think they have a greater lower-layer MTU than they actually have.
>
>  
>
> Bernard asserts it's an issue outside the scope of RADEXT to figure out how
> to prevent fragmentation.
>
>  
>
> Accept as WG item?
>
>  
>
> 9:50 - 10:10 Design Guidelines, Bernard Aboba
>
>  
>
> Alan DeKok has accepted the editing responsibility.  Design guidelines deal
> with the current data model, not extensions.  We don't deprecate formats,
> but to explain them and articulate design principles.
>
>  
>
> Went through document outline section by section. 
>
>  
>
> Section 2 describes vendor space.
>
>  
>
> Bernard raises question whether anyone in group knows all possible formats
> used by vendors.  We may want to describe the various VSA formats.
>
>  
>
> Alan DeKok says he has a pretty good handle.
>
>  
>
> Glen Zorn says it's likely not possible. He doesn't even know all the
> formats for his company (Cisco). Cisco has 4 kinds.
>
>  
>
> Dave N. asserts that it was unfortunate that 2865 essentially described VSAs
> as private sandboxes.
>
>    
>
> Dan: Do we make a distinction between SDO's and vendors? Is SDO the correct
> term?  Industry forum?
>
>  
>
> Bernard asks Glen Z. whether it's possible to synchronize what's going on in
> the standard space with what's going in the vendor space?
>
>  
>
> Glen says no.  He feels it's not useful to spend the time.  
>
>  
>
> Bernard asserts that it's absurd to force SDOs to define attributes in the
> standard space if they already have a fully defined vendor space attribute.
>
>  
>
> Glen: We should encourage people to publish informational RFC's on their
> VSAs and VSA formats.
>
>  
>
> Joe S. points out that that SDOs that define vendor space attributes are
> also in control of those attributes.  It may be useful to have the IETF the
> controlling body, as it is for the standard space.
>
>  
>
> Bernard chimes that having the IETF in the middle of SDOs is probably not
> useful.
>
>  
>
> Dave N. feels that one basic step we should take is define a basic data
> model. He feels that it would help a lot towards improving interoperability.
>
>  
>
> Bernard took poll of room whether to accept as WG work item.  Raised hands
> in favor of accepting as WG item won over those not in favor.
>
>  
>
> 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
>
>  
>
> Bernard has question on resource allocation whether we can distinguish
> resource allocation requests.  Alan says yes based on the usage of RADIUS
> length of 0 to use as markers.
>
>  
>
> Joe asks whether there is more to do on the server besides the code snippet
> described in Alan's presentation.  Alan says there is additional work,
> mostly on the server side in order to do the muxing and demuxing. 
>
>  
>
> Scott Kelly chimed in that he has implemented DTLS and didn't find it too
> onerous.  Asserts that there are issues with the OpenSSL implementation.  He
> pointed out that fragmentation is not supported in DTLS and causes
> operational headaches.
>
>  
>
> Bernard asks whether the RADIUS 4K limit would effectively be limited to the
> DTLS MTU.
>
>  
>
> Scott says yes and feels it needs to be addressed. 
>
>  
>
> Comment: Isn't that hard to do. DTLS packets can't be fragmented.  We have
> little implementation experience.
>
>  
>
> 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
>
>  
>
> Bernard asked whether there are cryptographic property differences between
> the generic attribute and key wrap attributes. Joe replied that there are
> because usage scenarios for each attribute drive unique needs around
> cryptographic properties.
>
>  
>
> Hannes: End to end key distribution?  Or hop by hop?
>
>       
>
> Joe: Hop by hop.  But it's possible to encrypt between arbitrary parties.
>
>  
>
> Hannes: DTLS is hop by hop.  CMS in Diameter has similar issues.
>
>  
>
> Bernard: CMS is unrelated.
>
>       
>
> Joe / Hannes: It is the same.
>
>       
>
> Hannes: Issues that don't show up in a neighboring relationship need to run
> a discover step.
>
>  
>
> Joe: This draft is limited to hop by hop.  Not intending to do end to end.
>
>       
>
> Glen asserts scope of document is limited by trust topology of network.  If
> key is shared across many hops, then one could build an end-to-end solution.
> It's not the intention of this draft to create a radius key management
> system.
>
>  
>
> Hannes: Additional issues that need to be addressed when you address
> messages to non-neighboring nodes.
>
>  
>
> Glen: That's not an issue.  If a key is configured, you can use it.
>
>  
>
> Dan Harkins asks about the purpose of the IV.
>
>  
>
> Joe replied that NIST specs state that IV in draft should be used. 
>
>  
>
> Dan replies that it's not necessary. 
>
>  
>
> Dan asks about purpose of the MAC randomizer.
>
>  
>
> Joe says that not all messages may contain keys (which are key wrapped) and
> hence the need for the MAC randomizer arises.
>
>  
>
> Dan: Make Message-Authentication-Code not dependent on keywrap.
>
>       
>
> Bernard: We need a separate shared secret for each MAC algorithm.
>
> Joe: Yes.
>
>       
>
> Dan: Divorce Id's from attributes, and move them into other drafts.
>
>       
>
> Joe: There are advantages to having them here.
>
>  
>
> Dan questions the lack of any key management scheme.
>
>  
>
> Glen mentions the utter failure that Diameter CMS in trying to define a key
> system.
>
>  
>
> Hannes: The use of transport layer security seems to be OK for Diameter.
>
>  
>
> Steve Hanna: Pre-shared keys exist for TLS, we can use the same thing for
> DTLS.  It is compatible with existing practice.
>
>  
>
> Dan: DTLS & keywrap are equally new.
>
>  
>
> Glenn questions whether DTLS/TLS proposal makes key management any easier.  
>
>  
>
> Leif J. feels that key management in DTLS/TLS is easier because there are
> existing libraries to answer question.
>
>  
>
> Steve H. asks Alan what key management scheme he had in mind.  Alan replies
> that he hasn't specified any and acknowledges it must be discussed.
>
>  
>
> Steve states he favors DTLS because more existing work 
>
>  
>
> Bernard asks for clarification on the DTLS fragmentation.
>
>  
>
> Scott Kelly responds that it an oversight in the DTLS stack specification,
> but a workaround does exists that relies on manual fragmentation.  Suggests
> that issue be taken to TLS WG and get them to fix it.  
>
> Steve H. chimes in that he feels that we should use existing security
> mechanisms rather than invent one.  RADIUS WG has a bad track record in
> developing new security mechanisms.
>
>  
>
> Glen Z. highlighted past examples where security group has not taken well
> the re-use of existing security mechanisms. Ex. PEAP/TLS.
>
>  
>
> Dan H. feels that we're not defining a new security mechanism when in fact
> AES keywrap is a well established technology designed by smart
> cryptographers.
>
>  
>
> Steve feels that if we go down the AES keywrap the security area should be
> consulted and have them review RADIUS work.
>
>  
>
> Leif. J seconds Steve's recommendation for review by security area. 
>
>  
>
> Room poll taken on various questions
>
>    "Who favors the DTLS proposal?"   4 hands in favor
>
>    "Who favors the keywrap proposal?" 8 hands in favor
>
>    "Who doesn't like either proposal?"  1 hand
>
>       
>
> 11:10 - 11:20 RADSEC (Stefan Winter)
>
> http://www.ietf.org/internet-drafts/draft-winter-radsec-00.txt
>
>  
>
> Hannes: This is re-inventing Diameter.
>
>  
>
> Glen: It's mostly used between roaming providers.
>
>  
>
> Stefan: We can use it on NASes, radsec proxy exists.
>
>  
>
> Bernard asks whether this proposal assumes PKI, pre-shared secrets, etc. for
> key management.
>
>  
>
> Stefan responds that their implementation uses PKI, but in theory there is
> no inherent limit on how the keys are managed. 
>
>  
>
> Glen Z. asks whether the TLS connection is just between realms.
>
>  
>
> Glenn asks what IPR issues exist with Diameter.  
>
>  
>
> Bernard points Glenn to IETF IPR page that lists several claims against
> RFC3588.
>
>  
>
> Steve: Any issues with TCP?
>
>       
>
> Stefan: That hasn't been a problem.
>
>       
>
> Dan: Be careful about overlap with Diameter.
>
>       
>
>  
>
> Dave polls the question whether this work should be accepted as the solution
> to the crypto agility work (assuming transport issue with RADEXT charter is
> overcome)?
>
>  
>
>      8 in favor
>
>      6 against
>
>  
>
> Dan R. chimes in that it may possible to change the RADEXT charter to allow
> the TLS proposal to be worked on in RADEXT. 
>
>  
>
> Glen is not hostile to the proposal itself, but hostile to changing the
> charter. Feels there are better reasons to change the charter than for this
> document.  He would appeal if we changed charter to add this work.  Keywrap
> has been extensively reviewed.
>
>  
>
> Leif J. is surprised about hesitancy on changing charter.  Other groups
> change charter and survive.  Asks whether there is a rush to get this work
> done.  
>
>  
>
> Glenn says no, the keywrap draft has been around for three years. 
>
>  
>
> Lief: All proposals have issues, should we keep them all alive?
>
>       
>
> Dan: Yes, but WG is under pressure to do work. Do it as fast as you can.
>
>  
>
> Comment: We should be able to resolve on mailing list.  Don't wait.
>
>  
>
> Comment: RADSEC wants to change the transport, it's a bigger issue than it
> appears.  
>
>  
>
> Comment: Other protocols needs key transport.  3GPP2 will put dependencies
> on keywrap.  We need to get it done quickly.
>
>  
>
> Hannes suggests a proposal that takes elements from keywrap and from DTLS.
>
>  
>
> Bernard asserts that trying to mix DTLS and keywrap is going to result in a
> protocol that takes the worst from both and would be universally ignored.
>
>
>   

--
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, 04 Sep 2007 06:18:54 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: Minutes of the RADEXT session at IETF-69
Date: Mon, 3 Sep 2007 21:46:51 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_015C_01C7EE73.F0650330
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Minutes of the RADIUS Extensions (RADEXT) WG

IETF-69, Chicago, IL, USA

Thursday, July 26, 2007

9 AM - 11:30 AM

Note takers: Alan DeKok and Mauricio Sanchez.  Edited by Dave Nelson.

Call for revision to agenda items... none

Documents completing IETF last call (10 minutes)

RFC4690bis.  Problems caught in the examples.  Will be fixed in AUTH48.
Hopes no others are found.

Documents completing RADEXT WG last call (10 minutes)

Two documents completed WGLC

      RADIUS Issues & Fixes

      RADIUS Location Attributes (GEOPRIV WG)

Two documents completing WGLC 

      RFC3576bis

      RADIUS attributes for filtering and redirection

Several individual submissions are currently under review.

Hannes: Asks about how extensibility will work in the filter document, for
Diameter interoperability?

The current approach is to add grouped AVP around it.  Maybe it could be
handled via IANA considerations?  Request Hannes to submit this as a formal
ISSUE.

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

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

Draft -03 sent to IESG for comments, lots of comments and -04 came out.
Mostly  clarifications; Retransmit timers had not been discussed in -03 and
discussion added to -04

Draft -05 published, yet more comments streaming in.  Discussion around
invalidation of cache and why.  Suggest usage of client authenticator to
protect against forging.

Bernard question on how.

Backwards compatibility a concern. Many vendors have done strange thing with
their implementations.

Bernard asked group to read group document and comment.  If only one
document should be reviewed. It's this one. 

Dave asks whether Alan picked up the post-resolution text from the PANA
document?  Grab updated timer text from PANA.

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

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

 

This is a new version draft -03.

No comments, on the list.

Open issue: 172, suggested text looks good.

In response to Hannes' comment: use a version number.

Hannes: Version capability negotiation? Copy whole ABNF into new document?

Yes, it is a monolithic approach.

Hannes: In Dime, create grouped AVP, and associate the two.

Alan D: Add "chain" actions?

Glen Z: Get rid of the goofy BSD syntax, and put it into an extended
attribute.  String parsing is very unpopular on the NAS.  Parsing strings is
not good.

Hannes: Avi submitted document to DIME on that issue. Do encoding as
different attributes, which simplifies the extensibility.

Mauricio: Send link, and take it to the list.

Glen: It looks just like Diameter which is good, but the Diameter way is
broken.  We shouldn't continue this approach.

Bernard: is DIME going to change document?

Hannes: Not really.

Post issues to list.

Hannes: Encoding isn't a minor issue.

Glen: Is there a forgotten issue?

Bernard: We decided to do whatever DIME is doing.

Hannes: DIME is following RADEXT.

Bernard: We're chasing tails.

Hannes: People who care are in both groups. Multiple encodings are bad...
but we have them. Suggest to talk to AD.  Ask both WG's what to do.

Mauricio: Document presented to both groups, with little argument.  It's
tradition... no better way.

Alan D: Might as well wait to do it right.

Dan: Decisions need to be validated by list; wait a week, and confirm
decision.

David: If we change encodings, do simultaneous last calls in both DIME &
RADEXT

9:30 - 9:40 Attribute Type Extension, Glen Zorn

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

Extend attribute ID space, extend the length, support sub-attributes and
grouped attributes.  Described how type values are extended.  Uses VSAs with
a vendor code of 0.  Described how large attributes are to be supported. Use
a fragmentation bit in the header.  Described how attribute grouping is to
be supported. Uses a tag field in header similar to RFC 2868.

Alan D: MUST have similar attributes next to each other. Would like the
draft to strengthen the usage of fragmentation to prevent implementers
fragmenting attributes throughout the packet. Would like some usage rules
defined.

Bernard: Questions whether we are setting up two different ways of treating
"standard" attributes as specified by this draft and the RADIUS Issues and
Fixes draft. Must be able to ignore something you don't understand.

Glen: good question.

Bernard: Behavior is different...

Glen: We're defining a standard attribute here.  Should be handled the same
way as standards.

Bernard: This can become WG work item.

David: Is zero a special value for VSA's?

Glen / Bernard: Nope.  It seems to work in implementations.

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

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

Recently completed IEEE 802.11 review. Removed Allowed-SSID and SSID. Added
EAP-Lower-Layer. Might want to change policy based on lower layer or
pre-authentication. Ask folks in 802.1af to look at this.

Alan D: Asks what is done with EAP fragments?  The issue is with TLS. Apps
may think they have a greater lower-layer MTU than they actually have.

Bernard asserts it's an issue outside the scope of RADEXT to figure out how
to prevent fragmentation.

Accept as WG item?

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

Alan DeKok has accepted the editing responsibility.  Design guidelines deal
with the current data model, not extensions.  We don't deprecate formats,
but to explain them and articulate design principles.

Went through document outline section by section. 

Section 2 describes vendor space.

Bernard raises question whether anyone in group knows all possible formats
used by vendors.  We may want to describe the various VSA formats.

Alan DeKok says he has a pretty good handle.

Glen Zorn says it's likely not possible. He doesn't even know all the
formats for his company (Cisco). Cisco has 4 kinds.

Dave N. asserts that it was unfortunate that 2865 essentially described VSAs
as private sandboxes.

Dan: Do we make a distinction between SDO's and vendors? Is SDO the correct
term?  Industry forum?

Bernard asks Glen Z. whether it's possible to synchronize what's going on in
the standard space with what's going in the vendor space?

Glen says no.  He feels it's not useful to spend the time.  

Bernard asserts that it's absurd to force SDOs to define attributes in the
standard space if they already have a fully defined vendor space attribute.

Glen: We should encourage people to publish informational RFC's on their
VSAs and VSA formats.

Joe S. points out that that SDOs that define vendor space attributes are
also in control of those attributes.  It may be useful to have the IETF the
controlling body, as it is for the standard space.

Bernard chimes that having the IETF in the middle of SDOs is probably not
useful.

Dave N. feels that one basic step we should take is define a basic data
model. He feels that it would help a lot towards improving interoperability.

Bernard took poll of room whether to accept as WG work item.  Raised hands
in favor of accepting as WG item won over those not in favor.

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

Bernard has question on resource allocation whether we can distinguish
resource allocation requests.  Alan says yes based on the usage of RADIUS
length of 0 to use as markers.

Joe asks whether there is more to do on the server besides the code snippet
described in Alan's presentation.  Alan says there is additional work,
mostly on the server side in order to do the muxing and demuxing. 

Scott Kelly chimed in that he has implemented DTLS and didn't find it too
onerous.  Asserts that there are issues with the OpenSSL implementation.  He
pointed out that fragmentation is not supported in DTLS and causes
operational headaches.

Bernard asks whether the RADIUS 4K limit would effectively be limited to the
DTLS MTU.

Scott says yes and feels it needs to be addressed. 

Comment: Isn't that hard to do. DTLS packets can't be fragmented.  We have
little implementation experience.

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

Bernard asked whether there are cryptographic property differences between
the generic attribute and key wrap attributes. Joe replied that there are
because usage scenarios for each attribute drive unique needs around
cryptographic properties.

Hannes: End to end key distribution?  Or hop by hop?

Joe: Hop by hop.  But it's possible to encrypt between arbitrary parties.

Hannes: DTLS is hop by hop.  CMS in Diameter has similar issues.

Bernard: CMS is unrelated.

Joe / Hannes: It is the same.

Hannes: Issues that don't show up in a neighboring relationship need to run
a discover step.

Joe: This draft is limited to hop by hop.  Not intending to do end to end.

Glen asserts scope of document is limited by trust topology of network.  If
key is shared across many hops, then one could build an end-to-end solution.
It's not the intention of this draft to create a radius key management
system.

Hannes: Additional issues that need to be addressed when you address
messages to non-neighboring nodes.

Glen: That's not an issue.  If a key is configured, you can use it.

Dan Harkins asks about the purpose of the IV.

Joe replied that NIST specs state that IV in draft should be used. 

Dan replies that it's not necessary. 

Dan asks about purpose of the MAC randomizer.

Joe says that not all messages may contain keys (which are key wrapped) and
hence the need for the MAC randomizer arises.

Dan: Make Message-Authentication-Code not dependent on keywrap.

Bernard: We need a separate shared secret for each MAC algorithm.

Joe: Yes.

Dan: Divorce Id's from attributes, and move them into other drafts.

Joe: There are advantages to having them here.

Dan questions the lack of any key management scheme.

Glen mentions the utter failure that Diameter CMS in trying to define a key
system.

Hannes: The use of transport layer security seems to be OK for Diameter.

Steve Hanna: Pre-shared keys exist for TLS, we can use the same thing for
DTLS.  It is compatible with existing practice.

Dan: DTLS & keywrap are equally new.

Glenn questions whether DTLS/TLS proposal makes key management any easier.  

Leif J. feels that key management in DTLS/TLS is easier because there are
existing libraries to answer question.

Steve H. asks Alan what key management scheme he had in mind.  Alan replies
that he hasn't specified any and acknowledges it must be discussed.

Steve states he favors DTLS because more existing work 

Bernard asks for clarification on the DTLS fragmentation.

Scott Kelly responds that it an oversight in the DTLS stack specification,
but a workaround does exists that relies on manual fragmentation.  Suggests
that issue be taken to TLS WG and get them to fix it.  

Steve H. chimes in that he feels that we should use existing security
mechanisms rather than invent one.  RADIUS WG has a bad track record in
developing new security mechanisms.

Glen Z. highlighted past examples where security group has not taken well
the re-use of existing security mechanisms. Ex. PEAP/TLS.

Dan H. feels that we're not defining a new security mechanism when in fact
AES keywrap is a well established technology designed by smart
cryptographers.

Steve feels that if we go down the AES keywrap the security area should be
consulted and have them review RADIUS work.

Leif. J seconds Steve's recommendation for review by security area. 

Room poll taken on various questions

   "Who favors the DTLS proposal?"   4 hands in favor

   "Who favors the keywrap proposal?" 8 hands in favor

   "Who doesn't like either proposal?"  1 hand

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

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

Hannes: This is re-inventing Diameter.

Glen: It's mostly used between roaming providers.

Stefan: We can use it on NASes, radsec proxy exists.

Bernard asks whether this proposal assumes PKI, pre-shared secrets, etc. for
key management.

Stefan responds that their implementation uses PKI, but in theory there is
no inherent limit on how the keys are managed. 

Glen Z. asks whether the TLS connection is just between realms.

Glenn asks what IPR issues exist with Diameter.  

Bernard points Glenn to IETF IPR page that lists several claims against
RFC3588.

Steve: Any issues with TCP?

Stefan: That hasn't been a problem.

Dan: Be careful about overlap with Diameter.

 

Dave polls the question whether this work should be accepted as the solution
to the crypto agility work (assuming transport issue with RADEXT charter is
overcome)?

     8 in favor

     6 against

Dan R. chimes in that it may possible to change the RADEXT charter to allow
the TLS proposal to be worked on in RADEXT. 

Glen is not hostile to the proposal itself, but hostile to changing the
charter. Feels there are better reasons to change the charter than for this
document.  He would appeal if we changed charter to add this work.  Keywrap
has been extensively reviewed.

Leif J. is surprised about hesitancy on changing charter.  Other groups
change charter and survive.  Asks whether there is a rush to get this work
done.  

Glenn says no, the keywrap draft has been around for three years. 

Lief: All proposals have issues, should we keep them all alive?

Dan: Yes, but WG is under pressure to do work. Do it as fast as you can.

Comment: We should be able to resolve on mailing list.  Don't wait.

Comment: RADSEC wants to change the transport, it's a bigger issue than it
appears.  

Comment: Other protocols needs key transport.  3GPP2 will put dependencies
on keywrap.  We need to get it done quickly.

Hannes suggests a proposal that takes elements from keywrap and from DTLS.

Bernard asserts that trying to mix DTLS and keywrap is going to result in a
protocol that takes the worst from both and would be universally ignored.

------=_NextPart_000_015C_01C7EE73.F0650330
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:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
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)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<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 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=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Minutes of the RADIUS Extensions (RADEXT) =
WG<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>IETF-69, <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Chicago</st1:City>, <st1:State
 w:st=3D"on">IL</st1:State>, <st1:country-region =
w:st=3D"on">USA</st1:country-region></st1:place><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'><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'>Note takers: Alan DeKok and Mauricio Sanchez.&nbsp; Edited by =
Dave 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'>Call for revision to agenda items... =
none<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'>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'><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'>RFC4690bis.&nbsp; Problems caught in the examples.&nbsp; Will be =
fixed in
AUTH48.&nbsp; Hopes no others are found.<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'>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'><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'>Two documents completed WGLC<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'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RADIUS Issues &amp; =
Fixes<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;&nbsp;&nbsp; RADIUS Location Attributes =
(GEOPRIV WG)<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'>Two documents completing WGLC <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'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RFC3576bis<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;&nbsp;&nbsp; RADIUS attributes for filtering =
and redirection<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'>Several individual submissions are currently under =
review.<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'>Hannes: Asks about how extensibility will work in the filter =
document,
for Diameter interoperability?<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'>The current approach is to add grouped AVP around it.&nbsp; =
Maybe it could
be handled via IANA considerations?&nbsp; Request Hannes to submit this =
as a formal
ISSUE.<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: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'>Draft -03 sent to IESG for comments, lots of comments and -04 =
came out.
Mostly&nbsp; clarifications; Retransmit timers had not been discussed in =
-03 and
discussion added to -04<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'>Draft -05 published, yet more comments streaming in.&nbsp; =
Discussion around
invalidation of cache and why.&nbsp; Suggest usage of client =
authenticator to
protect against forging.<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'>Bernard question on how.<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'>Backwards compatibility a concern. Many vendors have done =
strange thing
with their implementations.<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'>Bernard asked group to read group document and comment.&nbsp; If =
only one
document should be reviewed. It's this one. =
<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'>Dave asks whether Alan picked up the post-resolution text from =
the PANA
document?&nbsp; Grab updated timer text from =
PANA.<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: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'><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=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>This is a new version draft -03.<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'>No comments, on the list.<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'>Open issue: 172, suggested text looks =
good.<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;&nbsp;&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'>In response to Hannes&#8217; comment: use a version =
number.<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;&nbsp;&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'>Hannes: Version capability negotiation? Copy whole ABNF into new
document?<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;&nbsp;&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'>Yes, it is a monolithic approach.<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;&nbsp;&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'>Hannes: In Dime, create grouped AVP, and associate the =
two.<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'>Alan D: Add &quot;chain&quot; =
actions?<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;&nbsp;&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'>Glen Z: Get rid of the goofy BSD syntax, and put it into an =
extended
attribute.&nbsp; String parsing is very unpopular on the NAS.&nbsp; =
Parsing strings is
not good.<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;&nbsp;&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'>Hannes: Avi submitted document to DIME on that issue. Do =
encoding as
different attributes, which simplifies the =
extensibility.<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;&nbsp;&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'>Mauricio: Send link, and take it to the =
list.<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;&nbsp;&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'>Glen: It looks just like Diameter which is good, but the =
Diameter way
is broken.&nbsp; We shouldn't continue this =
approach.<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;&nbsp;&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'>Bernard: is DIME going to change =
document?<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'>Hannes: Not really.<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'>Post issues to list.<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;&nbsp;&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'>Hannes: Encoding isn't a minor =
issue.<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;&nbsp;&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'>Glen: Is there a forgotten issue?<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;&nbsp;&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'>Bernard: We decided to do whatever DIME is =
doing.<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;&nbsp;&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'>Hannes: DIME is following RADEXT.<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;&nbsp;&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'>Bernard: We're chasing tails.<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;&nbsp;&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'>Hannes: People who care are in both groups. Multiple encodings =
are
bad... but we have them. Suggest to talk to AD.&nbsp; Ask both WG's what =
to do.<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;&nbsp;&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'>Mauricio: Document presented to both groups, with little =
argument.&nbsp;
It's tradition... no better way.<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;&nbsp;&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'>Alan D: Might as well wait to do it =
right.<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;&nbsp;&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'>Dan: Decisions need to be validated by list; wait a week, and =
confirm
decision.<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;&nbsp;&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'>David: If we change encodings, do simultaneous last calls in =
both DIME
&amp; RADEXT<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:30 - 9:40 Attribute Type Extension, Glen =
Zorn<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'>Extend attribute ID space, extend the length, support =
sub-attributes
and grouped attributes.&nbsp; Described how type values are =
extended.&nbsp; Uses VSAs
with a vendor code of 0.&nbsp; Described how large attributes are to be =
supported.
Use a fragmentation bit in the header.&nbsp; Described how attribute =
grouping is to
be supported. Uses a tag field in header similar to RFC =
2868.<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;&nbsp;&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'>Alan D: MUST have similar attributes next to each other. Would =
like the
draft to strengthen the usage of fragmentation to prevent implementers
fragmenting attributes throughout the packet. Would like some usage =
rules
defined.<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'>Bernard: Questions whether we are setting up two different ways =
of
treating &quot;standard&quot; attributes as specified by this draft and =
the
RADIUS Issues and Fixes draft. Must be able to ignore something you =
don't
understand.<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;&nbsp;&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'>Glen: good question.<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;&nbsp;&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'>Bernard: Behavior is different...<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;&nbsp;&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'>Glen: We're defining a standard attribute here.&nbsp; Should be =
handled the
same way as standards.<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Bernard: This can become WG work =
item.<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;&nbsp;&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'>David: Is zero a special value for =
VSA's?<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;&nbsp;&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'>Glen / Bernard: Nope.&nbsp; It seems to work in =
implementations.<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'><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'>Recently completed IEEE 802.11 review. Removed Allowed-SSID and =
SSID.
Added EAP-Lower-Layer. Might want to change policy based on lower layer =
or
pre-authentication. Ask folks in 802.1af to look at =
this.<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'>Alan D: Asks what is done with EAP fragments?&nbsp; The issue is =
with TLS.
Apps may think they have a greater lower-layer MTU than they actually =
have.<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'>Bernard asserts it's an issue outside the scope of RADEXT to =
figure out
how to prevent fragmentation.<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'>Accept as WG item?<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: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'><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'>Alan DeKok has accepted the editing responsibility.&nbsp; Design =
guidelines
deal with the current data model, not extensions.&nbsp; We don't =
deprecate formats,
but to explain them and articulate design =
principles.<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'>Went through document outline section by section. =
<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'>Section 2 describes vendor space.<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'>Bernard raises question whether anyone in group knows all =
possible
formats used by vendors.&nbsp; We may want to describe the various VSA =
formats.<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'>Alan DeKok says he has a pretty good =
handle.<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'>Glen Zorn says it's likely not possible. He doesn't even know =
all the
formats for his company (Cisco). Cisco has 4 =
kinds.<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'>Dave N. asserts that it was unfortunate that 2865 essentially =
described
VSAs as private sandboxes.<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; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Dan: Do we make a distinction between SDO's and vendors? Is SDO =
the
correct term?&nbsp; Industry forum?<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'>Bernard asks Glen Z. whether it's possible to synchronize what's =
going
on in the standard space with what's going in the vendor =
space?<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'>Glen says no.&nbsp; He feels it's not useful to spend the =
time.&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'><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'>Bernard asserts that it's absurd to force SDOs to define =
attributes in
the standard space if they already have a fully defined vendor space =
attribute.<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'>Glen: We should encourage people to publish informational RFC's =
on their
VSAs and VSA formats.<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'>Joe S. points out that that SDOs that define vendor space =
attributes
are also in control of those attributes.&nbsp; It may be useful to have =
the IETF the
controlling body, as it is for the standard =
space.<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'>Bernard chimes that having the IETF in the middle of SDOs is =
probably
not useful.<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'>Dave N. feels that one basic step we should take is define a =
basic data
model. He feels that it would help a lot towards improving =
interoperability.<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'>Bernard took poll of room whether to accept as WG work =
item.&nbsp; Raised
hands in favor of accepting as WG item won over those not in =
favor.<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'>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'><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'>Bernard has question on resource allocation whether we can =
distinguish
resource allocation requests.&nbsp; Alan says yes based on the usage of =
RADIUS
length of 0 to use as markers.<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'>Joe asks whether there is more to do on the server besides the =
code
snippet described in Alan's presentation.&nbsp; Alan says there is =
additional work,
mostly on the server side in order to do the muxing and demuxing. =
<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'>Scott Kelly chimed in that he has implemented DTLS and didn't =
find it
too onerous.&nbsp; Asserts that there are issues with the OpenSSL =
implementation.&nbsp;
He pointed out that fragmentation is not supported in DTLS and causes
operational headaches.<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'>Bernard asks whether the RADIUS 4K limit would effectively be =
limited
to the DTLS MTU.<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'>Scott says yes and feels it needs to be =
addressed.&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'><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'>Comment: Isn't that hard to do. DTLS packets can't be =
fragmented.&nbsp; We
have little implementation experience.<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'>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'>Bernard asked whether there are cryptographic property =
differences
between the generic attribute and key wrap attributes. Joe replied that =
there are
because usage scenarios for each attribute drive unique needs around
cryptographic properties.<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'>Hannes: End to end key distribution?&nbsp; Or hop by =
hop?<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;&nbsp;&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'>Joe: Hop by hop.&nbsp; But it&#8217;s possible to encrypt =
between arbitrary
parties.<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'>Hannes: DTLS is hop by hop.&nbsp; CMS in Diameter has similar =
issues.<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'>Bernard: CMS is unrelated.<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;&nbsp;&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'>Joe / Hannes: It is the same.<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;&nbsp;&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'>Hannes: Issues that don't show up in a neighboring relationship =
need to
run a discover step.<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'>Joe: This draft is limited to hop by hop.&nbsp; Not intending to =
do end to
end.<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;&nbsp;&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'>Glen asserts scope of document is limited by trust topology of
network.&nbsp; If key is shared across many hops, then one could build =
an end-to-end
solution.&nbsp; It's not the intention of this draft to create a radius =
key
management system.<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'>Hannes: Additional issues that need to be addressed when you =
address
messages to non-neighboring nodes.<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'>Glen: That&#8217;s not an issue.&nbsp; If a key is configured, =
you can use
it.<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'>Dan Harkins asks about the purpose of the =
IV.<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'>Joe replied that NIST specs state that IV in draft should be =
used. <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'>Dan replies that it's not necessary. =
<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'>Dan asks about purpose of the MAC =
randomizer.<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'>Joe says that not all messages may contain keys (which are key =
wrapped)
and hence the need for the MAC randomizer =
arises.<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'>Dan: Make Message-Authentication-Code not dependent on =
keywrap.<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;&nbsp;&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'>Bernard: We need a separate shared secret for each MAC =
algorithm.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Joe: Yes.<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;&nbsp;&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'>Dan: Divorce Id's from attributes, and move them into other =
drafts.<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;&nbsp;&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'>Joe: There are advantages to having them =
here.<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'>Dan questions the lack of any key management =
scheme.<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'>Glen mentions the utter failure that Diameter CMS in trying to =
define a
key system.<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'>Hannes: The use of transport layer security seems to be OK for
Diameter.<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'>Steve Hanna: Pre-shared keys exist for TLS, we can use the same =
thing
for DTLS.&nbsp; It is compatible with existing =
practice.<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'>Dan: DTLS &amp; keywrap are equally =
new.<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'>Glenn questions whether DTLS/TLS proposal makes key management =
any
easier.&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'><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'>Leif J. feels that key management in DTLS/TLS is easier because =
there
are existing libraries to answer question.<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'>Steve H. asks Alan what key management scheme he had in =
mind.&nbsp; Alan
replies that he hasn't specified any and acknowledges it must be =
discussed.<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'>Steve states he favors DTLS because more existing work =
<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'>Bernard asks for clarification on the DTLS =
fragmentation.<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'>Scott Kelly responds that it an oversight in the DTLS stack
specification, but a workaround does exists that relies on manual
fragmentation.&nbsp; Suggests that issue be taken to TLS WG and get them =
to fix it.&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'>Steve H. chimes in that he feels that we should use existing =
security
mechanisms rather than invent one.&nbsp; RADIUS WG has a bad track =
record in
developing new security mechanisms.<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'>Glen Z. highlighted past examples where security group has not =
taken
well the re-use of existing security mechanisms. Ex. =
PEAP/TLS.<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'>Dan H. feels that we're not defining a new security mechanism =
when in
fact AES keywrap is a well established technology designed by smart
cryptographers.<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'>Steve feels that if we go down the AES keywrap the security area =
should
be consulted and have them review RADIUS =
work.<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'>Leif. J seconds Steve's recommendation for review by security =
area. <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'>Room poll taken on various =
questions<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; &quot;Who favors the DTLS =
proposal?&quot;&nbsp;&nbsp; 4 hands in =
favor<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; &quot;Who favors the keywrap proposal?&quot; 8 =
hands in favor<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; &quot;Who doesn't like either proposal?&quot;&nbsp; =
1 hand<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;&nbsp;&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'><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'>Hannes: This is re-inventing =
Diameter.<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'>Glen: It&#8217;s mostly used between roaming =
providers.<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'>Stefan: We can use it on NASes, radsec proxy =
exists.<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'>Bernard asks whether this proposal assumes PKI, pre-shared =
secrets,
etc. for key management.<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'>Stefan responds that their implementation uses PKI, but in =
theory there
is no inherent limit on how the keys are managed. =
<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'>Glen Z. asks whether the TLS connection is just between =
realms.<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'>Glenn asks what IPR issues exist with Diameter.&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'><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'>Bernard points Glenn to IETF IPR page that lists several claims =
against
RFC3588.<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'>Steve: Any issues with TCP?<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;&nbsp;&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'>Stefan: That hasn't been a problem.<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;&nbsp;&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'>Dan: Be careful about overlap with =
Diameter.<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;&nbsp;&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'><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'>Dave polls the question whether this work should be accepted as =
the
solution to the crypto agility work (assuming transport issue with =
RADEXT
charter is overcome)?<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'>&nbsp;&nbsp;&nbsp;&nbsp; 8 in favor<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;&nbsp; 6 against<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'>Dan R. chimes in that it may possible to change the RADEXT =
charter to
allow the TLS proposal to be worked on in RADEXT. =
<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'>Glen is not hostile to the proposal itself, but hostile to =
changing the
charter. Feels there are better reasons to change the charter than for =
this
document.&nbsp; He would appeal if we changed charter to add this =
work.&nbsp; Keywrap has
been extensively reviewed.<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'>Leif J. is surprised about hesitancy on changing charter.&nbsp; =
Other groups
change charter and survive.&nbsp; Asks whether there is a rush to get =
this work
done.&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'><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'>Glenn says no, the keywrap draft has been around for three =
years. <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'>Lief: All proposals have issues, should we keep them all =
alive?<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;&nbsp;&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'>Dan: Yes, but WG is under pressure to do work. Do it as fast as =
you
can.<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'>Comment: We should be able to resolve on mailing list.&nbsp; =
Don't wait.<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'>Comment: RADSEC wants to change the transport, it's a bigger =
issue than
it appears.&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'><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'>Comment: Other protocols needs key transport.&nbsp; 3GPP2 will =
put
dependencies on keywrap.&nbsp; We need to get it done =
quickly.<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'>Hannes suggests a proposal that takes elements from keywrap and =
from
DTLS.<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=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Bernard asserts that trying to mix DTLS and =
keywrap
is going to result in a protocol that takes the worst from both and =
would be
universally ignored.</span></font><o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_015C_01C7EE73.F0650330--

--
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/>