Subject: Re: new format

From: Bernard Aboba <[email-masked]>
Date: Fri, 28 Dec 2007 13:23:49 -0800

[gwz] 
Actually, I've convinced myself that a) this idea was not quite baked & b) I
was wrong about making the Ext-Type field just one octet.  If we make the
Ext-Type field 16 bits in length _and_ start numbering the new attributes at
0x100, that would seem to solve a couple of problems nicely.

[BA]  Could you elaborate on the new design and the issues this would solve? 
--
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/>

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 28 Dec 2007 14:52:53 -0800

[gwz] 

[gwz] 
Making the Ext-Type field 16 bits instead of 8 basically eliminates the
prospect of running out of attribute numbers.  Starting the Ext-Type
numbering at 0x100 instead of 1 eliminates any conflict between the extended
attribute types and existing standard attributes; because the type spaces do
not conflict and it's easy to differentiate between extended and standard
attributes encapsulated in the new format (the most significant octet is
always zero for standard attributes & never zero for extended types), this
open the possibility of including standard attributes in the new format &
getting the benefits of grouping, etc. for them as well as newly defined
attributes.  My motivation for suggesting this change is that it just
occurred to me that all these groovy new capabilities defined for the
extended attributes are nice but not especially useful (how many new
standard attributes will we define? 5? 10? 20?) unless they could be applied
to existing attributes, too.
[/gwz]

Delivery-date: Fri, 28 Dec 2007 22:54:15 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: new format
Date: Fri, 28 Dec 2007 14:52:53 -0800

 [gwz] 

[gwz] 
Making the Ext-Type field 16 bits instead of 8 basically eliminates the
prospect of running out of attribute numbers.  Starting the Ext-Type
numbering at 0x100 instead of 1 eliminates any conflict between the extended
attribute types and existing standard attributes; because the type spaces do
not conflict and it's easy to differentiate between extended and standard
attributes encapsulated in the new format (the most significant octet is
always zero for standard attributes & never zero for extended types), this
open the possibility of including standard attributes in the new format &
getting the benefits of grouping, etc. for them as well as newly defined
attributes.  My motivation for suggesting this change is that it just
occurred to me that all these groovy new capabilities defined for the
extended attributes are nice but not especially useful (how many new
standard attributes will we define? 5? 10? 20?) unless they could be applied
to existing attributes, too.
[/gwz]

Delivery-date: Fri, 28 Dec 2007 21:25:02 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Re: new format
Date: Fri, 28 Dec 2007 13:23:49 -0800

[gwz]=20
Actually, I've convinced myself that a) this idea was not quite baked & b) =
I
was wrong about making the Ext-Type field just one octet.  If we make the
Ext-Type field 16 bits in length _and_ start numbering the new attributes a=
t
0x100, that would seem to solve a couple of problems nicely.

[BA]  Could you elaborate on the new design and the issues this would solve=
? =

Delivery-date: Fri, 28 Dec 2007 16:37:22 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Questions on modified Extended Attribute format?
Date: Fri, 28 Dec 2007 08:35:11 -0800

...

> [gwz] I don't know where the "from scratch" comes from; there is a format
> defined in
>
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00
> .txt.  I am suggesting adding a single octet to the format which

  Opens it up for change again, after a long discussion, where everyone
had agreed that the format in -00 was acceptable.

> Interesting definition of "incompatible".  If that is in fact the standard
> to be met we may as well just fold up our tents and go home since there is
> _no_ change that could be made which would have "*zero* impact on
> implementations that don't understand".

  It's not about changes, it's about *compatible* changes to the
*standard* attributes.  Let me re-phrase:

  - standard RADIUS attributes in a VSA MUST be compatible with existing
implementations that only understand standard RADIUS attributes

  Put that way, it's obviously impossible.  Since RADIUS has no
capability negotiation, there's no way for the NAS to tell the server it
is capable of that new functionality.

  Therefore, the proposed change is incompatible with existing deployments.

[gwz] 
As I said, put that way or any other way you like, ANY change is
incompatible with existing deployments.  If one were to add a new "standard"
attribute (in the old format or the proposed VSA-like format or any other)
it would be incompatible with existing deployments.  The whole idea of
extended attributes REQUIRES that existing deployment be updated, no matter
how they are formatted.
[/gwz]

>   If we can't put standard attributes into the new format, then we
> should just pick a better format, and ideally one that's been deployed.
>  The WiMAX format (plus grouping) seems to fit that definition fairly
well.
> 
> [gwz]
> Can you tell us what it looks like?
> [/gwz]

  The format in -00, which achieved WG consensus after long and
protracted discussion.
[gwz] 
Actually, while the timeframe was long, the discussion wasn't: I've only
received a couple of comments on it in the last months.  It _did_ take an
inordinate amount of time to reject the 'Diameterization' of RADIUS,
though...
[/gwz]

  Alan DeKok.

Delivery-date: Fri, 28 Dec 2007 11:15:40 +0000
Date: Fri, 28 Dec 2007 12:13:09 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: RADEXT WG last call on RADIUS Attributes for Filtering and Redirection

Bernard Aboba wrote:
> Given that no comments have been received during the last two RADEXT WG
> last calls, we are going to bring the document to RADEXT WG call again. 
> This RADEXT WG last call will last until January 15, 2008.

  Some comments:

1.4:

  It may be useful to note that an Accounting-Request packet MAY be
generated when the NAS cannot apply an attribute in the Access-Accept.
The Accounting Request MAY contain Error-Cause, with value "Unsupported
Attribute" (401), and Acct-Status-Type = Stop, Acct-Terminate-Cause =
NAS-Error.  This serves as limited capability feedback.

Page 12:

        "any"       Keyword for 0.0.0.0/0 or the IPv6 equivalent.

  The IPv6 equivalent is...?  It could be specified here.

        "ipoptions" Match if the IP header contains the comma separated
                     list of options specified in spec.  The supported

  Can we allow hexadecimal specifications of options, too?  This would
be useful, and would match the rest of the document (e.g. IP proto as a
number, icmptypes, ...)

  A similar comment applies for tcpoptions.

3.1:

  Acct-NAS-Traffic-Rule is a complex attribute not meeting the
suggestions in the guidelines document.  Is there another way to achieve
the same end?  Since the extended attributes draft is still pending, I
think the answer is "no".

1.3:

  Capability advertisement could be done in a limited way by permitting
NAS-Traffic-Rule in an Access-Request.  Allowing this has practical
uses, too.  e.g. a WiFi hotspot (walled garden) could advertise upstream
 that it is *currently* blocking traffic, by sending it's filter rule:

    NAS-Traffic-Rule = "v1 redirect http://....local-login/"

  Similarly, a NAS requiring 802.1x could send:

   NAS-Traffic-Rule = "v1 permit inout l2:ether2:0x888e from any to
NAS-MAC-address"

  i.e. EAPoL is permitted, everything else is discarded.

  This information is useful for upstream servers, and can help them
make better policy decisions.  It solves a serious problem in many
current deployments, where you have no idea what the NAS is currently
doing...

  Alan DeKok.

Delivery-date: Fri, 28 Dec 2007 08:43:35 +0000
Date: Fri, 28 Dec 2007 09:40:29 +0100
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: [email-masked]
Subject: Re: Questions on modified Extended Attribute format?

Glen Zorn wrote:
> [gwz] I don't know where the "from scratch" comes from; there is a format
> defined in
> http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00
> .txt.  I am suggesting adding a single octet to the format which

  Opens it up for change again, after a long discussion, where everyone
had agreed that the format in -00 was acceptable.

> Interesting definition of "incompatible".  If that is in fact the standard
> to be met we may as well just fold up our tents and go home since there is
> _no_ change that could be made which would have "*zero* impact on
> implementations that don't understand".

  It's not about changes, it's about *compatible* changes to the
*standard* attributes.  Let me re-phrase:

  - standard RADIUS attributes in a VSA MUST be compatible with existing
implementations that only understand standard RADIUS attributes

  Put that way, it's obviously impossible.  Since RADIUS has no
capability negotiation, there's no way for the NAS to tell the server it
is capable of that new functionality.

  Therefore, the proposed change is incompatible with existing deployments.

>   If we can't put standard attributes into the new format, then we
> should just pick a better format, and ideally one that's been deployed.
>  The WiMAX format (plus grouping) seems to fit that definition fairly well.
> 
> [gwz]
> Can you tell us what it looks like?
> [/gwz]

  The format in -00, which achieved WG consensus after long and
protracted discussion.

  Alan DeKok.

Delivery-date: Thu, 27 Dec 2007 23:30:30 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Questions on modified Extended Attribute format?
Date: Thu, 27 Dec 2007 15:28:26 -0800

Glen Zorn wrote:
> I understand, & sympathize; I think that it's important to remember that a
> major reason that we ended up in the position of having multiple external
> SDOs defining their own mutually incompatible VSAs is that we (the IETF)
> refused to address RADIUS' problems in a useful and meaningful way.  We
have
> an opportunity now to ameliorate if not solve that problem; I don't think
> that we should pass it up.

  If we're going to re-design the attribute format from scratch again,
I'd like to know what we've accomplished in the past year.  

[gwz] I don't know where the "from scratch" comes from; there is a format
defined in
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00
.txt.  I am suggesting adding a single octet to the format which A) would
considerably enlarge the new type space and B) _could_ be used to
standardize functionality that has been added to RADIUS over the years in an
ad hoc fashion.
[/gwz]

There were
proposals that were ugly, but solved almost all of the concerns that
were raised.  This includes the ability to group legacy RADIUS
attributes in a "new" format.

  The one show-stopper I see is putting standard RADIUS attributes into
a VSA.  If this has *zero* impact on implementations that don't
understand the new format, then it would be acceptable.  Otherwise, it's
an incompatible change to RADIUS.

[gwz]
Interesting definition of "incompatible".  If that is in fact the standard
to be met we may as well just fold up our tents and go home since there is
_no_ change that could be made which would have "*zero* impact on
implementations that don't understand".
[/gwz]

  If we can't put standard attributes into the new format, then we
should just pick a better format, and ideally one that's been deployed.
 The WiMAX format (plus grouping) seems to fit that definition fairly well.

[gwz]
Can you tell us what it looks like?
[/gwz]

  Alan DeKok.

Delivery-date: Thu, 27 Dec 2007 19:01:14 +0000
Date: Thu, 27 Dec 2007 19:59:26 +0100
From: Alan DeKok <[email-masked]>
To: Greg Weber <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: RADEXT WG last call on RADIUS Design Guidelines Document

Greg Weber wrote:
> I went through the current RADIUS Guidelines doc and do not have any
> technical comments -one question and a couple minor editorial comments
> below.  I think the doc can be passed to IESG.

  Great!
> Question:  In the description of polymorphic attributes (sec 3.2), what 
> does this mean:  "...the meaning of an attribute may depend on earlier
> packets in a sequence."  ?   Is that referring to a request/challenge
> sequence?

  Yes.  Or, a series of otherwise unrelated Accounting-Requests.

  It's targeted at un-named SDO's and/or vendors who have horrid
practices for dealing with attributes.  Not just polymorphic attributes
in one packet (if A then it's type B, otherwise it's type C), but across
packets for *unrelated* sessions.

> Minor Editorial changes:
> Sec 1.1: "it's usage" -> "its usage"
> Sec 2.1.3: "to introduced" -> "to be introduced"
> Sec 2.1.3: "This issues" -> "These issues"
> Sec 2.1.3: "attributes involve authentication" -> "attributes involving
> authentication"
> Sec 2.1.3: I'd remove the "(e.g., IPv6 address)" from the last
> paragraph.  That's not
>   a good example anymore as we've earlier called IPv6 a basic data type
> in Sec 2.1.1.
> Sec 2.2: Last paragraph has the wrong indentation
> Sec 3.1.1: "vendors and SDOs they SHOULD" -> "vendors and SDOs SHOULD"
> Sec 3.1.3: Expand PEC acronym at first use?

  Already done in Section 2.2.

> Sec A.1.2: "not included nested groups" -> "not include nested groups"

  All other changes are good, thanks.

  Alan DeKok.

Delivery-date: Thu, 27 Dec 2007 18:42:24 +0000
Date: Thu, 27 Dec 2007 13:41:17 -0500
From: "Greg Weber" <[email-masked]>
To: [email-masked]
Subject: Re: RADEXT WG last call on RADIUS Design Guidelines Document
Cc: [email-masked]

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

I went through the current RADIUS Guidelines doc and do not have anytechnical
comments -one question and a couple minor editorial comments
below.  I think the doc can be passed to IESG.

Question:  In the description of polymorphic attributes (sec 3.2), what
does this mean:  "...the meaning of an attribute may depend on earlier
packets in a sequence."  ?   Is that referring to a request/challenge
sequence?

Minor Editorial changes:
Sec 1.1: "it's usage" -> "its usage"
Sec 2.1.3: "to introduced" -> "to be introduced"
Sec 2.1.3: "This issues" -> "These issues"
Sec 2.1.3: "attributes involve authentication" -> "attributes involving
authentication"
Sec 2.1.3: I'd remove the "(e.g., IPv6 address)" from the last paragraph.
 That's not
  a good example anymore as we've earlier called IPv6 a basic data type in
Sec 2.1.1.
Sec 2.2: Last paragraph has the wrong indentation
Sec 3.1.1: "vendors and SDOs they SHOULD" -> "vendors and SDOs SHOULD"
Sec 3.1.3: Expand PEC acronym at first use?
Sec A.1.2: "not included nested groups" -> "not include nested groups"

Greg

On Dec 26, 2007 12:53 PM, <[email-masked]> wrote:

>  This is an announcement of RADEXT WG last call on the
> "RADIUS Design Guidelines" document, prior to sending
> it to the IESG for publication as a Proposed
> Standard.  The document is available for inspection here:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt
>
> RADEXT WG last call will complete on January 15, 2008.  Please respond
> to this solicitation if you have read the document, regardless of whether
> you
> have comments to provide or not.  In your email, please state whether you
> believe that the document is ready for publication.
>
> If you have comments to provide, please send them to the
> RADEXT WG mailing list ([email-masked]),
> using the format described in the RADEXT Issues tracker:
> http://www.drizzle.com/~aboba/RADEXT/
>

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

<div><br class="webkit-block-placeholder"></div>I went through the current RADIUS Guidelines doc and do not have any<div>technical comments -one question and a couple minor editorial comments</div><div>below. &nbsp;I think the doc can be passed to IESG.
</div><div><br class="webkit-block-placeholder"></div><div>Question: &nbsp;In the description of polymorphic attributes (sec 3.2), what&nbsp;</div><div>does this mean: &nbsp;&quot;...the meaning of an attribute may depend on earlier</div>
<div>packets in a sequence.&quot; &nbsp;? &nbsp; Is that referring to a request/challenge sequence?</div><div><br class="webkit-block-placeholder"></div><div>Minor Editorial changes:</div><div>Sec 1.1: &quot;it&#39;s usage&quot; -&gt; &quot;its usage&quot;
</div><div>Sec 2.1.3: &quot;to introduced&quot; -&gt; &quot;to be introduced&quot;</div><div>Sec 2.1.3: &quot;This issues&quot; -&gt; &quot;These issues&quot;</div><div>Sec 2.1.3: &quot;attributes involve authentication&quot; -&gt; &quot;attributes involving authentication&quot;
</div><div>Sec 2.1.3: I&#39;d remove the &quot;(e.g., IPv6 address)&quot; from the last paragraph. &nbsp;That&#39;s not</div><div>&nbsp;&nbsp;a good example anymore as we&#39;ve earlier called IPv6 a basic data type in Sec 2.1.1.</div><div>
Sec 2.2: Last paragraph has the wrong indentation</div><div>Sec 3.1.1: &quot;vendors and SDOs they SHOULD&quot; -&gt; &quot;vendors and SDOs SHOULD&quot;</div><div>Sec 3.1.3: Expand PEC acronym at first use?</div><div>Sec 
A.1.2: &quot;not included nested groups&quot; -&gt; &quot;not include nested groups&quot;</div><div><br class="webkit-block-placeholder"></div><div>Greg</div><div><br><br><div class="gmail_quote">On Dec 26, 2007 12:53 PM,  &lt;
<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div style="padding-right:10px;padding-left:10px;padding-top:15px" bgcolor="#ffffff" name="Compose message area">
<div><font face="Arial" size="2">
<div><font face="Courier" size="3">This is an announcement of RADEXT WG last call on 
the </font></div>
<div><font face="Courier" size="3">&quot;RADIUS Design Guidelines&quot;&nbsp;document, prior 
to sending </font></div>
<div><font face="Courier" size="3">it to the IESG for publication as a Proposed 
</font></div>
<div><font face="Courier" size="3">Standard.&nbsp; The document is </font><font face="Courier" size="3">available for inspection here: <br></font><a title="http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt
CTRL + Click to follow link" href="http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt" rel="nofollow" target="_blank"><font title="http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt
CTRL + Click to follow link" face="Courier" size="3">http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt</font></a><br><br><font face="Courier" size="3">RADEXT WG last call will complete on January&nbsp;15, 
2008.&nbsp; Please respond</font></div>
<div><font face="Courier" size="3">to this solicitation if you have read the 
document, regardless of whether you</font></div>
<div><font face="Courier" size="3">have comments to provide or not.&nbsp; In your 
email, please state whether you </font></div>
<div><font face="Courier" size="3">believe that the document is ready for 
publication.&nbsp; </font></div>
<div><font face="Courier" size="3"></font>&nbsp;</div>
<div><font face="Courier" size="3">If you have comments to provide, please send them 
to the </font></div>
<div><font face="Courier" size="3">RADEXT WG mailing list (</font><a title="mailto:[email-masked]
CTRL + Click to follow link" href="mailto:[email-masked]" rel="nofollow" target="_blank"><font title="mailto:[email-masked]
CTRL + Click to follow link" face="Courier" size="3">[email-masked]</font></a><font face="Courier" size="3">), </font></div>
<div><font face="Courier" size="3">using the format described in the RADEXT Issues 
tracker:<br></font><a href="http://www.drizzle.com/~aboba/RADEXT/" rel="nofollow" target="_blank"><font title="http://www.drizzle.com/~aboba/RADEXT/
CTRL + Click to follow link" face="Courier" size="3">http://www.drizzle.com/~aboba/RADEXT/</font></a></div></font></div></div>
</blockquote></div><br></div>

------=_Part_17060_15529360.1198780877398--

Delivery-date: Thu, 27 Dec 2007 18:39:38 +0000
Date: Thu, 27 Dec 2007 19:38:00 +0100
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on "practical deployments"

David B. Nelson wrote:
> I'm surprised to hear that (IPsec usage).  Is this in selected topologies or
> deployment scenarios?  If IPsec were really used for most RADIUS
> transmissions, wouldn't we have already solved the Crypto-Agility problem?

  Most roaming providers and large companies do AAA interchange via IPSec.

  IPSec doesn't solve Crypto-Agility because there's no way for the
RADIUS server to discover, or enforce, authentication and encryption
policies.  The only security relationships between the two are
maintained in administrators heads, or in scripts tying the two systems
together.  Neither method is scalable, maintainable, or standardizable.

  Alan DeKok.

Delivery-date: Thu, 27 Dec 2007 18:37:53 +0000
Date: Thu, 27 Dec 2007 19:35:02 +0100
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on "practical deployments"

David B. Nelson wrote:
>>   If the only way to obtain network access is via EAP, then you have a
>> bootstrapping problem.  Once the users have signed up, everything is
>> great.  The users who *haven't* signed up are shut out.  Permanently.
> 
> So, this is really an enrollment issue, not an authentication issue?

  No.  Think of roaming, which I've been spending a lot of time on lately.

  If authentication is required for any IP-based network access, then
how do roaming users know that they can authenticate using the local
network?  Pre-provisioning devices with roaming knowledge doesn't scale,
and it doesn't handle dynamic networks.  802.11af doesn't scale either,
and isn't designed to scale.

  When the user doesn't have any network access, they can't determine
whether or not authentication is possible.  They can't determine which
authentication credentials to use.  So requiring authentication means
*forbidding* network access to a large class of users who could
*potentially* obtain network access.

  Alan DeKok.

Delivery-date: Thu, 27 Dec 2007 16:25:17 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Comments on "practical deployments"
Date: Thu, 27 Dec 2007 11:22:25 -0500
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

> Plus, most RADIUS interconnects are now done over Ipsec, which helps
> with the underlying reliability.

I'm surprised to hear that (IPsec usage).  Is this in selected topologies or
deployment scenarios?  If IPsec were really used for most RADIUS
transmissions, wouldn't we have already solved the Crypto-Agility problem?
:-)  

Delivery-date: Thu, 27 Dec 2007 16:21:46 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Comments on "practical deployments"
Date: Thu, 27 Dec 2007 11:18:10 -0500
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

>   A customer wants to buy access.  Right now in WiFi hotspots, they
> connect to a walled garden, and type in credit card details.  Once
> payment has been processed, they obtain network access.
> 
>   If the only way to obtain network access is via EAP, then you have a
> bootstrapping problem.  Once the users have signed up, everything is
> great.  The users who *haven't* signed up are shut out.  Permanently.

So, this is really an enrollment issue, not an authentication issue?

Delivery-date: Thu, 27 Dec 2007 10:26:17 +0000
Date: Thu, 27 Dec 2007 11:23:24 +0100
From: Alan DeKok <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: E2E and crypto-agility

[email-masked] wrote:
>>  What is "end to end" ?
> 
> I think it means something like "protection of RADIUS attributes from
> disclosure to parties other than the NAS and home server". 

  OK.  I just wanted to be sure.

> In the AAA WG there were a number of mechanisms investigated by
> which a NAS and home server could derive a key that could be
> used to protect attributes from disclosure to proxies.  These methods
> included Kerberos and CMS.  For example, see:
> http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt

  i.e. The NAS somehow knows a realm, knows how to talk to a server for
that realm, and can obtain a secret key for that realm.

> So I think the question is not "can it be done?" but rather "how does
> this relate to RADIUS crypto-agility?" and
> "should solving this problem be a requirement?"

  I would say that it is a problem we should try to solve.  I'm not sure
how much it affects crypto-agility.

  Back to my earlier question about "end to end", I think the only ends
that matter are the end user and home server.  The NAS is in contact
with both, and can leverage it's relationship with the end user to do
things that are normally impossible in RADIUS.   If we assume that the
end user and home RADIUS server can independently derive keying
material, then the server can supply keying material to the NAS, and the
end user can do the same.  The NAS can then derive keying material,
without it being exposed to anyone else.

  e.g. RADIUS, end-user: derive K', K''
       RADIUS -> NAS: E = ENC(K')         (using key K'')
       end-user -> NAS: K''

  If we assume that each RADIUS hop also encrypts E using the
Tunnel-Password method:

       T = tunnel_encrypt(per-hop-secret, E)

  Then we have the following properties:

  - no RADIUS proxy knows K' (they only know E)
  - The NAS can derive K' from E and K''
  - an attacker watching RADIUS only knows T
  - an attacker watching the end-user traffic only knows K''
  - an attacker watching *both* RADIUS and supplicant traffic knows
    T and K'', which is insufficient to derive K'
  - any intermediary RADIUS proxy that handles tunnel-password
    encryption can transport E.

  For EAP-TLS based methods, the TLS master session key can be used to
derive keying material.  We would need to define one new RADIUS
attribute to transport the keying material E, and update EAPoL to
transport K''.   This capability could be negotiated between the NAS and
supplicant, and advertised to the home RADIUS server by the supplicant,
inside of the TLS tunnel.

  So far as crypto-agility goes, this method needs to be extensible to
multiple key sizes, encryption methods, authentication hashes, etc.  But
it's independent of transport proposals such as DTLS or TLS.

  (insert standard disclaimer here: this proposal has not been vetted by
a crypto expert)

  Alan DeKok.

Delivery-date: Thu, 27 Dec 2007 05:49:09 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on modified Extended Attribute format?
Date: Wed, 26 Dec 2007 21:47:35 -0800
From: "Matt Holdrege" <[email-masked]>
To: "Glen Zorn" <[email-masked]>
Cc: <[email-masked]>, "Alan DeKok" <[email-masked]>

No kidding. I think my first RADIUS WG meeting was almost 12 years ago =
at IETF 35. Take a look at =
http://www3.ietf.org/proceedings/96mar/area.and.wg.reports/ops/radius/rad=
ius.html and read the minutes.

You might laugh at the irony, or more likely cry. Are the current AD's =
aware of the history here?

-Matt

-----Original Message-----
From: Glen Zorn [mailto:[email-masked]]=20
Sent: Wednesday, December 26, 2007 11:12 PM
To: Matt Holdrege
Cc: [email-masked]; 'Alan DeKok'
Subject: RE: Questions on modified Extended Attribute format?

Glen,

Didn't you say this same exact thing here a year or two ago? Or am I
stuck in a time warp? Or is this group stuck in a time warp?

[gwz] Plus =E7a change, plus c'est la m=EAme chose... [/gwz]

-Matt (I'll go back into my hole now)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Glen Zorn
Sent: Wednesday, December 26, 2007 9:06 PM
To: 'Alan DeKok'
Cc: [email-masked]
Subject: RE: Questions on modified Extended Attribute format?

[gwz]=20
I understand, & sympathize; I think that it's important to remember that
a
major reason that we ended up in the position of having multiple
external
SDOs defining their own mutually incompatible VSAs is that we (the IETF)
refused to address RADIUS' problems in a useful and meaningful way.  We
have
an opportunity now to ameliorate if not solve that problem; I don't
think
that we should pass it up.
[/gwz]

Delivery-date: Thu, 27 Dec 2007 04:54:03 +0000
Date: Thu, 27 Dec 2007 05:52:19 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on "practical deployments"

Bernard Aboba wrote:
> It will be interesting to see how well it works.  I have previously been
> involved in a number of
> inter-domain roaming trials.  When the RADIUS traffic was routed through
> an exchange point,
> the results were not very promising.  With packet loss rates of 1-5%,

  I'll track the tests, and see if we can do some measurements under load.

  For existing (non-EAP) proxies, I don't recall seeing loss rates that
high.  I'll go check, but I think latencies and loss have decreased,
while bandwidth has increased in the net.  Plus, most RADIUS
interconnects are now done over Ipsec, which helps with the underlying
reliability.

> RADIUS retransmissions
> were pretty common and this would often lead to EAP retransmissions. 
> The overall
> authentication times could get pretty long and sometimes authentication
> wouldn't complete
> at all.  Most of the carriers we worked with ended up deploying web
> portals instead :(

  WiMAX is standardizing on EAP for authentication.  Discussions are
underway to design a standard interconnect architecture.  So this
appears to be less of a problem now.

  Alan DeKok.

Delivery-date: Thu, 27 Dec 2007 04:50:23 +0000
Date: Thu, 27 Dec 2007 05:48:29 +0100
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: [email-masked]
Subject: Re: Questions on modified Extended Attribute format?

Glen Zorn wrote:
> I understand, & sympathize; I think that it's important to remember that a
> major reason that we ended up in the position of having multiple external
> SDOs defining their own mutually incompatible VSAs is that we (the IETF)
> refused to address RADIUS' problems in a useful and meaningful way.  We have
> an opportunity now to ameliorate if not solve that problem; I don't think
> that we should pass it up.

  If we're going to re-design the attribute format from scratch again,
I'd like to know what we've accomplished in the past year.  There were
proposals that were ugly, but solved almost all of the concerns that
were raised.  This includes the ability to group legacy RADIUS
attributes in a "new" format.

  The one show-stopper I see is putting standard RADIUS attributes into
a VSA.  If this has *zero* impact on implementations that don't
understand the new format, then it would be acceptable.  Otherwise, it's
an incompatible change to RADIUS.

  If we can't put standard attributes into the new format, then we
should just pick a better format, and ideally one that's been deployed.
 The WiMAX format (plus grouping) seems to fit that definition fairly well.

  Alan DeKok.

Delivery-date: Thu, 27 Dec 2007 04:46:15 +0000
Date: Thu, 27 Dec 2007 05:43:51 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on "practical deployments"

Bernard Aboba wrote:
> Is this the Fixed Mobile Covergence Alliance? 

  Yes.  I've been advising on the interconnect.

>> Yes. In fact, the use of EAP *prevents* a large number of business
>> models for network access.
> 
> Could you expand on the problems?

  A customer wants to buy access.  Right now in WiFi hotspots, they
connect to a walled garden, and type in credit card details.  Once
payment has been processed, they obtain network access.

  If the only way to obtain network access is via EAP, then you have a
bootstrapping problem.  Once the users have signed up, everything is
great.  The users who *haven't* signed up are shut out.  Permanently.

  The issue is less EAP than EAPoL.  Without a real network connection,
it's impossible for a client machine to do much of anything.  EAP could
be used in a walled garden if PANA was widely deployed, for example.

  Alan DeKok.

Delivery-date: Thu, 27 Dec 2007 03:00:21 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Questions on modified Extended Attribute format?
Date: Wed, 26 Dec 2007 21:58:54 -0500

Bernard Aboba writes...
 
> >  WiMAX uses the same attribute format as proposed here.  Changes that
> > are incompatible with WiMAX should be discouraged.
> 
> I would agree.   If the extensions remain compatible with WiMAX then
> the amount of code duplication will be minimized.

I'm not so sure that I agree.  We should do what's right for the RADIUS
community.  If that happens to be compatible with WiMAX, then great.

Delivery-date: Wed, 26 Dec 2007 22:13:40 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Matt Holdrege'" <[email-masked]>
Cc: <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Subject: RE: Questions on modified Extended Attribute format?
Date: Wed, 26 Dec 2007 14:12:11 -0800

Glen,

Didn't you say this same exact thing here a year or two ago? Or am I
stuck in a time warp? Or is this group stuck in a time warp?

[gwz] Plus =E7a change, plus c'est la m=EAme chose... [/gwz]

-Matt (I'll go back into my hole now)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Glen Zorn
Sent: Wednesday, December 26, 2007 9:06 PM
To: 'Alan DeKok'
Cc: [email-masked]
Subject: RE: Questions on modified Extended Attribute format?

[gwz]=20
I understand, & sympathize; I think that it's important to remember that
a
major reason that we ended up in the position of having multiple
external
SDOs defining their own mutually incompatible VSAs is that we (the IETF)
refused to address RADIUS' problems in a useful and meaningful way.  We
have
an opportunity now to ameliorate if not solve that problem; I don't
think
that we should pass it up.
[/gwz]

Delivery-date: Wed, 26 Dec 2007 20:52:17 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on modified Extended Attribute format?
Date: Wed, 26 Dec 2007 12:51:25 -0800
From: "Matt Holdrege" <[email-masked]>
To: "Glen Zorn" <[email-masked]>, "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

Glen,

Didn't you say this same exact thing here a year or two ago? Or am I
stuck in a time warp? Or is this group stuck in a time warp?

-Matt (I'll go back into my hole now)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Glen Zorn
Sent: Wednesday, December 26, 2007 9:06 PM
To: 'Alan DeKok'
Cc: [email-masked]
Subject: RE: Questions on modified Extended Attribute format?

[gwz]=20
I understand, & sympathize; I think that it's important to remember that
a
major reason that we ended up in the position of having multiple
external
SDOs defining their own mutually incompatible VSAs is that we (the IETF)
refused to address RADIUS' problems in a useful and meaningful way.  We
have
an opportunity now to ameliorate if not solve that problem; I don't
think
that we should pass it up.
[/gwz]

Delivery-date: Wed, 26 Dec 2007 20:35:34 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on "practical deployments"
Date: Wed, 26 Dec 2007 21:34:24 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi,

> > > While proxies are widely used today to facilitate inter-domain=20
> > > roaming, as far as I know, the combination of=20
> inter-domain roaming=20
> > > and EAP is very rare.

GSMA trialed (with a number of hotspot & GSM operators mainly in
Europe & Asia) EAP-based 802.11 roaming few years ago. This concentrated
mainly on EAP-SIM and EAP-AKA.

> > The FMCA is trialling exactly this.
>=20
> Is this the Fixed Mobile Covergence Alliance? =20

Yes.

[snip]

> >> For example, the vast majority of all IEEE 802.11 hotspot=20
> deployments=20
> >> use Web-based access (e.g. UAM), not EAP.
> >=20
> > Yes. In fact, the use of EAP *prevents* a large number of business=20
> > models for network access.
>=20
> Could you expand on the problems?
>=20
> > UMA leverages EAP and RADIUS, but it's buried deep in the network.
>=20
> Yup.  Doesn't seem like this would require inter-domain proxies.

In the existing specs for 3GPP GAN (i.e. the current UMA) inter-operator
roaming is defined and reuses in a carbon-copy fashion 3GPP Interworking
WLAN EAP-based RADIUS roaming interface. However, operator business
models typically do not favor deployments where GAN would need
inter-operator
RADIUS interface.. at least I am not aware of any such deployments.

Jouni

>=20
>=20

Delivery-date: Wed, 26 Dec 2007 20:18:32 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: <[email-masked]>
Subject: RE: Comments on "practical deployments"
Date: Wed, 26 Dec 2007 12:18:16 -0800

--_6dd47e72-f355-459e-9cd1-8663ebd42293_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> The FMCA is trialling exactly this.=20

It will be interesting to see how well it works.  I have previously been in=
volved in a number of=20
inter-domain roaming trials.  When the RADIUS traffic was routed through an=
 exchange point,
the results were not very promising.  With packet loss rates of 1-5%, RADIU=
S retransmissions
were pretty common and this would often lead to EAP retransmissions.  The o=
verall
authentication times could get pretty long and sometimes authentication wou=
ldn't complete
at all.  Most of the carriers we worked with ended up deploying web portals=
 instead :(

--_6dd47e72-f355-459e-9cd1-8663ebd42293_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
&gt; The FMCA is trialling exactly this. <br><br>It will be interesting to =
see how well it works.&nbsp; I have previously been involved in a number of=
 <br>inter-domain roaming trials.&nbsp; When the RADIUS traffic was routed =
through an exchange point,<br>the results were not very promising.&nbsp; Wi=
th packet loss rates of 1-5%, RADIUS retransmissions<br>were pretty common =
and this would often lead to EAP retransmissions.&nbsp; The overall<br>auth=
entication times could get pretty long and sometimes authentication wouldn'=
t complete<br>at all.&nbsp; Most of the carriers we worked with ended up de=
ploying web portals instead :(<br></body>
</html>=

--_6dd47e72-f355-459e-9cd1-8663ebd42293_--

Delivery-date: Wed, 26 Dec 2007 20:11:37 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Questions on modified Extended Attribute format?
Date: Wed, 26 Dec 2007 12:10:32 -0800

> If we're suddenly worried about the size of code for processing VSAs, it
> would seem to make much more sense to be compatible with cisco's VSAs
since
> they are far more widely deployed than WiMax's (and probably always will
> be).

  Yes... but strings?  Really?

[gwz] 
I know, but the point stands, no?
[/gwz]

> I'm not suggesting anything of the sort: the capabilities for sending
large
> attributes & grouping them already exist (although in limited ways); I'm
> talking about standardizing these existing capabilies, not adding new
ones.

  If we can get the functionality of the new extended attributes applied
to legacy RADIUS, I'm all for it.  But I don't want it to be a lot of
work... that causes bugs and interoperability issues.

  My preferences are to leave the extended attributes defined the way
they are right now.  Anything else starts to cause issues.

  e.g. legacy attributes encapsulated in a VSA.... what happens with
legacy implementations?  The only image that comes to mind is a cloud
going *boom*.

[gwz] 
;-)  Not sure why, though -- they would be easily identified & it seems like
the code we're talking about should already exist (that's why we chose these
rather modest techniques in the first place, right?).
[/gwz]

  Alan DeKok.

Delivery-date: Wed, 26 Dec 2007 20:07:22 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Questions on modified Extended Attribute format?
Date: Wed, 26 Dec 2007 12:06:25 -0800

> I'm not at all sure why that would be the case; I don't recall the IETF
> bending over backwards to be compatible w/anyone else's VSAs...

  The last thing I need right now is yet another incompatible VSA format.
[gwz] 
I understand, & sympathize; I think that it's important to remember that a
major reason that we ended up in the position of having multiple external
SDOs defining their own mutually incompatible VSAs is that we (the IETF)
refused to address RADIUS' problems in a useful and meaningful way.  We have
an opportunity now to ameliorate if not solve that problem; I don't think
that we should pass it up.
[/gwz]

...

Delivery-date: Wed, 26 Dec 2007 20:05:37 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: <[email-masked]>
Subject: RE: Comments on "practical deployments"
Date: Wed, 26 Dec 2007 12:05:16 -0800

--_79d372da-1d12-4de7-b820-a264809dd28f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> > While proxies are widely used today to facilitate inter-domain
> > roaming, as far as I know, the combination of inter-domain roaming
> > and EAP is very rare.
>=20
>   The FMCA is trialling exactly this.

Is this the Fixed Mobile Covergence Alliance? =20

(This seemed the most likely of the expansions provided by Google, the othe=
rs being:

Family Motor Coach Association
Florida Mosquito Control Association
Florida Marine Contractors Association
Friends of Montgomery County Animals)

>> For example, the vast majority of all
>> IEEE 802.11 hotspot deployments use Web-based access (e.g. UAM), not EAP=
.
>=20
>   Yes.  In fact, the use of EAP *prevents* a large number of business
> models for network access.

Could you expand on the problems?

>   UMA leverages EAP and RADIUS, but it's buried deep in the network.

Yup.  Doesn't seem like this would require inter-domain proxies.

--_79d372da-1d12-4de7-b820-a264809dd28f_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
&gt; &gt; While proxies are widely used today to facilitate inter-domain<br=
>&gt; &gt; roaming, as far as I know, the combination of inter-domain roami=
ng<br>&gt; &gt; and EAP is very rare.<br>&gt; <br>&gt;   The FMCA is triall=
ing exactly this.<br><br>Is this the Fixed Mobile Covergence Alliance?&nbsp=
; <br><br>(This seemed the most likely of the expansions provided by Google=
, the others being:<br><br>Family Motor Coach Association<br>Florida Mosqui=
to Control Association<br>Florida Marine Contractors Association<br>Friends=
 of Montgomery County Animals)<br><br>&gt;&gt; For example, the vast majori=
ty of all<br>&gt;&gt; IEEE 802.11 hotspot deployments use Web-based access =
(e.g. UAM), not EAP.<br>&gt; <br>&gt;   Yes.  In fact, the use of EAP *prev=
ents* a large number of business<br>&gt; models for network access.<br><br>=
Could you expand on the problems?<br><br>&gt;   UMA leverages EAP and RADIU=
S, but it's buried deep in the network.<br><br>Yup.&nbsp; Doesn't seem like=
 this would require inter-domain proxies.<br></body>
</html>=

--_79d372da-1d12-4de7-b820-a264809dd28f_--

Delivery-date: Wed, 26 Dec 2007 19:54:27 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: RADEXT WG last call on RADIUS Attributes for Filtering and Redirection
Date: Wed, 26 Dec 2007 11:53:16 -0800

--_52ab49c8-2d30-4f2d-a476-48f4b20945a4_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On July 5, 2007 the RADEXT WG first began WG last call on "RADIUS Attribute=
s for=20
Filtering and Redirection":
http://ops.ietf.org/lists/radiusext/2007/msg00494.html
http://ops.ietf.org/lists/radiusext/2007/msg00541.html

This WG last call was to last until Monday, July 23, 2007.
During the WG last call, only a single comment was received, from Hannes=20
Tschofenig:
http://ops.ietf.org/lists/radiusext/2007/msg00496.html

No other messages were posted to the RADEXT WG mailing list indicating that=
=20
WG participants had read the document.

Given the light level of participation, the WG last=20
call was extended for 10 more days (until August 28, 2007):
http://ops.ietf.org/lists/radiusext/2007/msg00633.html

No comments were received during that WG last call either.

Given that no comments have been received during the last two RADEXT WG las=
t calls, we are going to bring the document to RADEXT WG call again.  This =
RADEXT WG last call will last until January 15, 2008.=20

If you have read the=20
document and approve of its publication as a Proposed Standard, please post=
=20
your approval to the list, even if you have no comments to provide.
If you have comments, please provide them in the format described on the=20
RADEXT WG Issues page:
http://www.drizzle.com/~aboba/RADEXT/

--_52ab49c8-2d30-4f2d-a476-48f4b20945a4_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
<tt>On July 5, 2007 the RADEXT WG first began WG last call on "RADIUS Attri=
butes for=20
</tt><tt>Filtering and Redirection":
</tt><pre style=3D"margin: 0em;"><a rel=3D"nofollow" href=3D"http://ops.iet=
f.org/lists/radiusext/2007/msg00494.html">http://ops.ietf.org/lists/radiuse=
xt/2007/msg00494.html</a><br><a rel=3D"nofollow" href=3D"http://ops.ietf.or=
g/lists/radiusext/2007/msg00541.html">http://ops.ietf.org/lists/radiusext/2=
007/msg00541.html</a><br><br>This WG last call was to last until Monday, Ju=
ly 23, 2007.<br></pre><tt>During the WG last call, only a single comment wa=
s received, from Hannes=20
</tt><tt>Tschofenig:
</tt><pre style=3D"margin: 0em;"><a rel=3D"nofollow" href=3D"http://ops.iet=
f.org/lists/radiusext/2007/msg00496.html">http://ops.ietf.org/lists/radiuse=
xt/2007/msg00496.html</a><br><tt><br>No other messages were posted to the R=
ADEXT WG mailing list indicating that=20
</tt>WG participants had read the document.
<br></pre><tt><br></tt><tt>Given the light level of participation, the WG l=
ast=20
</tt><tt>call was extended for 10 more days (until August 28, 2007):<br>htt=
p://ops.ietf.org/lists/radiusext/2007/msg00633.html<br><br>No comments were=
 received during that WG last call either.<br><br>Given that no comments ha=
ve been received during the last two RADEXT WG last calls, we are going to =
bring the document to RADEXT WG call again.&nbsp; This RADEXT WG last call =
will last until January 15, 2008. <br><br>If you have read the=20
</tt><tt>document and approve of its publication as a Proposed Standard, pl=
ease post=20
</tt><tt>your approval to the list, even if you have no comments to provide=
.
</tt><tt>If you have comments, please provide them in the format described =
on the=20
</tt><tt>RADEXT WG Issues page:
</tt><pre style=3D"margin: 0em;"><a rel=3D"nofollow" href=3D"http://www.dri=
zzle.com/%7Eaboba/RADEXT/">http://www.drizzle.com/~aboba/RADEXT/</a>
</pre></body>
</html>=

--_52ab49c8-2d30-4f2d-a476-48f4b20945a4_--

Delivery-date: Wed, 26 Dec 2007 19:34:06 +0000
Date: Wed, 26 Dec 2007 20:31:25 +0100
From: Alan DeKok <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Comments on "practical deployments"

[email-masked] wrote:
>>  problems in practical deployments.
> 
> Which "practical deployments" are we talking about?

  RADIUS proxies.  There are multiple inter-telco && inter-country
deployments using RADIUS.  I'm not aware of any similar large-scale
deployment of Diameter.  (i.e. everyone I've talked to says "perhaps one
day we'll move to Diameter".)

> While proxies are widely used today to facilitate inter-domain
> roaming, as far as I know, the combination of inter-domain roaming
> and EAP is very rare.

  The FMCA is trialling exactly this.

> While EAP-based technologies such as WiMAX may change the
> situation, as I understand it, the use of EAP today is largely confined
> to enterprise scenarios.    For example, the vast majority of all
> IEEE 802.11 hotspot deployments use Web-based access (e.g. UAM), not EAP.

  Yes.  In fact, the use of EAP *prevents* a large number of business
models for network access.

> In terms of major EAP deployments that support inter-domain roaming
> with substantial usage, one deployment (EDUROAM) is several orders of
> magnitude larger than any other that I am aware of.

  UMA leverages EAP and RADIUS, but it's buried deep in the network.

> As far as I know, EDUROAM does not use Diameter nor are there any
> major deployments of Diameter EAP.

  Yes.

> Am I missing something, or are there really any "practical experience"
> here?

  Practical experience with existing AAA servers, proxies, and business
models.  The current technology is RADIUS.  I'm trying to figure out how
 AAA redirection (and avoiding the intermediary proxies) helps anyone.
I don't think it does.

  Alan DeKok.

Delivery-date: Wed, 26 Dec 2007 19:17:21 +0000
Date: Wed, 26 Dec 2007 20:15:14 +0100
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Questions on modified Extended Attribute format?

Glen Zorn wrote:
> If we're suddenly worried about the size of code for processing VSAs, it
> would seem to make much more sense to be compatible with cisco's VSAs since
> they are far more widely deployed than WiMax's (and probably always will
> be).

  Yes... but strings?  Really?

> I'm not suggesting anything of the sort: the capabilities for sending large
> attributes & grouping them already exist (although in limited ways); I'm
> talking about standardizing these existing capabilies, not adding new ones.

  If we can get the functionality of the new extended attributes applied
to legacy RADIUS, I'm all for it.  But I don't want it to be a lot of
work... that causes bugs and interoperability issues.

  My preferences are to leave the extended attributes defined the way
they are right now.  Anything else starts to cause issues.

  e.g. legacy attributes encapsulated in a VSA.... what happens with
legacy implementations?  The only image that comes to mind is a cloud
going *boom*.

  Alan DeKok.

Delivery-date: Wed, 26 Dec 2007 19:13:14 +0000
Date: Wed, 26 Dec 2007 20:10:57 +0100
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: [email-masked]
Subject: Re: Questions on modified Extended Attribute format?

Glen Zorn wrote:
> I'm not at all sure why that would be the case; I don't recall the IETF
> bending over backwards to be compatible w/anyone else's VSAs...

  The last thing I need right now is yet another incompatible VSA format.

> 0x100, that would seem to solve a couple of problems nicely.

  I understand... I'm not sure I completely agree.

>   One question: If we DO permit this for legacy RADIUS attributes, what
> does the "C" bit mean?  Do we use the WiMAX method for splitting
> attributes encrypted with the "Tunnel-Password" method?
> [gwz] 
> I don't know what method that is, but I'm not sure why those attributes
> would be treated differently than others. 
> [/gwz]

  Neither am I.  But they are.

  Alan DeKok.

Delivery-date: Wed, 26 Dec 2007 18:52:54 +0000
From: <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>
Subject: Re: Comments on "practical deployments"
Date: Wed, 26 Dec 2007 10:52:31 -0800

>  problems in practical deployments.

Which "practical deployments" are we talking about?

While proxies are widely used today to facilitate inter-domain
roaming, as far as I know, the combination of inter-domain roaming
and EAP is very rare.

While EAP-based technologies such as WiMAX may change the
situation, as I understand it, the use of EAP today is largely confined
to enterprise scenarios.    For example, the vast majority of all
IEEE 802.11 hotspot deployments use Web-based access (e.g. UAM), not EAP.

In terms of major EAP deployments that support inter-domain roaming
with substantial usage, one deployment (EDUROAM) is several orders of
magnitude larger than any other that I am aware of.

As far as I know, EDUROAM does not use Diameter nor are there any
major deployments of Diameter EAP.

Am I missing something, or are there really any "practical experience" 
here?

Delivery-date: Wed, 26 Dec 2007 18:43:55 +0000
From: <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>
Subject: Re: E2E and crypto-agility
Date: Wed, 26 Dec 2007 10:42:20 -0800

>  What is "end to end" ?

I think it means something like "protection of RADIUS attributes from
disclosure to parties other than the NAS and home server".  

>  I don't see how we could do NAS to home server key transport in
> RADIUS.  So the answer is (I think) "No".  

In the AAA WG there were a number of mechanisms investigated by
which a NAS and home server could derive a key that could be
used to protect attributes from disclosure to proxies.  These methods
included Kerberos and CMS.  For example, see:
http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt

So I think the question is not "can it be done?" but rather 
"how does this relate to RADIUS crypto-agility?" and
"should solving this problem be a requirement?"

 

Delivery-date: Wed, 26 Dec 2007 18:17:37 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Questions on modified Extended Attribute format?
Date: Wed, 26 Dec 2007 10:16:28 -0800

>  WiMAX uses the same attribute format as proposed here.  Changes that
> are incompatible with WiMAX should be discouraged.

I would agree.   If the extensions remain compatible with WiMAX then
the amount of code duplication will be minimized.

[gwz] 
If we're suddenly worried about the size of code for processing VSAs, it
would seem to make much more sense to be compatible with cisco's VSAs since
they are far more widely deployed than WiMax's (and probably always will
be).
[/gwz]

>  If it's just stealing a bit (which WiMAX doesn't use), that sounds
> fine.  The ability to group legacy RADIUS attributes via a method other
> than tags would be good.
>
>  One question: If we DO permit this for legacy RADIUS attributes, what
> does the "C" bit mean?  Do we use the WiMAX method for splitting
> attributes encrypted with the "Tunnel-Password" method?

We need to be careful about feature creep here.  The original purpose of
the Extended Attributes document was to extend the RADIUS attribute space.

If the document is now taking on new problems (extending capabilities of the
RADIUS protocol or changing the semantics of existing attributes) then that
problem needs to be clearly stated, and justification needs to be provided. 

[gwz] 
I'm not suggesting anything of the sort: the capabilities for sending large
attributes & grouping them already exist (although in limited ways); I'm
talking about standardizing these existing capabilies, not adding new ones.
[/gwz]

Delivery-date: Wed, 26 Dec 2007 18:01:48 +0000
From: <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Glen Zorn" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Questions on modified Extended Attribute format?
Date: Wed, 26 Dec 2007 10:01:26 -0800

 >  WiMAX uses the same attribute format as proposed here.  Changes that
> are incompatible with WiMAX should be discouraged.

I would agree.   If the extensions remain compatible with WiMAX then
the amount of code duplication will be minimized.

>  If it's just stealing a bit (which WiMAX doesn't use), that sounds
> fine.  The ability to group legacy RADIUS attributes via a method other
> than tags would be good.
>
>  One question: If we DO permit this for legacy RADIUS attributes, what
> does the "C" bit mean?  Do we use the WiMAX method for splitting
> attributes encrypted with the "Tunnel-Password" method?

We need to be careful about feature creep here.  The original purpose of
the Extended Attributes document was to extend the RADIUS attribute space.

If the document is now taking on new problems (extending capabilities of the
RADIUS protocol or changing the semantics of existing attributes) then that
problem needs to be clearly stated, and justification needs to be provided. 

Delivery-date: Wed, 26 Dec 2007 18:00:52 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [ Comments on  automated key management and crypto agility
Date: Wed, 26 Dec 2007 09:59:23 -0800

...

  redirects have problems in practical deployments.  Intermediate nodes
often exist for commercial reasons, both for business relationships and
for application of intermediary policies.

[gwz] 
And, unfortunately, that's just scratching the surface; how that lame scheme
got into an RFC I'll never know... 
[/gwz]

  Alan DeKok.

Delivery-date: Wed, 26 Dec 2007 17:54:11 +0000
From: <[email-masked]>
To: <[email-masked]>
Subject: RADEXT WG last call on RADIUS Design Guidelines Document
Date: Wed, 26 Dec 2007 09:53:05 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_00CC_01C847A5.1CCD6D60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is an announcement of RADEXT WG last call on the=20
"RADIUS Design Guidelines" document, prior to sending=20
it to the IESG for publication as a Proposed=20
Standard.  The document is available for inspection here:=20
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt

RADEXT WG last call will complete on January 15, 2008.  Please respond
to this solicitation if you have read the document, regardless of =
whether you
have comments to provide or not.  In your email, please state whether =
you=20
believe that the document is ready for publication. =20

If you have comments to provide, please send them to the=20
RADEXT WG mailing list ([email-masked]),=20
using the format described in the RADEXT Issues tracker:
http://www.drizzle.com/~aboba/RADEXT/
------=_NextPart_000_00CC_01C847A5.1CCD6D60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3Diso-8859-1>
<META content=3D"MSHTML 6.00.6000.16546" name=3DGENERATOR></HEAD>
<BODY id=3DMailContainerBody=20
style=3D"PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-TOP: 15px"=20
bgColor=3D#ffffff leftMargin=3D0 topMargin=3D0 CanvasTabStop=3D"true"=20
name=3D"Compose message area">
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DCourier size=3D3>This is an announcement of RADEXT WG =
last call on=20
the </FONT></DIV>
<DIV><FONT face=3DCourier size=3D3>"RADIUS Design =
Guidelines"&nbsp;document, prior=20
to sending </FONT></DIV>
<DIV><FONT face=3DCourier size=3D3>it to the IESG for publication as a =
Proposed=20
</FONT></DIV>
<DIV><FONT face=3DCourier size=3D3>Standard.&nbsp; The document is =
</FONT><FONT=20
face=3DCourier size=3D3>available for inspection here: <BR></FONT><A=20
title=3D"http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.=
txt&#10;CTRL + Click to follow link"=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.t=
xt"=20
rel=3Dnofollow><FONT=20
title=3D"http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.=
txt&#10;CTRL + Click to follow link"=20
face=3DCourier=20
size=3D3>http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.=
txt</FONT></A><BR><BR><FONT=20
face=3DCourier size=3D3>RADEXT WG last call will complete on =
January&nbsp;15,=20
2008.&nbsp; Please respond</FONT></DIV>
<DIV><FONT face=3DCourier size=3D3>to this solicitation if you have read =
the=20
document, regardless of whether you</FONT></DIV>
<DIV><FONT face=3DCourier size=3D3>have comments to provide or =
not.&nbsp; In your=20
email, please state whether you </FONT></DIV>
<DIV><FONT face=3DCourier size=3D3>believe that the document is ready =
for=20
publication.&nbsp; </FONT></DIV>
<DIV><FONT face=3DCourier size=3D3></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D3>If you have comments to provide, =
please send them=20
to the </FONT></DIV>
<DIV><FONT face=3DCourier size=3D3>RADEXT WG mailing list (</FONT><A=20
title=3D"mailto:[email-masked]&#10;CTRL + Click to follow link"=20
href=3D"mailto:[email-masked]" rel=3Dnofollow><FONT=20
title=3D"mailto:[email-masked]&#10;CTRL + Click to follow link"=20
face=3DCourier size=3D3>[email-masked]</FONT></A><FONT =
face=3DCourier=20
size=3D3>), </FONT></DIV>
<DIV><FONT face=3DCourier size=3D3>using the format described in the =
RADEXT Issues=20
tracker:<BR></FONT><A href=3D"http://www.drizzle.com/~aboba/RADEXT/"=20
rel=3Dnofollow><FONT=20
title=3D"http://www.drizzle.com/~aboba/RADEXT/&#10;CTRL + Click to =
follow link"=20
face=3DCourier=20
size=3D3>http://www.drizzle.com/~aboba/RADEXT/</FONT></A></DIV></FONT></D=
IV></BODY></HTML>

------=_NextPart_000_00CC_01C847A5.1CCD6D60--

Delivery-date: Wed, 26 Dec 2007 17:53:54 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Questions on modified Extended Attribute format?
Date: Wed, 26 Dec 2007 09:52:47 -0800

Glen Zorn wrote:
> During the meeting last week, I thought that there were a couple of
> questions/comments on Jabber regarding the changes that I proposed to
> the extended attribute format (adding a bit to distinguish between new
> TLVs and legacy RADIUS attributes in extended attributes) but I didn't
> quite catch them.  Would those who presented those remarks mind
> repeating them in email?  TIA.

  WiMAX uses the same attribute format as proposed here.  Changes that
are incompatible with WiMAX should be discouraged.
[gwz] 
I'm not at all sure why that would be the case; I don't recall the IETF
bending over backwards to be compatible w/anyone else's VSAs...
[/gwz]

  If it's just stealing a bit (which WiMAX doesn't use), that sounds
fine.  The ability to group legacy RADIUS attributes via a method other
than tags would be good.
[gwz] 
Actually, I've convinced myself that a) this idea was not quite baked & b) I
was wrong about making the Ext-Type field just one octet.  If we make the
Ext-Type field 16 bits in length _and_ start numbering the new attributes at
0x100, that would seem to solve a couple of problems nicely.
[/gwz]

  One question: If we DO permit this for legacy RADIUS attributes, what
does the "C" bit mean?  Do we use the WiMAX method for splitting
attributes encrypted with the "Tunnel-Password" method?
[gwz] 
I don't know what method that is, but I'm not sure why those attributes
would be treated differently than others. 
[/gwz]

  Alan DeKok.

Delivery-date: Wed, 26 Dec 2007 17:51:15 +0000
Date: Wed, 26 Dec 2007 18:49:08 +0100
From: Alan DeKok <[email-masked]>
To: [email-masked]
Subject: Re: [ Comments on  automated key management and crypto agility

Bernard Aboba wrote:
> However, this is logically separate from the need to provide end-to-end
> protection for key transport.

  What is "end to end" ?

  Not to be dumb, but there are a number of parties involved:

  supplicant (or end user software)
  NAS (or AP)
  local RADIUS server
  intermediate proxies (0 or more)
  home RADIUS server (may be the same as the local RADIUS server)

  Which ends are we talking about?  The EAP-TLS methods allow the
supplicant and home server to agree on a key.  So any "end to end"
problem would appear to be getting keying material from the supplicant
OR home server to the NAS, without exposing that material to any local
server, or proxy server.

> So far, the need to solve the end-to-end key transport problem has not
> been part of RADIUS
> crypto-agility requirements.  Should it be?

  I don't see how we could do NAS to home server key transport in
RADIUS.  So the answer is (I think) "No".  Any end-to-end key transport
should involve EAP-TLS methods *and* RADIUS, I think.  Just doing it in
one or the other wouldn't work.

  If we tried to do it in RADIUS, we would end up with something that
looked nothing like RADIUS.

> With Diameter, it was clear that the IESG expected a solution to both
> problems -- ciphersuite
> negotiation (via TLS/IKE) as well as a mechanism for avoiding key
> disclosure to proxies
> (e.g. redirect).

  redirects have problems in practical deployments.  Intermediate nodes
often exist for commercial reasons, both for business relationships and
for application of intermediary policies.

  Alan DeKok.

Delivery-date: Wed, 26 Dec 2007 17:36:35 +0000
Date: Wed, 26 Dec 2007 18:33:56 +0100
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: [email-masked]
Subject: Re: Questions on modified Extended Attribute format?

Glen Zorn wrote:
> During the meeting last week, I thought that there were a couple of
> questions/comments on Jabber regarding the changes that I proposed to
> the extended attribute format (adding a bit to distinguish between new
> TLVs and legacy RADIUS attributes in extended attributes) but I didn't
> quite catch them.  Would those who presented those remarks mind
> repeating them in email?  TIA.

  WiMAX uses the same attribute format as proposed here.  Changes that
are incompatible with WiMAX should be discouraged.

  If it's just stealing a bit (which WiMAX doesn't use), that sounds
fine.  The ability to group legacy RADIUS attributes via a method other
than tags would be good.

  One question: If we DO permit this for legacy RADIUS attributes, what
does the "C" bit mean?  Do we use the WiMAX method for splitting
attributes encrypted with the "Tunnel-Password" method?

  Alan DeKok.

Delivery-date: Sun, 23 Dec 2007 09:08:19 +0000
From: Mike McCauley <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: AUTH48 [SG]: RFC 5090  <draft-ietf-radext-rfc4590bis-02.txt> NOW AVAILABLE
Date: Sun, 23 Dec 2007 19:07:08 +1000
Cc: [email-masked]

Hello Bernard,

On Sunday 23 December 2007 17:47, Bernard Aboba wrote:
> The test vectors in Section 6 are one of the major open questions. 
> Wolfgang did the original checks, but subsequent reviewers kept finding
> errors in them, so they have been revised several times.
>
> What do you think is wrong with the B->C messages?

I havent been able to reproduce the Digest-Response that is given the 2 
samples in the RFC.
I have some sample code that produces the correct digest result as given in 
RFC2617, but that same code gives Digest-Response different to that given in 
RFC5090 in both examples.

Here is some sample code, FYI, in perl. You can see that its set up to test 
against either RFC2617 test data or RFC5090. The response it calculates for 
the RFC5090 test data is not the one given in the RFC

use Digest::MD5;
use strict;

# RFC5090 web browser (second example)
# FAILS
#my $username = '12345678';
#my $realm    = 'example.com';
#my $qop      = 'auth';
#my $nonce    = 'a3086ac8';
#my $cnonce   = '56593a80';
#my $nc       = '00000001';
#my $pw       = 'secret';
#my $method   = 'GET';
#my $uri      = '/index.html';
#my $expected = 'ba623217b5ec024d30c4aaef9d8494de';

# RFC2617 OK:
my $username = 'Mufasa';
my $realm    = [email-masked]';
my $qop      = 'auth';
my $nonce    = 'dcd98b7102dd2f0e8b11d0f600bfb0c093';
my $cnonce   = '0a4f113b';
my $nc       = '00000001';
my $pw       = 'Circle Of Life';
my $method   = 'GET';
my $uri      = '/dir/index.html';
my $expected = '6629fae49393a05397450978507c4ef1';

# auth
my $ha1 = Digest::MD5::md5_hex("$username:$realm:$pw");
my $ha2 = Digest::MD5::md5_hex("$method:$uri");
my $response = Digest::MD5::md5_hex("$ha1:$nonce:$nc:$cnonce:$qop:$ha2");

print $response eq $expected ? "OK\n" : "WRONG RESPONSE\n";

Hope that helps.
Cheers.

>
>
> ----------------------------------------
>
> > From: [email-masked]
> > To: [email-masked]
> > Subject: Re: FW: AUTH48 [SG]: RFC 5090   NOW AVAILABLE
> > Date: Sun, 23 Dec 2007 15:50:37 +1000
> > CC: [email-masked]
> >
> > Hi Bernard,
> >
> > Have the test vectors in section 6 Examples been checked? How? Im not
> > sure I entirely agree with the Digest-Response values in the B->C
> > messages
> >
> > Cheers.
> >
> > On Sunday 23 December 2007 03:37, Bernard Aboba wrote:
> >> RFC 4590bis is now being held in AUTH48, pending final verification.
> >>
> >> What started as a "simple" IANA-problem fix has turned into a longer
> >> odyssey due to the discovery of additional errors/omissions.
> >>
> >> In attempt to bring this story to a close, we need to make very sure
> >> that we have looked over this document carefully so that we don't have
> >> to go through this again with RFC 4590ter.
> >>
> >> So if you have ever had any interest in RADIUS Digest Authentication,
> >> now would be the time to look over the AUTH48 version of the document,
> >> and speak up if there is a problem.
> >>
> >>> Date: Fri, 21 Dec 2007 15:14:46 -0800
> >>> From: [email-masked]
> >>> To: [email-masked]
> >>> CC: [email-masked]; [email-masked];
> >>> [email-masked]; [email-masked]; [email-masked];
> >>> [email-masked]; [email-masked]; [email-masked];
> >>> [email-masked] Subject: Re: AUTH48 [SG]: RFC 5090
> >>>  NOW AVAILABLE
> >>>
> >>> Greeings Wolfgang,
> >>>
> >>> Just a reminder that we are waiting to hear from you before continuing
> >>> on with the publication process.
> >>>
> >>> Please see the email below for document information.
> >>>
> >>> Thank you.
> >>>
> >>> RFC Editor
> >>>
> >>> On Fri, Dec 14, 2007 at 02:51:11PM -0800, RFC Editor wrote:
> >>>> Hi Wolfgang,
> >>>>
> >>>> Just a friendly reminder that we are waiting to hear from you before
> >>>> continuing on with the publication process for RFC 5090
> >>>> .
> >>>>
> >>>> Please review the files located at:
> >>>>
> >>>>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt
> >>>>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html
> >>>>
> >>>> Note that this diff file highlights only the differences between the
> >>>> last posted version of the document and the current text file.  The
> >>>> previously posted versions (during AUTH48) are available as:
> >>>>
> >>>> The originally posted AUTH48 files:
> >>>>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt
> >>>>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html
> >>>>
> >>>> Version 2 (includes author updates) of AUTH48 files:
> >>>>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt
> >>>>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html
> >>>> Note that this file highlights only the differences between the
> >>>> version 1 and 2 text files.
> >>>>
> >>>> We will wait to hear from you before continuing on with the
> >>>> publication process.
> >>>>
> >>>> Thank you.
> >>>>
> >>>> RFC Editor/sg
> >>>>
> >>>> On Tue, Dec 11, 2007 at 05:08:35AM -0800, Bernard Aboba wrote:
> >>>>> I also talked to Wolfgang at IETF 70.  He wanted to check the
> >>>>> document over carefully to make sure there were no further issues.
> >>>>>
> >>>>>> Subject: RE: AUTH48 [SG]: RFC 5090
> >>>>>
> >>>>>  NOW AVAILABLE> Date: Mon, 10
> >>>>> Dec 2007 20:30:51 +0200> From: [email-masked]> To:
> >>>>> [email-masked]; [email-masked]> CC:
> >>>>> [email-masked]; [email-masked]; [email-masked];
> >>>>> [email-masked]; [email-masked]; [email-masked];
> >>>>> [email-masked]>> Yes,>> David Schwartz saw him at the ietf
> >>>>> meeting and worked through the draft> with him. I think we should be
> >>>>> hearing from him soon.>> Baruch>>> -----Original Message----->
> >>>>> From: RFC Editor [mailto:[email-masked]]> Sent: Monday,
> >>>>> December 10, 2007 8:27 PM> To: [email-masked]; Baruch Sterman>
> >>>>> Cc: David Schwartz; RFC Editor; [email-masked];
> >>>>> [email-masked];> Dan Romascanu; Ronald Bonica;
> >>>>> [email-masked];> [email-masked]> Subject: Re:
> >>>>> AUTH48 [SG]: RFC 5090 > NOW
> >>>>> AVAILABLE>> All,>> Just checking to see if you have had any luck
> >>>>> contacting Wolfgang?>> Thanks!>> RFC Editor/sg>> On Tue, Nov 27,
> >>>>> 2007 at 09:21:45PM +0200, Baruch Sterman wrote:>> David Schwartz
> >>>>> will be at the IETF meetings next week. Maybe Wolfgang>> will be
> >>>>> there and he can nudge him to answer. Lets hold off until we> see>>
> >>>>> if that way forward works. If not, we can go with option 3.>>>>
> >>>>> Thanks,>>>> Baruch>>>>>> -----Original Message----->> From:
> >>>>> RFC Editor [mailto:[email-masked]]>> Sent: Tuesday,
> >>>>> November 27, 2007 12:41 AM>> To: Baruch Sterman>> Cc: RFC Editor>>
> >>>>> Subject: Re: AUTH48 [SG]: RFC 5090>
> >>>>>
> >>>>> >> NOW AVAILABLE>>>> Hi
> >>>>>
> >>>>> Baruch,>>>> We have a couple of ways to move forward.>>>> 1.
> >>>>> The author can be removed as an author, and moved to the>>
> >>>>> Acknowledgements section.>>>> 2. We can create a Contributor's
> >>>>> section and have him listed there.>>>> 3. We can request that the
> >>>>> AD approve the document in place of the>> unavailabe author.>>>>
> >>>>> Option 3 has been done before in instances where the missing author>
> >>>>>
> >>>>>> made sizeable contributions to the document, so the other authors>
> >>>>>> did not feel comfortable removing the individuals name as an>>
> >>>>>
> >>>>> author.>>>> It sounds as though 3 may be the proper way forward.
> >>>>> If this is the>> case, we will send an email to the ADs requesting
> >>>>> their approval in>> place of Wolfgang (the message will be cc'ed to
> >>>>> all relevant>> parties, including Wolfgang).>>>> If the above
> >>>>> suggestions are unacceptable and you have an alternative>> solution,
> >>>>> please let us know.>>>> Thank you.>>>> RFC Editor>>>> On
> >>>>> Mon, Nov 26, 2007 at 09:39:09AM +0200, Baruch Sterman wrote:>>> I
> >>>>> wrote to Wolfgang as well, but got no response. What is the>>
> >>>>> procedure>>> in this case? I am sure that Wolfgang would be ok with
> >>>>> the changes.>> The>>> last email I received was on October 19
> >>>>> where he said that he had> made>>> the one correction (suggested by
> >>>>> Ellermann) in the cnonce value.>>>>>> Baruch>>>>>>>>>
> >>>>> -----Original Message----->>> From: RFC Editor
> >>>>> [mailto:[email-masked]]>>> Sent: Wednesday, November
> >>>>> 21, 2007 10:35 PM>>> To: David Williams; Baruch Sterman;
> >>>>> [email-masked]; David>> Schwartz;>>> [email-masked]>>>
> >>>>> Cc: [email-masked]; [email-masked]; RFC>>
> >>>>> Editor>>> Subject: Re: AUTH48 [SG]: RFC 5090>>
> >>>>>
> >>>>> >>> NOW AVAILABLE>>>>>>
> >>>>>
> >>>>> Greetings Wolfgang,>>>>>> We do not believe we have received
> >>>>> your response regarding this>>> document's readiness for
> >>>>> publication as an RFC. Please review the>>> text and let us know if
> >>>>> you are content with the document as it now>>> appears at:>>>>>
> >>>>>
> >>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>
> >>>>>
> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>> Note
> >>>>> that this diff file highlights only the changes between the> last>>
> >>>>>
> >>>>>> posted version of the document and the current text file.>>>>>
> >>>>>>
> >>>>>>>>> The last versions of the document are available as:>>>>>
> >>>>>>
> >>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt>>>
> >>>>>
> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html>>>>
> >>>>>
> >>>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt>>>
> >>>>>
> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html>>>
> >>>>> Note that this diff file highlights only the changes between v1 and>
> >>>>>
> >>>>>>> the v2.>>>>>> We will wait to hear from you before
> >>>>>
> >>>>> continuing on with the>>> publication process.>>>>>> Thank
> >>>>> you.>>>>>> RFC Editor>>>>>> On Fri, Nov 16, 2007 at
> >>>>> 05:13:04PM -0800, RFC Editor wrote:>>>> Authors,>>>>>>>> We
> >>>>> have corrected the text as indicated below and posted the> revised>>
> >>>>>
> >>>>>>> version of the document at:>>>>>>>>
> >>>>>
> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>>
> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>>>
> >>>>> Note that this diff file highlights only the changes betwee the>
> >>>>> last>>>>>> posted version of the document and the current text
> >>>>> file.>>>>>>>> Please review the document and let us know if
> >>>>> you approve this>>>> text for publication.>>>>>>>> We
> >>>>> believe we are waiting for the following approvals:>>>>>>>>
> >>>>> Baruch Sterman - done>>>> Daniel Sadolevsky - done>>>> David
> >>>>> Schwartz - done>>>> David Williams>>>> Wolfgang Beck>>>>>>
> >>>>>
> >>>>>>> Bernard Aboba - done>>>>>>>>>>>> Thank you.>>>>>>
> >>>>>>> RFC Editor>>>>>>>>>>>> On Tue, Nov 06, 2007 at
> >>>>>
> >>>>> 04:58:49PM -0800, RFC Editor wrote:>>>>> Authors,>>>>>>>>
> >>>>>
> >>>>>>> Please confer and let us know how the text should/should not use>
> >>>>>>
> >>>>>> the>>>>> quote marks. It sounds as though this email was for
> >>>>>
> >>>>> discussion.>> If>>>>> the changes below are acceptable, we will
> >>>>> make the changes and>> post>>> a>>>>> revised version of the
> >>>>> document.>>>>>>>>>> Also, please note the following status
> >>>>> of document approvals:>>>>>>>>>> Baruch Sterman - done
> >>>>> (although we would like to know if you> agree>>>>> with the
> >>>>> changes described below)>>>>> Daniel Sadolevsky - done>>>>>
> >>>>> David Schwartz>>>>> David Williams>>>>> Wolfgang Beck>>>>
> >>>>>
> >>>>>>>>>>> Bernard Aboba - done>>>>>>>>>> We will wait to
> >>>>>
> >>>>> hear further before continuing on with the>>> publication>>>>>
> >>>>> process.>>>>>>>>>> Thank you.>>>>>>>>>> RFC Editor>
> >>>>>
> >>>>>>>>>>>>>>>>>>> On Fri, Oct 19, 2007 at 01:33:14PM -0400,
> >>>>>
> >>>>> David Williams wrote:>>>>>> Hi Baruch,>>>>>>>>>>>>
> >>>>> These look good, and I agree with your consistency comment. I>>>
> >>>>> have a few>>>>>> more specific changes to suggest that I would
> >>>>> like you and>> others>>> to>>>>>> review as well. But first
> >>>>> a couple of general style comments>> that>>> require>>>>>>
> >>>>> no changes to the document.>>>>>>>>>>>> General comment
> >>>>> #1: I tried to find a definitive style guide> to>>> use of>>>>
> >>>>>
> >>>>>>> single quotes versus double quotes and found there is no hard>>
> >>>>>>
> >>>>>> guidelines,>>>>>> that consistency is most important:>>>>
> >>>>>>
> >>>>>>> http://en.wikipedia.org/wiki/Quotation_mark>>>>>>
> >>>>>
> >>>>> http://forum.wordreference.com/showthread.php?t=120946>>>>>>
> >>>>> Though I tend to think that double quotes are more commonly> used>>
> >>>>>
> >>>>>> and match>>>>>> the syntax of more popular programming
> >>>>>
> >>>>> languages, but there> are>> so>>> many>>>>>> quoted items in
> >>>>> the document and it has been this way for a> long>>> time, so>>>
> >>>>>
> >>>>>>>> best to leave as is.>>>>>>>>>>>> General comment #2:
> >>>>>
> >>>>> When refering to responses from the radius>>> server>>>>>>
> >>>>> there are a lot of instances of a comment similiar to "without>>>
> >>>>> surrounding>>>>>> quotes" that potentially could be removed for
> >>>>> readability.>>> Especially if>>>>>> there were a more concise
> >>>>> definition up-front about the> general>>> form of>>>>>>
> >>>>> values returned from the radius server. But I am a little>>>
> >>>>> hesitant to>>>>>> just strip them out now.>>>>>>>>>>>
> >>>>>
> >>>>>> Specific comments, to build on top of your list:>>>>>>>>>>
> >>>>>>
> >>>>>>> In section 2.1.2, 1st paragraph should not have quotes around>>
> >>>>>>
> >>>>>> nonce.>>>>>> Paragraph should read:>>>>>>>>>>>> If
> >>>>>
> >>>>> a matching (Proxy-)Authorization header is present and>>> contains>
> >>>>>
> >>>>>>>>>> HTTP Digest information, the RADIUS client checks the
> >>>>>
> >>>>> nonce>>>>>> parameter.>>>>>>>>>>>> In next paragraph,
> >>>>> do not need quotes around response.>> Paragraph>>> should>>>>
> >>>>>
> >>>>>>> read:>>>>>>>>>>>> If the RADIUS client recognizes the
> >>>>>
> >>>>> nonce, it takes the>> header>>>>>> directives and puts them
> >>>>> into a RADIUS Access-Request> packet.>>> It>>>>>> puts the
> >>>>> response directive into a Digest-Response> attribute>>> and>>>>
> >>>>>
> >>>>>>> the realm, nonce, digest-uri, qop, algorithm, cnonce, nc,>>>
> >>>>>
> >>>>> username,>>>>>> and opaque directives into the respective
> >>>>> Digest-Realm,>>> Digest-Nonce,>>>>>> Digest-URI, Digest-Qop,
> >>>>> Digest-Algorithm, Digest-CNonce,>>> Digest->>>>>> Nonce-Count,
> >>>>> Digest-Username, and Digest-Opaque attributes.>>> The>>>>>>
> >>>>> RADIUS client puts the request method into the> Digest-Method>>>>
> >>>>>
> >>>>>>> attribute.>>>>>>>>>>>> In section 2.1.3, in addtion to
> >>>>>
> >>>>> the items you point out, in> the>>> last>>>>>> paragraph,
> >>>>> nextnounce does not need quoting. Paragraph> should>>> read:>>>>
> >>>>>
> >>>>>>>>>>>>> When the RADIUS server provides a Digest-Nextnonce>
> >>>>>
> >>>>> attribute>> in>>> the>>>>>> Access-Accept packet, the RADIUS
> >>>>> client puts the contents> of>>> this>>>>>> attribute into a
> >>>>> nextnonce directive. Now it can send an>> HTTP->>>>>> style
> >>>>> response.>>>>>>>>>>>> In section 2.1.4, 2nd paragraph, the
> >>>>> stale directive should> not>>> need>>>>>> quoting. Paragraph
> >>>>> should read:>>>>>>>>>>>> If the RADIUS client receives an
> >>>>> Access-Challenge packet in>>> response>>>>>> to an
> >>>>> Access-Request containing a Digest-Nonce attribute,> the>>> RADIUS>
> >>>>>
> >>>>>>>>>> server did not accept the nonce. If a Digest-Stale>
> >>>>>
> >>>>> attribute>>> is>>>>>> present in the Access-Challenge and has
> >>>>> a value of 'true'>>> (without>>>>>> surrounding quotes), the
> >>>>> RADIUS client sends an error>> response>>> (401>>>>>> or 407)
> >>>>> containing a WWW-/Proxy-Authenticate header with> the>>>>>>
> >>>>> directive stale and the digest directives derived from the>>>
> >>>>> Digest-*>>>>>> attributes.>>>>>>>>>>>> Except I think
> >>>>> the wording of the last sentence in this same>>> paragraph>>>>
> >>>>>
> >>>>>>> could be improved. So that the paragraph reads more like:>>>>
> >>>>>>>
> >>>>>>>>>>>>> If the RADIUS client receives an Access-Challenge
> >>>>>
> >>>>> packet in>>> response>>>>>> to an Access-Request containing a
> >>>>> Digest-Nonce attribute,> the>>> RADIUS>>>>>> server did not
> >>>>> accept the nonce. If a Digest-Stale> attribute>>> is>>>>>>
> >>>>> present in the Access-Challenge and has a value of 'true'>>>
> >>>>> (without>>>>>> surrounding quotes), the RADIUS client sends an
> >>>>> error>> response>>> (401>>>>>> or 407) containing a
> >>>>> WWW-/Proxy-Authenticate header with> the>>>>>> stale directive
> >>>>> set to 'true' and the digest directives>> derived>>> from>>>>>
> >>>>>
> >>>>>> the Digest-* attributes.>>>>>>>>>>>> In section 3.10,
> >>>>>
> >>>>> 1st paragraph, I believe the term "qop-level">> is>>> ill>>>>
> >>>>>
> >>>>>>> defined and should not be used, that qop directive or> qop-value>
> >>>>>>> would be>>>>>> better. In other words the paragraph should
> >>>>>
> >>>>> read:>>>>>>>>>>>> When using the qop-value 'auth-int', a
> >>>>> hash of the>>> HTTP-style>>>>>> message body's contents is
> >>>>> required for digest>>> calculation.>>>>>> Instead of sending
> >>>>> the complete body of the message,>> only>>> its>>>>>> hash
> >>>>> value is sent. This hash value can be used>> directly>>> in>>>>
> >>>>>
> >>>>>>> the digest calculation.>>>>>>>>>>>> In section 3.15,
> >>>>>
> >>>>> auth-param doesn't need quoting. So that the>>> paragraph>>>>>
> >>>>>
> >>>>>> becomes:>>>>>>>>>>>> This attribute is a placeholder for
> >>>>>
> >>>>> future extensions>> and>>>>>> corresponds to the auth-param
> >>>>> parameter defined in>>> Section>>>>>> 3.2.1 of [RFC2617]. The
> >>>>> Digest-Auth-Param is the>>> mechanism>>>>>> whereby the RADIUS
> >>>>> client and RADIUS server can>> exchange>>> auth->>>>>> param
> >>>>> extension parameters contained within Digest>>> headers that>>>>
> >>>>>
> >>>>>>> are not understood by the RADIUS client and for which>>> there
> >>>>>
> >>>>> are>>>>>> no corresponding stand-alone attributes.>>>>>>>
> >>>>>
> >>>>>>>>>> In section 3.17, domain doesn't need quoting. So that the>
> >>>>>>>
> >>>>>>> paragraph>>>>>> becomes:>>>>>>>>>>>> When a
> >>>>>
> >>>>> RADIUS client has asked for a nonce, the> RADIUS>>> server>>>>>
> >>>>>
> >>>>>> MAY send one or more Digest-Domain attributes in its>>> Access->
> >>>>>>
> >>>>>>>>>> Challenge packet. The RADIUS client puts them into> the>>
> >>>>>>
> >>>>>> quoted,>>>>>> space-separated list of URIs of the domain
> >>>>>
> >>>>> directive> of>> a>>>>>> WWW-Authenticate header. Together with
> >>>>> Digest-Realm,>> the>>> URIs>>>>>> in the list define the
> >>>>> protection space (see> [RFC2617],>>> Section>>>>>> 3.2.1) for
> >>>>> some HTTP-style protocols. This attribute>>> MUST only>>>>>>
> >>>>> be used in Access-Challenge and Accounting-Request>>> packets.>>>
> >>>>>
> >>>>>>>>>>>>>> In section 3.19, 1st paragraph, in addtion to no
> >>>>>
> >>>>> quotes around>>> rspauth as>>>>>> you pointed out, I believe
> >>>>> there should be no quotes around> qop.>>> So that>>>>>> the
> >>>>> paragraph reads:>>>>>>>>>>>> This attribute is used to
> >>>>> allow the generation of an>>>>>> Authentication-Info header,
> >>>>> even if the HTTP-style>>> response's>>>>>> body is required
> >>>>> for the calculation of the rspauth>>> value.>>>>>> It SHOULD
> >>>>> be used in Access-Accept packets if the>>> required>>>>>>
> >>>>> quality of protection (qop) is 'auth-int'.>>>>>>>>>>>>
> >>>>> thanks,>>>>>> -david>>>>>>>>>>>> On Fri, 19 Oct 2007,
> >>>>> 1:43pm, Baruch Sterman wRote:>>>>>>>>>>>>>After lengthy
> >>>>> discussions with my father-in-law who is a>>> professor of>>>>>
> >>>>>
> >>>>>>>English, I agree with Dave's method of using quotes only in> the>
> >>>>>>> value of>>>>>>>an attribute/directive, but not in
> >>>>>
> >>>>> referencing the>>> attribute/directive>>>>>>>by name. As
> >>>>> such, I have some changes.>>>>>>>>>>>>>>In section 2.1.3
> >>>>> 3rd paragraph should not have quotes around>> the>>> word>>>>>
> >>>>>
> >>>>>>>rspauth. Sentence should read:>>>>>>>>>>>>>> * If the
> >>>>>
> >>>>> Digest-Qop attribute's value is 'auth' or not>>> specified,>>>>
> >>>>>
> >>>>>>>> the RADIUS client puts the Digest-Response-Auth>>>
> >>>>>
> >>>>> attribute's>>>>>>> content into the Authentication-Info
> >>>>> header's rspauth>>>>>>> directive of the HTTP-style response.>
> >>>>>
> >>>>>>>>>>>>>>>>>>Same section 5th paragraph - no quotes around
> >>>>>
> >>>>> qop and>> algorithm:>>>>>>>>>>>>>> o If the
> >>>>> Access-Accept packet contains a Digest-HA1>> attribute,>>> the>>
> >>>>>
> >>>>>>>>>> RADIUS client checks the qop and algorithm directives in>>
> >>>>>
> >>>>> the>>>>>>> Authorization header of the HTTP-style request it
> >>>>> wants> to>>>>>>> authorize:>>>>>>>>>>>>>>Next
> >>>>> paragraph - no quotes around qop>>>>>>>>>>>>>> * If the
> >>>>> qop directive is missing or its value is> 'auth',>>> the>>>>>>
> >>>>>
> >>>>>> RADIUS client ignores the Digest-HA1 attribute. It>> does>>>
> >>>>>
> >>>>> not>>>>>>> include an Authentication-Info header in its>
> >>>>> HTTP-style>>>>>>> response.>>>>>>>>>>>>>>Next
> >>>>> paragraph - no quotes around qop or rspauth.>>>>>>>>>>>>>
> >>>>>
> >>>>>> * If the qop directive's value is 'auth-int' and at> least>>>
> >>>>>
> >>>>> one>>>>>>> of the following conditions is true, the RADIUS>
> >>>>> client>>>>>>> calculates the contents of the HTTP-style
> >>>>> response's>>> rspauth>>>>>>> directive:>>>>>>>>>>>>
> >>>>>
> >>>>>>>>>>>>>>2 paragraphs later - no quotes around rspauth>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The RADIUS client creates the HTTP-style response>
> >>>>>>
> >>>>>> message>>> and>>>>>>> calculates the hash of this message's
> >>>>>
> >>>>> body. It uses>> the>>> result>>>>>>> and the Digest-URI
> >>>>> attribute's value of the>> corresponding>>>>>>> Access-Request
> >>>>> packet to perform the H(A2)> calculation.>>> It>>>>>>> takes
> >>>>> the Digest-Nonce, Digest-Nonce-Count,>>> Digest-CNonce, and>>>>
> >>>>>
> >>>>>>>> Digest-Qop values of the corresponding Access-Request>> and>>
> >>>>>>
> >>>>>> the>>>>>>> Digest-HA1 attribute's value to finish the>
> >>>>>
> >>>>> computation>> of>>> the>>>>>>> rspauth value.>>>>>>>>
> >>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>Section 3.4 paragraph 1 - no
> >>>>>
> >>>>> quotes around rspauth>>>>>>>>>>>>>> This attribute
> >>>>> enables the RADIUS server to prove>>> possession of>>>>>>>
> >>>>> the password. If the previously received Digest-Qop>>> attribute>>
> >>>>>
> >>>>>>>>>> was 'auth-int' (without surrounding quotes), the> RADIUS>>
> >>>>>>
> >>>>>> server>>>>>>> MUST send a Digest-HA1 attribute instead of a>
> >>>>>>
> >>>>>>> Digest-Response->>>>>>> Auth attribute. The
> >>>>>
> >>>>> Digest-Response-Auth attribute>> MUST>>> only>>>>>>> be used
> >>>>> in Access-Accept packets. The RADIUS client>> puts>>> the>>>>>
> >>>>>
> >>>>>>> attribute value without surrounding quotes into the>>> rspauth>
> >>>>>>>
> >>>>>>>>>>> directive of the Authentication-Info header.>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>Section 3.5 2nd paragraph - no quotes
> >>>>>
> >>>>> around nextnonce>>>>>>>>>>>>>> The RADIUS server MAY put
> >>>>> a Digest-Nextnonce> attribute>>> into an>>>>>>> Access-Accept
> >>>>> packet. If this attribute is present,>> the>>> RADIUS>>>>>>>
> >>>>> client MUST put the contents of this attribute into> the>>>>>>>
> >>>>> nextnonce directive of an Authentication-Info header> in>>> its>>
> >>>>>
> >>>>>>>>>> HTTP-style response. This attribute MUST only be> used>>
> >>>>>
> >>>>> in>>>>>>> Access-Accept packets.>>>>>>>>>>>>>>>>>
> >>>>>
> >>>>>>>>>Section 3.7, 4th paragraph - no quotes around uri>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>> If the HTTP-style request has an Authorization>
> >>>>>
> >>>>> header,>>> the>>>>>>> RADIUS client puts the value of the uri
> >>>>> directive> found>>> in>>>>>>> the HTTP-style request
> >>>>> Authorization header (known as>>> "digest->>>>>>> uri-value"
> >>>>> in Section 3.2.2 of [RFC2617]) without>>> surrounding>>>>>>>
> >>>>> quotes into this attribute. If there is no>> Authorization>>>>>
> >>>>>
> >>>>>>> header, the RADIUS client takes the value of the>> request>>>
> >>>>>
> >>>>> URI>>>>>>> from the HTTP-style request it wants to
> >>>>> authenticate.>>>>>>>>>>>>>>>>>>>>>Section 3.8, 4th
> >>>>> paragraph - no quotes around qop>>>>>>>>>>>>>> In
> >>>>> Access-Requests, the RADIUS client takes the value>> of>>> the>>
> >>>>>
> >>>>>>>>>> qop directive (qop-value as described in [RFC2617])>>
> >>>>>
> >>>>> from>>> the>>>>>>> HTTP-style request it wants to
> >>>>> authenticate. In>> Access->>>>>>> Challenge packets, the
> >>>>> RADIUS server puts a desired>>> qop-value>>>>>>> into this
> >>>>> attribute. If the RADIUS server supports>> more>>> than>>>>>>
> >>>>>
> >>>>>> one "quality of protection" value, it puts each>> qop-value>>>
> >>>>>
> >>>>> into>>>>>>> a separate Digest-Qop attribute.>>>>>>>>>>
> >>>>>
> >>>>>>>>>Section 3.18 1st paragraph - no quotes around stale>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>> This attribute is sent by a RADIUS server in order to>
> >>>>>>>
> >>>>>>> notify>>>>>>> the RADIUS client whether it has accepted a
> >>>>>
> >>>>> nonce.> If>>> the>>>>>>> nonce presented by the RADIUS client
> >>>>> was stale, the>> value>>> is>>>>>>> 'true' and is 'false'
> >>>>> otherwise. The RADIUS client>> puts>>> the>>>>>>> content of
> >>>>> this attribute into a stale directive of> the>>> WWW->>>>>>>
> >>>>> Authenticate header in the HTTP-style response to the>>> request>>
> >>>>>
> >>>>>>>>>> it wants to authenticate. The attribute MUST only be>>>
> >>>>>
> >>>>> used in>>>>>>> Access-Challenge packets.>>>>>>>>>>>>
> >>>>>
> >>>>>>>3.19 1st paragraph - no quotes around rspauth>>>>>>>>>>>
> >>>>>>>
> >>>>>>>> This attribute is used to allow the generation of an>>>>>>
> >>>>>>
> >>>>>> Authentication-Info header, even if the HTTP-style>>> response's>
> >>>>>>
> >>>>>>>>>>> body is required for the calculation of the rspauth>>>
> >>>>>
> >>>>> value.>>>>>>> It SHOULD be used in Access-Accept packets if
> >>>>> the>>> required>>>>>>> quality of protection ('qop') is
> >>>>> 'auth-int'.>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>
> >>>>>>>>>I think that does it. Even if this is not right, at least it>
> >>>>>>>
> >>>>>>> should now>>>>>>>be consistent.>>>>>>>>>>>>>
> >>>>>>
> >>>>>>Comments?>>>>>>>>>>>>>>Baruch>>>>>>>>>>>>>>>
> >>>>>>
> >>>>>>>>>>>>>>>>>>-----Original Message----->>>>>>>From:
> >>>>>
> >>>>> RFC Editor [mailto:[email-masked]]>>>>>>>Sent:
> >>>>> Monday, October 15, 2007 8:45 PM>>>>>>>To: David Williams>>>
> >>>>>
> >>>>>>>>>Cc: Baruch Sterman; [email-masked]; David Schwartz;>>>
> >>>>>>>>>[email-masked]; [email-masked];>>>>>>
> >>>>>>
> >>>>>>[email-masked]; RFC Editor>>>>>>>Subject: Re:
> >>>>>
> >>>>> AUTH48 [SG]: RFC 5090>>> >>>
> >>>>>
> >>>>>>>>>NOW AVAILABLE>>>>>>>>>>>>>>Greeting all,>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>>>We have not heard further regarding the issues below
> >>>>>
> >>>>> or other>>> changes>>>>>>>that may be required before
> >>>>> publishing this document as an> RFC.>>>>>>>Please review the
> >>>>> document and let us know if there are any>>>>>>>corrections
> >>>>> required.>>>>>>>>>>>>>>
> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>>>>>
> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>>>>
> >>>>>
> >>>>>>>>>>>>>>We will wait to hear from you before continuing on
> >>>>>
> >>>>> with the>>>>>>>publication process.>>>>>>>>>>>>>
> >>>>>
> >>>>>>Thank you.>>>>>>>>>>>>>>RFC Editor>>>>>>>>>>>>
> >>>>>>
> >>>>>>>On Sun, Oct 07, 2007 at 01:29:00PM -0400, David Williams> wrote:>
> >>>>>>>
> >>>>>>>>>>>>On Thu, 4 Oct 2007, 3:40pm, RFC Editor wRote:>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>>>>Authors,>>>>>>>>>>>>>>>>>>While
> >>>>>
> >>>>> reviewing > during>>> AUTH48,>
> >>>>>
> >>>>>>>>>>>>>please consider the following.>>>>>>>>>>>>>>>
> >>>>>>>>
> >>>>>>>>In previous dialog, we had the following exchange:>>>>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>>>>>2. Please explain the usage of the single quote marks
> >>>>>
> >>>>> (')>> in>>>>>>>>>>>this document. There seems to be
> >>>>> inconsistency, but we> are>>>>>>>>>>>unable to determine which
> >>>>> values/attributes/parameters> you>>>>>>>>>>>wanted to appear in
> >>>>> quote marks. For example, we see>>>>>>>>>>>>>>>>>
> >>>>>
> >>>>>>>>>>'auth-int'/"auth-int">>>>>>>>>>>'rspauth'
> >>>>>
> >>>>> directive/rspauth directive>>>>>>>>>>>'rspauth' value/rspauth
> >>>>> value>>>>>>>>>>>>>>>>>>>>>As RfC 2617 always uses ",
> >>>>> replacing all 's in question> with>> ">>> seems>>>>>>>>>>the
> >>>>> right thing to do.>>>>>>>>>>>>>>>>>>Please note that we
> >>>>> did not replace all 's with "s because>>>>>>>>>RFC 4590 uses
> >>>>> 's. However, if you feel that the document>>> should be>>>>>>
> >>>>>
> >>>>>>>>more alignmed with RFC 2617, please let us know and we will>>>
> >>>>>
> >>>>> make>>>>>>>>>this change.>>>>>>>>>>>>>>>>If we are
> >>>>> taking a vote, I would prefer using " instead of '>>> around>>>>
> >>>>>
> >>>>>>>>the>>>>>>>>value strings. I think it is better to stay
> >>>>>
> >>>>> aligned with> 2617>>> rather>>>>>>>than>>>>>>>>4590.
> >>>>> Also I believe the " usage is more commonly used in>> other>>>>>
> >>>>>
> >>>>>>>>specifications.>>>>>>>>>>>>>>>>>>>>>>>>>>Also,
> >>>>>
> >>>>> we had a difficult time understanding the use of 's.>> We>>>>>>
> >>>>>
> >>>>>>>>inserted 's around auth-int, auth, qop, and rspauth when> they>>
> >>>>>>
> >>>>>> were>>>>>>>>>used as values or directives. However, we did
> >>>>>
> >>>>> not attempt> to>>> include>>>>>>>>>'s for *all* directives
> >>>>> and values (e.g., realm and> opaque).>>> Please>>>>>>>>>let
> >>>>> us know if this is not correct.>>>>>>>>>>>>>>>>I agree it
> >>>>> is confusing. Looking at 2617 I don't think it> is>>> entirely>>>
> >>>>>
> >>>>>>>>>>>>>>>>>consistent either, as I see references to ["qop"
> >>>>>
> >>>>> directive]> as>>> well as>>>>>>>the>>>>>>>>unquoted
> >>>>> form [qop directive].>>>>>>>>>>>>>>>>I am no authority on
> >>>>> style but my initial thought is to>> suggest>>>>>>>removing '>
> >>>>>
> >>>>>>>>>>>>and " from keywords when refering to a directive name
> >>>>>
> >>>>> rather>>> than its>>>>>>>>literal value, and then use "" when
> >>>>> refering to a value.> For>>> example,>>>>>>>the>>>>>>
> >>>>>
> >>>>>>>existing 5090 text would then become:>>>>>>>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>> o If the Access-Accept packet contains a
> >>>>>
> >>>>> Digest-HA1>>> attribute, the>>>>>>>> RADIUS client checks the
> >>>>> qop and algorithm directives> in>>> the>>>>>>>> Authorization
> >>>>> header of the HTTP-style request it> wants>> to>>>>>>>>
> >>>>> authorize:>>>>>>>>>>>>>>>> * If the qop directive is
> >>>>> missing or its value is>> "auth",>>> the>>>>>>>> RADIUS
> >>>>> client ignores the Digest-HA1 attribute. It>>> does not>>>>>>
> >>>>>
> >>>>>>> include an Authentication-Info header in its>> HTTP-style>>>>
> >>>>>>>
> >>>>>>>>> response.>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>
> >>>>>>>However when examing 2617 in more detail, using " around the>>>
> >>>>>
> >>>>> directive>>>>>>>>>>>>>>>names would be more consistent
> >>>>> with that draft. For example>>> this>>>>>>>would>>>>>>
> >>>>>
> >>>>>>>become:>>>>>>>>>>>>>>>>>>>>
> >>>>>>>
> >>>>>>>>> o If the Access-Accept packet contains a Digest-HA1>>>
> >>>>>
> >>>>> attribute, the>>>>>>>> RADIUS client checks the "qop" and
> >>>>> "algorithm">> directives>>> in the>>>>>>>> Authorization
> >>>>> header of the HTTP-style request it> wants>> to>>>>>>>>
> >>>>> authorize:>>>>>>>>>>>>>>>> * If the "qop" directive is
> >>>>> missing or its value is>>> "auth", the>>>>>>>> RADIUS client
> >>>>> ignores the Digest-HA1 attribute. It>>> does not>>>>>>>>
> >>>>> include an Authentication-Info header in its>> HTTP-style>>>>>>
> >>>>>
> >>>>>>> response.>>>>>>>>>>>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>Prehaps others can weigh in one which they believe is most>
> >>>>>>>>>>>appropriate.>>>>>>>>I believe either would be a
> >>>>>
> >>>>> slight improvement on the> existing>>> text>>>>>>>which>>>
> >>>>>
> >>>>>>>>>>uses single quotes around the string values.>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>thanks,>>>>>>>>-david>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>Thank you.>>>>>>>>>>>>>>>>>>RFC Editor>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>On Thu, Oct 04, 2007 at
> >>>>>
> >>>>> 03:11:50PM -0700,>>> [email-masked]>>>>>>>wrote:>
> >>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>****IMPORTANT*****>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>Updated 2007/10/04>>>>>>>>>>>>>>>>>>>>RFC
> >>>>>
> >>>>> AUTHOR(S):>>>>>>>>>>-------------->>>>>>>>>>>>>>>>
> >>>>>
> >>>>>>>>>This is your LAST CHANCE to make changes to your RFC to> be:>>>
> >>>>>>>>>
> >>>>>>>>>>>>draft-ietf-radext-rfc4590bis-02.txt, once the document is>
> >>>>>>>
> >>>>>>> published>>>>>>>as>>>>>>>>>>an RFC we *WILL NOT* make
> >>>>>
> >>>>> any changes.>>>>>>>>>>>>>>>>>>>>Please check your
> >>>>> document at:>>>>>>>>>>>>>>>>
> >>>>>
> >>>>>>>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>>>>>>>>ATTENTION: The editing process occasionally
> >>>>>
> >>>>> introduces>> errors>>> that>>>>>>>>>>were not in the
> >>>>> Internet Draft. Although the RFC Editor>> tries>>> very>>>>>>
> >>>>>
> >>>>>>>>>hard to catch all errors, proofreading the text at least>>>
> >>>>>
> >>>>> twice,>>>>>>>typos>>>>>>>>>>can slip through. You, as an
> >>>>> author of the RFC, are> taking>>>>>>>>>>responsibility for the
> >>>>> correctness of the final product> when>>> you OK>>>>>>
> >>>>>
> >>>>>>>>>publication. You should therefore proofread the entire> RFC>>>
> >>>>>>>>>carefully>>>>>>>>>>and without assumptions. Errors in
> >>>>>
> >>>>> RFCs last forever.>>>>>>>>>>>>>>>>>>>>NOTE: We have run a
> >>>>> diff tool that compares the approved>>>>>>>internet-draft>>>
> >>>>>
> >>>>>>>>>>>>against our edited RFC version of the document. Please>>
> >>>>>
> >>>>> review>>> this>>>>>>>>>>file at:>>>>>>>>>>>>>>>>>
> >>>>>
> >>>>>>>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>>
> >>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>Please note that we used a slightly altered
> >>>>>
> >>>>> version of the>>>>>>>originally>>>>>>>>>>submitted ID to
> >>>>> create the diff file above. To make the>> file>>> more>>>>>>
> >>>>>
> >>>>>>>>>useful, we moved the terminology section to to appear> after>>>
> >>>>>
> >>>>> the>>>>>>>>>>introduction, but we did not alter the text.>>>
> >>>>>
> >>>>>>>>>>>>>>>>>>>>>>The document will NOT BE PUBLISHED until
> >>>>>
> >>>>> ALL of the> authors>>> listed>>>>>>>in>>>>>>>>>>the RFC
> >>>>> have affirmed that the document is ready to be>>>>>>
> >>>>>
> >>>>>>>>>published, as ALL of the authors are equally responsible> for>>
> >>>>>>>>>
> >>>>>>>>>>verifying>>>>>>>>>>the documents readiness for
> >>>>>
> >>>>> publication.>>>>>>>>>>>>>>>>>>>>** Please send us a list
> >>>>> of suitable keywords for this>>> document,>>>>>>>over>>>>
> >>>>>
> >>>>>>>>>>>and above those which appear in the title.>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>> Frequently INCORRECT information includes>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> - Contact Information>>>>>>>>>> -
> >>>>>
> >>>>> References (are they up to date)>>>>>>>>>> - Section Numbers>>
> >>>>>
> >>>>>>>>>>>>> (especially if you originally put the copyright>>>>>
> >>>>>>>
> >>>>>>>somewhere>>>>>>>>>> other than the VERY end of the document,
> >>>>>
> >>>>> or if>> you>>>>>>>>>> numbered the 'Status of the Memo'
> >>>>> field)>>>>>>>>>>>>>>>>>>>>Please send us the changes, *DO
> >>>>> NOT* send a new document>> with>>> the>>>>>>>>>>changes
> >>>>> made. (If we think that the changes might be more>>> than>>>>>
> >>>>>
> >>>>>>>>>>editorial we will contact the AD or the IESG to confirm> that>
> >>>>>>>
> >>>>>>> the>>>>>>>>>>changes do not require review.)>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>>>>>Send us the changes in THIS format.>>>>>>
> >>>>>>>>>>>>>>>>>>> 1)*** SECTION #'s*** [i.e. Section 5, 2nd>>>
> >>>>>
> >>>>> paragraph]>>>>>>>>>> 2) the text you want changed,>>>>>>
> >>>>>
> >>>>>>>>> 3) the new correct text and>>>>>>>>>> 4) if the changes
> >>>>>
> >>>>> are spacing or indentation> than>>> please>>>>>>>note>>>>
> >>>>>
> >>>>>>>>>>> that.>>>>>>>>>>>>>>>>>>>>FOR EXAMPLE:>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Section 5.6, 3rd paragraph>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> OLD:>>>>>>>>>> The quick brown fox jumped over the
> >>>>>
> >>>>> lazy dog.>>>>>>>>>>>>>>>>>>>> NEW:>>>>>>>>>> The
> >>>>> quick brown dog jumps over the lazy fox.>>>>>>>>>> ^^^ ^ ^^^>>
> >>>>>
> >>>>>>>>>>>>>If you have a whole paragraph to replace you do not need>
> >>>>>
> >>>>> to>>> use>>>>>>>>>>the arrow to point out the differences>>
> >>>>>
> >>>>>>>>>>>>>>>>>>>>>>> INTRODUCTION, 2nd paragraph>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Replace OLD:>>>>>>>>>>>>>>>>>>>>
> >>>>>
> >>>>> alsdfja;sldjf;lajsd;fljas;dlfj;>>>>>>>>>>>>>>>>>>>> With
> >>>>> NEW:>>>>>>>>>>>>>>>>>>>> nv;alkjd;lsf;aoisj;ltjka;sldkjf>
> >>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>Spacing or indentation problems...>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Section 10, 1st paragraph (remove spaces>
> >>>>>
> >>>>> between>>> bit>>>>>>>>>> and of, add space after butter)>>>
> >>>>>
> >>>>>>>>>>>>>>>>>>>>>> OLD:>>>>>>>>>>>>>>>>>>>>
> >>>>>
> >>>>> Better botter bought a bit>>>>>>>>>> of bitter butterMary mary
> >>>>> quite contrary>>>>>>>>>>>>>>>>>>>> NEW:>>>>>>>>>>>
> >>>>>
> >>>>>>>>>>>>>> Better botter bought a bit of bitter butter>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Mary mary quite contrary>>>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>This document will NOT be published until we receive>>>
> >>>>>
> >>>>> agreement, from>>>>>>>>>>ALL listed authors, that the document
> >>>>> is ready for>>> publication.>>>>>>>>>>>>>>>>>>>>Thanks
> >>>>> for your cooperation,>>>>>>>>>>>>>>>>>>>>-RFC Editor>>>
> >>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Title : RADIUS Extension
> >>>>>
> >>>>> for Digest>>>>>>>>>> Authentication>>>>>>>>>>Author(s) :
> >>>>> B. Sterman, D. Sadolevsky,>>>>>>>>>> D. Schwartz, D. Williams,>
> >>>>>
> >>>>>>>>>>>>>> W. Beck>>>>>>>>>>Working Group Chair(s) :
> >>>>>
> >>>>> Bernard Aboba, David Nelson>>>>>>>>>>Area Director(s) : Dan
> >>>>> Romascanu, Ronald Bonica>>>>>>>>>>>>>>>>
> >
> > --
> > Mike McCauley                               [email-masked]
> > Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
> > 9 Bulbul Place Currumbin Waters QLD 4223 Australia  
> > http://www.open.com.au Phone +61 7 5598-7474                       Fax  
> > +61 7 5598-7070
> >
> > Radiator: the most portable, flexible and configurable RADIUS server
> > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
> > TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc.

-- 
Mike McCauley                               [email-masked]
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc.

Delivery-date: Sun, 23 Dec 2007 07:48:27 +0000
From: Bernard Aboba <[email-masked]>
To: Mike McCauley <[email-masked]>
CC: <[email-masked]>
Subject: RE: AUTH48 [SG]: RFC 5090  <draft-ietf-radext-rfc4590bis-02.txt> NOW AVAILABLE
Date: Sat, 22 Dec 2007 23:47:28 -0800

The test vectors in Section 6 are one of the major open questions.  Wolfgan=
g did the original checks, but subsequent reviewers kept finding errors in =
them, so they have been revised several times.=20

What do you think is wrong with the B->C messages?=20

----------------------------------------
> From: [email-masked]
> To: [email-masked]
> Subject: Re: FW: AUTH48 [SG]: RFC 5090   NOW AVAILABLE
> Date: Sun, 23 Dec 2007 15:50:37 +1000
> CC: [email-masked]
>=20
> Hi Bernard,
>=20
> Have the test vectors in section 6 Examples been checked? How? Im not sur=
e I=20
> entirely agree with the Digest-Response values in the B->C messages
>=20
> Cheers.
>=20
> On Sunday 23 December 2007 03:37, Bernard Aboba wrote:
>> RFC 4590bis is now being held in AUTH48, pending final verification.
>>
>> What started as a "simple" IANA-problem fix has turned into a longer
>> odyssey due to the discovery of additional errors/omissions.
>>
>> In attempt to bring this story to a close, we need to make very sure tha=
t
>> we have looked over this document carefully so that we don't have to go
>> through this again with RFC 4590ter.
>>
>> So if you have ever had any interest in RADIUS Digest Authentication, no=
w
>> would be the time to look over the AUTH48 version of the document, and
>> speak up if there is a problem.
>>
>>> Date: Fri, 21 Dec 2007 15:14:46 -0800
>>> From: [email-masked]
>>> To: [email-masked]
>>> CC: [email-masked]; [email-masked];
>>> [email-masked]; [email-masked]; [email-masked];
>>> [email-masked]; [email-masked]; [email-masked];
>>> [email-masked] Subject: Re: AUTH48 [SG]: RFC 5090=20
>>>  NOW AVAILABLE
>>>
>>> Greeings Wolfgang,
>>>
>>> Just a reminder that we are waiting to hear from you before continuing
>>> on with the publication process.
>>>
>>> Please see the email below for document information.
>>>
>>> Thank you.
>>>
>>> RFC Editor
>>>
>>> On Fri, Dec 14, 2007 at 02:51:11PM -0800, RFC Editor wrote:
>>>> Hi Wolfgang,
>>>>
>>>> Just a friendly reminder that we are waiting to hear from you before
>>>> continuing on with the publication process for RFC 5090
>>>> .
>>>>
>>>> Please review the files located at:
>>>>
>>>>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt
>>>>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html
>>>>
>>>> Note that this diff file highlights only the differences between the
>>>> last posted version of the document and the current text file.  The
>>>> previously posted versions (during AUTH48) are available as:
>>>>
>>>> The originally posted AUTH48 files:
>>>>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt
>>>>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html
>>>>
>>>> Version 2 (includes author updates) of AUTH48 files:
>>>>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt
>>>>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html
>>>> Note that this file highlights only the differences between the
>>>> version 1 and 2 text files.
>>>>
>>>> We will wait to hear from you before continuing on with the
>>>> publication process.
>>>>
>>>> Thank you.
>>>>
>>>> RFC Editor/sg
>>>>
>>>> On Tue, Dec 11, 2007 at 05:08:35AM -0800, Bernard Aboba wrote:
>>>>> I also talked to Wolfgang at IETF 70.  He wanted to check the
>>>>> document over carefully to make sure there were no further issues. =20
>>>>>> Subject: RE: AUTH48 [SG]: RFC 5090
>>>>>  NOW AVAILABLE> Date: Mon, 10
>>>>> Dec 2007 20:30:51 +0200> From: [email-masked]> To:
>>>>> [email-masked]; [email-masked]> CC:
>>>>> [email-masked]; [email-masked]; [email-masked];
>>>>> [email-masked]; [email-masked]; [email-masked];
>>>>> [email-masked]>> Yes,>> David Schwartz saw him at the ietf
>>>>> meeting and worked through the draft> with him. I think we should be
>>>>> hearing from him soon.>> Baruch>>> -----Original Message----->
>>>>> From: RFC Editor [mailto:[email-masked]]> Sent: Monday,
>>>>> December 10, 2007 8:27 PM> To: [email-masked]; Baruch Sterman>
>>>>> Cc: David Schwartz; RFC Editor; [email-masked];
>>>>> [email-masked];> Dan Romascanu; Ronald Bonica;
>>>>> [email-masked];> [email-masked]> Subject: Re:
>>>>> AUTH48 [SG]: RFC 5090 > NOW
>>>>> AVAILABLE>> All,>> Just checking to see if you have had any luck
>>>>> contacting Wolfgang?>> Thanks!>> RFC Editor/sg>> On Tue, Nov 27,
>>>>> 2007 at 09:21:45PM +0200, Baruch Sterman wrote:>> David Schwartz
>>>>> will be at the IETF meetings next week. Maybe Wolfgang>> will be
>>>>> there and he can nudge him to answer. Lets hold off until we> see>>
>>>>> if that way forward works. If not, we can go with option 3.>>>>
>>>>> Thanks,>>>> Baruch>>>>>> -----Original Message----->> From:
>>>>> RFC Editor [mailto:[email-masked]]>> Sent: Tuesday,
>>>>> November 27, 2007 12:41 AM>> To: Baruch Sterman>> Cc: RFC Editor>>
>>>>> Subject: Re: AUTH48 [SG]: RFC 5090>
>>>>> >> NOW AVAILABLE>>>> Hi
>>>>> Baruch,>>>> We have a couple of ways to move forward.>>>> 1.
>>>>> The author can be removed as an author, and moved to the>>
>>>>> Acknowledgements section.>>>> 2. We can create a Contributor's
>>>>> section and have him listed there.>>>> 3. We can request that the
>>>>> AD approve the document in place of the>> unavailabe author.>>>>
>>>>> Option 3 has been done before in instances where the missing author>
>>>>>> made sizeable contributions to the document, so the other authors>
>>>>>> did not feel comfortable removing the individuals name as an>>
>>>>> author.>>>> It sounds as though 3 may be the proper way forward.
>>>>> If this is the>> case, we will send an email to the ADs requesting
>>>>> their approval in>> place of Wolfgang (the message will be cc'ed to
>>>>> all relevant>> parties, including Wolfgang).>>>> If the above
>>>>> suggestions are unacceptable and you have an alternative>> solution,
>>>>> please let us know.>>>> Thank you.>>>> RFC Editor>>>> On
>>>>> Mon, Nov 26, 2007 at 09:39:09AM +0200, Baruch Sterman wrote:>>> I
>>>>> wrote to Wolfgang as well, but got no response. What is the>>
>>>>> procedure>>> in this case? I am sure that Wolfgang would be ok with
>>>>> the changes.>> The>>> last email I received was on October 19
>>>>> where he said that he had> made>>> the one correction (suggested by
>>>>> Ellermann) in the cnonce value.>>>>>> Baruch>>>>>>>>>
>>>>> -----Original Message----->>> From: RFC Editor
>>>>> [mailto:[email-masked]]>>> Sent: Wednesday, November
>>>>> 21, 2007 10:35 PM>>> To: David Williams; Baruch Sterman;
>>>>> [email-masked]; David>> Schwartz;>>> [email-masked]>>>
>>>>> Cc: [email-masked]; [email-masked]; RFC>>
>>>>> Editor>>> Subject: Re: AUTH48 [SG]: RFC 5090>>
>>>>> >>> NOW AVAILABLE>>>>>>
>>>>> Greetings Wolfgang,>>>>>> We do not believe we have received
>>>>> your response regarding this>>> document's readiness for
>>>>> publication as an RFC. Please review the>>> text and let us know if
>>>>> you are content with the document as it now>>> appears at:>>>>>
>>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>
>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>> Note
>>>>> that this diff file highlights only the changes between the> last>>
>>>>>> posted version of the document and the current text file.>>>>>
>>>>>>>>> The last versions of the document are available as:>>>>>
>>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt>>>
>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html>>>>
>>>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt>>>
>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html>>>
>>>>> Note that this diff file highlights only the changes between v1 and>
>>>>>>> the v2.>>>>>> We will wait to hear from you before
>>>>> continuing on with the>>> publication process.>>>>>> Thank
>>>>> you.>>>>>> RFC Editor>>>>>> On Fri, Nov 16, 2007 at
>>>>> 05:13:04PM -0800, RFC Editor wrote:>>>> Authors,>>>>>>>> We
>>>>> have corrected the text as indicated below and posted the> revised>>
>>>>>>> version of the document at:>>>>>>>>
>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>>
>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>>>
>>>>> Note that this diff file highlights only the changes betwee the>
>>>>> last>>>>>> posted version of the document and the current text
>>>>> file.>>>>>>>> Please review the document and let us know if
>>>>> you approve this>>>> text for publication.>>>>>>>> We
>>>>> believe we are waiting for the following approvals:>>>>>>>>
>>>>> Baruch Sterman - done>>>> Daniel Sadolevsky - done>>>> David
>>>>> Schwartz - done>>>> David Williams>>>> Wolfgang Beck>>>>>>
>>>>>>> Bernard Aboba - done>>>>>>>>>>>> Thank you.>>>>>>
>>>>>>> RFC Editor>>>>>>>>>>>> On Tue, Nov 06, 2007 at
>>>>> 04:58:49PM -0800, RFC Editor wrote:>>>>> Authors,>>>>>>>>
>>>>>>> Please confer and let us know how the text should/should not use>
>>>>>> the>>>>> quote marks. It sounds as though this email was for
>>>>> discussion.>> If>>>>> the changes below are acceptable, we will
>>>>> make the changes and>> post>>> a>>>>> revised version of the
>>>>> document.>>>>>>>>>> Also, please note the following status
>>>>> of document approvals:>>>>>>>>>> Baruch Sterman - done
>>>>> (although we would like to know if you> agree>>>>> with the
>>>>> changes described below)>>>>> Daniel Sadolevsky - done>>>>>
>>>>> David Schwartz>>>>> David Williams>>>>> Wolfgang Beck>>>>
>>>>>>>>>>> Bernard Aboba - done>>>>>>>>>> We will wait to
>>>>> hear further before continuing on with the>>> publication>>>>>
>>>>> process.>>>>>>>>>> Thank you.>>>>>>>>>> RFC Editor>
>>>>>>>>>>>>>>>>>>> On Fri, Oct 19, 2007 at 01:33:14PM -0400,
>>>>> David Williams wrote:>>>>>> Hi Baruch,>>>>>>>>>>>>
>>>>> These look good, and I agree with your consistency comment. I>>>
>>>>> have a few>>>>>> more specific changes to suggest that I would
>>>>> like you and>> others>>> to>>>>>> review as well. But first
>>>>> a couple of general style comments>> that>>> require>>>>>>
>>>>> no changes to the document.>>>>>>>>>>>> General comment
>>>>> #1: I tried to find a definitive style guide> to>>> use of>>>>
>>>>>>> single quotes versus double quotes and found there is no hard>>
>>>>>> guidelines,>>>>>> that consistency is most important:>>>>
>>>>>>> http://en.wikipedia.org/wiki/Quotation_mark>>>>>>
>>>>> http://forum.wordreference.com/showthread.php?t=3D120946>>>>>>
>>>>> Though I tend to think that double quotes are more commonly> used>>
>>>>>> and match>>>>>> the syntax of more popular programming
>>>>> languages, but there> are>> so>>> many>>>>>> quoted items in
>>>>> the document and it has been this way for a> long>>> time, so>>>
>>>>>>>> best to leave as is.>>>>>>>>>>>> General comment #2:
>>>>> When refering to responses from the radius>>> server>>>>>>
>>>>> there are a lot of instances of a comment similiar to "without>>>
>>>>> surrounding>>>>>> quotes" that potentially could be removed for
>>>>> readability.>>> Especially if>>>>>> there were a more concise
>>>>> definition up-front about the> general>>> form of>>>>>>
>>>>> values returned from the radius server. But I am a little>>>
>>>>> hesitant to>>>>>> just strip them out now.>>>>>>>>>>>
>>>>>> Specific comments, to build on top of your list:>>>>>>>>>>
>>>>>>> In section 2.1.2, 1st paragraph should not have quotes around>>
>>>>>> nonce.>>>>>> Paragraph should read:>>>>>>>>>>>> If
>>>>> a matching (Proxy-)Authorization header is present and>>> contains>
>>>>>>>>>> HTTP Digest information, the RADIUS client checks the
>>>>> nonce>>>>>> parameter.>>>>>>>>>>>> In next paragraph,
>>>>> do not need quotes around response.>> Paragraph>>> should>>>>
>>>>>>> read:>>>>>>>>>>>> If the RADIUS client recognizes the
>>>>> nonce, it takes the>> header>>>>>> directives and puts them
>>>>> into a RADIUS Access-Request> packet.>>> It>>>>>> puts the
>>>>> response directive into a Digest-Response> attribute>>> and>>>>
>>>>>>> the realm, nonce, digest-uri, qop, algorithm, cnonce, nc,>>>
>>>>> username,>>>>>> and opaque directives into the respective
>>>>> Digest-Realm,>>> Digest-Nonce,>>>>>> Digest-URI, Digest-Qop,
>>>>> Digest-Algorithm, Digest-CNonce,>>> Digest->>>>>> Nonce-Count,
>>>>> Digest-Username, and Digest-Opaque attributes.>>> The>>>>>>
>>>>> RADIUS client puts the request method into the> Digest-Method>>>>
>>>>>>> attribute.>>>>>>>>>>>> In section 2.1.3, in addtion to
>>>>> the items you point out, in> the>>> last>>>>>> paragraph,
>>>>> nextnounce does not need quoting. Paragraph> should>>> read:>>>>
>>>>>>>>>>>>> When the RADIUS server provides a Digest-Nextnonce>
>>>>> attribute>> in>>> the>>>>>> Access-Accept packet, the RADIUS
>>>>> client puts the contents> of>>> this>>>>>> attribute into a
>>>>> nextnonce directive. Now it can send an>> HTTP->>>>>> style
>>>>> response.>>>>>>>>>>>> In section 2.1.4, 2nd paragraph, the
>>>>> stale directive should> not>>> need>>>>>> quoting. Paragraph
>>>>> should read:>>>>>>>>>>>> If the RADIUS client receives an
>>>>> Access-Challenge packet in>>> response>>>>>> to an
>>>>> Access-Request containing a Digest-Nonce attribute,> the>>> RADIUS>
>>>>>>>>>> server did not accept the nonce. If a Digest-Stale>
>>>>> attribute>>> is>>>>>> present in the Access-Challenge and has
>>>>> a value of 'true'>>> (without>>>>>> surrounding quotes), the
>>>>> RADIUS client sends an error>> response>>> (401>>>>>> or 407)
>>>>> containing a WWW-/Proxy-Authenticate header with> the>>>>>>
>>>>> directive stale and the digest directives derived from the>>>
>>>>> Digest-*>>>>>> attributes.>>>>>>>>>>>> Except I think
>>>>> the wording of the last sentence in this same>>> paragraph>>>>
>>>>>>> could be improved. So that the paragraph reads more like:>>>>
>>>>>>>>>>>>> If the RADIUS client receives an Access-Challenge
>>>>> packet in>>> response>>>>>> to an Access-Request containing a
>>>>> Digest-Nonce attribute,> the>>> RADIUS>>>>>> server did not
>>>>> accept the nonce. If a Digest-Stale> attribute>>> is>>>>>>
>>>>> present in the Access-Challenge and has a value of 'true'>>>
>>>>> (without>>>>>> surrounding quotes), the RADIUS client sends an
>>>>> error>> response>>> (401>>>>>> or 407) containing a
>>>>> WWW-/Proxy-Authenticate header with> the>>>>>> stale directive
>>>>> set to 'true' and the digest directives>> derived>>> from>>>>>
>>>>>> the Digest-* attributes.>>>>>>>>>>>> In section 3.10,
>>>>> 1st paragraph, I believe the term "qop-level">> is>>> ill>>>>
>>>>>>> defined and should not be used, that qop directive or> qop-value>
>>>>>>> would be>>>>>> better. In other words the paragraph should
>>>>> read:>>>>>>>>>>>> When using the qop-value 'auth-int', a
>>>>> hash of the>>> HTTP-style>>>>>> message body's contents is
>>>>> required for digest>>> calculation.>>>>>> Instead of sending
>>>>> the complete body of the message,>> only>>> its>>>>>> hash
>>>>> value is sent. This hash value can be used>> directly>>> in>>>>
>>>>>>> the digest calculation.>>>>>>>>>>>> In section 3.15,
>>>>> auth-param doesn't need quoting. So that the>>> paragraph>>>>>
>>>>>> becomes:>>>>>>>>>>>> This attribute is a placeholder for
>>>>> future extensions>> and>>>>>> corresponds to the auth-param
>>>>> parameter defined in>>> Section>>>>>> 3.2.1 of [RFC2617]. The
>>>>> Digest-Auth-Param is the>>> mechanism>>>>>> whereby the RADIUS
>>>>> client and RADIUS server can>> exchange>>> auth->>>>>> param
>>>>> extension parameters contained within Digest>>> headers that>>>>
>>>>>>> are not understood by the RADIUS client and for which>>> there
>>>>> are>>>>>> no corresponding stand-alone attributes.>>>>>>>
>>>>>>>>>> In section 3.17, domain doesn't need quoting. So that the>
>>>>>>> paragraph>>>>>> becomes:>>>>>>>>>>>> When a
>>>>> RADIUS client has asked for a nonce, the> RADIUS>>> server>>>>>
>>>>>> MAY send one or more Digest-Domain attributes in its>>> Access->
>>>>>>>>>> Challenge packet. The RADIUS client puts them into> the>>
>>>>>> quoted,>>>>>> space-separated list of URIs of the domain
>>>>> directive> of>> a>>>>>> WWW-Authenticate header. Together with
>>>>> Digest-Realm,>> the>>> URIs>>>>>> in the list define the
>>>>> protection space (see> [RFC2617],>>> Section>>>>>> 3.2.1) for
>>>>> some HTTP-style protocols. This attribute>>> MUST only>>>>>>
>>>>> be used in Access-Challenge and Accounting-Request>>> packets.>>>
>>>>>>>>>>>>>> In section 3.19, 1st paragraph, in addtion to no
>>>>> quotes around>>> rspauth as>>>>>> you pointed out, I believe
>>>>> there should be no quotes around> qop.>>> So that>>>>>> the
>>>>> paragraph reads:>>>>>>>>>>>> This attribute is used to
>>>>> allow the generation of an>>>>>> Authentication-Info header,
>>>>> even if the HTTP-style>>> response's>>>>>> body is required
>>>>> for the calculation of the rspauth>>> value.>>>>>> It SHOULD
>>>>> be used in Access-Accept packets if the>>> required>>>>>>
>>>>> quality of protection (qop) is 'auth-int'.>>>>>>>>>>>>
>>>>> thanks,>>>>>> -david>>>>>>>>>>>> On Fri, 19 Oct 2007,
>>>>> 1:43pm, Baruch Sterman wRote:>>>>>>>>>>>>>After lengthy
>>>>> discussions with my father-in-law who is a>>> professor of>>>>>
>>>>>>>English, I agree with Dave's method of using quotes only in> the>
>>>>>>> value of>>>>>>>an attribute/directive, but not in
>>>>> referencing the>>> attribute/directive>>>>>>>by name. As
>>>>> such, I have some changes.>>>>>>>>>>>>>>In section 2.1.3
>>>>> 3rd paragraph should not have quotes around>> the>>> word>>>>>
>>>>>>>rspauth. Sentence should read:>>>>>>>>>>>>>> * If the
>>>>> Digest-Qop attribute's value is 'auth' or not>>> specified,>>>>
>>>>>>>> the RADIUS client puts the Digest-Response-Auth>>>
>>>>> attribute's>>>>>>> content into the Authentication-Info
>>>>> header's rspauth>>>>>>> directive of the HTTP-style response.>
>>>>>>>>>>>>>>>>>>Same section 5th paragraph - no quotes around
>>>>> qop and>> algorithm:>>>>>>>>>>>>>> o If the
>>>>> Access-Accept packet contains a Digest-HA1>> attribute,>>> the>>
>>>>>>>>>> RADIUS client checks the qop and algorithm directives in>>
>>>>> the>>>>>>> Authorization header of the HTTP-style request it
>>>>> wants> to>>>>>>> authorize:>>>>>>>>>>>>>>Next
>>>>> paragraph - no quotes around qop>>>>>>>>>>>>>> * If the
>>>>> qop directive is missing or its value is> 'auth',>>> the>>>>>>
>>>>>> RADIUS client ignores the Digest-HA1 attribute. It>> does>>>
>>>>> not>>>>>>> include an Authentication-Info header in its>
>>>>> HTTP-style>>>>>>> response.>>>>>>>>>>>>>>Next
>>>>> paragraph - no quotes around qop or rspauth.>>>>>>>>>>>>>
>>>>>> * If the qop directive's value is 'auth-int' and at> least>>>
>>>>> one>>>>>>> of the following conditions is true, the RADIUS>
>>>>> client>>>>>>> calculates the contents of the HTTP-style
>>>>> response's>>> rspauth>>>>>>> directive:>>>>>>>>>>>>
>>>>>>>>>>>>>>2 paragraphs later - no quotes around rspauth>>>>
>>>>>>>>>>>>>>> The RADIUS client creates the HTTP-style response>
>>>>>> message>>> and>>>>>>> calculates the hash of this message's
>>>>> body. It uses>> the>>> result>>>>>>> and the Digest-URI
>>>>> attribute's value of the>> corresponding>>>>>>> Access-Request
>>>>> packet to perform the H(A2)> calculation.>>> It>>>>>>> takes
>>>>> the Digest-Nonce, Digest-Nonce-Count,>>> Digest-CNonce, and>>>>
>>>>>>>> Digest-Qop values of the corresponding Access-Request>> and>>
>>>>>> the>>>>>>> Digest-HA1 attribute's value to finish the>
>>>>> computation>> of>>> the>>>>>>> rspauth value.>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>Section 3.4 paragraph 1 - no
>>>>> quotes around rspauth>>>>>>>>>>>>>> This attribute
>>>>> enables the RADIUS server to prove>>> possession of>>>>>>>
>>>>> the password. If the previously received Digest-Qop>>> attribute>>
>>>>>>>>>> was 'auth-int' (without surrounding quotes), the> RADIUS>>
>>>>>> server>>>>>>> MUST send a Digest-HA1 attribute instead of a>
>>>>>>> Digest-Response->>>>>>> Auth attribute. The
>>>>> Digest-Response-Auth attribute>> MUST>>> only>>>>>>> be used
>>>>> in Access-Accept packets. The RADIUS client>> puts>>> the>>>>>
>>>>>>> attribute value without surrounding quotes into the>>> rspauth>
>>>>>>>>>>> directive of the Authentication-Info header.>>>>>>
>>>>>>>>>>>>>>>>>>>>Section 3.5 2nd paragraph - no quotes
>>>>> around nextnonce>>>>>>>>>>>>>> The RADIUS server MAY put
>>>>> a Digest-Nextnonce> attribute>>> into an>>>>>>> Access-Accept
>>>>> packet. If this attribute is present,>> the>>> RADIUS>>>>>>>
>>>>> client MUST put the contents of this attribute into> the>>>>>>>
>>>>> nextnonce directive of an Authentication-Info header> in>>> its>>
>>>>>>>>>> HTTP-style response. This attribute MUST only be> used>>
>>>>> in>>>>>>> Access-Accept packets.>>>>>>>>>>>>>>>>>
>>>>>>>>>Section 3.7, 4th paragraph - no quotes around uri>>>>>>
>>>>>>>>>>>>> If the HTTP-style request has an Authorization>
>>>>> header,>>> the>>>>>>> RADIUS client puts the value of the uri
>>>>> directive> found>>> in>>>>>>> the HTTP-style request
>>>>> Authorization header (known as>>> "digest->>>>>>> uri-value"
>>>>> in Section 3.2.2 of [RFC2617]) without>>> surrounding>>>>>>>
>>>>> quotes into this attribute. If there is no>> Authorization>>>>>
>>>>>>> header, the RADIUS client takes the value of the>> request>>>
>>>>> URI>>>>>>> from the HTTP-style request it wants to
>>>>> authenticate.>>>>>>>>>>>>>>>>>>>>>Section 3.8, 4th
>>>>> paragraph - no quotes around qop>>>>>>>>>>>>>> In
>>>>> Access-Requests, the RADIUS client takes the value>> of>>> the>>
>>>>>>>>>> qop directive (qop-value as described in [RFC2617])>>
>>>>> from>>> the>>>>>>> HTTP-style request it wants to
>>>>> authenticate. In>> Access->>>>>>> Challenge packets, the
>>>>> RADIUS server puts a desired>>> qop-value>>>>>>> into this
>>>>> attribute. If the RADIUS server supports>> more>>> than>>>>>>
>>>>>> one "quality of protection" value, it puts each>> qop-value>>>
>>>>> into>>>>>>> a separate Digest-Qop attribute.>>>>>>>>>>
>>>>>>>>>Section 3.18 1st paragraph - no quotes around stale>>>>>>
>>>>>>>>>>>>> This attribute is sent by a RADIUS server in order to>
>>>>>>> notify>>>>>>> the RADIUS client whether it has accepted a
>>>>> nonce.> If>>> the>>>>>>> nonce presented by the RADIUS client
>>>>> was stale, the>> value>>> is>>>>>>> 'true' and is 'false'
>>>>> otherwise. The RADIUS client>> puts>>> the>>>>>>> content of
>>>>> this attribute into a stale directive of> the>>> WWW->>>>>>>
>>>>> Authenticate header in the HTTP-style response to the>>> request>>
>>>>>>>>>> it wants to authenticate. The attribute MUST only be>>>
>>>>> used in>>>>>>> Access-Challenge packets.>>>>>>>>>>>>
>>>>>>>3.19 1st paragraph - no quotes around rspauth>>>>>>>>>>>
>>>>>>>> This attribute is used to allow the generation of an>>>>>>
>>>>>> Authentication-Info header, even if the HTTP-style>>> response's>
>>>>>>>>>>> body is required for the calculation of the rspauth>>>
>>>>> value.>>>>>>> It SHOULD be used in Access-Accept packets if
>>>>> the>>> required>>>>>>> quality of protection ('qop') is
>>>>> 'auth-int'.>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>I think that does it. Even if this is not right, at least it>
>>>>>>> should now>>>>>>>be consistent.>>>>>>>>>>>>>
>>>>>>Comments?>>>>>>>>>>>>>>Baruch>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>-----Original Message----->>>>>>>From:
>>>>> RFC Editor [mailto:[email-masked]]>>>>>>>Sent:
>>>>> Monday, October 15, 2007 8:45 PM>>>>>>>To: David Williams>>>
>>>>>>>>>Cc: Baruch Sterman; [email-masked]; David Schwartz;>>>
>>>>>>>>>[email-masked]; [email-masked];>>>>>>
>>>>>>[email-masked]; RFC Editor>>>>>>>Subject: Re:
>>>>> AUTH48 [SG]: RFC 5090>>> >>>
>>>>>>>>>NOW AVAILABLE>>>>>>>>>>>>>>Greeting all,>>>>>
>>>>>>>>>>>>>>We have not heard further regarding the issues below
>>>>> or other>>> changes>>>>>>>that may be required before
>>>>> publishing this document as an> RFC.>>>>>>>Please review the
>>>>> document and let us know if there are any>>>>>>>corrections
>>>>> required.>>>>>>>>>>>>>>
>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>>>>>
>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>>>>
>>>>>>>>>>>>>>We will wait to hear from you before continuing on
>>>>> with the>>>>>>>publication process.>>>>>>>>>>>>>
>>>>>>Thank you.>>>>>>>>>>>>>>RFC Editor>>>>>>>>>>>>
>>>>>>>On Sun, Oct 07, 2007 at 01:29:00PM -0400, David Williams> wrote:>
>>>>>>>>>>>>On Thu, 4 Oct 2007, 3:40pm, RFC Editor wRote:>>>>>>
>>>>>>>>>>>>>>>>Authors,>>>>>>>>>>>>>>>>>>While
>>>>> reviewing > during>>> AUTH48,>
>>>>>>>>>>>>>please consider the following.>>>>>>>>>>>>>>>
>>>>>>>>In previous dialog, we had the following exchange:>>>>>>>>>>
>>>>>>>>>>>>>>>2. Please explain the usage of the single quote marks
>>>>> (')>> in>>>>>>>>>>>this document. There seems to be
>>>>> inconsistency, but we> are>>>>>>>>>>>unable to determine which
>>>>> values/attributes/parameters> you>>>>>>>>>>>wanted to appear in
>>>>> quote marks. For example, we see>>>>>>>>>>>>>>>>>
>>>>>>>>>>'auth-int'/"auth-int">>>>>>>>>>>'rspauth'
>>>>> directive/rspauth directive>>>>>>>>>>>'rspauth' value/rspauth
>>>>> value>>>>>>>>>>>>>>>>>>>>>As RfC 2617 always uses ",
>>>>> replacing all 's in question> with>> ">>> seems>>>>>>>>>>the
>>>>> right thing to do.>>>>>>>>>>>>>>>>>>Please note that we
>>>>> did not replace all 's with "s because>>>>>>>>>RFC 4590 uses
>>>>> 's. However, if you feel that the document>>> should be>>>>>>
>>>>>>>>more alignmed with RFC 2617, please let us know and we will>>>
>>>>> make>>>>>>>>>this change.>>>>>>>>>>>>>>>>If we are
>>>>> taking a vote, I would prefer using " instead of '>>> around>>>>
>>>>>>>>the>>>>>>>>value strings. I think it is better to stay
>>>>> aligned with> 2617>>> rather>>>>>>>than>>>>>>>>4590.
>>>>> Also I believe the " usage is more commonly used in>> other>>>>>
>>>>>>>>specifications.>>>>>>>>>>>>>>>>>>>>>>>>>>Also,
>>>>> we had a difficult time understanding the use of 's.>> We>>>>>>
>>>>>>>>inserted 's around auth-int, auth, qop, and rspauth when> they>>
>>>>>> were>>>>>>>>>used as values or directives. However, we did
>>>>> not attempt> to>>> include>>>>>>>>>'s for *all* directives
>>>>> and values (e.g., realm and> opaque).>>> Please>>>>>>>>>let
>>>>> us know if this is not correct.>>>>>>>>>>>>>>>>I agree it
>>>>> is confusing. Looking at 2617 I don't think it> is>>> entirely>>>
>>>>>>>>>>>>>>>>>consistent either, as I see references to ["qop"
>>>>> directive]> as>>> well as>>>>>>>the>>>>>>>>unquoted
>>>>> form [qop directive].>>>>>>>>>>>>>>>>I am no authority on
>>>>> style but my initial thought is to>> suggest>>>>>>>removing '>
>>>>>>>>>>>>and " from keywords when refering to a directive name
>>>>> rather>>> than its>>>>>>>>literal value, and then use "" when
>>>>> refering to a value.> For>>> example,>>>>>>>the>>>>>>
>>>>>>>existing 5090 text would then become:>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> o If the Access-Accept packet contains a
>>>>> Digest-HA1>>> attribute, the>>>>>>>> RADIUS client checks the
>>>>> qop and algorithm directives> in>>> the>>>>>>>> Authorization
>>>>> header of the HTTP-style request it> wants>> to>>>>>>>>
>>>>> authorize:>>>>>>>>>>>>>>>> * If the qop directive is
>>>>> missing or its value is>> "auth",>>> the>>>>>>>> RADIUS
>>>>> client ignores the Digest-HA1 attribute. It>>> does not>>>>>>
>>>>>>> include an Authentication-Info header in its>> HTTP-style>>>>
>>>>>>>>> response.>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>However when examing 2617 in more detail, using " around the>>>
>>>>> directive>>>>>>>>>>>>>>>names would be more consistent
>>>>> with that draft. For example>>> this>>>>>>>would>>>>>>
>>>>>>>become:>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> o If the Access-Accept packet contains a Digest-HA1>>>
>>>>> attribute, the>>>>>>>> RADIUS client checks the "qop" and
>>>>> "algorithm">> directives>>> in the>>>>>>>> Authorization
>>>>> header of the HTTP-style request it> wants>> to>>>>>>>>
>>>>> authorize:>>>>>>>>>>>>>>>> * If the "qop" directive is
>>>>> missing or its value is>>> "auth", the>>>>>>>> RADIUS client
>>>>> ignores the Digest-HA1 attribute. It>>> does not>>>>>>>>
>>>>> include an Authentication-Info header in its>> HTTP-style>>>>>>
>>>>>>> response.>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>Prehaps others can weigh in one which they believe is most>
>>>>>>>>>>>appropriate.>>>>>>>>I believe either would be a
>>>>> slight improvement on the> existing>>> text>>>>>>>which>>>
>>>>>>>>>>uses single quotes around the string values.>>>>>>>>>>
>>>>>>>>>>>thanks,>>>>>>>>-david>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>Thank you.>>>>>>>>>>>>>>>>>>RFC Editor>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>On Thu, Oct 04, 2007 at
>>>>> 03:11:50PM -0700,>>> [email-masked]>>>>>>>wrote:>
>>>>>>>>>>>>>>>>>>>>>>>>****IMPORTANT*****>>>>>>>>>>>>>
>>>>>>>>>>>>Updated 2007/10/04>>>>>>>>>>>>>>>>>>>>RFC
>>>>> AUTHOR(S):>>>>>>>>>>-------------->>>>>>>>>>>>>>>>
>>>>>>>>>This is your LAST CHANCE to make changes to your RFC to> be:>>>
>>>>>>>>>>>>draft-ietf-radext-rfc4590bis-02.txt, once the document is>
>>>>>>> published>>>>>>>as>>>>>>>>>>an RFC we *WILL NOT* make
>>>>> any changes.>>>>>>>>>>>>>>>>>>>>Please check your
>>>>> document at:>>>>>>>>>>>>>>>>
>>>>>>>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>>>>
>>>>>>>>>>>>>>>>>>>ATTENTION: The editing process occasionally
>>>>> introduces>> errors>>> that>>>>>>>>>>were not in the
>>>>> Internet Draft. Although the RFC Editor>> tries>>> very>>>>>>
>>>>>>>>>hard to catch all errors, proofreading the text at least>>>
>>>>> twice,>>>>>>>typos>>>>>>>>>>can slip through. You, as an
>>>>> author of the RFC, are> taking>>>>>>>>>>responsibility for the
>>>>> correctness of the final product> when>>> you OK>>>>>>
>>>>>>>>>publication. You should therefore proofread the entire> RFC>>>
>>>>>>>>>carefully>>>>>>>>>>and without assumptions. Errors in
>>>>> RFCs last forever.>>>>>>>>>>>>>>>>>>>>NOTE: We have run a
>>>>> diff tool that compares the approved>>>>>>>internet-draft>>>
>>>>>>>>>>>>against our edited RFC version of the document. Please>>
>>>>> review>>> this>>>>>>>>>>file at:>>>>>>>>>>>>>>>>>
>>>>>>>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>>
>>>>>>>>>>>>>>>>>>>>>>Please note that we used a slightly altered
>>>>> version of the>>>>>>>originally>>>>>>>>>>submitted ID to
>>>>> create the diff file above. To make the>> file>>> more>>>>>>
>>>>>>>>>useful, we moved the terminology section to to appear> after>>>
>>>>> the>>>>>>>>>>introduction, but we did not alter the text.>>>
>>>>>>>>>>>>>>>>>>>>>>The document will NOT BE PUBLISHED until
>>>>> ALL of the> authors>>> listed>>>>>>>in>>>>>>>>>>the RFC
>>>>> have affirmed that the document is ready to be>>>>>>
>>>>>>>>>published, as ALL of the authors are equally responsible> for>>
>>>>>>>>>>verifying>>>>>>>>>>the documents readiness for
>>>>> publication.>>>>>>>>>>>>>>>>>>>>** Please send us a list
>>>>> of suitable keywords for this>>> document,>>>>>>>over>>>>
>>>>>>>>>>>and above those which appear in the title.>>>>>>>>>>>>
>>>>>>>>>>>>> Frequently INCORRECT information includes>>>>>>
>>>>>>>>>>>>>>>>>>> - Contact Information>>>>>>>>>> -
>>>>> References (are they up to date)>>>>>>>>>> - Section Numbers>>
>>>>>>>>>>>>> (especially if you originally put the copyright>>>>>
>>>>>>>somewhere>>>>>>>>>> other than the VERY end of the document,
>>>>> or if>> you>>>>>>>>>> numbered the 'Status of the Memo'
>>>>> field)>>>>>>>>>>>>>>>>>>>>Please send us the changes, *DO
>>>>> NOT* send a new document>> with>>> the>>>>>>>>>>changes
>>>>> made. (If we think that the changes might be more>>> than>>>>>
>>>>>>>>>>editorial we will contact the AD or the IESG to confirm> that>
>>>>>>> the>>>>>>>>>>changes do not require review.)>>>>>>
>>>>>>>>>>>>>>>>>>>Send us the changes in THIS format.>>>>>>
>>>>>>>>>>>>>>>>>>> 1)*** SECTION #'s*** [i.e. Section 5, 2nd>>>
>>>>> paragraph]>>>>>>>>>> 2) the text you want changed,>>>>>>
>>>>>>>>> 3) the new correct text and>>>>>>>>>> 4) if the changes
>>>>> are spacing or indentation> than>>> please>>>>>>>note>>>>
>>>>>>>>>>> that.>>>>>>>>>>>>>>>>>>>>FOR EXAMPLE:>>>>>>
>>>>>>>>>>>>>>>>>>> Section 5.6, 3rd paragraph>>>>>>>>>>>>>
>>>>>>>>>>>> OLD:>>>>>>>>>> The quick brown fox jumped over the
>>>>> lazy dog.>>>>>>>>>>>>>>>>>>>> NEW:>>>>>>>>>> The
>>>>> quick brown dog jumps over the lazy fox.>>>>>>>>>> ^^^ ^ ^^^>>
>>>>>>>>>>>>>If you have a whole paragraph to replace you do not need>
>>>>> to>>> use>>>>>>>>>>the arrow to point out the differences>>
>>>>>>>>>>>>>>>>>>>>>>> INTRODUCTION, 2nd paragraph>>>>>>
>>>>>>>>>>>>>>>>>>> Replace OLD:>>>>>>>>>>>>>>>>>>>>
>>>>> alsdfja;sldjf;lajsd;fljas;dlfj;>>>>>>>>>>>>>>>>>>>> With
>>>>> NEW:>>>>>>>>>>>>>>>>>>>> nv;alkjd;lsf;aoisj;ltjka;sldkjf>
>>>>>>>>>>>>>>>>>>>>>>>>Spacing or indentation problems...>>>
>>>>>>>>>>>>>>>>>>>>>> Section 10, 1st paragraph (remove spaces>
>>>>> between>>> bit>>>>>>>>>> and of, add space after butter)>>>
>>>>>>>>>>>>>>>>>>>>>> OLD:>>>>>>>>>>>>>>>>>>>>
>>>>> Better botter bought a bit>>>>>>>>>> of bitter butterMary mary
>>>>> quite contrary>>>>>>>>>>>>>>>>>>>> NEW:>>>>>>>>>>>
>>>>>>>>>>>>>> Better botter bought a bit of bitter butter>>>>>>
>>>>>>>>>>>>>>>>>>> Mary mary quite contrary>>>>>>>>>>>>>>
>>>>>>>>>>>This document will NOT be published until we receive>>>
>>>>> agreement, from>>>>>>>>>>ALL listed authors, that the document
>>>>> is ready for>>> publication.>>>>>>>>>>>>>>>>>>>>Thanks
>>>>> for your cooperation,>>>>>>>>>>>>>>>>>>>>-RFC Editor>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Title : RADIUS Extension
>>>>> for Digest>>>>>>>>>> Authentication>>>>>>>>>>Author(s) :
>>>>> B. Sterman, D. Sadolevsky,>>>>>>>>>> D. Schwartz, D. Williams,>
>>>>>>>>>>>>>> W. Beck>>>>>>>>>>Working Group Chair(s) :
>>>>> Bernard Aboba, David Nelson>>>>>>>>>>Area Director(s) : Dan
>>>>> Romascanu, Ronald Bonica>>>>>>>>>>>>>>>>
>=20
> --=20
> Mike McCauley                               [email-masked]
> Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
> 9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.=
au
> Phone +61 7 5598-7474                       Fax   +61 7 5598-7070
>=20
> Radiator: the most portable, flexible and configurable RADIUS server=20
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,=20
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,=20
> TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc.

Delivery-date: Sun, 23 Dec 2007 05:52:02 +0000
From: Mike McCauley <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: FW: AUTH48 [SG]: RFC 5090  <draft-ietf-radext-rfc4590bis-02.txt> NOW AVAILABLE
Date: Sun, 23 Dec 2007 15:50:37 +1000
Cc: [email-masked]

Hi Bernard,

Have the test vectors in section 6 Examples been checked? How? Im not sure I 
entirely agree with the Digest-Response values in the B->C messages

Cheers.

On Sunday 23 December 2007 03:37, Bernard Aboba wrote:
> RFC 4590bis is now being held in AUTH48, pending final verification.
>
> What started as a "simple" IANA-problem fix has turned into a longer
> odyssey due to the discovery of additional errors/omissions.
>
> In attempt to bring this story to a close, we need to make very sure that
> we have looked over this document carefully so that we don't have to go
> through this again with RFC 4590ter.
>
> So if you have ever had any interest in RADIUS Digest Authentication, now
> would be the time to look over the AUTH48 version of the document, and
> speak up if there is a problem.
>
> > Date: Fri, 21 Dec 2007 15:14:46 -0800
> > From: [email-masked]
> > To: [email-masked]
> > CC: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked];
> > [email-masked] Subject: Re: AUTH48 [SG]: RFC 5090 
> > <draft-ietf-radext-rfc4590bis-02.txt> NOW AVAILABLE
> >
> > Greeings Wolfgang,
> >
> > Just a reminder that we are waiting to hear from you before continuing
> > on with the publication process.
> >
> > Please see the email below for document information.
> >
> > Thank you.
> >
> > RFC Editor
> >
> > On Fri, Dec 14, 2007 at 02:51:11PM -0800, RFC Editor wrote:
> > > Hi Wolfgang,
> > >
> > > Just a friendly reminder that we are waiting to hear from you before
> > > continuing on with the publication process for RFC 5090
> > > <draft-ietf-radext-rfc4590bis-09.txt>.
> > >
> > > Please review the files located at:
> > >
> > >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt
> > >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html
> > >
> > > Note that this diff file highlights only the differences between the
> > > last posted version of the document and the current text file.  The
> > > previously posted versions (during AUTH48) are available as:
> > >
> > > The originally posted AUTH48 files:
> > >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt
> > >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html
> > >
> > > Version 2 (includes author updates) of AUTH48 files:
> > >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt
> > >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html
> > > Note that this file highlights only the differences between the
> > > version 1 and 2 text files.
> > >
> > > We will wait to hear from you before continuing on with the
> > > publication process.
> > >
> > > Thank you.
> > >
> > > RFC Editor/sg
> > >
> > > On Tue, Dec 11, 2007 at 05:08:35AM -0800, Bernard Aboba wrote:
> > > > I also talked to Wolfgang at IETF 70.  He wanted to check the
> > > > document over carefully to make sure there were no further issues.  
> > > > > Subject: RE: AUTH48 [SG]: RFC 5090
> > > > <draft-ietf-radext-rfc4590bis-02.txt> NOW AVAILABLE> Date: Mon, 10
> > > > Dec 2007 20:30:51 +0200> From: [email-masked]> To:
> > > > [email-masked]; [email-masked]> CC:
> > > > [email-masked]; [email-masked]; [email-masked];
> > > > [email-masked]; [email-masked]; [email-masked];
> > > > [email-masked]> > Yes,> > David Schwartz saw him at the ietf
> > > > meeting and worked through the draft> with him. I think we should be
> > > > hearing from him soon.> > Baruch> > > -----Original Message----->
> > > > From: RFC Editor [mailto:[email-masked]] > Sent: Monday,
> > > > December 10, 2007 8:27 PM> To: [email-masked]; Baruch Sterman>
> > > > Cc: David Schwartz; RFC Editor; [email-masked];
> > > > [email-masked];> Dan Romascanu; Ronald Bonica;
> > > > [email-masked];> [email-masked]> Subject: Re:
> > > > AUTH48 [SG]: RFC 5090 <draft-ietf-radext-rfc4590bis-02.txt>> NOW
> > > > AVAILABLE> > All,> > Just checking to see if you have had any luck
> > > > contacting Wolfgang?> > Thanks!> > RFC Editor/sg> > On Tue, Nov 27,
> > > > 2007 at 09:21:45PM +0200, Baruch Sterman wrote:> > David Schwartz
> > > > will be at the IETF meetings next week. Maybe Wolfgang> > will be
> > > > there and he can nudge him to answer. Lets hold off until we> see> >
> > > > if that way forward works. If not, we can go with option 3.> > > >
> > > > Thanks,> > > > Baruch> > > > > > -----Original Message-----> > From:
> > > > RFC Editor [mailto:[email-masked]] > > Sent: Tuesday,
> > > > November 27, 2007 12:41 AM> > To: Baruch Sterman> > Cc: RFC Editor> >
> > > > Subject: Re: AUTH48 [SG]: RFC 5090>
> > > > <draft-ietf-radext-rfc4590bis-02.txt>> > NOW AVAILABLE> > > > Hi
> > > > Baruch,> > > > We have a couple of ways to move forward.> > > > 1.
> > > > The author can be removed as an author, and moved to the> >
> > > > Acknowledgements section.> > > > 2. We can create a Contributor's
> > > > section and have him listed there.> > > > 3. We can request that the
> > > > AD approve the document in place of the> > unavailabe author. > > > >
> > > > Option 3 has been done before in instances where the missing author>
> > > > > made sizeable contributions to the document, so the other authors>
> > > > > did not feel comfortable removing the individuals name as an> >
> > > > author. > > > > It sounds as though 3 may be the proper way forward.
> > > > If this is the> > case, we will send an email to the ADs requesting
> > > > their approval in> > place of Wolfgang (the message will be cc'ed to
> > > > all relevant> > parties, including Wolfgang). > > > > If the above
> > > > suggestions are unacceptable and you have an alternative> > solution,
> > > > please let us know. > > > > Thank you.> > > > RFC Editor> > > > On
> > > > Mon, Nov 26, 2007 at 09:39:09AM +0200, Baruch Sterman wrote:> > > I
> > > > wrote to Wolfgang as well, but got no response. What is the> >
> > > > procedure> > > in this case? I am sure that Wolfgang would be ok with
> > > > the changes.> > The> > > last email I received was on October 19
> > > > where he said that he had> made> > > the one correction (suggested by
> > > > Ellermann) in the cnonce value. > > > > > > Baruch> > > > > > > > >
> > > > -----Original Message-----> > > From: RFC Editor
> > > > [mailto:[email-masked]] > > > Sent: Wednesday, November
> > > > 21, 2007 10:35 PM> > > To: David Williams; Baruch Sterman;
> > > > [email-masked]; David> > Schwartz;> > > [email-masked]> > >
> > > > Cc: [email-masked]; [email-masked]; RFC> >
> > > > Editor> > > Subject: Re: AUTH48 [SG]: RFC 5090> >
> > > > <draft-ietf-radext-rfc4590bis-02.txt>> > > NOW AVAILABLE> > > > > >
> > > > Greetings Wolfgang,> > > > > > We do not believe we have received
> > > > your response regarding this> > > document's readiness for
> > > > publication as an RFC. Please review the> > > text and let us know if
> > > > you are content with the document as it now> > > appears at:> > > > >
> > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt> > >
> > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html> > > Note
> > > > that this diff file highlights only the changes between the> last > >
> > > > > posted version of the document and the current text file.> > > > >
> > > > > > > > The last versions of the document are available as:> > > > >
> > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt> > >
> > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html> > > >
> > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt> > >
> > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html> > >
> > > > Note that this diff file highlights only the changes between v1 and>
> > > > > > the v2.> > > > > > We will wait to hear from you before
> > > > continuing on with the> > > publication process.> > > > > > Thank
> > > > you.> > > > > > RFC Editor> > > > > > On Fri, Nov 16, 2007 at
> > > > 05:13:04PM -0800, RFC Editor wrote:> > > > Authors,> > > > > > > > We
> > > > have corrected the text as indicated below and posted the> revised> >
> > > > > > version of the document at:> > > > > > > >
> > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt> > > >
> > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html> > > >
> > > > Note that this diff file highlights only the changes betwee the>
> > > > last> > > > > > posted version of the document and the current text
> > > > file.> > > > > > > > Please review the document and let us know if
> > > > you approve this> > > > text for publication.> > > > > > > > We
> > > > believe we are waiting for the following approvals:> > > > > > > >
> > > > Baruch Sterman - done > > > > Daniel Sadolevsky - done> > > > David
> > > > Schwartz - done> > > > David Williams> > > > Wolfgang Beck> > > > > >
> > > > > > Bernard Aboba - done> > > > > > > > > > > > Thank you.> > > > > >
> > > > > > RFC Editor> > > > > > > > > > > > On Tue, Nov 06, 2007 at
> > > > 04:58:49PM -0800, RFC Editor wrote:> > > > > Authors,> > > > > > > >
> > > > > > Please confer and let us know how the text should/should not use>
> > > > > the> > > > > quote marks. It sounds as though this email was for
> > > > discussion.> > If> > > > > the changes below are acceptable, we will
> > > > make the changes and> > post> > > a> > > > > revised version of the
> > > > document.> > > > > > > > > > Also, please note the following status
> > > > of document approvals:> > > > > > > > > > Baruch Sterman - done
> > > > (although we would like to know if you> agree> > > > > with the
> > > > changes described below)> > > > > Daniel Sadolevsky - done> > > > >
> > > > David Schwartz> > > > > David Williams> > > > > Wolfgang Beck> > > >
> > > > > > > > > > Bernard Aboba - done> > > > > > > > > > We will wait to
> > > > hear further before continuing on with the> > > publication> > > > >
> > > > process.> > > > > > > > > > Thank you.> > > > > > > > > > RFC Editor>
> > > > > > > > > > > > > > > > > > On Fri, Oct 19, 2007 at 01:33:14PM -0400,
> > > > David Williams wrote:> > > > > > Hi Baruch,> > > > > > > > > > > >
> > > > These look good, and I agree with your consistency comment. I> > >
> > > > have a few > > > > > > more specific changes to suggest that I would
> > > > like you and> > others> > > to > > > > > > review as well. But first
> > > > a couple of general style comments> > that> > > require > > > > > >
> > > > no changes to the document.> > > > > > > > > > > > General comment
> > > > #1: I tried to find a definitive style guide> to> > > use of > > > >
> > > > > > single quotes versus double quotes and found there is no hard> >
> > > > > guidelines, > > > > > > that consistency is most important:> > > >
> > > > > > http://en.wikipedia.org/wiki/Quotation_mark> > > > > >
> > > > http://forum.wordreference.com/showthread.php?t=120946> > > > > >
> > > > Though I tend to think that double quotes are more commonly> used> >
> > > > > and match > > > > > > the syntax of more popular programming
> > > > languages, but there> are> > so> > > many > > > > > > quoted items in
> > > > the document and it has been this way for a> long> > > time, so > > >
> > > > > > > best to leave as is.> > > > > > > > > > > > General comment #2:
> > > > When refering to responses from the radius> > > server > > > > > >
> > > > there are a lot of instances of a comment similiar to "without> > >
> > > > surrounding > > > > > > quotes" that potentially could be removed for
> > > > readability.> > > Especially if > > > > > > there were a more concise
> > > > definition up-front about the> general> > > form of > > > > > >
> > > > values returned from the radius server. But I am a little> > >
> > > > hesitant to > > > > > > just strip them out now.> > > > > > > > > > >
> > > > > Specific comments, to build on top of your list:> > > > > > > > > >
> > > > > > In section 2.1.2, 1st paragraph should not have quotes around> >
> > > > > nonce. > > > > > > Paragraph should read:> > > > > > > > > > > > If
> > > > a matching (Proxy-)Authorization header is present and> > > contains>
> > > > > > > > > HTTP Digest information, the RADIUS client checks the
> > > > nonce> > > > > > parameter.> > > > > > > > > > > > In next paragraph,
> > > > do not need quotes around response.> > Paragraph> > > should > > > >
> > > > > > read:> > > > > > > > > > > > If the RADIUS client recognizes the
> > > > nonce, it takes the> > header> > > > > > directives and puts them
> > > > into a RADIUS Access-Request> packet.> > > It> > > > > > puts the
> > > > response directive into a Digest-Response> attribute> > > and> > > >
> > > > > > the realm, nonce, digest-uri, qop, algorithm, cnonce, nc,> > >
> > > > username,> > > > > > and opaque directives into the respective
> > > > Digest-Realm,> > > Digest-Nonce,> > > > > > Digest-URI, Digest-Qop,
> > > > Digest-Algorithm, Digest-CNonce,> > > Digest-> > > > > > Nonce-Count,
> > > > Digest-Username, and Digest-Opaque attributes.> > > The> > > > > >
> > > > RADIUS client puts the request method into the> Digest-Method> > > >
> > > > > > attribute.> > > > > > > > > > > > In section 2.1.3, in addtion to
> > > > the items you point out, in> the> > > last > > > > > > paragraph,
> > > > nextnounce does not need quoting. Paragraph> should> > > read:> > > >
> > > > > > > > > > > > When the RADIUS server provides a Digest-Nextnonce>
> > > > attribute> > in> > > the> > > > > > Access-Accept packet, the RADIUS
> > > > client puts the contents> of> > > this> > > > > > attribute into a
> > > > nextnonce directive. Now it can send an> > HTTP-> > > > > > style
> > > > response.> > > > > > > > > > > > In section 2.1.4, 2nd paragraph, the
> > > > stale directive should> not> > > need > > > > > > quoting. Paragraph
> > > > should read:> > > > > > > > > > > > If the RADIUS client receives an
> > > > Access-Challenge packet in> > > response> > > > > > to an
> > > > Access-Request containing a Digest-Nonce attribute,> the> > > RADIUS>
> > > > > > > > > server did not accept the nonce. If a Digest-Stale>
> > > > attribute> > > is> > > > > > present in the Access-Challenge and has
> > > > a value of 'true'> > > (without> > > > > > surrounding quotes), the
> > > > RADIUS client sends an error> > response> > > (401> > > > > > or 407)
> > > > containing a WWW-/Proxy-Authenticate header with> the> > > > > >
> > > > directive stale and the digest directives derived from the> > >
> > > > Digest-*> > > > > > attributes.> > > > > > > > > > > > Except I think
> > > > the wording of the last sentence in this same> > > paragraph > > > >
> > > > > > could be improved. So that the paragraph reads more like:> > > >
> > > > > > > > > > > > If the RADIUS client receives an Access-Challenge
> > > > packet in> > > response> > > > > > to an Access-Request containing a
> > > > Digest-Nonce attribute,> the> > > RADIUS> > > > > > server did not
> > > > accept the nonce. If a Digest-Stale> attribute> > > is> > > > > >
> > > > present in the Access-Challenge and has a value of 'true'> > >
> > > > (without> > > > > > surrounding quotes), the RADIUS client sends an
> > > > error> > response> > > (401> > > > > > or 407) containing a
> > > > WWW-/Proxy-Authenticate header with> the> > > > > > stale directive
> > > > set to 'true' and the digest directives> > derived> > > from> > > > >
> > > > > the Digest-* attributes.> > > > > > > > > > > > In section 3.10,
> > > > 1st paragraph, I believe the term "qop-level"> > is> > > ill > > > >
> > > > > > defined and should not be used, that qop directive or> qop-value>
> > > > > > would be > > > > > > better. In other words the paragraph should
> > > > read:> > > > > > > > > > > > When using the qop-value 'auth-int', a
> > > > hash of the> > > HTTP-style> > > > > > message body's contents is
> > > > required for digest> > > calculation.> > > > > > Instead of sending
> > > > the complete body of the message,> > only> > > its> > > > > > hash
> > > > value is sent. This hash value can be used> > directly> > > in> > > >
> > > > > > the digest calculation.> > > > > > > > > > > > In section 3.15,
> > > > auth-param doesn't need quoting. So that the> > > paragraph > > > > >
> > > > > becomes:> > > > > > > > > > > > This attribute is a placeholder for
> > > > future extensions> > and> > > > > > corresponds to the auth-param
> > > > parameter defined in> > > Section> > > > > > 3.2.1 of [RFC2617]. The
> > > > Digest-Auth-Param is the> > > mechanism> > > > > > whereby the RADIUS
> > > > client and RADIUS server can> > exchange> > > auth-> > > > > > param
> > > > extension parameters contained within Digest> > > headers that> > > >
> > > > > > are not understood by the RADIUS client and for which> > > there
> > > > are> > > > > > no corresponding stand-alone attributes.> > > > > > >
> > > > > > > > > In section 3.17, domain doesn't need quoting. So that the>
> > > > > > paragraph > > > > > > becomes:> > > > > > > > > > > > When a
> > > > RADIUS client has asked for a nonce, the> RADIUS> > > server> > > > >
> > > > > MAY send one or more Digest-Domain attributes in its> > > Access->
> > > > > > > > > Challenge packet. The RADIUS client puts them into> the> >
> > > > > quoted,> > > > > > space-separated list of URIs of the domain
> > > > directive> of> > a> > > > > > WWW-Authenticate header. Together with
> > > > Digest-Realm,> > the> > > URIs> > > > > > in the list define the
> > > > protection space (see> [RFC2617],> > > Section> > > > > > 3.2.1) for
> > > > some HTTP-style protocols. This attribute> > > MUST only> > > > > >
> > > > be used in Access-Challenge and Accounting-Request> > > packets.> > >
> > > > > > > > > > > > > In section 3.19, 1st paragraph, in addtion to no
> > > > quotes around> > > rspauth as > > > > > > you pointed out, I believe
> > > > there should be no quotes around> qop.> > > So that > > > > > > the
> > > > paragraph reads:> > > > > > > > > > > > This attribute is used to
> > > > allow the generation of an> > > > > > Authentication-Info header,
> > > > even if the HTTP-style> > > response's> > > > > > body is required
> > > > for the calculation of the rspauth> > > value.> > > > > > It SHOULD
> > > > be used in Access-Accept packets if the> > > required> > > > > >
> > > > quality of protection (qop) is 'auth-int'.> > > > > > > > > > > >
> > > > thanks,> > > > > > -david> > > > > > > > > > > > On Fri, 19 Oct 2007,
> > > > 1:43pm, Baruch Sterman wRote:> > > > > > > > > > > > >After lengthy
> > > > discussions with my father-in-law who is a> > > professor of> > > > >
> > > > > >English, I agree with Dave's method of using quotes only in> the>
> > > > > > value of> > > > > > >an attribute/directive, but not in
> > > > referencing the> > > attribute/directive> > > > > > >by name. As
> > > > such, I have some changes.> > > > > > >> > > > > > >In section 2.1.3
> > > > 3rd paragraph should not have quotes around> > the> > > word> > > > >
> > > > > >rspauth. Sentence should read:> > > > > > >> > > > > > > * If the
> > > > Digest-Qop attribute's value is 'auth' or not> > > specified,> > > >
> > > > > > > the RADIUS client puts the Digest-Response-Auth> > >
> > > > attribute's> > > > > > > content into the Authentication-Info
> > > > header's rspauth> > > > > > > directive of the HTTP-style response.>
> > > > > > > > > >> > > > > > >Same section 5th paragraph - no quotes around
> > > > qop and> > algorithm:> > > > > > >> > > > > > > o If the
> > > > Access-Accept packet contains a Digest-HA1> > attribute,> > > the> >
> > > > > > > > > RADIUS client checks the qop and algorithm directives in> >
> > > > the> > > > > > > Authorization header of the HTTP-style request it
> > > > wants> to> > > > > > > authorize:> > > > > > >> > > > > > >Next
> > > > paragraph - no quotes around qop> > > > > > >> > > > > > > * If the
> > > > qop directive is missing or its value is> 'auth',> > > the> > > > > >
> > > > > RADIUS client ignores the Digest-HA1 attribute. It> > does> > >
> > > > not> > > > > > > include an Authentication-Info header in its>
> > > > HTTP-style> > > > > > > response.> > > > > > >> > > > > > >Next
> > > > paragraph - no quotes around qop or rspauth.> > > > > > >> > > > > >
> > > > > * If the qop directive's value is 'auth-int' and at> least> > >
> > > > one> > > > > > > of the following conditions is true, the RADIUS>
> > > > client> > > > > > > calculates the contents of the HTTP-style
> > > > response's> > > rspauth> > > > > > > directive:> > > > > > >> > > > >
> > > > > >> > > > > > >2 paragraphs later - no quotes around rspauth> > > >
> > > > > > >> > > > > > > The RADIUS client creates the HTTP-style response>
> > > > > message> > > and> > > > > > > calculates the hash of this message's
> > > > body. It uses> > the> > > result> > > > > > > and the Digest-URI
> > > > attribute's value of the> > corresponding> > > > > > > Access-Request
> > > > packet to perform the H(A2)> calculation.> > > It> > > > > > > takes
> > > > the Digest-Nonce, Digest-Nonce-Count,> > > Digest-CNonce, and> > > >
> > > > > > > Digest-Qop values of the corresponding Access-Request> > and> >
> > > > > the> > > > > > > Digest-HA1 attribute's value to finish the>
> > > > computation> > of> > > the> > > > > > > rspauth value.> > > > > > >>
> > > > > > > > > >> > > > > > >> > > > > > >Section 3.4 paragraph 1 - no
> > > > quotes around rspauth> > > > > > >> > > > > > > This attribute
> > > > enables the RADIUS server to prove> > > possession of> > > > > > >
> > > > the password. If the previously received Digest-Qop> > > attribute> >
> > > > > > > > > was 'auth-int' (without surrounding quotes), the> RADIUS> >
> > > > > server> > > > > > > MUST send a Digest-HA1 attribute instead of a>
> > > > > > Digest-Response-> > > > > > > Auth attribute. The
> > > > Digest-Response-Auth attribute> > MUST> > > only> > > > > > > be used
> > > > in Access-Accept packets. The RADIUS client> > puts> > > the> > > > >
> > > > > > attribute value without surrounding quotes into the> > > rspauth>
> > > > > > > > > > directive of the Authentication-Info header.> > > > > >
> > > > >> > > > > > >> > > > > > >Section 3.5 2nd paragraph - no quotes
> > > > around nextnonce> > > > > > >> > > > > > > The RADIUS server MAY put
> > > > a Digest-Nextnonce> attribute> > > into an> > > > > > > Access-Accept
> > > > packet. If this attribute is present,> > the> > > RADIUS> > > > > > >
> > > > client MUST put the contents of this attribute into> the> > > > > > >
> > > > nextnonce directive of an Authentication-Info header> in> > > its> >
> > > > > > > > > HTTP-style response. This attribute MUST only be> used> >
> > > > in> > > > > > > Access-Accept packets.> > > > > > >> > > > > > >> > >
> > > > > > > >Section 3.7, 4th paragraph - no quotes around uri> > > > > >
> > > > >> > > > > > > If the HTTP-style request has an Authorization>
> > > > header,> > > the> > > > > > > RADIUS client puts the value of the uri
> > > > directive> found> > > in> > > > > > > the HTTP-style request
> > > > Authorization header (known as> > > "digest-> > > > > > > uri-value"
> > > > in Section 3.2.2 of [RFC2617]) without> > > surrounding> > > > > > >
> > > > quotes into this attribute. If there is no> > Authorization> > > > >
> > > > > > header, the RADIUS client takes the value of the> > request> > >
> > > > URI> > > > > > > from the HTTP-style request it wants to
> > > > authenticate.> > > > > > >> > > > > > >> > > > > > >Section 3.8, 4th
> > > > paragraph - no quotes around qop> > > > > > >> > > > > > > In
> > > > Access-Requests, the RADIUS client takes the value> > of> > > the> >
> > > > > > > > > qop directive (qop-value as described in [RFC2617])> >
> > > > from> > > the> > > > > > > HTTP-style request it wants to
> > > > authenticate. In> > Access-> > > > > > > Challenge packets, the
> > > > RADIUS server puts a desired> > > qop-value> > > > > > > into this
> > > > attribute. If the RADIUS server supports> > more> > > than> > > > > >
> > > > > one "quality of protection" value, it puts each> > qop-value> > >
> > > > into> > > > > > > a separate Digest-Qop attribute.> > > > > > >> > >
> > > > > > > >Section 3.18 1st paragraph - no quotes around stale> > > > > >
> > > > >> > > > > > > This attribute is sent by a RADIUS server in order to>
> > > > > > notify> > > > > > > the RADIUS client whether it has accepted a
> > > > nonce.> If> > > the> > > > > > > nonce presented by the RADIUS client
> > > > was stale, the> > value> > > is> > > > > > > 'true' and is 'false'
> > > > otherwise. The RADIUS client> > puts> > > the> > > > > > > content of
> > > > this attribute into a stale directive of> the> > > WWW-> > > > > > >
> > > > Authenticate header in the HTTP-style response to the> > > request> >
> > > > > > > > > it wants to authenticate. The attribute MUST only be> > >
> > > > used in> > > > > > > Access-Challenge packets.> > > > > > >> > > > >
> > > > > >3.19 1st paragraph - no quotes around rspauth> > > > > > >> > > >
> > > > > > > This attribute is used to allow the generation of an> > > > > >
> > > > > Authentication-Info header, even if the HTTP-style> > > response's>
> > > > > > > > > > body is required for the calculation of the rspauth> > >
> > > > value.> > > > > > > It SHOULD be used in Access-Accept packets if
> > > > the> > > required> > > > > > > quality of protection ('qop') is
> > > > 'auth-int'.> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > >
> > > > > > > >I think that does it. Even if this is not right, at least it>
> > > > > > should now> > > > > > >be consistent.> > > > > > >> > > > > >
> > > > >Comments?> > > > > > >> > > > > > >Baruch> > > > > > >> > > > > > >>
> > > > > > > > > >> > > > > > >-----Original Message-----> > > > > > >From:
> > > > RFC Editor [mailto:[email-masked]]> > > > > > >Sent:
> > > > Monday, October 15, 2007 8:45 PM> > > > > > >To: David Williams> > >
> > > > > > > >Cc: Baruch Sterman; [email-masked]; David Schwartz;> > >
> > > > > > > >[email-masked]; [email-masked];> > > > > >
> > > > >[email-masked]; RFC Editor> > > > > > >Subject: Re:
> > > > AUTH48 [SG]: RFC 5090> > > <draft-ietf-radext-rfc4590bis-02.txt>> > >
> > > > > > > >NOW AVAILABLE> > > > > > >> > > > > > >Greeting all,> > > > >
> > > > > >> > > > > > >We have not heard further regarding the issues below
> > > > or other> > > changes> > > > > > >that may be required before
> > > > publishing this document as an> RFC.> > > > > > >Please review the
> > > > document and let us know if there are any> > > > > > >corrections
> > > > required.> > > > > > >> > > > > > >
> > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt> > > > > > >
> > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html> > > > >
> > > > > >> > > > > > >We will wait to hear from you before continuing on
> > > > with the> > > > > > >publication process.> > > > > > >> > > > > >
> > > > >Thank you.> > > > > > >> > > > > > >RFC Editor> > > > > > >> > > > >
> > > > > >On Sun, Oct 07, 2007 at 01:29:00PM -0400, David Williams> wrote:>
> > > > > > > > > >>On Thu, 4 Oct 2007, 3:40pm, RFC Editor wRote:> > > > > >
> > > > >>> > > > > > >>>Authors,> > > > > > >>>> > > > > > >>>While
> > > > reviewing <draft-ietf-radext-rfc4590bis-02.txt>> during> > > AUTH48,>
> > > > > > > > > >>>please consider the following.> > > > > > >>>> > > > > >
> > > > >>>In previous dialog, we had the following exchange:> > > > > > >>>>
> > > > > > > > > >>>>>2. Please explain the usage of the single quote marks
> > > > (')> > in> > > > > > >>>>>this document. There seems to be
> > > > inconsistency, but we> are> > > > > > >>>>>unable to determine which
> > > > values/attributes/parameters> you> > > > > > >>>>>wanted to appear in
> > > > quote marks. For example, we see> > > > > > >>>>>> > > > > >
> > > > >>>>>'auth-int'/"auth-int"> > > > > > >>>>>'rspauth'
> > > > directive/rspauth directive> > > > > > >>>>>'rspauth' value/rspauth
> > > > value> > > > > > >>>>>> > > > > > >>>>As RfC 2617 always uses ",
> > > > replacing all 's in question> with> > "> > > seems> > > > > > >>>>the
> > > > right thing to do.> > > > > > >>>> > > > > > >>>Please note that we
> > > > did not replace all 's with "s because> > > > > > >>>RFC 4590 uses
> > > > 's. However, if you feel that the document> > > should be> > > > > >
> > > > >>>more alignmed with RFC 2617, please let us know and we will> > >
> > > > make> > > > > > >>>this change.> > > > > > >>> > > > > > >>If we are
> > > > taking a vote, I would prefer using " instead of '> > > around> > > >
> > > > > > >the> > > > > > >>value strings. I think it is better to stay
> > > > aligned with> 2617> > > rather> > > > > > >than> > > > > > >>4590.
> > > > Also I believe the " usage is more commonly used in> > other> > > > >
> > > > > >>specifications.> > > > > > >>> > > > > > >>>> > > > > > >>>Also,
> > > > we had a difficult time understanding the use of 's.> > We> > > > > >
> > > > >>>inserted 's around auth-int, auth, qop, and rspauth when> they> >
> > > > > were> > > > > > >>>used as values or directives. However, we did
> > > > not attempt> to> > > include> > > > > > >>>'s for *all* directives
> > > > and values (e.g., realm and> opaque).> > > Please> > > > > > >>>let
> > > > us know if this is not correct.> > > > > > >>> > > > > > >>I agree it
> > > > is confusing. Looking at 2617 I don't think it> is> > > entirely> > >
> > > > > > > >> > > > > > >>consistent either, as I see references to ["qop"
> > > > directive]> as> > > well as> > > > > > >the> > > > > > >>unquoted
> > > > form [qop directive].> > > > > > >>> > > > > > >>I am no authority on
> > > > style but my initial thought is to> > suggest> > > > > > >removing '>
> > > > > > > > > >>and " from keywords when refering to a directive name
> > > > rather> > > than its> > > > > > >>literal value, and then use "" when
> > > > refering to a value.> For> > > example,> > > > > > >the> > > > > >
> > > > >>existing 5090 text would then become:> > > > > > >>> > > > > >
> > > > >><snip>> > > > > > >> o If the Access-Accept packet contains a
> > > > Digest-HA1> > > attribute, the> > > > > > >> RADIUS client checks the
> > > > qop and algorithm directives> in> > > the> > > > > > >> Authorization
> > > > header of the HTTP-style request it> wants> > to> > > > > > >>
> > > > authorize:> > > > > > >>> > > > > > >> * If the qop directive is
> > > > missing or its value is> > "auth",> > > the> > > > > > >> RADIUS
> > > > client ignores the Digest-HA1 attribute. It> > > does not> > > > > >
> > > > >> include an Authentication-Info header in its> > HTTP-style> > > >
> > > > > > >> response.> > > > > > >></snip>> > > > > > >>> > > > > >
> > > > >>However when examing 2617 in more detail, using " around the> > >
> > > > directive> > > > > > >> > > > > > >>names would be more consistent
> > > > with that draft. For example> > > this> > > > > > >would> > > > > >
> > > > >>become:> > > > > > >>> > > > > > >><snip more like RFC 2617>> > > >
> > > > > > >> o If the Access-Accept packet contains a Digest-HA1> > >
> > > > attribute, the> > > > > > >> RADIUS client checks the "qop" and
> > > > "algorithm"> > directives> > > in the> > > > > > >> Authorization
> > > > header of the HTTP-style request it> wants> > to> > > > > > >>
> > > > authorize:> > > > > > >>> > > > > > >> * If the "qop" directive is
> > > > missing or its value is> > > "auth", the> > > > > > >> RADIUS client
> > > > ignores the Digest-HA1 attribute. It> > > does not> > > > > > >>
> > > > include an Authentication-Info header in its> > HTTP-style> > > > > >
> > > > >> response.> > > > > > >></snip more like RFC 2617>> > > > > > >>> >
> > > > > > > > >>Prehaps others can weigh in one which they believe is most>
> > > > > > > > > >appropriate.> > > > > > >>I believe either would be a
> > > > slight improvement on the> existing> > > text> > > > > > >which> > >
> > > > > > > >>uses single quotes around the string values.> > > > > > >>> >
> > > > > > > > >>thanks,> > > > > > >>-david> > > > > > >>> > > > > > >>>> >
> > > > > > > > >>>Thank you.> > > > > > >>>> > > > > > >>>RFC Editor> > > >
> > > > > > >>>> > > > > > >>>> > > > > > >>>On Thu, Oct 04, 2007 at
> > > > 03:11:50PM -0700,> > > [email-masked]> > > > > > >wrote:>
> > > > > > > > > >>>>> > > > > > >>>>****IMPORTANT*****> > > > > > >>>>> > >
> > > > > > > >>>>Updated 2007/10/04> > > > > > >>>>> > > > > > >>>>RFC
> > > > AUTHOR(S):> > > > > > >>>>--------------> > > > > > >>>>> > > > > >
> > > > >>>>This is your LAST CHANCE to make changes to your RFC to> be:> > >
> > > > > > > >>>>draft-ietf-radext-rfc4590bis-02.txt, once the document is>
> > > > > > published> > > > > > >as> > > > > > >>>>an RFC we *WILL NOT* make
> > > > any changes.> > > > > > >>>>> > > > > > >>>>Please check your
> > > > document at:> > > > > > >>>>> > > > > >
> > > > >>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt> > > > > >
> > > > >>>>> > > > > > >>>>ATTENTION: The editing process occasionally
> > > > introduces> > errors> > > that> > > > > > >>>>were not in the
> > > > Internet Draft. Although the RFC Editor> > tries> > > very> > > > > >
> > > > >>>>hard to catch all errors, proofreading the text at least> > >
> > > > twice,> > > > > > >typos> > > > > > >>>>can slip through. You, as an
> > > > author of the RFC, are> taking> > > > > > >>>>responsibility for the
> > > > correctness of the final product> when> > > you OK> > > > > >
> > > > >>>>publication. You should therefore proofread the entire> RFC> > >
> > > > > > > >carefully> > > > > > >>>>and without assumptions. Errors in
> > > > RFCs last forever.> > > > > > >>>>> > > > > > >>>>NOTE: We have run a
> > > > diff tool that compares the approved> > > > > > >internet-draft> > >
> > > > > > > >>>>against our edited RFC version of the document. Please> >
> > > > review> > > this> > > > > > >>>>file at:> > > > > > >>>>> > > > > >>
> > > > >>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html> > >
> > > > > > > >>>>> > > > > > >>>>Please note that we used a slightly altered
> > > > version of the> > > > > > >originally> > > > > > >>>>submitted ID to
> > > > create the diff file above. To make the> > file> > > more> > > > > >
> > > > >>>>useful, we moved the terminology section to to appear> after> > >
> > > > the> > > > > > >>>>introduction, but we did not alter the text.> > >
> > > > > > > >>>>> > > > > > >>>>The document will NOT BE PUBLISHED until
> > > > ALL of the> authors> > > listed> > > > > > >in> > > > > > >>>>the RFC
> > > > have affirmed that the document is ready to be> > > > > >
> > > > >>>>published, as ALL of the authors are equally responsible> for> >
> > > > > > > > >verifying> > > > > > >>>>the documents readiness for
> > > > publication.> > > > > > >>>>> > > > > > >>>>** Please send us a list
> > > > of suitable keywords for this> > > document,> > > > > > >over> > > >
> > > > > > >>>>and above those which appear in the title.> > > > > > >>>>> >
> > > > > > > > >>>> Frequently INCORRECT information includes> > > > > >
> > > > >>>>> > > > > > >>>> - Contact Information> > > > > > >>>> -
> > > > References (are they up to date)> > > > > > >>>> - Section Numbers> >
> > > > > > > > >>>> (especially if you originally put the copyright> > > > >
> > > > > >somewhere> > > > > > >>>> other than the VERY end of the document,
> > > > or if> > you> > > > > > >>>> numbered the 'Status of the Memo'
> > > > field)> > > > > > >>>>> > > > > > >>>>Please send us the changes, *DO
> > > > NOT* send a new document> > with> > > the> > > > > > >>>>changes
> > > > made. (If we think that the changes might be more> > > than> > > > >
> > > > > >>>>editorial we will contact the AD or the IESG to confirm> that>
> > > > > > the> > > > > > >>>>changes do not require review.)> > > > > >
> > > > >>>>> > > > > > >>>>Send us the changes in THIS format.> > > > > >
> > > > >>>>> > > > > > >>>> 1)*** SECTION #'s*** [i.e. Section 5, 2nd> > >
> > > > paragraph]> > > > > > >>>> 2) the text you want changed,> > > > > >
> > > > >>>> 3) the new correct text and> > > > > > >>>> 4) if the changes
> > > > are spacing or indentation> than> > > please> > > > > > >note> > > >
> > > > > > >>>> that.> > > > > > >>>>> > > > > > >>>>FOR EXAMPLE:> > > > > >
> > > > >>>>> > > > > > >>>> Section 5.6, 3rd paragraph> > > > > > >>>>> > >
> > > > > > > >>>> OLD:> > > > > > >>>> The quick brown fox jumped over the
> > > > lazy dog.> > > > > > >>>>> > > > > > >>>> NEW:> > > > > > >>>> The
> > > > quick brown dog jumps over the lazy fox.> > > > > > >>>> ^^^ ^ ^^^> >
> > > > > > > > >>>>If you have a whole paragraph to replace you do not need>
> > > > to> > > use> > > > > > >>>>the arrow to point out the differences> >
> > > > > > > > >>>>> > > > > > >>>> INTRODUCTION, 2nd paragraph> > > > > >
> > > > >>>>> > > > > > >>>> Replace OLD:> > > > > > >>>>> > > > > > >>>>
> > > > alsdfja;sldjf;lajsd;fljas;dlfj;> > > > > > >>>>> > > > > > >>>> With
> > > > NEW:> > > > > > >>>>> > > > > > >>>> nv;alkjd;lsf;aoisj;ltjka;sldkjf>
> > > > > > > > > >>>>> > > > > > >>>>Spacing or indentation problems...> > >
> > > > > > > >>>>> > > > > > >>>> Section 10, 1st paragraph (remove spaces>
> > > > between> > > bit> > > > > > >>>> and of, add space after butter)> > >
> > > > > > > >>>>> > > > > > >>>> OLD:> > > > > > >>>>> > > > > > >>>>
> > > > Better botter bought a bit> > > > > > >>>> of bitter butterMary mary
> > > > quite contrary> > > > > > >>>>> > > > > > >>>> NEW:> > > > > > >>>>>
> > > > > > > > > >>>> Better botter bought a bit of bitter butter> > > > > >
> > > > >>>>> > > > > > >>>> Mary mary quite contrary> > > > > > >>>>> > > >
> > > > > > >>>>This document will NOT be published until we receive> > >
> > > > agreement, from> > > > > > >>>>ALL listed authors, that the document
> > > > is ready for> > > publication.> > > > > > >>>>> > > > > > >>>>Thanks
> > > > for your cooperation,> > > > > > >>>>> > > > > > >>>>-RFC Editor> > >
> > > > > > > >>>>> > > > > > >>>>> > > > > > >>>>Title : RADIUS Extension
> > > > for Digest> > > > > > >>>> Authentication> > > > > > >>>>Author(s) :
> > > > B. Sterman, D. Sadolevsky,> > > > > > >>>> D. Schwartz, D. Williams,>
> > > > > > > > > >>>> W. Beck> > > > > > >>>>Working Group Chair(s) :
> > > > Bernard Aboba, David Nelson> > > > > > >>>>Area Director(s) : Dan
> > > > Romascanu, Ronald Bonica> > > > > > >>>> > > > > > >

-- 
Mike McCauley                               [email-masked]
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc.

Delivery-date: Sat, 22 Dec 2007 17:57:11 +0000
From: Bernard Aboba <[email-masked]>
To: Sam Hartman <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [ Comments on  automated key management and crypto agility
Date: Sat, 22 Dec 2007 09:56:47 -0800

--_5c2fec55-f7cc-4f89-9c57-3d3f789da0cd_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

To clarify --

RADIUS has previously used MD5 as a stream cipher to protect attributes inc=
luding passwords
(User-Password, Tunnel-Password) and keys (keying attributes within RFC 254=
8). =20

While the use of MD5 for integrity protection has a set of issues (e.g. col=
lisions), the use of MD5
as a stream cipher brings up another set of issues, such as known plaintext=
 attacks. =20

Given this, the ability to negotiate alternative "hiding" mechanisms is con=
sidered an important part
of RADIUS crypto-agility.  =20

However, this is logically separate from the need to provide end-to-end pro=
tection for key transport.=20

So far, the need to solve the end-to-end key transport problem has not been=
 part of RADIUS
crypto-agility requirements.  Should it be?=20

Note that it is possible for a crypto-agility solution to solve the "hiding=
" problem without solving the
end-to-end transport problem.=20

With Diameter, it was clear that the IESG expected a solution to both probl=
ems -- ciphersuite
negotiation (via TLS/IKE) as well as a mechanism for avoiding key disclosur=
e to proxies=20
(e.g. redirect).=20

The current RADIUS crypto-agility requirements only appear to require solut=
ion to the=20
former problem (ciphersuite negotiation), but not the latter (key disclosur=
e).  That said,
there has been some discussion of how the current proposals (RADIUS crypto-=
agility and=20
RADIUS/DTLS) could address the key disclosure problem.

> From: [email-masked]
> To: [email-masked]; [email-masked]
> Date: Thu, 20 Dec 2007 22:44:10 -0500
> Subject: [ Comments on  automated key management and crypto agility
>=20
>=20
>=20
>=20
> It's my understanding that you are in the middle or have just finished
> a consensus call regarding automated key management and radius crypto
> agility.
>=20
> I gave the chairs some advice on this topic a while ago.  It turns out
> I completely failed to understand the question I was asked.
>=20
>=20
> I assumed that the crypto agility work was intended to strengthen
> radius's integrity protection and dependence on md5.
>=20
> However as I understand now, the scope of the work also includes a
> real solution to the key transport problem.
>=20
> So I don't think the advice I gave the WG applies.
>=20
> I don't know if this changes any of your deliberations, but I just though=
t I'd write and let you know that I was confused.
>=20
> Here's my current understanding of the situation in this space.
>=20
> * RFC 3962 says that we should have a way so that people do not need
>   to expose keys to third parties (proxies).  This is not mandatory to
>   use, but we need to have a solution for that problem.
>=20
> * Diameter has the redirect mechanism which handles this need in some
>   deployments.
>=20
> * Our protocols don't force you to use proxies, but there are a lot of
>   good reasons why you might want to do so.
>=20
>=20
> * Hokey may need to have a solution to do key management that meets
>   the RFC 3962 requirements.
>=20
> * It may be the easiest place for hokey to solve its problem if it has
>   one is at the radius key transport level.
>=20
> * That doesn't inherently make it radext's problem to solve.  We also
>   still haven't   even figured out how much of this is hokey's problem.
>=20
> I'm trying to understand this all better and to try and figure out
> what sort of consensus we want to build.

--_5c2fec55-f7cc-4f89-9c57-3d3f789da0cd_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
To clarify --<br><br>RADIUS has previously used MD5 as a stream cipher to p=
rotect attributes including passwords<br>(User-Password, Tunnel-Password) a=
nd keys (keying attributes within RFC 2548).&nbsp; <br><br>While the use of=
 MD5 for integrity protection has a set of issues (e.g. collisions), the us=
e of MD5<br>as a stream cipher brings up another set of issues, such as kno=
wn plaintext attacks.&nbsp; <br><br>Given this, the ability to negotiate al=
ternative "hiding" mechanisms is considered an important part<br>of RADIUS =
crypto-agility.&nbsp;&nbsp; <br><br>However, this is logically separate fro=
m the need to provide end-to-end protection for key transport. <br><br>So f=
ar, the need to solve the end-to-end key transport problem has not been par=
t of RADIUS<br>crypto-agility requirements.&nbsp; Should it be? <br><br>Not=
e that it is possible for a crypto-agility solution to solve the "hiding" p=
roblem without solving the<br>end-to-end transport problem. <br><br>With Di=
ameter, it was clear that the IESG expected a solution to both problems -- =
ciphersuite<br>negotiation (via TLS/IKE) as well as a mechanism for avoidin=
g key disclosure to proxies <br>(e.g. redirect). <br><br>The current RADIUS=
 crypto-agility requirements only appear to require solution to the <br>for=
mer problem (ciphersuite negotiation), but not the latter (key disclosure).=
&nbsp; That said,<br>there has been some discussion of how the current prop=
osals (RADIUS crypto-agility and <br>RADIUS/DTLS) could address the key dis=
closure problem.<br><br><br><br>&gt; From: [email-masked]<br>&gt; To=
: [email-masked]; [email-masked]<br>&gt; Date: Thu, 2=
0 Dec 2007 22:44:10 -0500<br>&gt; Subject: [ Comments on  automated key man=
agement and crypto agility<br>&gt; <br>&gt; <br>&gt; <br>&gt; <br>&gt; It's=
 my understanding that you are in the middle or have just finished<br>&gt; =
a consensus call regarding automated key management and radius crypto<br>&g=
t; agility.<br>&gt; <br>&gt; I gave the chairs some advice on this topic a =
while ago.  It turns out<br>&gt; I completely failed to understand the ques=
tion I was asked.<br>&gt; <br>&gt; <br>&gt; I assumed that the crypto agili=
ty work was intended to strengthen<br>&gt; radius's integrity protection an=
d dependence on md5.<br>&gt; <br>&gt; However as I understand now, the scop=
e of the work also includes a<br>&gt; real solution to the key transport pr=
oblem.<br>&gt; <br>&gt; So I don't think the advice I gave the WG applies.<=
br>&gt; <br>&gt; I don't know if this changes any of your deliberations, bu=
t I just thought I'd write and let you know that I was confused.<br>&gt; <b=
r>&gt; Here's my current understanding of the situation in this space.<br>&=
gt; <br>&gt; * RFC 3962 says that we should have a way so that people do no=
t need<br>&gt;   to expose keys to third parties (proxies).  This is not ma=
ndatory to<br>&gt;   use, but we need to have a solution for that problem.<=
br>&gt; <br>&gt; * Diameter has the redirect mechanism which handles this n=
eed in some<br>&gt;   deployments.<br>&gt; <br>&gt; * Our protocols don't f=
orce you to use proxies, but there are a lot of<br>&gt;   good reasons why =
you might want to do so.<br>&gt; <br>&gt; <br>&gt; * Hokey may need to have=
 a solution to do key management that meets<br>&gt;   the RFC 3962 requirem=
ents.<br>&gt; <br>&gt; * It may be the easiest place for hokey to solve its=
 problem if it has<br>&gt;   one is at the radius key transport level.<br>&=
gt; <br>&gt; * That doesn't inherently make it radext's problem to solve.  =
We also<br>&gt;   still haven't   even figured out how much of this is hoke=
y's problem.<br>&gt; <br>&gt; I'm trying to understand this all better and =
to try and figure out<br>&gt; what sort of consensus we want to build.<br><=
/body>
</html>=

--_5c2fec55-f7cc-4f89-9c57-3d3f789da0cd_--

Delivery-date: Sat, 22 Dec 2007 17:38:37 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: FW: AUTH48 [SG]: RFC 5090  <draft-ietf-radext-rfc4590bis-02.txt> NOW AVAILABLE
Date: Sat, 22 Dec 2007 09:37:13 -0800

--_850a5faa-11aa-4c9f-9f82-831ac36344fd_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RFC 4590bis is now being held in AUTH48, pending final verification.=20

What started as a "simple" IANA-problem fix has turned into a longer odysse=
y due to the=20
discovery of additional errors/omissions. =20

In attempt to bring this story to a close, we need to make very sure that w=
e have looked over
this document carefully so that we don't have to go through this again with=
 RFC 4590ter.=20

So if you have ever had any interest in RADIUS Digest Authentication, now w=
ould be the time
to look over the AUTH48 version of the document, and speak up if there is a=
 problem. =20

> Date: Fri, 21 Dec 2007 15:14:46 -0800
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]; dscreat@dscre=
at.com; [email-masked]; [email-masked]; [email-masked]; d.b.nels=
[email-masked]; [email-masked]; [email-masked]
> Subject: Re: AUTH48 [SG]: RFC 5090  <draft-ietf-radext-rfc4590bis-02.txt>=
 NOW AVAILABLE
>=20
> Greeings Wolfgang,
>=20
> Just a reminder that we are waiting to hear from you before continuing
> on with the publication process.
>=20
> Please see the email below for document information.
>=20
> Thank you.
>=20
> RFC Editor
>=20
> On Fri, Dec 14, 2007 at 02:51:11PM -0800, RFC Editor wrote:
> > Hi Wolfgang,
> >=20
> > Just a friendly reminder that we are waiting to hear from you before
> > continuing on with the publication process for RFC 5090
> > <draft-ietf-radext-rfc4590bis-09.txt>. =20
> >=20
> > Please review the files located at:
> >=20
> >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt
> >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html
> >=20
> > Note that this diff file highlights only the differences between the
> > last posted version of the document and the current text file.  The
> > previously posted versions (during AUTH48) are available as:
> >=20
> > The originally posted AUTH48 files:
> >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt
> >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html
> >=20
> > Version 2 (includes author updates) of AUTH48 files:
> >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt
> >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html
> > Note that this file highlights only the differences between the
> > version 1 and 2 text files.
> >=20
> > We will wait to hear from you before continuing on with the
> > publication process.
> >=20
> > Thank you.
> >=20
> > RFC Editor/sg
> >=20
> >=20
> > On Tue, Dec 11, 2007 at 05:08:35AM -0800, Bernard Aboba wrote:
> > >=20
> > > I also talked to Wolfgang at IETF 70.  He wanted to check the documen=
t over carefully to make sure there
> > > were no further issues.   > Subject: RE: AUTH48 [SG]: RFC 5090 <draft=
-ietf-radext-rfc4590bis-02.txt> NOW AVAILABLE> Date: Mon, 10 Dec 2007 20:30=
:51 +0200> From: [email-masked]> To: [email-masked]; =
[email-masked]> CC: [email-masked]; [email-masked]; =
[email-masked]; [email-masked]; [email-masked]; Bernard_Aboba@ho=
tmail.com; [email-masked]> > Yes,> > David Schwartz saw him at the =
ietf meeting and worked through the draft> with him. I think we should be h=
earing from him soon.> > Baruch> > > -----Original Message-----> From: RFC =
Editor [mailto:[email-masked]] > Sent: Monday, December 10, 2007=
 8:27 PM> To: [email-masked]; Baruch Sterman> Cc: David Schwartz; RFC =
Editor; [email-masked]; [email-masked];> Dan Romascanu; Ronald Bonic=
a; [email-masked];> [email-masked]> Subject: Re: AUTH48 =
[SG]: RFC 5090 <draft-ietf-radext-rfc4590bis-02.txt>> NOW AVAILABLE> > All,=
> > Just checking to see if you have had any luck contacting Wolfgang?> > T=
hanks!> > RFC Editor/sg> > On Tue, Nov 27, 2007 at 09:21:45PM +0200, Baruch=
 Sterman wrote:> > David Schwartz will be at the IETF meetings next week. M=
aybe Wolfgang> > will be there and he can nudge him to answer. Lets hold of=
f until we> see> > if that way forward works. If not, we can go with option=
 3.> > > > Thanks,> > > > Baruch> > > > > > -----Original Message-----> > F=
rom: RFC Editor [mailto:[email-masked]] > > Sent: Tuesday, Novem=
ber 27, 2007 12:41 AM> > To: Baruch Sterman> > Cc: RFC Editor> > Subject: R=
e: AUTH48 [SG]: RFC 5090> <draft-ietf-radext-rfc4590bis-02.txt>> > NOW AVAI=
LABLE> > > > Hi Baruch,> > > > We have a couple of ways to move forward.> >=
 > > 1. The author can be removed as an author, and moved to the> > Acknowl=
edgements section.> > > > 2. We can create a Contributor's section and have=
 him listed there.> > > > 3. We can request that the AD approve the documen=
t in place of the> > unavailabe author. > > > > Option 3 has been done befo=
re in instances where the missing author> > made sizeable contributions to =
the document, so the other authors> > did not feel comfortable removing the=
 individuals name as an> > author. > > > > It sounds as though 3 may be the=
 proper way forward. If this is the> > case, we will send an email to the A=
Ds requesting their approval in> > place of Wolfgang (the message will be c=
c'ed to all relevant> > parties, including Wolfgang). > > > > If the above =
suggestions are unacceptable and you have an alternative> > solution, pleas=
e let us know. > > > > Thank you.> > > > RFC Editor> > > > On Mon, Nov 26, =
2007 at 09:39:09AM +0200, Baruch Sterman wrote:> > > I wrote to Wolfgang as=
 well, but got no response. What is the> > procedure> > > in this case? I a=
m sure that Wolfgang would be ok with the changes.> > The> > > last email I=
 received was on October 19 where he said that he had> made> > > the one co=
rrection (suggested by Ellermann) in the cnonce value. > > > > > > Baruch> =
> > > > > > > > -----Original Message-----> > > From: RFC Editor [mailto:rf=
[email-masked]] > > > Sent: Wednesday, November 21, 2007 10:35 PM>=
 > > To: David Williams; Baruch Sterman; [email-masked]; David> > Schw=
artz;> > > [email-masked]> > > Cc: [email-masked]; radext-c=
[email-masked]; RFC> > Editor> > > Subject: Re: AUTH48 [SG]: RFC 5090=
> > <draft-ietf-radext-rfc4590bis-02.txt>> > > NOW AVAILABLE> > > > > > Gre=
etings Wolfgang,> > > > > > We do not believe we have received your respons=
e regarding this> > > document's readiness for publication as an RFC. Pleas=
e review the> > > text and let us know if you are content with the document=
 as it now> > > appears at:> > > > > > ftp://ftp.rfc-editor.org/in-notes/au=
thors/rfc5090.txt> > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-di=
ff.html> > > Note that this diff file highlights only the changes between t=
he> last > > > posted version of the document and the current text file.> >=
 > > > > > > > The last versions of the document are available as:> > > > >=
 > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt> > > ftp://ftp.r=
fc-editor.org/in-notes/authors/rfc5090v1-diff.html> > > > > > ftp://ftp.rfc=
-editor.org/in-notes/authors/rfc5090v2.txt> > > ftp://ftp.rfc-editor.org/in=
-notes/authors/rfc5090v2-diff.html> > > Note that this diff file highlights=
 only the changes between v1 and> > > the v2.> > > > > > We will wait to he=
ar from you before continuing on with the> > > publication process.> > > > =
> > Thank you.> > > > > > RFC Editor> > > > > > On Fri, Nov 16, 2007 at 05:=
13:04PM -0800, RFC Editor wrote:> > > > Authors,> > > > > > > > We have cor=
rected the text as indicated below and posted the> revised> > > > version o=
f the document at:> > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors=
/rfc5090.txt> > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.=
html> > > > Note that this diff file highlights only the changes betwee the=
> last> > > > > > posted version of the document and the current text file.=
> > > > > > > > Please review the document and let us know if you approve t=
his> > > > text for publication.> > > > > > > > We believe we are waiting f=
or the following approvals:> > > > > > > > Baruch Sterman - done > > > > Da=
niel Sadolevsky - done> > > > David Schwartz - done> > > > David Williams> =
> > > Wolfgang Beck> > > > > > > > Bernard Aboba - done> > > > > > > > > > =
> > Thank you.> > > > > > > > RFC Editor> > > > > > > > > > > > On Tue, Nov=
 06, 2007 at 04:58:49PM -0800, RFC Editor wrote:> > > > > Authors,> > > > >=
 > > > > > Please confer and let us know how the text should/should not use=
> > the> > > > > quote marks. It sounds as though this email was for discus=
sion.> > If> > > > > the changes below are acceptable, we will make the cha=
nges and> > post> > > a> > > > > revised version of the document.> > > > > =
> > > > > Also, please note the following status of document approvals:> > =
> > > > > > > > Baruch Sterman - done (although we would like to know if yo=
u> agree> > > > > with the changes described below)> > > > > Daniel Sadolev=
sky - done> > > > > David Schwartz> > > > > David Williams> > > > > Wolfgan=
g Beck> > > > > > > > > > Bernard Aboba - done> > > > > > > > > > We will w=
ait to hear further before continuing on with the> > > publication> > > > >=
 process.> > > > > > > > > > Thank you.> > > > > > > > > > RFC Editor> > > =
> > > > > > > > > > > > On Fri, Oct 19, 2007 at 01:33:14PM -0400, David Wil=
liams wrote:> > > > > > Hi Baruch,> > > > > > > > > > > > These look good, =
and I agree with your consistency comment. I> > > have a few > > > > > > mo=
re specific changes to suggest that I would like you and> > others> > > to =
> > > > > > review as well. But first a couple of general style comments> >=
 that> > > require > > > > > > no changes to the document.> > > > > > > > >=
 > > > General comment #1: I tried to find a definitive style guide> to> > =
> use of > > > > > > single quotes versus double quotes and found there is =
no hard> > > guidelines, > > > > > > that consistency is most important:> >=
 > > > > http://en.wikipedia.org/wiki/Quotation_mark> > > > > > http://foru=
m.wordreference.com/showthread.php?t=3D120946> > > > > > Though I tend to t=
hink that double quotes are more commonly> used> > > and match > > > > > > =
the syntax of more popular programming languages, but there> are> > so> > >=
 many > > > > > > quoted items in the document and it has been this way for=
 a> long> > > time, so > > > > > > best to leave as is.> > > > > > > > > > =
> > General comment #2: When refering to responses from the radius> > > ser=
ver > > > > > > there are a lot of instances of a comment similiar to "with=
out> > > surrounding > > > > > > quotes" that potentially could be removed =
for readability.> > > Especially if > > > > > > there were a more concise d=
efinition up-front about the> general> > > form of > > > > > > values retur=
ned from the radius server. But I am a little> > > hesitant to > > > > > > =
just strip them out now.> > > > > > > > > > > > Specific comments, to build=
 on top of your list:> > > > > > > > > > > > In section 2.1.2, 1st paragrap=
h should not have quotes around> > > nonce. > > > > > > Paragraph should re=
ad:> > > > > > > > > > > > If a matching (Proxy-)Authorization header is pr=
esent and> > > contains> > > > > > HTTP Digest information, the RADIUS clie=
nt checks the nonce> > > > > > parameter.> > > > > > > > > > > > In next pa=
ragraph, do not need quotes around response.> > Paragraph> > > should > > >=
 > > > read:> > > > > > > > > > > > If the RADIUS client recognizes the non=
ce, it takes the> > header> > > > > > directives and puts them into a RADIU=
S Access-Request> packet.> > > It> > > > > > puts the response directive in=
to a Digest-Response> attribute> > > and> > > > > > the realm, nonce, diges=
t-uri, qop, algorithm, cnonce, nc,> > > username,> > > > > > and opaque dir=
ectives into the respective Digest-Realm,> > > Digest-Nonce,> > > > > > Dig=
est-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce,> > > Digest-> > > > >=
 > Nonce-Count, Digest-Username, and Digest-Opaque attributes.> > > The> > =
> > > > RADIUS client puts the request method into the> Digest-Method> > > =
> > > attribute.> > > > > > > > > > > > In section 2.1.3, in addtion to the=
 items you point out, in> the> > > last > > > > > > paragraph, nextnounce d=
oes not need quoting. Paragraph> should> > > read:> > > > > > > > > > > > W=
hen the RADIUS server provides a Digest-Nextnonce> attribute> > in> > > the=
> > > > > > Access-Accept packet, the RADIUS client puts the contents> of> =
> > this> > > > > > attribute into a nextnonce directive. Now it can send a=
n> > HTTP-> > > > > > style response.> > > > > > > > > > > > In section 2.1=
.4, 2nd paragraph, the stale directive should> not> > > need > > > > > > qu=
oting. Paragraph should read:> > > > > > > > > > > > If the RADIUS client r=
eceives an Access-Challenge packet in> > > response> > > > > > to an Access=
-Request containing a Digest-Nonce attribute,> the> > > RADIUS> > > > > > s=
erver did not accept the nonce. If a Digest-Stale> attribute> > > is> > > >=
 > > present in the Access-Challenge and has a value of 'true'> > > (withou=
t> > > > > > surrounding quotes), the RADIUS client sends an error> > respo=
nse> > > (401> > > > > > or 407) containing a WWW-/Proxy-Authenticate heade=
r with> the> > > > > > directive stale and the digest directives derived fr=
om the> > > Digest-*> > > > > > attributes.> > > > > > > > > > > > Except I=
 think the wording of the last sentence in this same> > > paragraph > > > >=
 > > could be improved. So that the paragraph reads more like:> > > > > > >=
 > > > > > If the RADIUS client receives an Access-Challenge packet in> > >=
 response> > > > > > to an Access-Request containing a Digest-Nonce attribu=
te,> the> > > RADIUS> > > > > > server did not accept the nonce. If a Diges=
t-Stale> attribute> > > is> > > > > > present in the Access-Challenge and h=
as a value of 'true'> > > (without> > > > > > surrounding quotes), the RADI=
US client sends an error> > response> > > (401> > > > > > or 407) containin=
g a WWW-/Proxy-Authenticate header with> the> > > > > > stale directive set=
 to 'true' and the digest directives> > derived> > > from> > > > > > the Di=
gest-* attributes.> > > > > > > > > > > > In section 3.10, 1st paragraph, I=
 believe the term "qop-level"> > is> > > ill > > > > > > defined and should=
 not be used, that qop directive or> qop-value> > > would be > > > > > > be=
tter. In other words the paragraph should read:> > > > > > > > > > > > When=
 using the qop-value 'auth-int', a hash of the> > > HTTP-style> > > > > > m=
essage body's contents is required for digest> > > calculation.> > > > > > =
Instead of sending the complete body of the message,> > only> > > its> > > =
> > > hash value is sent. This hash value can be used> > directly> > > in> =
> > > > > the digest calculation.> > > > > > > > > > > > In section 3.15, a=
uth-param doesn't need quoting. So that the> > > paragraph > > > > > > beco=
mes:> > > > > > > > > > > > This attribute is a placeholder for future exte=
nsions> > and> > > > > > corresponds to the auth-param parameter defined in=
> > > Section> > > > > > 3.2.1 of [RFC2617]. The Digest-Auth-Param is the> =
> > mechanism> > > > > > whereby the RADIUS client and RADIUS server can> >=
 exchange> > > auth-> > > > > > param extension parameters contained within=
 Digest> > > headers that> > > > > > are not understood by the RADIUS clien=
t and for which> > > there are> > > > > > no corresponding stand-alone attr=
ibutes.> > > > > > > > > > > > In section 3.17, domain doesn't need quoting=
. So that the> > > paragraph > > > > > > becomes:> > > > > > > > > > > > Wh=
en a RADIUS client has asked for a nonce, the> RADIUS> > > server> > > > > =
> MAY send one or more Digest-Domain attributes in its> > > Access-> > > > =
> > Challenge packet. The RADIUS client puts them into> the> > > quoted,> >=
 > > > > space-separated list of URIs of the domain directive> of> > a> > >=
 > > > WWW-Authenticate header. Together with Digest-Realm,> > the> > > URI=
s> > > > > > in the list define the protection space (see> [RFC2617],> > > =
Section> > > > > > 3.2.1) for some HTTP-style protocols. This attribute> > =
> MUST only> > > > > > be used in Access-Challenge and Accounting-Request> =
> > packets.> > > > > > > > > > > > In section 3.19, 1st paragraph, in addt=
ion to no quotes around> > > rspauth as > > > > > > you pointed out, I beli=
eve there should be no quotes around> qop.> > > So that > > > > > > the par=
agraph reads:> > > > > > > > > > > > This attribute is used to allow the ge=
neration of an> > > > > > Authentication-Info header, even if the HTTP-styl=
e> > > response's> > > > > > body is required for the calculation of the rs=
pauth> > > value.> > > > > > It SHOULD be used in Access-Accept packets if =
the> > > required> > > > > > quality of protection (qop) is 'auth-int'.> > =
> > > > > > > > > > thanks,> > > > > > -david> > > > > > > > > > > > On Fri=
, 19 Oct 2007, 1:43pm, Baruch Sterman wRote:> > > > > > > > > > > > >After =
lengthy discussions with my father-in-law who is a> > > professor of> > > >=
 > > >English, I agree with Dave's method of using quotes only in> the> > >=
 value of> > > > > > >an attribute/directive, but not in referencing the> >=
 > attribute/directive> > > > > > >by name. As such, I have some changes.> =
> > > > > >> > > > > > >In section 2.1.3 3rd paragraph should not have quot=
es around> > the> > > word> > > > > > >rspauth. Sentence should read:> > > =
> > > >> > > > > > > * If the Digest-Qop attribute's value is 'auth' or not=
> > > specified,> > > > > > > the RADIUS client puts the Digest-Response-Au=
th> > > attribute's> > > > > > > content into the Authentication-Info heade=
r's rspauth> > > > > > > directive of the HTTP-style response.> > > > > > >=
> > > > > > >Same section 5th paragraph - no quotes around qop and> > algor=
ithm:> > > > > > >> > > > > > > o If the Access-Accept packet contains a Di=
gest-HA1> > attribute,> > > the> > > > > > > RADIUS client checks the qop a=
nd algorithm directives in> > the> > > > > > > Authorization header of the =
HTTP-style request it wants> to> > > > > > > authorize:> > > > > > >> > > >=
 > > >Next paragraph - no quotes around qop> > > > > > >> > > > > > > * If =
the qop directive is missing or its value is> 'auth',> > > the> > > > > > >=
 RADIUS client ignores the Digest-HA1 attribute. It> > does> > > not> > > >=
 > > > include an Authentication-Info header in its> HTTP-style> > > > > > =
> response.> > > > > > >> > > > > > >Next paragraph - no quotes around qop =
or rspauth.> > > > > > >> > > > > > > * If the qop directive's value is 'au=
th-int' and at> least> > > one> > > > > > > of the following conditions is =
true, the RADIUS> client> > > > > > > calculates the contents of the HTTP-s=
tyle response's> > > rspauth> > > > > > > directive:> > > > > > >> > > > > =
> >> > > > > > >2 paragraphs later - no quotes around rspauth> > > > > > >>=
 > > > > > > The RADIUS client creates the HTTP-style response> > message> =
> > and> > > > > > > calculates the hash of this message's body. It uses> >=
 the> > > result> > > > > > > and the Digest-URI attribute's value of the> =
> corresponding> > > > > > > Access-Request packet to perform the H(A2)> ca=
lculation.> > > It> > > > > > > takes the Digest-Nonce, Digest-Nonce-Count,=
> > > Digest-CNonce, and> > > > > > > Digest-Qop values of the correspondin=
g Access-Request> > and> > > the> > > > > > > Digest-HA1 attribute's value =
to finish the> computation> > of> > > the> > > > > > > rspauth value.> > > =
> > > >> > > > > > >> > > > > > >> > > > > > >Section 3.4 paragraph 1 - no =
quotes around rspauth> > > > > > >> > > > > > > This attribute enables the =
RADIUS server to prove> > > possession of> > > > > > > the password. If the=
 previously received Digest-Qop> > > attribute> > > > > > > was 'auth-int' =
(without surrounding quotes), the> RADIUS> > > server> > > > > > > MUST sen=
d a Digest-HA1 attribute instead of a> > > Digest-Response-> > > > > > > Au=
th attribute. The Digest-Response-Auth attribute> > MUST> > > only> > > > >=
 > > be used in Access-Accept packets. The RADIUS client> > puts> > > the> =
> > > > > > attribute value without surrounding quotes into the> > > rspaut=
h> > > > > > > directive of the Authentication-Info header.> > > > > > >> >=
 > > > > >> > > > > > >Section 3.5 2nd paragraph - no quotes around nextnon=
ce> > > > > > >> > > > > > > The RADIUS server MAY put a Digest-Nextnonce> =
attribute> > > into an> > > > > > > Access-Accept packet. If this attribute=
 is present,> > the> > > RADIUS> > > > > > > client MUST put the contents o=
f this attribute into> the> > > > > > > nextnonce directive of an Authentic=
ation-Info header> in> > > its> > > > > > > HTTP-style response. This attri=
bute MUST only be> used> > in> > > > > > > Access-Accept packets.> > > > > =
> >> > > > > > >> > > > > > >Section 3.7, 4th paragraph - no quotes around =
uri> > > > > > >> > > > > > > If the HTTP-style request has an Authorizatio=
n> header,> > > the> > > > > > > RADIUS client puts the value of the uri di=
rective> found> > > in> > > > > > > the HTTP-style request Authorization he=
ader (known as> > > "digest-> > > > > > > uri-value" in Section 3.2.2 of [R=
FC2617]) without> > > surrounding> > > > > > > quotes into this attribute. =
If there is no> > Authorization> > > > > > > header, the RADIUS client take=
s the value of the> > request> > > URI> > > > > > > from the HTTP-style req=
uest it wants to authenticate.> > > > > > >> > > > > > >> > > > > > >Sectio=
n 3.8, 4th paragraph - no quotes around qop> > > > > > >> > > > > > > In Ac=
cess-Requests, the RADIUS client takes the value> > of> > > the> > > > > > =
> qop directive (qop-value as described in [RFC2617])> > from> > > the> > >=
 > > > > HTTP-style request it wants to authenticate. In> > Access-> > > > =
> > > Challenge packets, the RADIUS server puts a desired> > > qop-value> >=
 > > > > > into this attribute. If the RADIUS server supports> > more> > > =
than> > > > > > > one "quality of protection" value, it puts each> > qop-va=
lue> > > into> > > > > > > a separate Digest-Qop attribute.> > > > > > >> >=
 > > > > >Section 3.18 1st paragraph - no quotes around stale> > > > > > >>=
 > > > > > > This attribute is sent by a RADIUS server in order to> > > not=
ify> > > > > > > the RADIUS client whether it has accepted a nonce.> If> > =
> the> > > > > > > nonce presented by the RADIUS client was stale, the> > v=
alue> > > is> > > > > > > 'true' and is 'false' otherwise. The RADIUS clien=
t> > puts> > > the> > > > > > > content of this attribute into a stale dire=
ctive of> the> > > WWW-> > > > > > > Authenticate header in the HTTP-style =
response to the> > > request> > > > > > > it wants to authenticate. The att=
ribute MUST only be> > > used in> > > > > > > Access-Challenge packets.> > =
> > > > >> > > > > > >3.19 1st paragraph - no quotes around rspauth> > > > =
> > >> > > > > > > This attribute is used to allow the generation of an> > =
> > > > > Authentication-Info header, even if the HTTP-style> > > response'=
s> > > > > > > body is required for the calculation of the rspauth> > > val=
ue.> > > > > > > It SHOULD be used in Access-Accept packets if the> > > req=
uired> > > > > > > quality of protection ('qop') is 'auth-int'.> > > > > > =
>> > > > > > >> > > > > > >> > > > > > >> > > > > > >I think that does it. =
Even if this is not right, at least it> > > should now> > > > > > >be consi=
stent.> > > > > > >> > > > > > >Comments?> > > > > > >> > > > > > >Baruch> =
> > > > > >> > > > > > >> > > > > > >> > > > > > >-----Original Message----=
-> > > > > > >From: RFC Editor [mailto:[email-masked]]> > > > > =
> >Sent: Monday, October 15, 2007 8:45 PM> > > > > > >To: David Williams> >=
 > > > > >Cc: Baruch Sterman; [email-masked]; David Schwartz;> > > > >=
 > >[email-masked]; [email-masked];> > > > > > >radext-chai=
[email-masked]; RFC Editor> > > > > > >Subject: Re: AUTH48 [SG]: RFC 509=
0> > > <draft-ietf-radext-rfc4590bis-02.txt>> > > > > > >NOW AVAILABLE> > >=
 > > > >> > > > > > >Greeting all,> > > > > > >> > > > > > >We have not hea=
rd further regarding the issues below or other> > > changes> > > > > > >tha=
t may be required before publishing this document as an> RFC.> > > > > > >P=
lease review the document and let us know if there are any> > > > > > >corr=
ections required.> > > > > > >> > > > > > > ftp://ftp.rfc-editor.org/in-not=
es/authors/rfc5090.txt> > > > > > > ftp://ftp.rfc-editor.org/in-notes/autho=
rs/rfc5090-diff.html> > > > > > >> > > > > > >We will wait to hear from you=
 before continuing on with the> > > > > > >publication process.> > > > > > =
>> > > > > > >Thank you.> > > > > > >> > > > > > >RFC Editor> > > > > > >> =
> > > > > >On Sun, Oct 07, 2007 at 01:29:00PM -0400, David Williams> wrote:=
> > > > > > >>On Thu, 4 Oct 2007, 3:40pm, RFC Editor wRote:> > > > > > >>> =
> > > > > >>>Authors,> > > > > > >>>> > > > > > >>>While reviewing <draft-i=
etf-radext-rfc4590bis-02.txt>> during> > > AUTH48,> > > > > > >>>please con=
sider the following.> > > > > > >>>> > > > > > >>>In previous dialog, we ha=
d the following exchange:> > > > > > >>>> > > > > > >>>>>2. Please explain =
the usage of the single quote marks (')> > in> > > > > > >>>>>this document=
. There seems to be inconsistency, but we> are> > > > > > >>>>>unable to de=
termine which values/attributes/parameters> you> > > > > > >>>>>wanted to a=
ppear in quote marks. For example, we see> > > > > > >>>>>> > > > > > >>>>>=
'auth-int'/"auth-int"> > > > > > >>>>>'rspauth' directive/rspauth directive=
> > > > > > >>>>>'rspauth' value/rspauth value> > > > > > >>>>>> > > > > > =
>>>>As RfC 2617 always uses ", replacing all 's in question> with> > "> > >=
 seems> > > > > > >>>>the right thing to do.> > > > > > >>>> > > > > > >>>P=
lease note that we did not replace all 's with "s because> > > > > > >>>RFC=
 4590 uses 's. However, if you feel that the document> > > should be> > > >=
 > > >>>more alignmed with RFC 2617, please let us know and we will> > > ma=
ke> > > > > > >>>this change.> > > > > > >>> > > > > > >>If we are taking a=
 vote, I would prefer using " instead of '> > > around> > > > > > >the> > >=
 > > > >>value strings. I think it is better to stay aligned with> 2617> > =
> rather> > > > > > >than> > > > > > >>4590. Also I believe the " usage is =
more commonly used in> > other> > > > > > >>specifications.> > > > > > >>> =
> > > > > >>>> > > > > > >>>Also, we had a difficult time understanding the=
 use of 's.> > We> > > > > > >>>inserted 's around auth-int, auth, qop, and=
 rspauth when> they> > > were> > > > > > >>>used as values or directives. H=
owever, we did not attempt> to> > > include> > > > > > >>>'s for *all* dire=
ctives and values (e.g., realm and> opaque).> > > Please> > > > > > >>>let =
us know if this is not correct.> > > > > > >>> > > > > > >>I agree it is co=
nfusing. Looking at 2617 I don't think it> is> > > entirely> > > > > > >> >=
 > > > > >>consistent either, as I see references to ["qop" directive]> as>=
 > > well as> > > > > > >the> > > > > > >>unquoted form [qop directive].> >=
 > > > > >>> > > > > > >>I am no authority on style but my initial thought =
is to> > suggest> > > > > > >removing '> > > > > > >>and " from keywords wh=
en refering to a directive name rather> > > than its> > > > > > >>literal v=
alue, and then use "" when refering to a value.> For> > > example,> > > > >=
 > >the> > > > > > >>existing 5090 text would then become:> > > > > > >>> >=
 > > > > >><snip>> > > > > > >> o If the Access-Accept packet contains a Di=
gest-HA1> > > attribute, the> > > > > > >> RADIUS client checks the qop and=
 algorithm directives> in> > > the> > > > > > >> Authorization header of th=
e HTTP-style request it> wants> > to> > > > > > >> authorize:> > > > > > >>=
> > > > > > >> * If the qop directive is missing or its value is> > "auth",=
> > > the> > > > > > >> RADIUS client ignores the Digest-HA1 attribute. It>=
 > > does not> > > > > > >> include an Authentication-Info header in its> >=
 HTTP-style> > > > > > >> response.> > > > > > >></snip>> > > > > > >>> > >=
 > > > >>However when examing 2617 in more detail, using " around the> > > =
directive> > > > > > >> > > > > > >>names would be more consistent with tha=
t draft. For example> > > this> > > > > > >would> > > > > > >>become:> > > =
> > > >>> > > > > > >><snip more like RFC 2617>> > > > > > >> o If the Acce=
ss-Accept packet contains a Digest-HA1> > > attribute, the> > > > > > >> RA=
DIUS client checks the "qop" and "algorithm"> > directives> > > in the> > >=
 > > > >> Authorization header of the HTTP-style request it> wants> > to> >=
 > > > > >> authorize:> > > > > > >>> > > > > > >> * If the "qop" directive=
 is missing or its value is> > > "auth", the> > > > > > >> RADIUS client ig=
nores the Digest-HA1 attribute. It> > > does not> > > > > > >> include an A=
uthentication-Info header in its> > HTTP-style> > > > > > >> response.> > >=
 > > > >></snip more like RFC 2617>> > > > > > >>> > > > > > >>Prehaps othe=
rs can weigh in one which they believe is most> > > > > > >appropriate.> > =
> > > > >>I believe either would be a slight improvement on the> existing> =
> > text> > > > > > >which> > > > > > >>uses single quotes around the strin=
g values.> > > > > > >>> > > > > > >>thanks,> > > > > > >>-david> > > > > >=
 >>> > > > > > >>>> > > > > > >>>Thank you.> > > > > > >>>> > > > > > >>>RF=
C Editor> > > > > > >>>> > > > > > >>>> > > > > > >>>On Thu, Oct 04, 2007 a=
t 03:11:50PM -0700,> > > [email-masked]> > > > > > >wrote:> > > =
> > > >>>>> > > > > > >>>>****IMPORTANT*****> > > > > > >>>>> > > > > > >>>=
>Updated 2007/10/04> > > > > > >>>>> > > > > > >>>>RFC AUTHOR(S):> > > > > =
> >>>>--------------> > > > > > >>>>> > > > > > >>>>This is your LAST CHANC=
E to make changes to your RFC to> be:> > > > > > >>>>draft-ietf-radext-rfc4=
590bis-02.txt, once the document is> > > published> > > > > > >as> > > > > =
> >>>>an RFC we *WILL NOT* make any changes.> > > > > > >>>>> > > > > > >>>=
>Please check your document at:> > > > > > >>>>> > > > > > >>>>ftp://ftp.rf=
c-editor.org/in-notes/authors/rfc5090.txt> > > > > > >>>>> > > > > > >>>>AT=
TENTION: The editing process occasionally introduces> > errors> > > that> >=
 > > > > >>>>were not in the Internet Draft. Although the RFC Editor> > tri=
es> > > very> > > > > > >>>>hard to catch all errors, proofreading the text=
 at least> > > twice,> > > > > > >typos> > > > > > >>>>can slip through. Yo=
u, as an author of the RFC, are> taking> > > > > > >>>>responsibility for t=
he correctness of the final product> when> > > you OK> > > > > > >>>>public=
ation. You should therefore proofread the entire> RFC> > > > > > >carefully=
> > > > > > >>>>and without assumptions. Errors in RFCs last forever.> > > =
> > > >>>>> > > > > > >>>>NOTE: We have run a diff tool that compares the a=
pproved> > > > > > >internet-draft> > > > > > >>>>against our edited RFC ve=
rsion of the document. Please> > review> > > this> > > > > > >>>>file at:> =
> > > > > >>>>> > > > > >> >>>>ftp://ftp.rfc-editor.org/in-notes/authors/rf=
c5090-diff.html> > > > > > >>>>> > > > > > >>>>Please note that we used a s=
lightly altered version of the> > > > > > >originally> > > > > > >>>>submit=
ted ID to create the diff file above. To make the> > file> > > more> > > > =
> > >>>>useful, we moved the terminology section to to appear> after> > > t=
he> > > > > > >>>>introduction, but we did not alter the text.> > > > > > >=
>>>> > > > > > >>>>The document will NOT BE PUBLISHED until ALL of the> aut=
hors> > > listed> > > > > > >in> > > > > > >>>>the RFC have affirmed that t=
he document is ready to be> > > > > > >>>>published, as ALL of the authors =
are equally responsible> for> > > > > > >verifying> > > > > > >>>>the docum=
ents readiness for publication.> > > > > > >>>>> > > > > > >>>>** Please se=
nd us a list of suitable keywords for this> > > document,> > > > > > >over>=
 > > > > > >>>>and above those which appear in the title.> > > > > > >>>>> =
> > > > > >>>> Frequently INCORRECT information includes> > > > > > >>>>> >=
 > > > > >>>> - Contact Information> > > > > > >>>> - References (are they =
up to date)> > > > > > >>>> - Section Numbers> > > > > > >>>> (especially i=
f you originally put the copyright> > > > > > >somewhere> > > > > > >>>> ot=
her than the VERY end of the document, or if> > you> > > > > > >>>> numbere=
d the 'Status of the Memo' field)> > > > > > >>>>> > > > > > >>>>Please sen=
d us the changes, *DO NOT* send a new document> > with> > > the> > > > > > =
>>>>changes made. (If we think that the changes might be more> > > than> > =
> > > > >>>>editorial we will contact the AD or the IESG to confirm> that> =
> > the> > > > > > >>>>changes do not require review.)> > > > > > >>>>> > >=
 > > > >>>>Send us the changes in THIS format.> > > > > > >>>>> > > > > > >=
>>> 1)*** SECTION #'s*** [i.e. Section 5, 2nd> > > paragraph]> > > > > > >>=
>> 2) the text you want changed,> > > > > > >>>> 3) the new correct text an=
d> > > > > > >>>> 4) if the changes are spacing or indentation> than> > > p=
lease> > > > > > >note> > > > > > >>>> that.> > > > > > >>>>> > > > > > >>>=
>FOR EXAMPLE:> > > > > > >>>>> > > > > > >>>> Section 5.6, 3rd paragraph> >=
 > > > > >>>>> > > > > > >>>> OLD:> > > > > > >>>> The quick brown fox jump=
ed over the lazy dog.> > > > > > >>>>> > > > > > >>>> NEW:> > > > > > >>>> =
The quick brown dog jumps over the lazy fox.> > > > > > >>>> ^^^ ^ ^^^> > >=
 > > > >>>>If you have a whole paragraph to replace you do not need> to> > =
> use> > > > > > >>>>the arrow to point out the differences> > > > > > >>>>=
> > > > > > >>>> INTRODUCTION, 2nd paragraph> > > > > > >>>>> > > > > > >>>=
> Replace OLD:> > > > > > >>>>> > > > > > >>>> alsdfja;sldjf;lajsd;fljas;dl=
fj;> > > > > > >>>>> > > > > > >>>> With NEW:> > > > > > >>>>> > > > > > >>=
>> nv;alkjd;lsf;aoisj;ltjka;sldkjf> > > > > > >>>>> > > > > > >>>>Spacing o=
r indentation problems...> > > > > > >>>>> > > > > > >>>> Section 10, 1st p=
aragraph (remove spaces> between> > > bit> > > > > > >>>> and of, add space=
 after butter)> > > > > > >>>>> > > > > > >>>> OLD:> > > > > > >>>>> > > > =
> > >>>> Better botter bought a bit> > > > > > >>>> of bitter butterMary ma=
ry quite contrary> > > > > > >>>>> > > > > > >>>> NEW:> > > > > > >>>>> > >=
 > > > >>>> Better botter bought a bit of bitter butter> > > > > > >>>>> > =
> > > > >>>> Mary mary quite contrary> > > > > > >>>>> > > > > > >>>>This d=
ocument will NOT be published until we receive> > > agreement, from> > > > =
> > >>>>ALL listed authors, that the document is ready for> > > publication=
.> > > > > > >>>>> > > > > > >>>>Thanks for your cooperation,> > > > > > >>=
>>> > > > > > >>>>-RFC Editor> > > > > > >>>>> > > > > > >>>>> > > > > > >>=
>>Title : RADIUS Extension for Digest> > > > > > >>>> Authentication> > > >=
 > > >>>>Author(s) : B. Sterman, D. Sadolevsky,> > > > > > >>>> D. Schwartz=
, D. Williams,> > > > > > >>>> W. Beck> > > > > > >>>>Working Group Chair(s=
) : Bernard Aboba, David Nelson> > > > > > >>>>Area Director(s) : Dan Romas=
canu, Ronald Bonica> > > > > > >>>> > > > > > >

--_850a5faa-11aa-4c9f-9f82-831ac36344fd_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
RFC 4590bis is now being held in AUTH48, pending final verification. <br><b=
r>What started as a "simple" IANA-problem fix has turned into a longer odys=
sey due to the <br>discovery of additional errors/omissions.&nbsp; <br><br>=
In attempt to bring this story to a close, we need to make very sure that w=
e have looked over<br>this document carefully so that we don't have to go t=
hrough this again with RFC 4590ter. <br><br>So if you have ever had any int=
erest in RADIUS Digest Authentication, now would be the time<br>to look ove=
r the AUTH48 version of the document, and speak up if there is a problem.&n=
bsp; <br><br>&gt; Date: Fri, 21 Dec 2007 15:14:46 -0800<br>&gt; From: rfc-e=
[email-masked]<br>&gt; To: [email-masked]<br>&gt; CC: baruch.ste=
[email-masked]; [email-masked]; [email-masked]; dwilli@c=
isco.com; [email-masked]; [email-masked]; [email-masked]; =
[email-masked]; [email-masked]<br>&gt; Subject: Re: A=
UTH48 [SG]: RFC 5090  &lt;draft-ietf-radext-rfc4590bis-02.txt&gt; NOW AVAIL=
ABLE<br>&gt; <br>&gt; Greeings Wolfgang,<br>&gt; <br>&gt; Just a reminder t=
hat we are waiting to hear from you before continuing<br>&gt; on with the p=
ublication process.<br>&gt; <br>&gt; Please see the email below for documen=
t information.<br>&gt; <br>&gt; Thank you.<br>&gt; <br>&gt; RFC Editor<br>&=
gt; <br>&gt; On Fri, Dec 14, 2007 at 02:51:11PM -0800, RFC Editor wrote:<br=
>&gt; &gt; Hi Wolfgang,<br>&gt; &gt; <br>&gt; &gt; Just a friendly reminder=
 that we are waiting to hear from you before<br>&gt; &gt; continuing on wit=
h the publication process for RFC 5090<br>&gt; &gt; &lt;draft-ietf-radext-r=
fc4590bis-09.txt&gt;.  <br>&gt; &gt; <br>&gt; &gt; Please review the files =
located at:<br>&gt; &gt; <br>&gt; &gt;    ftp://ftp.rfc-editor.org/in-notes=
/authors/rfc5090.txt<br>&gt; &gt;    ftp://ftp.rfc-editor.org/in-notes/auth=
ors/rfc5090-diff.html<br>&gt; &gt; <br>&gt; &gt; Note that this diff file h=
ighlights only the differences between the<br>&gt; &gt; last posted version=
 of the document and the current text file.  The<br>&gt; &gt; previously po=
sted versions (during AUTH48) are available as:<br>&gt; &gt; <br>&gt; &gt; =
The originally posted AUTH48 files:<br>&gt; &gt;    ftp://ftp.rfc-editor.or=
g/in-notes/authors/rfc5090v1.txt<br>&gt; &gt;    ftp://ftp.rfc-editor.org/i=
n-notes/authors/rfc5090v1-diff.html<br>&gt; &gt; <br>&gt; &gt; Version 2 (i=
ncludes author updates) of AUTH48 files:<br>&gt; &gt;    ftp://ftp.rfc-edit=
or.org/in-notes/authors/rfc5090v2.txt<br>&gt; &gt;    ftp://ftp.rfc-editor.=
org/in-notes/authors/rfc5090v2-diff.html<br>&gt; &gt; Note that this file h=
ighlights only the differences between the<br>&gt; &gt; version 1 and 2 tex=
t files.<br>&gt; &gt; <br>&gt; &gt; We will wait to hear from you before co=
ntinuing on with the<br>&gt; &gt; publication process.<br>&gt; &gt; <br>&gt=
; &gt; Thank you.<br>&gt; &gt; <br>&gt; &gt; RFC Editor/sg<br>&gt; &gt; <br=
>&gt; &gt; <br>&gt; &gt; On Tue, Dec 11, 2007 at 05:08:35AM -0800, Bernard =
Aboba wrote:<br>&gt; &gt; &gt; <br>&gt; &gt; &gt; I also talked to Wolfgang=
 at IETF 70.  He wanted to check the document over carefully to make sure t=
here<br>&gt; &gt; &gt; were no further issues.   &gt; Subject: RE: AUTH48 [=
SG]: RFC 5090 &lt;draft-ietf-radext-rfc4590bis-02.txt&gt; NOW AVAILABLE&gt;=
 Date: Mon, 10 Dec 2007 20:30:51 +0200&gt; From: [email-masked]&=
gt; To: [email-masked]; [email-masked]&gt; CC: david.schwar=
[email-masked]; [email-masked]; [email-masked]; [email-masked];=
 [email-masked]; [email-masked]; [email-masked]&gt;=
 &gt; Yes,&gt; &gt; David Schwartz saw him at the ietf meeting and worked t=
hrough the draft&gt; with him. I think we should be hearing from him soon.&=
gt; &gt; Baruch&gt; &gt; &gt; -----Original Message-----&gt; From: RFC Edit=
or [mailto:[email-masked]] &gt; Sent: Monday, December 10, 2007 =
8:27 PM&gt; To: [email-masked]; Baruch Sterman&gt; Cc: David Schwartz;=
 RFC Editor; [email-masked]; [email-masked];&gt; Dan Romascanu; Rona=
ld Bonica; [email-masked];&gt; [email-masked]&gt; Subjec=
t: Re: AUTH48 [SG]: RFC 5090 &lt;draft-ietf-radext-rfc4590bis-02.txt&gt;&gt=
; NOW AVAILABLE&gt; &gt; All,&gt; &gt; Just checking to see if you have had=
 any luck contacting Wolfgang?&gt; &gt; Thanks!&gt; &gt; RFC Editor/sg&gt; =
&gt; On Tue, Nov 27, 2007 at 09:21:45PM +0200, Baruch Sterman wrote:&gt; &g=
t; David Schwartz will be at the IETF meetings next week. Maybe Wolfgang&gt=
; &gt; will be there and he can nudge him to answer. Lets hold off until we=
&gt; see&gt; &gt; if that way forward works. If not, we can go with option =
3.&gt; &gt; &gt; &gt; Thanks,&gt; &gt; &gt; &gt; Baruch&gt; &gt; &gt; &gt; =
&gt; &gt; -----Original Message-----&gt; &gt; From: RFC Editor [mailto:rfc-=
[email-masked]] &gt; &gt; Sent: Tuesday, November 27, 2007 12:41 AM&=
gt; &gt; To: Baruch Sterman&gt; &gt; Cc: RFC Editor&gt; &gt; Subject: Re: A=
UTH48 [SG]: RFC 5090&gt; &lt;draft-ietf-radext-rfc4590bis-02.txt&gt;&gt; &g=
t; NOW AVAILABLE&gt; &gt; &gt; &gt; Hi Baruch,&gt; &gt; &gt; &gt; We have a=
 couple of ways to move forward.&gt; &gt; &gt; &gt; 1. The author can be re=
moved as an author, and moved to the&gt; &gt; Acknowledgements section.&gt;=
 &gt; &gt; &gt; 2. We can create a Contributor's section and have him liste=
d there.&gt; &gt; &gt; &gt; 3. We can request that the AD approve the docum=
ent in place of the&gt; &gt; unavailabe author. &gt; &gt; &gt; &gt; Option =
3 has been done before in instances where the missing author&gt; &gt; made =
sizeable contributions to the document, so the other authors&gt; &gt; did n=
ot feel comfortable removing the individuals name as an&gt; &gt; author. &g=
t; &gt; &gt; &gt; It sounds as though 3 may be the proper way forward. If t=
his is the&gt; &gt; case, we will send an email to the ADs requesting their=
 approval in&gt; &gt; place of Wolfgang (the message will be cc'ed to all r=
elevant&gt; &gt; parties, including Wolfgang). &gt; &gt; &gt; &gt; If the a=
bove suggestions are unacceptable and you have an alternative&gt; &gt; solu=
tion, please let us know. &gt; &gt; &gt; &gt; Thank you.&gt; &gt; &gt; &gt;=
 RFC Editor&gt; &gt; &gt; &gt; On Mon, Nov 26, 2007 at 09:39:09AM +0200, Ba=
ruch Sterman wrote:&gt; &gt; &gt; I wrote to Wolfgang as well, but got no r=
esponse. What is the&gt; &gt; procedure&gt; &gt; &gt; in this case? I am su=
re that Wolfgang would be ok with the changes.&gt; &gt; The&gt; &gt; &gt; l=
ast email I received was on October 19 where he said that he had&gt; made&g=
t; &gt; &gt; the one correction (suggested by Ellermann) in the cnonce valu=
e. &gt; &gt; &gt; &gt; &gt; &gt; Baruch&gt; &gt; &gt; &gt; &gt; &gt; &gt; &=
gt; &gt; -----Original Message-----&gt; &gt; &gt; From: RFC Editor [mailto:=
[email-masked]] &gt; &gt; &gt; Sent: Wednesday, November 21, 200=
7 10:35 PM&gt; &gt; &gt; To: David Williams; Baruch Sterman; dscreat@dscrea=
t.com; David&gt; &gt; Schwartz;&gt; &gt; &gt; [email-masked]&gt; &gt; =
&gt; Cc: [email-masked]; [email-masked]; RFC&gt; &=
gt; Editor&gt; &gt; &gt; Subject: Re: AUTH48 [SG]: RFC 5090&gt; &gt; &lt;dr=
aft-ietf-radext-rfc4590bis-02.txt&gt;&gt; &gt; &gt; NOW AVAILABLE&gt; &gt; =
&gt; &gt; &gt; &gt; Greetings Wolfgang,&gt; &gt; &gt; &gt; &gt; &gt; We do =
not believe we have received your response regarding this&gt; &gt; &gt; doc=
ument's readiness for publication as an RFC. Please review the&gt; &gt; &gt=
; text and let us know if you are content with the document as it now&gt; &=
gt; &gt; appears at:&gt; &gt; &gt; &gt; &gt; &gt; ftp://ftp.rfc-editor.org/=
in-notes/authors/rfc5090.txt&gt; &gt; &gt; ftp://ftp.rfc-editor.org/in-note=
s/authors/rfc5090-diff.html&gt; &gt; &gt; Note that this diff file highligh=
ts only the changes between the&gt; last &gt; &gt; &gt; posted version of t=
he document and the current text file.&gt; &gt; &gt; &gt; &gt; &gt; &gt; &g=
t; &gt; The last versions of the document are available as:&gt; &gt; &gt; &=
gt; &gt; &gt; ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt&gt; &=
gt; &gt; ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html&gt; =
&gt; &gt; &gt; &gt; &gt; ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v=
2.txt&gt; &gt; &gt; ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-dif=
f.html&gt; &gt; &gt; Note that this diff file highlights only the changes b=
etween v1 and&gt; &gt; &gt; the v2.&gt; &gt; &gt; &gt; &gt; &gt; We will wa=
it to hear from you before continuing on with the&gt; &gt; &gt; publication=
 process.&gt; &gt; &gt; &gt; &gt; &gt; Thank you.&gt; &gt; &gt; &gt; &gt; &=
gt; RFC Editor&gt; &gt; &gt; &gt; &gt; &gt; On Fri, Nov 16, 2007 at 05:13:0=
4PM -0800, RFC Editor wrote:&gt; &gt; &gt; &gt; Authors,&gt; &gt; &gt; &gt;=
 &gt; &gt; &gt; &gt; We have corrected the text as indicated below and post=
ed the&gt; revised&gt; &gt; &gt; &gt; version of the document at:&gt; &gt; =
&gt; &gt; &gt; &gt; &gt; &gt; ftp://ftp.rfc-editor.org/in-notes/authors/rfc=
5090.txt&gt; &gt; &gt; &gt; ftp://ftp.rfc-editor.org/in-notes/authors/rfc50=
90-diff.html&gt; &gt; &gt; &gt; Note that this diff file highlights only th=
e changes betwee the&gt; last&gt; &gt; &gt; &gt; &gt; &gt; posted version o=
f the document and the current text file.&gt; &gt; &gt; &gt; &gt; &gt; &gt;=
 &gt; Please review the document and let us know if you approve this&gt; &g=
t; &gt; &gt; text for publication.&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; W=
e believe we are waiting for the following approvals:&gt; &gt; &gt; &gt; &g=
t; &gt; &gt; &gt; Baruch Sterman - done &gt; &gt; &gt; &gt; Daniel Sadolevs=
ky - done&gt; &gt; &gt; &gt; David Schwartz - done&gt; &gt; &gt; &gt; David=
 Williams&gt; &gt; &gt; &gt; Wolfgang Beck&gt; &gt; &gt; &gt; &gt; &gt; &gt=
; &gt; Bernard Aboba - done&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt=
; &gt; &gt; Thank you.&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; RFC Editor&gt=
; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; On Tue, Nov 06, 20=
07 at 04:58:49PM -0800, RFC Editor wrote:&gt; &gt; &gt; &gt; &gt; Authors,&=
gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Please confer and let us k=
now how the text should/should not use&gt; &gt; the&gt; &gt; &gt; &gt; &gt;=
 quote marks. It sounds as though this email was for discussion.&gt; &gt; I=
f&gt; &gt; &gt; &gt; &gt; the changes below are acceptable, we will make th=
e changes and&gt; &gt; post&gt; &gt; &gt; a&gt; &gt; &gt; &gt; &gt; revised=
 version of the document.&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
Also, please note the following status of document approvals:&gt; &gt; &gt;=
 &gt; &gt; &gt; &gt; &gt; &gt; &gt; Baruch Sterman - done (although we woul=
d like to know if you&gt; agree&gt; &gt; &gt; &gt; &gt; with the changes de=
scribed below)&gt; &gt; &gt; &gt; &gt; Daniel Sadolevsky - done&gt; &gt; &g=
t; &gt; &gt; David Schwartz&gt; &gt; &gt; &gt; &gt; David Williams&gt; &gt;=
 &gt; &gt; &gt; Wolfgang Beck&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &=
gt; Bernard Aboba - done&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; W=
e will wait to hear further before continuing on with the&gt; &gt; &gt; pub=
lication&gt; &gt; &gt; &gt; &gt; process.&gt; &gt; &gt; &gt; &gt; &gt; &gt;=
 &gt; &gt; &gt; Thank you.&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=
 RFC Editor&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=
 &gt; &gt; On Fri, Oct 19, 2007 at 01:33:14PM -0400, David Williams wrote:&=
gt; &gt; &gt; &gt; &gt; &gt; Hi Baruch,&gt; &gt; &gt; &gt; &gt; &gt; &gt; &=
gt; &gt; &gt; &gt; &gt; These look good, and I agree with your consistency =
comment. I&gt; &gt; &gt; have a few &gt; &gt; &gt; &gt; &gt; &gt; more spec=
ific changes to suggest that I would like you and&gt; &gt; others&gt; &gt; =
&gt; to &gt; &gt; &gt; &gt; &gt; &gt; review as well. But first a couple of=
 general style comments&gt; &gt; that&gt; &gt; &gt; require &gt; &gt; &gt; =
&gt; &gt; &gt; no changes to the document.&gt; &gt; &gt; &gt; &gt; &gt; &gt=
; &gt; &gt; &gt; &gt; &gt; General comment #1: I tried to find a definitive=
 style guide&gt; to&gt; &gt; &gt; use of &gt; &gt; &gt; &gt; &gt; &gt; sing=
le quotes versus double quotes and found there is no hard&gt; &gt; &gt; gui=
delines, &gt; &gt; &gt; &gt; &gt; &gt; that consistency is most important:&=
gt; &gt; &gt; &gt; &gt; &gt; http://en.wikipedia.org/wiki/Quotation_mark&gt=
; &gt; &gt; &gt; &gt; &gt; http://forum.wordreference.com/showthread.php?t=
=3D120946&gt; &gt; &gt; &gt; &gt; &gt; Though I tend to think that double q=
uotes are more commonly&gt; used&gt; &gt; &gt; and match &gt; &gt; &gt; &gt=
; &gt; &gt; the syntax of more popular programming languages, but there&gt;=
 are&gt; &gt; so&gt; &gt; &gt; many &gt; &gt; &gt; &gt; &gt; &gt; quoted it=
ems in the document and it has been this way for a&gt; long&gt; &gt; &gt; t=
ime, so &gt; &gt; &gt; &gt; &gt; &gt; best to leave as is.&gt; &gt; &gt; &g=
t; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; General comment #2: When referin=
g to responses from the radius&gt; &gt; &gt; server &gt; &gt; &gt; &gt; &gt=
; &gt; there are a lot of instances of a comment similiar to "without&gt; &=
gt; &gt; surrounding &gt; &gt; &gt; &gt; &gt; &gt; quotes" that potentially=
 could be removed for readability.&gt; &gt; &gt; Especially if &gt; &gt; &g=
t; &gt; &gt; &gt; there were a more concise definition up-front about the&g=
t; general&gt; &gt; &gt; form of &gt; &gt; &gt; &gt; &gt; &gt; values retur=
ned from the radius server. But I am a little&gt; &gt; &gt; hesitant to &gt=
; &gt; &gt; &gt; &gt; &gt; just strip them out now.&gt; &gt; &gt; &gt; &gt;=
 &gt; &gt; &gt; &gt; &gt; &gt; &gt; Specific comments, to build on top of y=
our list:&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; In sec=
tion 2.1.2, 1st paragraph should not have quotes around&gt; &gt; &gt; nonce=
. &gt; &gt; &gt; &gt; &gt; &gt; Paragraph should read:&gt; &gt; &gt; &gt; &=
gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; If a matching (Proxy-)Authorization =
header is present and&gt; &gt; &gt; contains&gt; &gt; &gt; &gt; &gt; &gt; H=
TTP Digest information, the RADIUS client checks the nonce&gt; &gt; &gt; &g=
t; &gt; &gt; parameter.&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &g=
t; &gt; In next paragraph, do not need quotes around response.&gt; &gt; Par=
agraph&gt; &gt; &gt; should &gt; &gt; &gt; &gt; &gt; &gt; read:&gt; &gt; &g=
t; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; If the RADIUS client recogn=
izes the nonce, it takes the&gt; &gt; header&gt; &gt; &gt; &gt; &gt; &gt; d=
irectives and puts them into a RADIUS Access-Request&gt; packet.&gt; &gt; &=
gt; It&gt; &gt; &gt; &gt; &gt; &gt; puts the response directive into a Dige=
st-Response&gt; attribute&gt; &gt; &gt; and&gt; &gt; &gt; &gt; &gt; &gt; th=
e realm, nonce, digest-uri, qop, algorithm, cnonce, nc,&gt; &gt; &gt; usern=
ame,&gt; &gt; &gt; &gt; &gt; &gt; and opaque directives into the respective=
 Digest-Realm,&gt; &gt; &gt; Digest-Nonce,&gt; &gt; &gt; &gt; &gt; &gt; Dig=
est-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce,&gt; &gt; &gt; Digest-=
&gt; &gt; &gt; &gt; &gt; &gt; Nonce-Count, Digest-Username, and Digest-Opaq=
ue attributes.&gt; &gt; &gt; The&gt; &gt; &gt; &gt; &gt; &gt; RADIUS client=
 puts the request method into the&gt; Digest-Method&gt; &gt; &gt; &gt; &gt;=
 &gt; attribute.&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=
 In section 2.1.3, in addtion to the items you point out, in&gt; the&gt; &g=
t; &gt; last &gt; &gt; &gt; &gt; &gt; &gt; paragraph, nextnounce does not n=
eed quoting. Paragraph&gt; should&gt; &gt; &gt; read:&gt; &gt; &gt; &gt; &g=
t; &gt; &gt; &gt; &gt; &gt; &gt; &gt; When the RADIUS server provides a Dig=
est-Nextnonce&gt; attribute&gt; &gt; in&gt; &gt; &gt; the&gt; &gt; &gt; &gt=
; &gt; &gt; Access-Accept packet, the RADIUS client puts the contents&gt; o=
f&gt; &gt; &gt; this&gt; &gt; &gt; &gt; &gt; &gt; attribute into a nextnonc=
e directive. Now it can send an&gt; &gt; HTTP-&gt; &gt; &gt; &gt; &gt; &gt;=
 style response.&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=
 In section 2.1.4, 2nd paragraph, the stale directive should&gt; not&gt; &g=
t; &gt; need &gt; &gt; &gt; &gt; &gt; &gt; quoting. Paragraph should read:&=
gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; If the RADIUS cl=
ient receives an Access-Challenge packet in&gt; &gt; &gt; response&gt; &gt;=
 &gt; &gt; &gt; &gt; to an Access-Request containing a Digest-Nonce attribu=
te,&gt; the&gt; &gt; &gt; RADIUS&gt; &gt; &gt; &gt; &gt; &gt; server did no=
t accept the nonce. If a Digest-Stale&gt; attribute&gt; &gt; &gt; is&gt; &g=
t; &gt; &gt; &gt; &gt; present in the Access-Challenge and has a value of '=
true'&gt; &gt; &gt; (without&gt; &gt; &gt; &gt; &gt; &gt; surrounding quote=
s), the RADIUS client sends an error&gt; &gt; response&gt; &gt; &gt; (401&g=
t; &gt; &gt; &gt; &gt; &gt; or 407) containing a WWW-/Proxy-Authenticate he=
ader with&gt; the&gt; &gt; &gt; &gt; &gt; &gt; directive stale and the dige=
st directives derived from the&gt; &gt; &gt; Digest-*&gt; &gt; &gt; &gt; &g=
t; &gt; attributes.&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &=
gt; Except I think the wording of the last sentence in this same&gt; &gt; &=
gt; paragraph &gt; &gt; &gt; &gt; &gt; &gt; could be improved. So that the =
paragraph reads more like:&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=
 &gt; &gt; If the RADIUS client receives an Access-Challenge packet in&gt; =
&gt; &gt; response&gt; &gt; &gt; &gt; &gt; &gt; to an Access-Request contai=
ning a Digest-Nonce attribute,&gt; the&gt; &gt; &gt; RADIUS&gt; &gt; &gt; &=
gt; &gt; &gt; server did not accept the nonce. If a Digest-Stale&gt; attrib=
ute&gt; &gt; &gt; is&gt; &gt; &gt; &gt; &gt; &gt; present in the Access-Cha=
llenge and has a value of 'true'&gt; &gt; &gt; (without&gt; &gt; &gt; &gt; =
&gt; &gt; surrounding quotes), the RADIUS client sends an error&gt; &gt; re=
sponse&gt; &gt; &gt; (401&gt; &gt; &gt; &gt; &gt; &gt; or 407) containing a=
 WWW-/Proxy-Authenticate header with&gt; the&gt; &gt; &gt; &gt; &gt; &gt; s=
tale directive set to 'true' and the digest directives&gt; &gt; derived&gt;=
 &gt; &gt; from&gt; &gt; &gt; &gt; &gt; &gt; the Digest-* attributes.&gt; &=
gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; In section 3.10, 1st =
paragraph, I believe the term "qop-level"&gt; &gt; is&gt; &gt; &gt; ill &gt=
; &gt; &gt; &gt; &gt; &gt; defined and should not be used, that qop directi=
ve or&gt; qop-value&gt; &gt; &gt; would be &gt; &gt; &gt; &gt; &gt; &gt; be=
tter. In other words the paragraph should read:&gt; &gt; &gt; &gt; &gt; &gt=
; &gt; &gt; &gt; &gt; &gt; &gt; When using the qop-value 'auth-int', a hash=
 of the&gt; &gt; &gt; HTTP-style&gt; &gt; &gt; &gt; &gt; &gt; message body'=
s contents is required for digest&gt; &gt; &gt; calculation.&gt; &gt; &gt; =
&gt; &gt; &gt; Instead of sending the complete body of the message,&gt; &gt=
; only&gt; &gt; &gt; its&gt; &gt; &gt; &gt; &gt; &gt; hash value is sent. T=
his hash value can be used&gt; &gt; directly&gt; &gt; &gt; in&gt; &gt; &gt;=
 &gt; &gt; &gt; the digest calculation.&gt; &gt; &gt; &gt; &gt; &gt; &gt; &=
gt; &gt; &gt; &gt; &gt; In section 3.15, auth-param doesn't need quoting. S=
o that the&gt; &gt; &gt; paragraph &gt; &gt; &gt; &gt; &gt; &gt; becomes:&g=
t; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; This attribute is=
 a placeholder for future extensions&gt; &gt; and&gt; &gt; &gt; &gt; &gt; &=
gt; corresponds to the auth-param parameter defined in&gt; &gt; &gt; Sectio=
n&gt; &gt; &gt; &gt; &gt; &gt; 3.2.1 of [RFC2617]. The Digest-Auth-Param is=
 the&gt; &gt; &gt; mechanism&gt; &gt; &gt; &gt; &gt; &gt; whereby the RADIU=
S client and RADIUS server can&gt; &gt; exchange&gt; &gt; &gt; auth-&gt; &g=
t; &gt; &gt; &gt; &gt; param extension parameters contained within Digest&g=
t; &gt; &gt; headers that&gt; &gt; &gt; &gt; &gt; &gt; are not understood b=
y the RADIUS client and for which&gt; &gt; &gt; there are&gt; &gt; &gt; &gt=
; &gt; &gt; no corresponding stand-alone attributes.&gt; &gt; &gt; &gt; &gt=
; &gt; &gt; &gt; &gt; &gt; &gt; &gt; In section 3.17, domain doesn't need q=
uoting. So that the&gt; &gt; &gt; paragraph &gt; &gt; &gt; &gt; &gt; &gt; b=
ecomes:&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; When a R=
ADIUS client has asked for a nonce, the&gt; RADIUS&gt; &gt; &gt; server&gt;=
 &gt; &gt; &gt; &gt; &gt; MAY send one or more Digest-Domain attributes in =
its&gt; &gt; &gt; Access-&gt; &gt; &gt; &gt; &gt; &gt; Challenge packet. Th=
e RADIUS client puts them into&gt; the&gt; &gt; &gt; quoted,&gt; &gt; &gt; =
&gt; &gt; &gt; space-separated list of URIs of the domain directive&gt; of&=
gt; &gt; a&gt; &gt; &gt; &gt; &gt; &gt; WWW-Authenticate header. Together w=
ith Digest-Realm,&gt; &gt; the&gt; &gt; &gt; URIs&gt; &gt; &gt; &gt; &gt; &=
gt; in the list define the protection space (see&gt; [RFC2617],&gt; &gt; &g=
t; Section&gt; &gt; &gt; &gt; &gt; &gt; 3.2.1) for some HTTP-style protocol=
s. This attribute&gt; &gt; &gt; MUST only&gt; &gt; &gt; &gt; &gt; &gt; be u=
sed in Access-Challenge and Accounting-Request&gt; &gt; &gt; packets.&gt; &=
gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; In section 3.19, 1st =
paragraph, in addtion to no quotes around&gt; &gt; &gt; rspauth as &gt; &gt=
; &gt; &gt; &gt; &gt; you pointed out, I believe there should be no quotes =
around&gt; qop.&gt; &gt; &gt; So that &gt; &gt; &gt; &gt; &gt; &gt; the par=
agraph reads:&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Th=
is attribute is used to allow the generation of an&gt; &gt; &gt; &gt; &gt; =
&gt; Authentication-Info header, even if the HTTP-style&gt; &gt; &gt; respo=
nse's&gt; &gt; &gt; &gt; &gt; &gt; body is required for the calculation of =
the rspauth&gt; &gt; &gt; value.&gt; &gt; &gt; &gt; &gt; &gt; It SHOULD be =
used in Access-Accept packets if the&gt; &gt; &gt; required&gt; &gt; &gt; &=
gt; &gt; &gt; quality of protection (qop) is 'auth-int'.&gt; &gt; &gt; &gt;=
 &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; thanks,&gt; &gt; &gt; &gt; &gt; &g=
t; -david&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; On Fri=
, 19 Oct 2007, 1:43pm, Baruch Sterman wRote:&gt; &gt; &gt; &gt; &gt; &gt; &=
gt; &gt; &gt; &gt; &gt; &gt; &gt;After lengthy discussions with my father-i=
n-law who is a&gt; &gt; &gt; professor of&gt; &gt; &gt; &gt; &gt; &gt; &gt;=
English, I agree with Dave's method of using quotes only in&gt; the&gt; &gt=
; &gt; value of&gt; &gt; &gt; &gt; &gt; &gt; &gt;an attribute/directive, bu=
t not in referencing the&gt; &gt; &gt; attribute/directive&gt; &gt; &gt; &g=
t; &gt; &gt; &gt;by name. As such, I have some changes.&gt; &gt; &gt; &gt; =
&gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;In section 2.1.3 3rd paragr=
aph should not have quotes around&gt; &gt; the&gt; &gt; &gt; word&gt; &gt; =
&gt; &gt; &gt; &gt; &gt;rspauth. Sentence should read:&gt; &gt; &gt; &gt; &=
gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt; * If the Digest-Qop attribu=
te's value is 'auth' or not&gt; &gt; &gt; specified,&gt; &gt; &gt; &gt; &gt=
; &gt; &gt; the RADIUS client puts the Digest-Response-Auth&gt; &gt; &gt; a=
ttribute's&gt; &gt; &gt; &gt; &gt; &gt; &gt; content into the Authenticatio=
n-Info header's rspauth&gt; &gt; &gt; &gt; &gt; &gt; &gt; directive of the =
HTTP-style response.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &=
gt; &gt; &gt;Same section 5th paragraph - no quotes around qop and&gt; &gt;=
 algorithm:&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; =
&gt; o If the Access-Accept packet contains a Digest-HA1&gt; &gt; attribute=
,&gt; &gt; &gt; the&gt; &gt; &gt; &gt; &gt; &gt; &gt; RADIUS client checks =
the qop and algorithm directives in&gt; &gt; the&gt; &gt; &gt; &gt; &gt; &g=
t; &gt; Authorization header of the HTTP-style request it wants&gt; to&gt; =
&gt; &gt; &gt; &gt; &gt; &gt; authorize:&gt; &gt; &gt; &gt; &gt; &gt; &gt;&=
gt; &gt; &gt; &gt; &gt; &gt; &gt;Next paragraph - no quotes around qop&gt; =
&gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt; * If the qo=
p directive is missing or its value is&gt; 'auth',&gt; &gt; &gt; the&gt; &g=
t; &gt; &gt; &gt; &gt; &gt; RADIUS client ignores the Digest-HA1 attribute.=
 It&gt; &gt; does&gt; &gt; &gt; not&gt; &gt; &gt; &gt; &gt; &gt; &gt; inclu=
de an Authentication-Info header in its&gt; HTTP-style&gt; &gt; &gt; &gt; &=
gt; &gt; &gt; response.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt=
; &gt; &gt; &gt;Next paragraph - no quotes around qop or rspauth.&gt; &gt; =
&gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt; * If the qop dir=
ective's value is 'auth-int' and at&gt; least&gt; &gt; &gt; one&gt; &gt; &g=
t; &gt; &gt; &gt; &gt; of the following conditions is true, the RADIUS&gt; =
client&gt; &gt; &gt; &gt; &gt; &gt; &gt; calculates the contents of the HTT=
P-style response's&gt; &gt; &gt; rspauth&gt; &gt; &gt; &gt; &gt; &gt; &gt; =
directive:&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &=
gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;2 paragraphs later - no quotes around =
rspauth&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;=
 The RADIUS client creates the HTTP-style response&gt; &gt; message&gt; &gt=
; &gt; and&gt; &gt; &gt; &gt; &gt; &gt; &gt; calculates the hash of this me=
ssage's body. It uses&gt; &gt; the&gt; &gt; &gt; result&gt; &gt; &gt; &gt; =
&gt; &gt; &gt; and the Digest-URI attribute's value of the&gt; &gt; corresp=
onding&gt; &gt; &gt; &gt; &gt; &gt; &gt; Access-Request packet to perform t=
he H(A2)&gt; calculation.&gt; &gt; &gt; It&gt; &gt; &gt; &gt; &gt; &gt; &gt=
; takes the Digest-Nonce, Digest-Nonce-Count,&gt; &gt; &gt; Digest-CNonce, =
and&gt; &gt; &gt; &gt; &gt; &gt; &gt; Digest-Qop values of the correspondin=
g Access-Request&gt; &gt; and&gt; &gt; &gt; the&gt; &gt; &gt; &gt; &gt; &gt=
; &gt; Digest-HA1 attribute's value to finish the&gt; computation&gt; &gt; =
of&gt; &gt; &gt; the&gt; &gt; &gt; &gt; &gt; &gt; &gt; rspauth value.&gt; &=
gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt=
; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;Section 3.4 paragrap=
h 1 - no quotes around rspauth&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &=
gt; &gt; &gt; &gt; &gt; This attribute enables the RADIUS server to prove&g=
t; &gt; &gt; possession of&gt; &gt; &gt; &gt; &gt; &gt; &gt; the password. =
If the previously received Digest-Qop&gt; &gt; &gt; attribute&gt; &gt; &gt;=
 &gt; &gt; &gt; &gt; was 'auth-int' (without surrounding quotes), the&gt; R=
ADIUS&gt; &gt; &gt; server&gt; &gt; &gt; &gt; &gt; &gt; &gt; MUST send a Di=
gest-HA1 attribute instead of a&gt; &gt; &gt; Digest-Response-&gt; &gt; &gt=
; &gt; &gt; &gt; &gt; Auth attribute. The Digest-Response-Auth attribute&gt=
; &gt; MUST&gt; &gt; &gt; only&gt; &gt; &gt; &gt; &gt; &gt; &gt; be used in=
 Access-Accept packets. The RADIUS client&gt; &gt; puts&gt; &gt; &gt; the&g=
t; &gt; &gt; &gt; &gt; &gt; &gt; attribute value without surrounding quotes=
 into the&gt; &gt; &gt; rspauth&gt; &gt; &gt; &gt; &gt; &gt; &gt; directive=
 of the Authentication-Info header.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &=
gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;Section 3.5 2=
nd paragraph - no quotes around nextnonce&gt; &gt; &gt; &gt; &gt; &gt; &gt;=
&gt; &gt; &gt; &gt; &gt; &gt; &gt; The RADIUS server MAY put a Digest-Nextn=
once&gt; attribute&gt; &gt; &gt; into an&gt; &gt; &gt; &gt; &gt; &gt; &gt; =
Access-Accept packet. If this attribute is present,&gt; &gt; the&gt; &gt; &=
gt; RADIUS&gt; &gt; &gt; &gt; &gt; &gt; &gt; client MUST put the contents o=
f this attribute into&gt; the&gt; &gt; &gt; &gt; &gt; &gt; &gt; nextnonce d=
irective of an Authentication-Info header&gt; in&gt; &gt; &gt; its&gt; &gt;=
 &gt; &gt; &gt; &gt; &gt; HTTP-style response. This attribute MUST only be&=
gt; used&gt; &gt; in&gt; &gt; &gt; &gt; &gt; &gt; &gt; Access-Accept packet=
s.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; =
&gt; &gt; &gt; &gt; &gt; &gt;Section 3.7, 4th paragraph - no quotes around =
uri&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt; If =
the HTTP-style request has an Authorization&gt; header,&gt; &gt; &gt; the&g=
t; &gt; &gt; &gt; &gt; &gt; &gt; RADIUS client puts the value of the uri di=
rective&gt; found&gt; &gt; &gt; in&gt; &gt; &gt; &gt; &gt; &gt; &gt; the HT=
TP-style request Authorization header (known as&gt; &gt; &gt; "digest-&gt; =
&gt; &gt; &gt; &gt; &gt; &gt; uri-value" in Section 3.2.2 of [RFC2617]) wit=
hout&gt; &gt; &gt; surrounding&gt; &gt; &gt; &gt; &gt; &gt; &gt; quotes int=
o this attribute. If there is no&gt; &gt; Authorization&gt; &gt; &gt; &gt; =
&gt; &gt; &gt; header, the RADIUS client takes the value of the&gt; &gt; re=
quest&gt; &gt; &gt; URI&gt; &gt; &gt; &gt; &gt; &gt; &gt; from the HTTP-sty=
le request it wants to authenticate.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; =
&gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;Section 3.8,=
 4th paragraph - no quotes around qop&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;=
 &gt; &gt; &gt; &gt; &gt; &gt; In Access-Requests, the RADIUS client takes =
the value&gt; &gt; of&gt; &gt; &gt; the&gt; &gt; &gt; &gt; &gt; &gt; &gt; q=
op directive (qop-value as described in [RFC2617])&gt; &gt; from&gt; &gt; &=
gt; the&gt; &gt; &gt; &gt; &gt; &gt; &gt; HTTP-style request it wants to au=
thenticate. In&gt; &gt; Access-&gt; &gt; &gt; &gt; &gt; &gt; &gt; Challenge=
 packets, the RADIUS server puts a desired&gt; &gt; &gt; qop-value&gt; &gt;=
 &gt; &gt; &gt; &gt; &gt; into this attribute. If the RADIUS server support=
s&gt; &gt; more&gt; &gt; &gt; than&gt; &gt; &gt; &gt; &gt; &gt; &gt; one "q=
uality of protection" value, it puts each&gt; &gt; qop-value&gt; &gt; &gt; =
into&gt; &gt; &gt; &gt; &gt; &gt; &gt; a separate Digest-Qop attribute.&gt;=
 &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;Section 3.1=
8 1st paragraph - no quotes around stale&gt; &gt; &gt; &gt; &gt; &gt; &gt;&=
gt; &gt; &gt; &gt; &gt; &gt; &gt; This attribute is sent by a RADIUS server=
 in order to&gt; &gt; &gt; notify&gt; &gt; &gt; &gt; &gt; &gt; &gt; the RAD=
IUS client whether it has accepted a nonce.&gt; If&gt; &gt; &gt; the&gt; &g=
t; &gt; &gt; &gt; &gt; &gt; nonce presented by the RADIUS client was stale,=
 the&gt; &gt; value&gt; &gt; &gt; is&gt; &gt; &gt; &gt; &gt; &gt; &gt; 'tru=
e' and is 'false' otherwise. The RADIUS client&gt; &gt; puts&gt; &gt; &gt; =
the&gt; &gt; &gt; &gt; &gt; &gt; &gt; content of this attribute into a stal=
e directive of&gt; the&gt; &gt; &gt; WWW-&gt; &gt; &gt; &gt; &gt; &gt; &gt;=
 Authenticate header in the HTTP-style response to the&gt; &gt; &gt; reques=
t&gt; &gt; &gt; &gt; &gt; &gt; &gt; it wants to authenticate. The attribute=
 MUST only be&gt; &gt; &gt; used in&gt; &gt; &gt; &gt; &gt; &gt; &gt; Acces=
s-Challenge packets.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &=
gt; &gt; &gt;3.19 1st paragraph - no quotes around rspauth&gt; &gt; &gt; &g=
t; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt; This attribute is used =
to allow the generation of an&gt; &gt; &gt; &gt; &gt; &gt; &gt; Authenticat=
ion-Info header, even if the HTTP-style&gt; &gt; &gt; response's&gt; &gt; &=
gt; &gt; &gt; &gt; &gt; body is required for the calculation of the rspauth=
&gt; &gt; &gt; value.&gt; &gt; &gt; &gt; &gt; &gt; &gt; It SHOULD be used i=
n Access-Accept packets if the&gt; &gt; &gt; required&gt; &gt; &gt; &gt; &g=
t; &gt; &gt; quality of protection ('qop') is 'auth-int'.&gt; &gt; &gt; &gt=
; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; =
&gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &g=
t;I think that does it. Even if this is not right, at least it&gt; &gt; &gt=
; should now&gt; &gt; &gt; &gt; &gt; &gt; &gt;be consistent.&gt; &gt; &gt; =
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;Comments?&gt; &gt; &gt=
; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;Baruch&gt; &gt; &gt;=
 &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &=
gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;-----Original Message-----&g=
t; &gt; &gt; &gt; &gt; &gt; &gt;From: RFC Editor [mailto:rfc-editor@rfc-edi=
tor.org]&gt; &gt; &gt; &gt; &gt; &gt; &gt;Sent: Monday, October 15, 2007 8:=
45 PM&gt; &gt; &gt; &gt; &gt; &gt; &gt;To: David Williams&gt; &gt; &gt; &gt=
; &gt; &gt; &gt;Cc: Baruch Sterman; [email-masked]; David Schwartz;&gt=
; &gt; &gt; &gt; &gt; &gt; &gt;[email-masked]; [email-masked]=
rg;&gt; &gt; &gt; &gt; &gt; &gt; &gt;[email-masked]; RFC Edit=
or&gt; &gt; &gt; &gt; &gt; &gt; &gt;Subject: Re: AUTH48 [SG]: RFC 5090&gt; =
&gt; &gt; &lt;draft-ietf-radext-rfc4590bis-02.txt&gt;&gt; &gt; &gt; &gt; &g=
t; &gt; &gt;NOW AVAILABLE&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &=
gt; &gt; &gt; &gt;Greeting all,&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; =
&gt; &gt; &gt; &gt; &gt;We have not heard further regarding the issues belo=
w or other&gt; &gt; &gt; changes&gt; &gt; &gt; &gt; &gt; &gt; &gt;that may =
be required before publishing this document as an&gt; RFC.&gt; &gt; &gt; &g=
t; &gt; &gt; &gt;Please review the document and let us know if there are an=
y&gt; &gt; &gt; &gt; &gt; &gt; &gt;corrections required.&gt; &gt; &gt; &gt;=
 &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt; ftp://ftp.rfc-editor.org/=
in-notes/authors/rfc5090.txt&gt; &gt; &gt; &gt; &gt; &gt; &gt; ftp://ftp.rf=
c-editor.org/in-notes/authors/rfc5090-diff.html&gt; &gt; &gt; &gt; &gt; &gt=
; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;We will wait to hear from you befor=
e continuing on with the&gt; &gt; &gt; &gt; &gt; &gt; &gt;publication proce=
ss.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;Than=
k you.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;R=
FC Editor&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &g=
t;On Sun, Oct 07, 2007 at 01:29:00PM -0400, David Williams&gt; wrote:&gt; &=
gt; &gt; &gt; &gt; &gt; &gt;&gt;On Thu, 4 Oct 2007, 3:40pm, RFC Editor wRot=
e:&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&=
gt;&gt;Authors,&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; &gt; &gt; &gt=
; &gt; &gt; &gt;&gt;&gt;While reviewing &lt;draft-ietf-radext-rfc4590bis-02=
.txt&gt;&gt; during&gt; &gt; &gt; AUTH48,&gt; &gt; &gt; &gt; &gt; &gt; &gt;=
&gt;&gt;please consider the following.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt=
;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;In previous dialog, we had t=
he following exchange:&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; &gt; &=
gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt;2. Please explain the usage of the s=
ingle quote marks (')&gt; &gt; in&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;=
&gt;&gt;this document. There seems to be inconsistency, but we&gt; are&gt; =
&gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt;unable to determine which valu=
es/attributes/parameters&gt; you&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&=
gt;&gt;wanted to appear in quote marks. For example, we see&gt; &gt; &gt; &=
gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt=
;&gt;&gt;'auth-int'/"auth-int"&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt=
;&gt;'rspauth' directive/rspauth directive&gt; &gt; &gt; &gt; &gt; &gt; &gt=
;&gt;&gt;&gt;&gt;'rspauth' value/rspauth value&gt; &gt; &gt; &gt; &gt; &gt;=
 &gt;&gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;As RfC 2=
617 always uses ", replacing all 's in question&gt; with&gt; &gt; "&gt; &gt=
; &gt; seems&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;the right thing t=
o do.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt=
; &gt;&gt;&gt;Please note that we did not replace all 's with "s because&gt=
; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;RFC 4590 uses 's. However, if you fe=
el that the document&gt; &gt; &gt; should be&gt; &gt; &gt; &gt; &gt; &gt; &=
gt;&gt;&gt;more alignmed with RFC 2617, please let us know and we will&gt; =
&gt; &gt; make&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;this change.&gt; &g=
t; &gt; &gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;If we =
are taking a vote, I would prefer using " instead of '&gt; &gt; &gt; around=
&gt; &gt; &gt; &gt; &gt; &gt; &gt;the&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;=
value strings. I think it is better to stay aligned with&gt; 2617&gt; &gt; =
&gt; rather&gt; &gt; &gt; &gt; &gt; &gt; &gt;than&gt; &gt; &gt; &gt; &gt; &=
gt; &gt;&gt;4590. Also I believe the " usage is more commonly used in&gt; &=
gt; other&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;specifications.&gt; &gt; &gt=
; &gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; &gt=
; &gt; &gt; &gt; &gt; &gt;&gt;&gt;Also, we had a difficult time understandi=
ng the use of 's.&gt; &gt; We&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;inse=
rted 's around auth-int, auth, qop, and rspauth when&gt; they&gt; &gt; &gt;=
 were&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;used as values or directives=
. However, we did not attempt&gt; to&gt; &gt; &gt; include&gt; &gt; &gt; &g=
t; &gt; &gt; &gt;&gt;&gt;'s for *all* directives and values (e.g., realm an=
d&gt; opaque).&gt; &gt; &gt; Please&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&g=
t;let us know if this is not correct.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;=
&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;I agree it is confusing. Looking at 2=
617 I don't think it&gt; is&gt; &gt; &gt; entirely&gt; &gt; &gt; &gt; &gt; =
&gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;consistent either, as I see =
references to ["qop" directive]&gt; as&gt; &gt; &gt; well as&gt; &gt; &gt; =
&gt; &gt; &gt; &gt;the&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;unquoted form [=
qop directive].&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; &gt; &g=
t; &gt; &gt;&gt;I am no authority on style but my initial thought is to&gt;=
 &gt; suggest&gt; &gt; &gt; &gt; &gt; &gt; &gt;removing '&gt; &gt; &gt; &gt=
; &gt; &gt; &gt;&gt;and " from keywords when refering to a directive name r=
ather&gt; &gt; &gt; than its&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;literal v=
alue, and then use "" when refering to a value.&gt; For&gt; &gt; &gt; examp=
le,&gt; &gt; &gt; &gt; &gt; &gt; &gt;the&gt; &gt; &gt; &gt; &gt; &gt; &gt;&=
gt;existing 5090 text would then become:&gt; &gt; &gt; &gt; &gt; &gt; &gt;&=
gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&lt;snip&gt;&gt; &gt; &gt; &gt; &g=
t; &gt; &gt;&gt; o If the Access-Accept packet contains a Digest-HA1&gt; &g=
t; &gt; attribute, the&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; RADIUS client =
checks the qop and algorithm directives&gt; in&gt; &gt; &gt; the&gt; &gt; &=
gt; &gt; &gt; &gt; &gt;&gt; Authorization header of the HTTP-style request =
it&gt; wants&gt; &gt; to&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; authorize:&g=
t; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; =
* If the qop directive is missing or its value is&gt; &gt; "auth",&gt; &gt;=
 &gt; the&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; RADIUS client ignores the D=
igest-HA1 attribute. It&gt; &gt; &gt; does not&gt; &gt; &gt; &gt; &gt; &gt;=
 &gt;&gt; include an Authentication-Info header in its&gt; &gt; HTTP-style&=
gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; response.&gt; &gt; &gt; &gt; &gt; &gt=
; &gt;&gt;&lt;/snip&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt;=
 &gt; &gt; &gt; &gt;&gt;However when examing 2617 in more detail, using " a=
round the&gt; &gt; &gt; directive&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt=
; &gt; &gt; &gt; &gt; &gt;&gt;names would be more consistent with that draf=
t. For example&gt; &gt; &gt; this&gt; &gt; &gt; &gt; &gt; &gt; &gt;would&gt=
; &gt; &gt; &gt; &gt; &gt; &gt;&gt;become:&gt; &gt; &gt; &gt; &gt; &gt; &gt=
;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&lt;snip more like RFC 2617&gt;&=
gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; o If the Access-Accept packet contain=
s a Digest-HA1&gt; &gt; &gt; attribute, the&gt; &gt; &gt; &gt; &gt; &gt; &g=
t;&gt; RADIUS client checks the "qop" and "algorithm"&gt; &gt; directives&g=
t; &gt; &gt; in the&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; Authorization hea=
der of the HTTP-style request it&gt; wants&gt; &gt; to&gt; &gt; &gt; &gt; &=
gt; &gt; &gt;&gt; authorize:&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt; &gt;=
 &gt; &gt; &gt; &gt; &gt;&gt; * If the "qop" directive is missing or its va=
lue is&gt; &gt; &gt; "auth", the&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; RADI=
US client ignores the Digest-HA1 attribute. It&gt; &gt; &gt; does not&gt; &=
gt; &gt; &gt; &gt; &gt; &gt;&gt; include an Authentication-Info header in i=
ts&gt; &gt; HTTP-style&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt; response.&gt; =
&gt; &gt; &gt; &gt; &gt; &gt;&gt;&lt;/snip more like RFC 2617&gt;&gt; &gt; =
&gt; &gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;Prehaps o=
thers can weigh in one which they believe is most&gt; &gt; &gt; &gt; &gt; &=
gt; &gt;appropriate.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;I believe either =
would be a slight improvement on the&gt; existing&gt; &gt; &gt; text&gt; &g=
t; &gt; &gt; &gt; &gt; &gt;which&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;uses =
single quotes around the string values.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&g=
t;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;thanks,&gt; &gt; &gt; &gt; &gt; &gt=
; &gt;&gt;-david&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; &gt; &=
gt; &gt; &gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;Thank you.&g=
t; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&=
gt;&gt;RFC Editor&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; &gt; &gt; &=
gt; &gt; &gt; &gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;On Thu,=
 Oct 04, 2007 at 03:11:50PM -0700,&gt; &gt; &gt; [email-masked]&=
gt; &gt; &gt; &gt; &gt; &gt; &gt;wrote:&gt; &gt; &gt; &gt; &gt; &gt; &gt;&g=
t;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;****IMPORTANT*****&=
gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; =
&gt;&gt;&gt;&gt;Updated 2007/10/04&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt=
;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;RFC AUTHOR(S):&gt; &gt; =
&gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;--------------&gt; &gt; &gt; &gt; &gt; =
&gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;This is =
your LAST CHANCE to make changes to your RFC to&gt; be:&gt; &gt; &gt; &gt; =
&gt; &gt; &gt;&gt;&gt;&gt;draft-ietf-radext-rfc4590bis-02.txt, once the doc=
ument is&gt; &gt; &gt; published&gt; &gt; &gt; &gt; &gt; &gt; &gt;as&gt; &g=
t; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;an RFC we *WILL NOT* make any change=
s.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &g=
t; &gt;&gt;&gt;&gt;Please check your document at:&gt; &gt; &gt; &gt; &gt; &=
gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;ftp://ftp=
.rfc-editor.org/in-notes/authors/rfc5090.txt&gt; &gt; &gt; &gt; &gt; &gt; &=
gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;ATTENTION: The=
 editing process occasionally introduces&gt; &gt; errors&gt; &gt; &gt; that=
&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;were not in the Internet Draf=
t. Although the RFC Editor&gt; &gt; tries&gt; &gt; &gt; very&gt; &gt; &gt; =
&gt; &gt; &gt; &gt;&gt;&gt;&gt;hard to catch all errors, proofreading the t=
ext at least&gt; &gt; &gt; twice,&gt; &gt; &gt; &gt; &gt; &gt; &gt;typos&gt=
; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;can slip through. You, as an aut=
hor of the RFC, are&gt; taking&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt=
;responsibility for the correctness of the final product&gt; when&gt; &gt; =
&gt; you OK&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;publication. You s=
hould therefore proofread the entire&gt; RFC&gt; &gt; &gt; &gt; &gt; &gt; &=
gt;carefully&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;and without assum=
ptions. Errors in RFCs last forever.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&=
gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;NOTE: We have run a di=
ff tool that compares the approved&gt; &gt; &gt; &gt; &gt; &gt; &gt;interne=
t-draft&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;against our edited RFC=
 version of the document. Please&gt; &gt; review&gt; &gt; &gt; this&gt; &gt=
; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;file at:&gt; &gt; &gt; &gt; &gt; &gt;=
 &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt;&gt; &gt;&gt;&gt;&gt;ftp://ft=
p.rfc-editor.org/in-notes/authors/rfc5090-diff.html&gt; &gt; &gt; &gt; &gt;=
 &gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;Please =
note that we used a slightly altered version of the&gt; &gt; &gt; &gt; &gt;=
 &gt; &gt;originally&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;submitted=
 ID to create the diff file above. To make the&gt; &gt; file&gt; &gt; &gt; =
more&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;useful, we moved the term=
inology section to to appear&gt; after&gt; &gt; &gt; the&gt; &gt; &gt; &gt;=
 &gt; &gt; &gt;&gt;&gt;&gt;introduction, but we did not alter the text.&gt;=
 &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt=
;&gt;&gt;&gt;The document will NOT BE PUBLISHED until ALL of the&gt; author=
s&gt; &gt; &gt; listed&gt; &gt; &gt; &gt; &gt; &gt; &gt;in&gt; &gt; &gt; &g=
t; &gt; &gt; &gt;&gt;&gt;&gt;the RFC have affirmed that the document is rea=
dy to be&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;published, as ALL of =
the authors are equally responsible&gt; for&gt; &gt; &gt; &gt; &gt; &gt; &g=
t;verifying&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;the documents read=
iness for publication.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &g=
t; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;** Please send us a list of suitable=
 keywords for this&gt; &gt; &gt; document,&gt; &gt; &gt; &gt; &gt; &gt; &gt=
;over&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;and above those which ap=
pear in the title.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt; &=
gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; Frequently INCORRECT information includ=
es&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &g=
t; &gt;&gt;&gt;&gt; - Contact Information&gt; &gt; &gt; &gt; &gt; &gt; &gt;=
&gt;&gt;&gt; - References (are they up to date)&gt; &gt; &gt; &gt; &gt; &gt=
; &gt;&gt;&gt;&gt; - Section Numbers&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&=
gt;&gt; (especially if you originally put the copyright&gt; &gt; &gt; &gt; =
&gt; &gt; &gt;somewhere&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; other=
 than the VERY end of the document, or if&gt; &gt; you&gt; &gt; &gt; &gt; &=
gt; &gt; &gt;&gt;&gt;&gt; numbered the 'Status of the Memo' field)&gt; &gt;=
 &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;=
&gt;&gt;Please send us the changes, *DO NOT* send a new document&gt; &gt; w=
ith&gt; &gt; &gt; the&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;changes =
made. (If we think that the changes might be more&gt; &gt; &gt; than&gt; &g=
t; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;editorial we will contact the AD or =
the IESG to confirm&gt; that&gt; &gt; &gt; the&gt; &gt; &gt; &gt; &gt; &gt;=
 &gt;&gt;&gt;&gt;changes do not require review.)&gt; &gt; &gt; &gt; &gt; &g=
t; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;Send us th=
e changes in THIS format.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt;=
 &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; 1)*** SECTION #'s*** [i.e. Secti=
on 5, 2nd&gt; &gt; &gt; paragraph]&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt=
;&gt; 2) the text you want changed,&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&g=
t;&gt; 3) the new correct text and&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt=
;&gt; 4) if the changes are spacing or indentation&gt; than&gt; &gt; &gt; p=
lease&gt; &gt; &gt; &gt; &gt; &gt; &gt;note&gt; &gt; &gt; &gt; &gt; &gt; &g=
t;&gt;&gt;&gt; that.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt;=
 &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;FOR EXAMPLE:&gt; &gt; &gt; &gt; &gt; &=
gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; Section =
5.6, 3rd paragraph&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt; &=
gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; OLD:&gt; &gt; &gt; &gt; &gt; &gt; &gt;&=
gt;&gt;&gt; The quick brown fox jumped over the lazy dog.&gt; &gt; &gt; &gt=
; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; =
NEW:&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; The quick brown dog jump=
s over the lazy fox.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; ^^^ ^ ^^=
^&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;If you have a whole paragrap=
h to replace you do not need&gt; to&gt; &gt; &gt; use&gt; &gt; &gt; &gt; &g=
t; &gt; &gt;&gt;&gt;&gt;the arrow to point out the differences&gt; &gt; &gt=
; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;=
&gt; INTRODUCTION, 2nd paragraph&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&=
gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; Replace OLD:&gt; &gt; &gt=
; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;=
&gt; alsdfja;sldjf;lajsd;fljas;dlfj;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&=
gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; With NEW:&gt; &gt; &g=
t; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt=
;&gt; nv;alkjd;lsf;aoisj;ltjka;sldkjf&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;=
&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;Spacing or indentatio=
n problems...&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &=
gt; &gt; &gt; &gt;&gt;&gt;&gt; Section 10, 1st paragraph (remove spaces&gt;=
 between&gt; &gt; &gt; bit&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; an=
d of, add space after butter)&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;=
&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; OLD:&gt; &gt; &gt; &gt; &gt;=
 &gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; Better=
 botter bought a bit&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; of bitte=
r butterMary mary quite contrary&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&=
gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; NEW:&gt; &gt; &gt; &gt; &=
gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; Bet=
ter botter bought a bit of bitter butter&gt; &gt; &gt; &gt; &gt; &gt; &gt;&=
gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; Mary mary quite c=
ontrary&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &g=
t; &gt; &gt;&gt;&gt;&gt;This document will NOT be published until we receiv=
e&gt; &gt; &gt; agreement, from&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&g=
t;ALL listed authors, that the document is ready for&gt; &gt; &gt; publicat=
ion.&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; =
&gt; &gt;&gt;&gt;&gt;Thanks for your cooperation,&gt; &gt; &gt; &gt; &gt; &=
gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;-RFC Edit=
or&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &g=
t; &gt;&gt;&gt;&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;Title : RA=
DIUS Extension for Digest&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; Aut=
hentication&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;Author(s) : B. Ste=
rman, D. Sadolevsky,&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; D. Schwa=
rtz, D. Williams,&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt; W. Beck&gt;=
 &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;Working Group Chair(s) : Bernard =
Aboba, David Nelson&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;&gt;&gt;Area Direc=
tor(s) : Dan Romascanu, Ronald Bonica&gt; &gt; &gt; &gt; &gt; &gt; &gt;&gt;=
&gt;&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br></body>
</html>=

--_850a5faa-11aa-4c9f-9f82-831ac36344fd_--

Delivery-date: Thu, 20 Dec 2007 13:18:43 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'li chunxiu'" <[email-masked]>
Subject: RE: a question about Management Authorization -01 document
Date: Thu, 20 Dec 2007 08:16:56 -0500

Li Chunxiu writes...

> Maybe there is need to define the "local scope" concept in the
> draft-ietf-radext-management-authorization-01.

We could certainly do that.  I'll add that to the issues list.  It works
exactly like the Filter-Id attribute, which also relies on rules of local
scope.  Therefore, it's a well understood RADIUS operational paradigm.  The
rules are provisioned on all that NASes that are likely to need to know and
apply them by some out of band means, such as via a MIB using SNMP, via the
CLI or via FTP.

Note that there is work in RADEXT to define attributes that supplement
Filter-Id by provisioning and defining the rules at the same time.  That is
to say, defining a RADIUS filter rule attribute that actually contains the
rules.  This work leverages work done previously for Diameter. See RFC 4849.

So far, there has been no effort to define similar self-contained management
policy rules.

Delivery-date: Thu, 20 Dec 2007 10:02:07 +0000
Date: Thu, 20 Dec 2007 18:01:04 +0800
From: li chunxiu <[email-masked]>
Subject: Re:a question about Management Authorization -01 document
To: [email-masked]
Cc: "'David B. Nelson'" <[email-masked]>, [email-masked]

> j/s wrote:
> > But in the SNMP/Netconf Access Control process, there are 3 entities,
agent,
> > NAS and Radius server. Could you please explain how to define the "local
> > scope" concept?
> 
> For me, the agent and the NAS are effectively the same thing. From the
> SNMP perspective, a manager talks to an agent. From a RADIUS
> perspective, the agent acts as a NAS to the RADIUS server. See also
> draft-ietf-isms-radius-usage-01.txt.

Maybe there is need to define the "local scope" concept in the
draft-ietf-radext-management-authorization-01.

Regards
Li chunxiu

Delivery-date: Thu, 20 Dec 2007 08:29:41 +0000
Date: Thu, 20 Dec 2007 09:28:25 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: li chunxiu <[email-masked]>
Cc: "'David B. Nelson'" <[email-masked]>, [email-masked]
Subject: Re: ????: a question about Management Authorization -01 document
Reply-To: [email-masked]
Mail-Followup-To: li chunxiu <[email-masked]>, "'David B. Nelson'" <[email-masked]>, [email-masked]

On Thu, Dec 20, 2007 at 04:21:26PM +0800, li chunxiu wrote:

> But in the SNMP/Netconf Access Control process, there are 3 entities, agent,
> NAS and Radius server. Could you please explain how to define the "local
> scope" concept? 

For me, the agent and the NAS are effectively the same thing. From the
SNMP perspective, a manager talks to an agent. From a RADIUS
perspective, the agent acts as a NAS to the RADIUS server. See also
draft-ietf-isms-radius-usage-01.txt.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Delivery-date: Thu, 20 Dec 2007 08:22:14 +0000
Date: Thu, 20 Dec 2007 16:21:26 +0800
From: li chunxiu <[email-masked]>
Subject: =?gb2312?B?tPC4tDogYSBxdWVzdGlvbiBhYm91dCBNYW5hZ2VtZW50IEF1dGhvcg==?= =?gb2312?B?aXphdGlvbiAtMDEgZG9jdW1lbnQ=?=
To: [email-masked]
Cc: "'David B. Nelson'" <[email-masked]>, [email-masked]

> > I agree with the point of view of a local policy named
"read-only-group1"
> > and another named "read-write-group1".
> > If the Access Control is mainly done in NAS, the Access Control policy
in
> > Radius may be very simple, and the pattern of "read-only-group1" is ok.
> > If the Radius needs to participate in the Access Control, there may be
some
> > complicate policies. If the policies are too complicated to be expressed
in
> > one Management-Policy-Id, which expression is better? Will the policies
be
> > separated to several parts in each Management-Policy-Id within each
> > Access-Accept? And these parts will be composed to be whole policies in
the
> > NAS to accomplish the Access Control, right?
> 
> Section 4 defines the purpose and scope of the access control policy
> attributes. In particular, note that the Management-Policy-Id and
> Management-Privilege-Level attributes are not meant to carry accress
> control rules; they merely identify which locally known access control
> rules to apply.

Thank you for clarify this two concepts. 
But in the SNMP/Netconf Access Control process, there are 3 entities, agent,
NAS and Radius server. Could you please explain how to define the "local
scope" concept? 
Thanks,
Li chunxiu 

Delivery-date: Thu, 20 Dec 2007 07:33:16 +0000
Date: Thu, 20 Dec 2007 08:31:21 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: li chunxiu <[email-masked]>
Cc: "'David B. Nelson'" <[email-masked]>, [email-masked]
Subject: Re: a question about Management Authorization -01 document
Reply-To: [email-masked]
Mail-Followup-To: li chunxiu <[email-masked]>, "'David B. Nelson'" <[email-masked]>, [email-masked]

On Thu, Dec 20, 2007 at 11:08:03AM +0800, li chunxiu wrote:

> I agree with the point of view of a local policy named "read-only-group1"
> and another named "read-write-group1". 
> If the Access Control is mainly done in NAS, the Access Control policy in
> Radius may be very simple, and the pattern of "read-only-group1" is ok.
> If the Radius needs to participate in the Access Control, there may be some
> complicate policies. If the policies are too complicated to be expressed in
> one Management-Policy-Id, which expression is better? Will the policies be
> separated to several parts in each Management-Policy-Id within each
> Access-Accept? And these parts will be composed to be whole policies in the
> NAS to accomplish the Access Control, right? 

Section 4 defines the purpose and scope of the access control policy
attributes. In particular, note that the Management-Policy-Id and
Management-Privilege-Level attributes are not meant to carry accress
control rules; they merely identify which locally known access control
rules to apply.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Delivery-date: Thu, 20 Dec 2007 03:09:15 +0000
Date: Thu, 20 Dec 2007 11:08:03 +0800
From: li chunxiu <[email-masked]>
Subject: RE: a question about Management Authorization -01 document
To: "'David B. Nelson'" <[email-masked]>, [email-masked]

> Dave writes...
> I take it that in this example the Management-Policy-Id is composed of two
> separate elements, "Read-only" which provides an over-riding access
control
> policy of read only, and "group1", which provides some other access
control
> policy, perhaps based on access to certain branches of the management
tree.
> This is exactly the type of implementation that we discourage in the -01
> text.  The content of Management-Policy-Id should be exactly one name of a
> policy of local scope to the NAS.  It should not be composed of
sub-strings,
> each of which separately names a different policy element.  You could
> certainly have a local policy named "read-only-group1" and another named
> "read-write-group1".  That might accomplish your objective.
I agree with the point of view of a local policy named "read-only-group1"
and another named "read-write-group1". 
If the Access Control is mainly done in NAS, the Access Control policy in
Radius may be very simple, and the pattern of "read-only-group1" is ok.
If the Radius needs to participate in the Access Control, there may be some
complicate policies. If the policies are too complicated to be expressed in
one Management-Policy-Id, which expression is better? Will the policies be
separated to several parts in each Management-Policy-Id within each
Access-Accept? And these parts will be composed to be whole policies in the
NAS to accomplish the Access Control, right? 
> This could be workable, in that the Management-Policy-Id is restricted to
a
> single, flat name of local scope (no sub-fields).  It is possible to
define
> a scenario in which two access control provisioning attributes are used in
> the same Access-Accept, but...  It would be necessary to define the
> precedence relationship between them, should there be any conflicts in the
> underlying access control rules that would result from application of the
> polices in the NAS.  That is also feasible to do.
This needs to be researched.
 > The only use case that I can come up with in which it might be beneficial
to
> apply disparate, separately named management policies in a single
> Access-Accept is the proxy RADIUS case, in which the operator of NAS and
the
> first hop proxy RADIUS server may wish to overlay restrictions on the
access
> control provisioned by the operator of the home RADIUS server.  Unless
these
> policies are well coordinated, and the precedence relationships well
> specified, the result may be unpredictable.
I agree.
Comments on this?

Li chunxiu

Delivery-date: Wed, 19 Dec 2007 13:58:10 +0000
From: "David B. Nelson" <[email-masked]>
To: "'li chunxiu'" <[email-masked]>, <[email-masked]>
Subject: RE: a question about Management Authorization -01 document
Date: Wed, 19 Dec 2007 08:57:01 -0500

> Li Chunxiu writes...

> Here is a situation:
> 1.NETCONF access, defined by a policy:
>       *  Service-Type (6) = Framed-Management (xx)
>       *  Framed-Management-Protocol (xx) = NETCONF(3)
>       *  Management-Policy-Id (xx) = " Read-only group1"

I take it that in this example the Management-Policy-Id is composed of two
separate elements, "Read-only" which provides an over-riding access control
policy of read only, and "group1", which provides some other access control
policy, perhaps based on access to certain branches of the management tree.

This is exactly the type of implementation that we discourage in the -01
text.  The content of Management-Policy-Id should be exactly one name of a
policy of local scope to the NAS.  It should not be composed of sub-strings,
each of which separately names a different policy element.  You could
certainly have a local policy named "read-only-group1" and another named
"read-write-group1".  That might accomplish your objective.

> 3. NETCONF access, defined by a policy, with the Management-Privilege-
> Level
> attribute:
>       *  Service-Type (6) = Framed-Management (xx)
>       *  Framed-Management-Protocol (xx) = NETCONF(3)
>       *  Management-Policy-Id (xx) = "group1 "
>       *  Management-Privilege-Level (xx) = 15
> Comment:15 denotes Read-only
>         16 denotes create  ... ...

This could be workable, in that the Management-Policy-Id is restricted to a
single, flat name of local scope (no sub-fields).  It is possible to define
a scenario in which two access control provisioning attributes are used in
the same Access-Accept, but...  It would be necessary to define the
precedence relationship between them, should there be any conflicts in the
underlying access control rules that would result from application of the
polices in the NAS.  That is also feasible to do.

> I think the 3rd example using the Management-Privilege-Level attribute
> clarifies the use methods of Management-Privilege-Level attribute.
> What is your opinion?

My question is whether it is necessary to support the application of two (or
more) separately defined (and named) access control policies in the NAS at
one time?  In any case where multiple, separate policies are applied, it is
also possible to create a single name for the combined policy.  Of course,
if there are a large number of such sub-policies that can be combined, the
number of unique, flat names to represent them becomes combinatorially
large.  However, I think it is a true statement that organizations using a
form of role-based access control policy will typically only define a
hand-full of really distinct roles.  For that reason, I think that the
"mix-and-match" capability of provisioning multiple local policies via
RADIUS, either in separate attributes or as sub-elements of a single
attribute, creates added complexity disproportionate to the practical value.
But that's just my opinion.

The only use case that I can come up with in which it might be beneficial to
apply disparate, separately named management policies in a single
Access-Accept is the proxy RADIUS case, in which the operator of NAS and the
first hop proxy RADIUS server may wish to overlay restrictions on the access
control provisioned by the operator of the home RADIUS server.  Unless these
policies are well coordinated, and the precedence relationships well
specified, the result may be unpredictable.

I tend to agree with Juergen Schoenwaelder's comments on whether this kind
of approach will ever be required by NETCONF.

However, if the WG members think that addressing the proxy RADIUS server
(e.g. the access outsourcing) use case is important, we could do that, in a
couple of different ways.

Comments on this?

Delivery-date: Wed, 19 Dec 2007 07:43:19 +0000
Date: Wed, 19 Dec 2007 08:41:53 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: li chunxiu <[email-masked]>
Cc: "'David B. Nelson'" <[email-masked]>, [email-masked]
Subject: Re: ????: a question about Management Authorization -01 document
Reply-To: [email-masked]
Mail-Followup-To: li chunxiu <[email-masked]>, "'David B. Nelson'" <[email-masked]>, [email-masked]

On Wed, Dec 19, 2007 at 10:46:36AM +0800, li chunxiu wrote:

> Here is a situation:
> 1.NETCONF access, defined by a policy:
>       *  Service-Type (6) = Framed-Management (xx)
>       *  Framed-Management-Protocol (xx) = NETCONF(3)
>       *  Management-Policy-Id (xx) = " Read-only group1"
> 2. NETCONF access, defined by a policy:
>       *  Service-Type (6) = Framed-Management (xx)
>       *  Framed-Management-Protocol (xx) = NETCONF(3)
>       *  Management-Policy-Id (xx) = "group1 Read-only"
> 3. NETCONF access, defined by a policy, with the Management-Privilege-Level
> attribute:
>       *  Service-Type (6) = Framed-Management (xx)
>       *  Framed-Management-Protocol (xx) = NETCONF(3)
>       *  Management-Policy-Id (xx) = "group1 "
>       *  Management-Privilege-Level (xx) = 15 
> Comment:15 denotes Read-only 
>         16 denotes create  ... ...
> I think the 3rd example using the Management-Privilege-Level attribute
> clarifies the use methods of Management-Privilege-Level attribute. 
> What is your opinion?

Since NETCONF right now does not have a defined access control system,
the discussion is kind of pointless since implementations can do
whatever they like. That said, let me say that I personally find a
combination of Management-Policy-Id and Management-Privilege-Level
somewhat strange.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Delivery-date: Wed, 19 Dec 2007 02:47:38 +0000
Date: Wed, 19 Dec 2007 10:46:36 +0800
From: li chunxiu <[email-masked]>
Subject: =?gb2312?B?tPC4tDogYSBxdWVzdGlvbiBhYm91dCBNYW5hZ2VtZW50IEF1dGhvcg==?= =?gb2312?B?aXphdGlvbiAtMDEgZG9jdW1lbnQ=?=
To: "'David B. Nelson'" <[email-masked]>, [email-masked]

> Li Chunxiu writes...
> > In the RADIUS NAS Management Authorization Draft=A3=ACthe added =
attribute
> > Management-Privilege-Level is an integer-valued attribute for use =
with
> > CLI access methods, I have a question about it, does it apply to the
> > Framed-Management-Protocol?
> The Management-Privilege-Level attribute was added to address a review
> comment and a long standing use case.
> In the -01 draft, we made it clear that the Management-Policy-Id =
attribute
> was to be a flat, simple name of local scope, and that the field was =
not
to
> be overloaded with other kinds of elements, all in the name of good
> interoperability.  To address a need that might have tempted vendors =
to
> overload the Management-Policy-Id attribute and to provide a way to
> provision a long standing CLI management parameter, we added the new
> attribute.
> The use case is that of integer valued-privilege level for CLI usages, =
as
> exemplified by the "enable' levels in Cisco's IOS.  This use is common =
in
> other vendor's products, as well.
> I don't see any reason that the Management-Privilege-Level attribute =
could
> not be made applicable to Framed-Management sessions, but I don't see =
any
> compelling reason for doing so.  Having it available as a matter of
protocol
> symmetry might be nice, but is there actually a use case that it would
> support?
>=20
> > For example, in access control of SNMP protocol or Netconf protocol, =
is
> > it necessary to use the Management-Privilege-Level attribute?
>=20
> It seems to me that the named policy of Management-Policy-Id would be
> sufficient for uses such as SNMP or Netconf.  Can you suggest a =
situation
> where it would be desirable to have an integer-valued parameter for
> provisioning access control via either of these methods?
>=20
Here is a situation:
1.NETCONF access, defined by a policy:
      *  Service-Type (6) =3D Framed-Management (xx)
      *  Framed-Management-Protocol (xx) =3D NETCONF(3)
      *  Management-Policy-Id (xx) =3D " Read-only group1"
2. NETCONF access, defined by a policy:
      *  Service-Type (6) =3D Framed-Management (xx)
      *  Framed-Management-Protocol (xx) =3D NETCONF(3)
      *  Management-Policy-Id (xx) =3D "group1 Read-only"
3. NETCONF access, defined by a policy, with the =
Management-Privilege-Level
attribute:
      *  Service-Type (6) =3D Framed-Management (xx)
      *  Framed-Management-Protocol (xx) =3D NETCONF(3)
      *  Management-Policy-Id (xx) =3D "group1 "
      *  Management-Privilege-Level (xx) =3D 15=20
Comment:15 denotes Read-only=20
        16 denotes create  ... ...
I think the 3rd example using the Management-Privilege-Level attribute
clarifies the use methods of Management-Privilege-Level attribute.=20
What is your opinion?

 Regards,=20
Li chunxiu

Delivery-date: Tue, 18 Dec 2007 23:15:23 +0000
Date: Tue, 18 Dec 2007 15:14:16 -0800
From: Vijay Devarapalli <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  [email-masked]
Subject: Re: Question on the Class attribute

Got it. Thanks for the responses.

Vijay

Bernard Aboba wrote:
>  > It appears to me that RFC 2865 requires the class attribute, if
>  > used, to be the same in the Access Accept and the Accounting
>  > Request. I agree with you that if the Accounting Request goes to
>  > a different server from the one that sent the Access Accept
>  > message, this matching does not make sense. The use of this
>  > attribute also may not make sense.
> 
> The Class attribute is designed to allow the RADIUS authentication server
> to provide information to be placed within accounting records.  This is
> typically most useful in situations where the accounting server may not
> have access to all the information which the authentication server has
> access to -- because if it did, why would the Class attribute be needed 
> at all?
>  
> Accounting records need not even be handled by the same administrative 
> domain
> (let alone the same RADIUS authentication server).  So the Class 
> attribute does not
> assume that the RADIUS authentication server and accounting server are the
> same entity. 

Delivery-date: Tue, 18 Dec 2007 19:59:02 +0000
From: Bernard Aboba <[email-masked]>
To: Vijay Devarapalli <[email-masked]>, "David B. Nelson" <[email-masked]>
CC: <[email-masked]>
Subject: RE: Question on the Class attribute
Date: Tue, 18 Dec 2007 11:58:00 -0800

--_3fb94013-14d8-4a23-bbd6-9b7bbbee681d_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> It appears to me that RFC 2865 requires the class attribute, if> used, to=
 be the same in the Access Accept and the Accounting> Request. I agree with=
 you that if the Accounting Request goes to> a different server from the on=
e that sent the Access Accept> message, this matching does not make sense. =
The use of this> attribute also may not make sense.
The Class attribute is designed to allow the RADIUS authentication server
to provide information to be placed within accounting records.  This is=20
typically most useful in situations where the accounting server may not
have access to all the information which the authentication server has
access to -- because if it did, why would the Class attribute be needed at =
all?=20
=20
Accounting records need not even be handled by the same administrative doma=
in=20
(let alone the same RADIUS authentication server).  So the Class attribute =
does not
assume that the RADIUS authentication server and accounting server are the
same entity.  =

--_3fb94013-14d8-4a23-bbd6-9b7bbbee681d_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
&gt; It appears to me that RFC 2865 requires the class attribute, if<BR>&gt=
; used, to be the same in the Access Accept and the Accounting<BR>&gt; Requ=
est. I agree with you that if the Accounting Request goes to<BR>&gt; a diff=
erent server from the one that sent the Access Accept<BR>&gt; message, this=
 matching does not make sense. The use of this<BR>&gt; attribute also may n=
ot make sense.<BR><BR>
The Class attribute is designed to allow the RADIUS authentication server<B=
R>
to provide information to be placed within accounting records.&nbsp; This i=
s <BR>
typically most useful in situations where the accounting server may not<BR>
have access to all the information which the authentication server has<BR>
access to -- because if it did, why would the Class attribute be needed at =
all? <BR>
&nbsp;<BR>
Accounting records need not even be handled by the same administrative doma=
in <BR>
(let alone the same RADIUS authentication server).&nbsp; So the Class attri=
bute does not<BR>
assume that the RADIUS authentication server and accounting server are the<=
BR>
same entity.&nbsp; <BR></body>
</html>=

--_3fb94013-14d8-4a23-bbd6-9b7bbbee681d_--

Delivery-date: Tue, 18 Dec 2007 18:41:55 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Vijay Devarapalli'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Question on the Class attribute
Date: Tue, 18 Dec 2007 13:39:02 -0500
Organization: Elbrys Networks, Inc.

Vijay Devarapalli writes...

> It appears to me that RFC 2865 requires the class attribute, if
> used, to be the same in the Access Accept and the Accounting
> Request.

It requires that the RADIUS client (NAS or proxy) not change the content of
Class, and that it be passed intact in the Accounting-Request messages.
Class is a "cookie" between the RADIUS Server and the RADIUS Accounting
server, much as State is a "cookie" between the RADIUS Server (e.g.
Access-Challenge message) and the RADIUS Server (e.g. Access-Request
message).

> Our AAA server does not implement this attribute right now. We
> were asked to. I am trying to figure out what this attribute is
> about, where it is commonly used, etc...

It is used to "bind" sessions, as authorized by a RADIUS Server, to
accounting records, as logged on a RADIUS Accounting Server.

> However, it looks like the RADIUS AAA server behavior when the 
> value in the Class attribute in the Access Accept and Accounting
> Request does not match is unspecified.

That is correct, primarily because in the most general case there is no way
for the RADIUS Accounting Server to perform the "does it match" check.  It
takes the correct handling of the Class attribute by the NAS and by proxies
on faith, as that behavior is specified in RFC 2865.

There may be ways to detect broken behavior around the handling of Class
attributes by means of manual inspection of the server records.

There may be ways to automate the Class checking in the special case of a
tightly bound RADIUS Server and RADIUS Accounting Server, but that is beyond
the scope of RFC 2865 or RFC 2866.

Delivery-date: Tue, 18 Dec 2007 18:27:55 +0000
Date: Tue, 18 Dec 2007 10:25:22 -0800
From: Vijay Devarapalli <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: [email-masked]
Subject: Re: Question on the Class attribute

Hi David,

David B. Nelson wrote:
> Vijay Devarapalli wrote:
> 
>> I had a question on the Class attribute [RFC 2865]. What should
>> the RADIUS server do if the Class in the Access Accept message
>> that it sent does not match with the Accounting Request message
>> that comes later?
> 
> Given that the RADIUS Accounting Server may be completely independent of 
> the RADIUS Server, how would a RADIUS Accounting Server, in the most 
> general case, be able to tell that the content of the Class attribute 
> had been modified?  What session identifier information from other 
> RADIUS attributes would it use to make that determination?

It appears to me that RFC 2865 requires the class attribute, if
used, to be the same in the Access Accept and the Accounting
Request. I agree with you that if the Accounting Request goes to
a different server from the one that sent the Access Accept
message, this matching does not make sense. The use of this
attribute also may not make sense.

> In the special case where the RADIUS Accounting Server is tightly 
> coupled with the RADIUS Server and has a priori knowledge of sessions 
> that the RADIUS Server has authorized, and therefore the intended value 
> of the Class attribute, it might be possible to take some action.  In 
> these special cases it is not entirely clear what value exists in the 
> Class attribute.

I have no idea either.

> Could you elaborate on a particular use case that exemplifies your 
> concerns?

Our AAA server does not implement this attribute right now. We
were asked to. I am trying to figure out what this attribute is
about, where it is commonly used, etc... However, it looks like
the RADIUS AAA server behavior when the value in the Class
attribute in the Access Accept and Accounting Request does not
match is unspecified.

Vijay

Delivery-date: Tue, 18 Dec 2007 14:46:37 +0000
Date: Tue, 18 Dec 2007 09:44:37 -0500
From: "David B. Nelson" <[email-masked]>
To: Vijay Devarapalli <[email-masked]>
CC:  [email-masked]
Subject: Re: Question on the Class attribute

Vijay Devarapalli wrote:

> I had a question on the Class attribute [RFC 2865]. What should
> the RADIUS server do if the Class in the Access Accept message
> that it sent does not match with the Accounting Request message
> that comes later?

Given that the RADIUS Accounting Server may be completely independent of 
the RADIUS Server, how would a RADIUS Accounting Server, in the most 
general case, be able to tell that the content of the Class attribute 
had been modified?  What session identifier information from other 
RADIUS attributes would it use to make that determination?

In the special case where the RADIUS Accounting Server is tightly 
coupled with the RADIUS Server and has a priori knowledge of sessions 
that the RADIUS Server has authorized, and therefore the intended value 
of the Class attribute, it might be possible to take some action.  In 
these special cases it is not entirely clear what value exists in the 
Class attribute.

Could you elaborate on a particular use case that exemplifies your concerns?

Delivery-date: Tue, 18 Dec 2007 14:10:30 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: a question about Management Authorization -01 document
Date: Tue, 18 Dec 2007 09:09:13 -0500

Li Chunxiu writes...

> In the RADIUS NAS Management Authorization Draft，the added attribute
> Management-Privilege-Level is an integer-valued attribute for use with
> CLI access methods, I have a question about it, does it apply to the
> Framed-Management-Protocol?

The Management-Privilege-Level attribute was added to address a review
comment and a long standing use case.

In the -01 draft, we made it clear that the Management-Policy-Id attribute
was to be a flat, simple name of local scope, and that the field was not to
be overloaded with other kinds of elements, all in the name of good
interoperability.  To address a need that might have tempted vendors to
overload the Management-Policy-Id attribute and to provide a way to
provision a long standing CLI management parameter, we added the new
attribute.

The use case is that of integer valued-privilege level for CLI usages, as
exemplified by the "enable' levels in Cisco's IOS.  This use is common in
other vendor's products, as well.

I don't see any reason that the Management-Privilege-Level attribute could
not be made applicable to Framed-Management sessions, but I don't see any
compelling reason for doing so.  Having it available as a matter of protocol
symmetry might be nice, but is there actually a use case that it would
support?  

> For example, in access control of SNMP protocol or Netconf protocol, is
> it necessary to use the Management-Privilege-Level attribute?

It seems to me that the named policy of Management-Policy-Id would be
sufficient for uses such as SNMP or Netconf.  Can you suggest a situation
where it would be desirable to have an integer-valued parameter for
provisioning access control via either of these methods?

Regards,

Dave

Delivery-date: Tue, 18 Dec 2007 03:09:21 +0000
Date: Tue, 18 Dec 2007 11:08:06 +0800
From: li chunxiu <[email-masked]>
Subject: a question about Management Authorization -01 document
To: "'David B. Nelson'" <[email-masked]>
Cc: [email-masked]

Hello, David
In the RADIUS NAS Management Authorization Draft=A3=ACthe added =
attribute
Management-Privilege-Level is an integer-valued attribute for use with =
CLI
access methods, I have a question about it, does it apply to the
Framed-Management-Protocol?
 For example, in access control of SNMP protocol or Netconf protocol, is =
it
necessary to use the Management-Privilege-Level attribute?

Thanks,
Chunxiu li

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Dec 2007 01:05:10 +0000
To: [email-masked], [email-masked]
Subject:  RFC 5080 on Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes
From: [email-masked]
Cc: [email-masked], [email-masked]
Message-Id: <[email-masked]>
Date: Mon, 17 Dec 2007 17:02:49 -0800 (PST)

A new Request for Comments is now available in online RFC libraries.

        RFC 5080

        Title:      Common Remote Authentication Dial In 
                    User Service (RADIUS) Implementation Issues and 
                    Suggested Fixes 
        Author:     D. Nelson, A. DeKok
        Status:     Standards Track
        Date:       December 2007
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      28
        Characters: 64138
        Updates:    RFC2865, RFC2866, RFC2869, RFC3579
        See-Also:   

        I-D Tag:    draft-ietf-radext-fixes-08.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5080.txt

This document describes common issues seen in Remote Authentication
Dial In User Service (RADIUS) implementations and suggests some fixes.
Where applicable, ambiguities and errors in previous RADIUS
specifications are clarified.  [STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

Delivery-date: Mon, 17 Dec 2007 19:07:32 +0000
Date: Mon, 17 Dec 2007 11:04:28 -0800
From: Vijay Devarapalli <[email-masked]>
To: [email-masked]
Subject: Question on the Class attribute

Hello,

I had a question on the Class attribute [RFC 2865]. What should
the RADIUS server do if the Class in the Access Accept message
that it sent does not match with the Accounting Request message
that comes later?

RFC 2865 does say this attribute should never be modified by the
client. But I think the server behavior should still be specified
in case there is a mismatch. Is there any document that talks
about this?

Thanks in advance
Vijay

Delivery-date: Sun, 09 Dec 2007 18:42:55 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>
Cc: "'Glen Zorn'" <[email-masked]>
Subject: Questions on modified Extended Attribute format?
Date: Sun, 9 Dec 2007 10:39:33 -0800

This is a multipart message in MIME format.

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

During the meeting last week, I thought that there were a couple of
questions/comments on Jabber regarding the changes that I proposed to the
extended attribute format (adding a bit to distinguish between new TLVs and
legacy RADIUS attributes in extended attributes) but I didn't quite catch
them.  Would those who presented those remarks mind repeating them in email?
TIA.

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

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"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>During the meeting last week, I thought that there =
were a
couple of questions/comments on Jabber regarding the changes that I =
proposed to
the extended attribute format (adding a bit to distinguish between new =
TLVs and
legacy RADIUS attributes in extended attributes) but I didn't quite =
catch
them.&nbsp; Would those who presented those remarks mind repeating them =
in email?&nbsp;
TIA.<o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0035_01C83A4F.CD4B9850--

Delivery-date: Fri, 07 Dec 2007 08:03:56 +0000
Date: Fri, 07 Dec 2007 09:02:11 +0100
From: Alan DeKok <[email-masked]>
To: Stefan Winter <[email-masked]>
CC: [email-masked]
Subject: Re: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements

Stefan Winter wrote:
>> [ certs ]
> That is exactly the plan. We are not quite there yet with full deployment, but 
> on our way.

  That addresses some of my concerns about scalability.

> We are facing a requirement of RADIUS-at-roaming-end to RADIUS-at-thome-end 
> security, which is where my wish to have auto key mgmt came from.

  I think end-to-end security is outside of the scope of RADIUS.

  If hop-by-hop security is sufficient, then the requirements and
assertions can go into a vendor-specific dictionary.

  Alan DeKok.

Delivery-date: Fri, 07 Dec 2007 07:25:08 +0000
From: Stefan Winter <[email-masked]>
Organization: Fondation RESTENA
To: [email-masked]
Subject: Re: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements
Date: Fri, 7 Dec 2007 08:23:15 +0100
Cc: Alan DeKok <[email-masked]>

--nextPart4311849.K2hZFybWMa
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

>   I think Eduroam is the only (N x N) deployment I've seen where N > 10.

And even we are avoiding N^2 complexity at the moment with a tree structure=
:=20
star topology with central proxy from institutions within a country, star=20
topology of country proxies to root.

If you care enough: even with RadSec and peer resolution, we might still ha=
ve=20
proxies in between, for entirely non-technical reasons. Some countries want=
=20
to reserve the right to filter attributes at a national level, so any=20
resolution technique would be configured on their side to end up at the=20
national TLD proxy, and be distributed onwards from there.

>   Since Eduroam is using RadSec, I suspect that the N^2 issue could be
> solved by leveraging a central Eduroam Certificate Authority.  It would
> issue, and sign, certificates for each participating institution or
> country.  Each particpant would then be responsible for using those
> certs, and for validating the certs of Eduroam partners.

That is exactly the plan. We are not quite there yet with full deployment, =
but=20
on our way.

> > 2. RFC 4107 criteria do not apply to a RADIUS crypto-agile solution:
> >   a. RADIUS client-server communication is not an N^2 problem (except
> > perhaps in the roaming
> > situation where end-to-end protection is being provided).
>
>   Yes.

We are facing a requirement of RADIUS-at-roaming-end to RADIUS-at-thome-end=
=20
security, which is where my wish to have auto key mgmt came from. The=20
concrete use case we have is that some countries need the age of a user to=
=20
determine if he's legally allowed to get unfiltered internet access.

This means we would need to transfer either birthday or at least age via=20
RADIUS. This kind of user attribute can be easily tied to a concrete=20
User-Name in most cases and is thus subject to law regulations regarding=20
transmission and storage of personal data.

=46or the moment our only solution is to keep eduroam to higher ed and rese=
arch=20
only, where all eligible users can be expected to be over eighteen. We are=
=20
currently working on a quite sophisticated out-of-band handshaking for such=
=20
data (there are more examples than just age), but would be a lot happier if=
=20
there was an easy in-band solution.

I agree though that our woes in that regard are pretty much unique.

Greetings,

Stefan

=2D-=20
Stefan WINTER

RESTENA Foundation - R=E9seau T=E9l=E9informatique de l'Education Nationale=
 et de=20
la Recherche
R&D Engineer

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
email: [email-masked] =A0 =A0 Tel.: =A0 =A0=A0+352 424409-1
http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 4224=
73

--nextPart4311849.K2hZFybWMa
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart4311849.K2hZFybWMa--

Delivery-date: Fri, 07 Dec 2007 00:19:16 +0000
Date: Fri, 07 Dec 2007 01:10:08 +0100
From: Alan DeKok <[email-masked]>
To: [email-masked]
Subject: Re: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements

[email-masked] wrote:
> This is a call for RADEXT WG mailing list consensus on this issue.  
> Does the mailing list agree
> that Automated Key Management is not a requirement for a RADIUS
> Crypto-agility solution?

  I agree  Pointing to my response:

http://psg.com/lists/radiusext/2007/msg00911.html

> Some of the arguments made include:
>  
> 1. While automated key management may prove convenient in some
> circumstances (e.g. EDUROAM),
> the demand is by no means universal, nor is the pain of the current
> manual keying environment considered
> acute by most customers.

  Most commercial deployments of RADIUS interconnects are either

    ( N x N ) -  where N is small, < 5
    (N x 1 + 1 x M) - where N and M may each be > 30

  i.e. full interconnects are usually small.  Otherwise, intermediary
proxies are used to simplify the problem.

  I think Eduroam is the only (N x N) deployment I've seen where N > 10.

  Since Eduroam is using RadSec, I suspect that the N^2 issue could be
solved by leveraging a central Eduroam Certificate Authority.  It would
issue, and sign, certificates for each participating institution or
country.  Each particpant would then be responsible for using those
certs, and for validating the certs of Eduroam partners.

> 2. RFC 4107 criteria do not apply to a RADIUS crypto-agile solution:
>   a. RADIUS client-server communication is not an N^2 problem (except
> perhaps in the roaming
> situation where end-to-end protection is being provided). 

  Yes.

>   b. One of the goals of RADIUS crypto-agility is to remove the use of
> stream ciphers.
>   c.  RADIUS traffic is generally light enough that a credible
> ciphersuite would not require rekey for a long time.

  Yes.

  Alan DeKok.

Delivery-date: Thu, 06 Dec 2007 23:52:59 +0000
From: [email-masked]
To: <[email-masked]>, <[email-masked]>
Subject: Re: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements
Date: Thu, 06 Dec 2007 23:51:47 +0000

--NextPart_Webmail_9m3u9jl4l_15546_1196985107_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

I agree.

-------------- Original message -------------- 
From: <[email-masked]> 

At IETF 70, we discussed the applicability of RFC 4107 to RADIUS Crypto-agility requirements. 

The consensus within the room was that Automated Key Management should not be added to the list
of Crypto-agility requirements. 

This is a call for RADEXT WG mailing list consensus on this issue.   Does the mailing list agree
that Automated Key Management is not a requirement for a RADIUS Crypto-agility solution? 

Some of the arguments made include:

1. While automated key management may prove convenient in some circumstances (e.g. EDUROAM),
the demand is by no means universal, nor is the pain of the current manual keying environment considered
acute by most customers. 

2. RFC 4107 criteria do not apply to a RADIUS crypto-agile solution:
  a. RADIUS client-server communication is not an N^2 problem (except perhaps in the roaming
situation where end-to-end protection is being provided).  
  b. One of the goals of RADIUS crypto-agility is to remove the use of stream ciphers.
  c.  RADIUS traffic is generally light enough that a credible ciphersuite would not require rekey for a long time. 

So, does the WG agree with these arguments?  Please respond to the list even if you have no new arguments
to add, if only to say that you agree (or disagree) with the consensus in the room at IETF 70. 
--NextPart_Webmail_9m3u9jl4l_15546_1196985107_0
Content-Type: text/html
Content-Transfer-Encoding: 8bit

<html><body>
<DIV>I agree.</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">-------------- Original message -------------- <BR>From: &lt;[email-masked]&gt; <BR>
<META content="MSHTML 6.00.6000.16546" name=GENERATOR>
<DIV><FONT face=Arial size=2>At IETF 70, we discussed the applicability of RFC 4107 to RADIUS Crypto-agility requirements. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>The consensus within the room was that Automated Key Management should not be added to the list</FONT></DIV>
<DIV><FONT face=Arial size=2>of Crypto-agility requirements. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>This is a call for RADEXT WG mailing list consensus on this issue.&nbsp;&nbsp; Does the mailing list agree</FONT></DIV>
<DIV><FONT face=Arial size=2>that Automated Key Management is not a requirement for a RADIUS Crypto-agility solution? </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Some of the arguments made include:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>1.&nbsp;While automated key management may prove convenient in some circumstances (e.g. EDUROAM),</FONT></DIV>
<DIV><FONT face=Arial size=2>the demand is by no means universal, nor is the pain of the current manual keying environment considered</FONT></DIV>
<DIV><FONT face=Arial size=2>acute by most customers. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>2. RFC 4107 criteria do not apply to a RADIUS crypto-agile solution:</FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp; a. </FONT><FONT face=Arial size=2>RADIUS client-server communication is not an N^2 problem (except perhaps in the roaming</FONT></DIV>
<DIV><FONT face=Arial size=2>situation where end-to-end protection is being provided).&nbsp; </FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp; b. One of the goals of RADIUS crypto-agility </FONT><FONT face=Arial size=2>is to remove the use of stream ciphers.</FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;c.&nbsp; RADIUS traffic is generally light enough that a credible </FONT><FONT face=Arial size=2>ciphersuite would not require rekey for a long time. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>So, does the WG agree with these arguments?&nbsp; Please respond to the list even if you have no new arguments</FONT></DIV>
<DIV><FONT face=Arial size=2>to add, if only to say that you agree (or disagree) with the consensus in the room at IETF 70. </FONT></DIV></BLOCKQUOTE></body></html>

--NextPart_Webmail_9m3u9jl4l_15546_1196985107_0--

Delivery-date: Thu, 06 Dec 2007 18:34:09 +0000
From: <[email-masked]>
To: <[email-masked]>
Subject: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements
Date: Thu, 6 Dec 2007 10:33:17 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_0051_01C837F3.6A2D3F70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

At IETF 70, we discussed the applicability of RFC 4107 to RADIUS =
Crypto-agility requirements.=20

The consensus within the room was that Automated Key Management should =
not be added to the list
of Crypto-agility requirements.=20

This is a call for RADEXT WG mailing list consensus on this issue.   =
Does the mailing list agree
that Automated Key Management is not a requirement for a RADIUS =
Crypto-agility solution?=20

Some of the arguments made include:

1. While automated key management may prove convenient in some =
circumstances (e.g. EDUROAM),
the demand is by no means universal, nor is the pain of the current =
manual keying environment considered
acute by most customers.=20

2. RFC 4107 criteria do not apply to a RADIUS crypto-agile solution:
  a. RADIUS client-server communication is not an N^2 problem (except =
perhaps in the roaming
situation where end-to-end protection is being provided). =20
  b. One of the goals of RADIUS crypto-agility is to remove the use of =
stream ciphers.
  c.  RADIUS traffic is generally light enough that a credible =
ciphersuite would not require rekey for a long time.=20

So, does the WG agree with these arguments?  Please respond to the list =
even if you have no new arguments
to add, if only to say that you agree (or disagree) with the consensus =
in the room at IETF 70. 
------=_NextPart_000_0051_01C837F3.6A2D3F70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3Diso-8859-1>
<META content=3D"MSHTML 6.00.6000.16546" name=3DGENERATOR></HEAD>
<BODY id=3DMailContainerBody=20
style=3D"PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-TOP: 15px"=20
bgColor=3D#ffffff leftMargin=3D0 topMargin=3D0 CanvasTabStop=3D"true"=20
name=3D"Compose message area">
<DIV><FONT face=3DArial size=3D2>At IETF 70, we discussed the =
applicability of RFC=20
4107 to RADIUS Crypto-agility requirements. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The consensus within the room was that =
Automated=20
Key Management should not be added to the list</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>of Crypto-agility requirements. =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>This is a call for RADEXT WG mailing =
list consensus=20
on this issue.&nbsp;&nbsp; Does the mailing list agree</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>that Automated Key Management is not a =
requirement=20
for a RADIUS Crypto-agility solution? </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Some of the arguments made =
include:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1.&nbsp;While automated key management =
may prove=20
convenient in some circumstances (e.g. EDUROAM),</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>the demand is by no means universal, =
nor is the=20
pain of the current manual keying environment considered</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>acute by most customers. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2. RFC 4107 criteria do not apply to a =
RADIUS=20
crypto-agile solution:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; a. </FONT><FONT face=3DArial =
size=3D2>RADIUS=20
client-server communication is not an N^2 problem (except perhaps in the =

roaming</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>situation where end-to-end protection =
is being=20
provided).&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; b. One of the goals of RADIUS =
crypto-agility=20
</FONT><FONT face=3DArial size=3D2>is to remove the use of stream=20
ciphers.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;c.&nbsp; RADIUS traffic is =
generally=20
light enough that a credible </FONT><FONT face=3DArial =
size=3D2>ciphersuite would=20
not require rekey for a long time. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>So, does the WG agree with these =
arguments?&nbsp;=20
Please respond to the list even if you have no new =
arguments</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>to add, if only to say that you agree =
(or disagree)=20
with the consensus in the room at IETF 70. </FONT></DIV></BODY></HTML>

------=_NextPart_000_0051_01C837F3.6A2D3F70--

Delivery-date: Wed, 05 Dec 2007 10:11:22 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-radext-design-02.txt 
Date: Wed, 05 Dec 2007 05:10:02 -0500

--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, et al.
	Filename        : draft-ietf-radext-design-02.txt
	Pages           : 31
	Date            : 2007-12-05

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-02.txt

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

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

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-design-02.txt".

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

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

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

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

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

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

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

Content-Type: text/plain
Content-ID:     <2007-12-05050411.I-D\@ietf.org>

--OtherAccess--

--NextPart--

Delivery-date: Wed, 05 Dec 2007 09:05:59 +0000
Date: Wed, 05 Dec 2007 10:03:21 +0100
From: Alan DeKok <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: Drafts for the meeting

  I have put the drafts up on my web site:

http://deployingradius.com/ietf/

  I've included the DTLS draft, which has expired.  I've also included
the -02 draft, which I have just submitted.

  Alan DeKok.

Delivery-date: Wed, 05 Dec 2007 03:49:12 +0000
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 5 Dec 2007 03:47:51 +0000
Subject: Request for review of RADIUS Attributes for IEEE 802 Networks
Accept-Language: en-US
acceptlanguage: en-US

------=_NextPart_000_0305_01C836AE.8E327520
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I support this document as a RADEXT WG item.

Cheers,
MS

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of David B. Nelson
> Sent: Tuesday, November 13, 2007 1:00 PM
> To: [email-masked]
> Subject: Request for review of RADIUS Attributes for IEEE 802 Networks
> 
> The Internet-Draft "RADIUS Attributes for IEEE 802 Networks" was
> revised on
> July 30, 2007, after incorporating review from the IEEE 802.11 WG.
> This
> document appears on the RADEXT WG charter as a June 2006 milestone
> "WLAN
> Attributes draft submitted as a Proposed Standard RFC".  It would be
> good to
> make additional progress on this document.  It appears that all the
> required
> external (i.e. IEEE) review has been completed.
> 
> Please review this draft to determine if it is ready to be taken on as
> a
> RADEXT WG work item.  The draft is to be found at:
> 
> http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-06.txt
> 
> In light of the upcoming IETF-70 meeting, this request for review will
> last
> until December 7, 2007, i.e. approximately four weeks, including the
> IETF
> week.
> 
> Please indicate whether you would like this document to be taken on as
> a WG
> work item. Please respond even if you have no issues with the document.
> If
> you have comments, please send the issues to the RADEXT WG mailing list
> in
> the format provided here:
> 
> http://www.drizzle.com/~aboba/RADEXT/
> 
> Thanks!
> 
> Regards,
> 
> Dave Nelson
> 
> 
> 
> --

------=_NextPart_000_0305_01C836AE.8E327520
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

------=_NextPart_000_0305_01C836AE.8E327520--

Delivery-date: Tue, 04 Dec 2007 19:04:19 +0000
From: <[email-masked]>
To: <[email-masked]>
Subject: IETF 70 slides available
Date: Tue, 4 Dec 2007 11:00:36 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_016E_01C83664.E6334B90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Slides for the IETF 70 meeting of the RADEXT WG are being posted online =
as they arrive:
https://datatracker.ietf.org/meeting/70/materials.html

If you have not sent in your slides, please do so ASAP. 
------=_NextPart_000_016E_01C83664.E6334B90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3Diso-8859-1>
<META content=3D"MSHTML 6.00.6000.16546" name=3DGENERATOR></HEAD>
<BODY id=3DMailContainerBody=20
style=3D"PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-TOP: 15px"=20
bgColor=3D#ffffff leftMargin=3D0 topMargin=3D0 CanvasTabStop=3D"true"=20
name=3D"Compose message area">
<DIV><FONT face=3DArial size=3D2>Slides for the IETF 70 meeting of the =
RADEXT WG are=20
being posted online as they arrive:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
title=3D"https://datatracker.ietf.org/meeting/70/materials.html&#10;CTRL =
+ Click to follow link"=20
href=3D"https://datatracker.ietf.org/meeting/70/materials.html">https://d=
atatracker.ietf.org/meeting/70/materials.html</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>If you have not sent in your slides, =
please do so=20
ASAP. </FONT></DIV></BODY></HTML>

------=_NextPart_000_016E_01C83664.E6334B90--

Delivery-date: Mon, 03 Dec 2007 20:06:14 +0000
Date: Mon, 03 Dec 2007 21:04:24 +0100
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: 'Bernard Aboba' <[email-masked]>, [email-masked]
Subject: Re: Review of draft-ietf-radext-design-01.txt

David B. Nelson wrote:
> Bernard Aboba writes...
> 
> There is some overlap in coverage.  My recommendation is to reorganize
> the discussion as follows:
...
> DBN: I think this text is very good.

  Updated as recommended.
...
> DBN:  I think this last sentence could be a bit more specific.  All
> attributes encode data.  The question is what kind of data.  I think what
> you want to say is:

  Updated

> DBN: I recommend clarifying this last sentence just a bit by:

  Updated.

  I'll post a new version before the meeting.

  Alan DeKok.

Delivery-date: Mon, 03 Dec 2007 19:59:20 +0000
Date: Mon, 03 Dec 2007 20:57:07 +0100
From: Alan DeKok <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Review of draft-ietf-radext-design-01.txt

[email-masked] wrote:
> How about this?
> 
> "Where the intent is to represent a specific IPv6 address, the IPv6
...

  Done.

> Suggest adding:  "The threat is particularly severe when the opaque data

  Word-smithing:

   The threat is particularly severe when the opaque data does not
   originate from, or is checked by the NAS.  In those cases, the RADIUS
   server is potentially exposed to attack by malware residing on an
   unauthenticated host.  Applications consuming opaque data that reside
   on the RADIUS server SHOULD be properly isolated from the RADIUS
   server, and SHOULD run with minimal privileges.  Any potential
   vulnerabilities in that application will then have minimal impact on
   the security of the system as a whole.

  (chopping long sentences, etc.)

  Alan DeKok.

Delivery-date: Mon, 03 Dec 2007 17:05:23 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: Review of draft-ietf-radext-design-01.txt
Date: Mon, 3 Dec 2007 12:01:57 -0500
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

There is some overlap in coverage.=A0 My recommendation is to reorganize
the discussion as follows:
=A0
"1.=A0 Introduction
=A0=A0 This document provides guidelines for the design of RADIUS =
attributes
=A0=A0 both within the IETF as well as within other Standards =
Development
=A0=A0 Organizations (SDOs).=A0 By articulating RADIUS design =
guidelines, it=20
=A0=A0 is hoped that this document will encourage the development and
=A0=A0 publication of high quality RADIUS attribute specifications.
=A0=A0 The advice in this document will not be helpful unless it is put =
to use.=A0

=A0=A0 As with "Guidelines for Authors and Reviewers of MIB Documents"
=A0=A0 [RFC4181], it is expected that this document will enable authors =
to
=A0=A0 check their document against the guidelines prior to requesting a
=A0=A0 review (such an "Expert Review" described in [RFC3575]).=A0 =
Similarly,
=A0=A0 it is hoped that this document will be of use to reviewers (such =
as
=A0=A0 WG participants or the AAA Doctors) in improving the consistency =
of
=A0=A0 reviews.
=A0
=A0=A0 In order to meet these objectives, this document needs to cover =
not
=A0=A0 only the science of attribute design, but also the art.=A0 As a =
result,
=A0=A0 in addition to covering the most frequently encountered issues, =
this
=A0=A0 document attempts to provide some of the considerations =
motivating
=A0=A0 the guidelines.
=A0
=A0=A0 In order to characterize current attribute usage, both the basic =
and
=A0=A0 complex data types defined in the existing RADIUS RFCs are =
reviewed,
=A0=A0 together with the ad-hoc extensions to that data model that have =
been
=A0=A0 used in Vendor-Specific Attributes.

DBN: I think this text is very good.

1.1.=A0 Applicability
=A0=A0 As RADIUS has become more widely accepted as a management =
protocol,
=A0=A0 its usage has become more prevalent, both within the IETF as well =
as
=A0=A0 within other SDOs.=A0 Given the expanded utilization of RADIUS,
=A0=A0 it has become apparent that requiring SDOs to accomplish all =
their=20
=A0=A0 RADIUS work within the IETF is inherently inefficient and =
unscalable.
=A0=A0 By articulating guidelines for RADIUS attribute design, this =
document=20
=A0=A0 enables SDOs to design their own RADIUS attributes within the=20
=A0=A0 Vendor-Specific Attribute (VSA) space, seeking review from the =
IETF.
=A0=A0 In order enable IETF review of SDO RADIUS attribute =
specifications,
=A0=A0 the authors recommend:
=A0
=A0=A0=A0=A0=A0 * Development of a program to encourage SDOs to make =
their RADIUS
=A0=A0=A0=A0=A0 attribute specifications publicly available;
=A0=A0=A0=A0=A0 * Review of IETF and SDO specifications according to the
=A0=A0=A0=A0=A0 guidelines proposed in this document;
=A0
=A0=A0 The advice in this document applies to attributes used to encode
=A0=A0 data.

DBN:  I think this last sentence could be a bit more specific.  All
attributes encode data.  The question is what kind of data.  I think =
what
you want to say is:

   The advice in this document applies to attributes used to encode
   service-provisioning or authentication data.

=A0  RADIUS protocol changes, or specification of attributes that
=A0=A0 can be used to provide new RADIUS commands (such as Service-Type) =
are
=A0=A0 out of scope.

DBN: I recommend clarifying this last sentence just a bit by:

s/can be used to provide new RADIUS commands/can be used to, in effect,
provide new RADIUS commands/

=A0  Since protocol changes require greater expertise and
=A0=A0 deeper review, such changes should not be undertaken outside the =
IETF
=A0=A0 and when handled within the IETF require "IETF Consensus" for
=A0=A0 adoption, as noted in [RFC3575] Section 2.1.
=A0
=A0=A0 As with protocol changes, this document does not provide guidance =
to
=A0=A0 document authors seeking to change the RADIUS operational model.
=A0=A0 While RADIUS server implementations may keep state, the RADIUS
=A0=A0 protocol is stateless, although information may be passed from =
one
=A0=A0 protocol transaction to another via the State Attribute.=A0 As a
=A0=A0 result, documents which require stateful protocol behavior =
without
=A0=A0 use of the State Attribute are inherently incompatible with =
RADIUS as
=A0=A0 defined in [RFC2865], and need to be redesigned.
=A0=A0 See [RFC5080] Section 2.1.1 for a more in-depth discussion of the =
use
=A0=A0 of the State Attribute."
=A0

Delivery-date: Mon, 03 Dec 2007 15:43:35 +0000
From: <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>
Subject: Re: Review of draft-ietf-radext-design-01.txt
Date: Mon, 3 Dec 2007 07:42:18 -0800

>>    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.
>>
>> Judging by some recent specifications, there appears to be some confusion
>> between these two types.  Should an IPv6 address type always be used to
>> represent an address (as opposed to the prefix type).  If so, you might
>> state this explicitly using some normative language.
>
>  Hmm... suggestions?

How about this?

"Where the intent is to represent a specific IPv6 address, the IPv6 address 
type
SHOULD be used.  Although it is possible to utilize the IPv6 Prefix type 
with a prefix
length of 128 to represent an IPv6 address,  this usage is NOT RECOMMENDED."

> 2.1.4.  Complex Attributes and Security
>
>   The introduction of complex data types brings the potential for the
>   introduction of new security vulnerabilities.  Experience shows that
>   the common data types have few security vulnerabilities, or else that
>   all known issues have been found and fixed.  New data types require
>   new code, which may introduce new bugs, and therefore new attack
>   vectors.
>
>   RADIUS servers are highly valued targets, as they control network
>   access and interact with databases that store usernames and
>   passwords.  An extreme outcome of a vulnerability due to a new,
>   complex type would be that an attacker is capable of taking complete
>   control over the RADIUS server.
>
>   The use of attributes representing opaque data does not reduce this
>   threat.  The threat merely moves from the RADIUS server to the
>   application that consumes that opaque data.

Suggest adding:  "The threat is particularly severe when the opaque data
is not originated or checked by the NAS, so that the RADIUS server is
potentially exposed to attack by malware residing on a host.  Applications
consuming opaque data that reside on the RADIUS server

>   SHOULD be properly isolated from the RADIUS server, and SHOULD run
>   with minimal privileges.  Any potential vulnerabilities in that
>   application will then have minimal impact on the security of the
>   system as a whole. 

Delivery-date: Mon, 03 Dec 2007 12:27:13 +0000
Date: Mon, 03 Dec 2007 13:24:17 +0100
From: Alan DeKok <[email-masked]>
To: [email-masked]
Subject: Re: Review of draft-ietf-radext-design-01.txt

Bernard Aboba wrote:
> Designation
>  
> I thought that this document was a BCP, no?  -01 states that
> it is "Standards Track". 

  -00 was Standards Track, too.  The next version can be changed to a BCP.

> Sections 1 and 1.1
>  
> There is some overlap in coverage.  My recommendation is to reorganize
> the discussion as follows:
...

  OK.

> BTW, I would also suggest a statement that this document does not apply
> to new uses of RADIUS (e.g. uses of RADIUS that go beyond conversations
> between a RADIUS client and server).
> Section 2.1.1

  OK.

>    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.
> 
> Judging by some recent specifications, there appears to be some confusion
> between these two types.  Should an IPv6 address type always be used to
> represent an address (as opposed to the prefix type).  If so, you might
> state this explicitly using some normative language.

  Hmm... suggestions?

>    integer64      64 bit unsigned value, most significant octet first.
>  
> I believe that this type has also been used to express an IPv6 Identifier
> value, no?

  Yes.  That is mentioned in the following paragraph.  I'll add a line
here saying the same thing.

> limitatations -> limitations

  Fixed, thanks.

> Section 2.1.3
..
> I think it may be worth expanding this discussion of opaque data types
> somewhat and covering additional implications, security related ones
> in particular.

  Section 2.1.3 is already over two pages long.  I suggest adding a new
section immediately following it, "Complex attributes and Security":

2.1.4.  Complex Attributes and Security

   The introduction of complex data types brings the potential for the
   introduction of new security vulnerabilities.  Experience shows that
   the common data types have few security vulnerabilities, or else that
   all known issues have been found and fixed.  New data types require
   new code, which may introduce new bugs, and therefore new attack
   vectors.

   RADIUS servers are highly valued targets, as they control network
   access and interact with databases that store usernames and
   passwords.  An extreme outcome of a vulnerability due to a new,
   complex type would be that an attacker is capable of taking complete
   control over the RADIUS server.

   The use of attributes representing opaque data does not reduce this
   threat.  The threat merely moves from the RADIUS server to the
   application that consumes that opaque data.  Any such application
   SHOULD be properly isolated from the RADIUS server, and SHOULD run
   with minimal privileges.  Any potential vulnerabilities in that
   application will then have minimal impact on the security of the
   system as a whole.

  I've also added text in the security section referencing 2.1.4.

> Section 3.1.3
...
> Can you expand "PEC" on first use?

  Done in Section 2.2.

> Rehosting may also require changes to the RADIUS data model
>    which will affect implementations that do not intend to support the
>    SDO specifications
> 
> Period needed at the end of the sentence.

  Fixed, thanks.

> IDNITs check
...
> ----------------------------------------------------------------------------
>   == Using lowercase 'not' together with uppercase 'MUST' is not an accepted
>      usage according to RFC 2119.  Please use 'MUST NOT' (if that is
> what you
>      mean).

  Text changed to MUST NOT.

>   -- Looks like a reference, but probably isn't: '8' on line 1191

  It's in a quote from another document.

>   == Unused Reference: 'RFC4005' is defined on line 795, but no explicit
>      reference was found in the text
>      '[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
> "Diamete...'

  That reference can be deleted.

>   -- No information found for draft-ietf-radext-extended-attributes - is the
>      name correct?

  Yes.

  Alan DeKok.

Delivery-date: Mon, 03 Dec 2007 01:43:02 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Review of draft-ietf-radext-design-01.txt
Date: Sun, 2 Dec 2007 17:41:27 -0800

--_60a8d9c3-4f9e-46f3-9371-bd3b267b2210_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Review of draft-ietf-radext-design-01.txt
=20
Designation
=20
I thought that this document was a BCP, no?  -01 states thatit is "Standard=
s Track".=20
=20
Sections 1 and 1.1
=20
There is some overlap in coverage.  My recommendation is to reorganizethe d=
iscussion as follows:
=20
"1.  Introduction
   This document provides guidelines for the design of RADIUS attributes   =
both within the IETF as well as within other Standards Development   Organi=
zations (SDOs).  By articulating RADIUS design guidelines, it    is hoped t=
hat this document will encourage the development and   publication of high =
quality RADIUS attribute specifications.
   The advice in this document will not be helpful unless it is put to use.=
     As with "Guidelines for Authors and Reviewers of MIB Documents"   [RFC=
4181], it is expected that this document will enable authors to   check the=
ir document against the guidelines prior to requesting a   review (such an =
"Expert Review" described in [RFC3575]).  Similarly,   it is hoped that thi=
s document will be of use to reviewers (such as   WG participants or the AA=
A Doctors) in improving the consistency of   reviews.
=20
   In order to meet these objectives, this document needs to cover not   on=
ly the science of attribute design, but also the art.  As a result,   in ad=
dition to covering the most frequently encountered issues, this   document =
attempts to provide some of the considerations motivating   the guidelines.
=20
   In order to characterize current attribute usage, both the basic and   c=
omplex data types defined in the existing RADIUS RFCs are reviewed,   toget=
her with the ad-hoc extensions to that data model that have been   used in =
Vendor-Specific Attributes.
=20
1.1.  Applicability
   As RADIUS has become more widely accepted as a management protocol,   it=
s usage has become more prevalent, both within the IETF as well as   within=
 other SDOs.  Given the expanded utilization of RADIUS,   it has become app=
arent that requiring SDOs to accomplish all their    RADIUS work within the=
 IETF is inherently inefficient and unscalable.
   By articulating guidelines for RADIUS attribute design, this document   =
 enables SDOs to design their own RADIUS attributes within the    Vendor-Sp=
ecific Attribute (VSA) space, seeking review from the IETF.   In order enab=
le IETF review of SDO RADIUS attribute specifications,   the authors recomm=
end:
=20
      * Development of a program to encourage SDOs to make their RADIUS    =
  attribute specifications publicly available;
      * Review of IETF and SDO specifications according to the      guideli=
nes proposed in this document;
=20
   The advice in this document applies to attributes used to encode   data.=
  RADIUS protocol changes, or specification of attributes that   can be use=
d to provide new RADIUS commands (such as Service-Type) are   out of scope.=
  Since protocol changes require greater expertise and   deeper review, suc=
h changes should not be undertaken outside the IETF   and when handled with=
in the IETF require "IETF Consensus" for   adoption, as noted in [RFC3575] =
Section 2.1.
=20
   As with protocol changes, this document does not provide guidance to   d=
ocument authors seeking to change the RADIUS operational model.   While RAD=
IUS server implementations may keep state, the RADIUS   protocol is statele=
ss, although information may be passed from one   protocol transaction to a=
nother via the State Attribute.  As a   result, documents which require sta=
teful protocol behavior without   use of the State Attribute are inherently=
 incompatible with RADIUS as   defined in [RFC2865], and need to be redesig=
ned.
   See [RFC5080] Section 2.1.1 for a more in-depth discussion of the use   =
of the State Attribute."
=20
BTW, I would also suggest a statement that this document does not applyto n=
ew uses of RADIUS (e.g. uses of RADIUS that go beyond conversationsbetween =
a RADIUS client and server).=20
Section 2.1.1
   IPv6 address   128 bit value, most significant octet first.   IPv6 prefi=
x    8 bits of reserved, 8 bits of prefix length, up to                  12=
8 bits of value, most significant octet first.
Judging by some recent specifications, there appears to be some confusionbe=
tween these two types.  Should an IPv6 address type always be used torepres=
ent an address (as opposed to the prefix type).  If so, you mightstate this=
 explicitly using some normative language.=20
=20
   integer64      64 bit unsigned value, most significant octet first.
=20
I believe that this type has also been used to express an IPv6 Identifierva=
lue, no?=20
=20
Section 2.1.2
=20
"  New attributes SHOULD NOT use this tagging method because of the   limit=
atations described above."
=20
limitatations -> limitations
=20
Section 2.1.3
=20
   The only other exception to the recommendation against complex types   i=
s for types that can be treated as opaque data by the RADIUS server.   For =
example, the EAP-Message attribute, defined in [RFC3579] Section   3.1 cont=
ains a complex data type that is an EAP packet.  Since these   complex type=
s do not need to be parsed by the RADIUS server, the   issues arising from =
policy language limitations do not arise.   Similarly, since attributes of =
these complex types can be configured   on the server using a data type of =
String, dictionary limitations are   also not encountered.  Section A.1 bel=
ow includes a series of   checklists that may be used to analyze a design f=
or RECOMMENDED and   NOT RECOMMENDED behavior in relation to complex types.
=20
I think it may be worth expanding this discussion of opaque data typessomew=
hat and covering additional implications, security related onesin particula=
r.  In general, RADIUS servers are highly valued targets sothat the introdu=
ction of complex data types brings withit the potential for introduction of=
 security vulnerabilities such asbuffer overflows.  An extreme outcome woul=
d be a vulnerability thatwould allow an attacker to take over the RADIUS se=
rver.
=20
The use of attributes representing opaque data does not reduce thisthreat, =
it merely moves it from the RADIUS server to an applicationthat consumes RA=
DIUS attributes.  Should this application not beproperly isolated, or run w=
ith extended privileges, then the introduction of new opaque data types (or=
 changes in the formatof existing opaque types) may introduce serious new s=
ecurity vulnerabilities.=20
=20
Section 3.1.3
=20
   This change control can be obtained by requesting a PEC from the   Inter=
net Assigned Number Authority (IANA), for use as a Vendor-Id   within a Ven=
dor-Specific attribute. =20
=20
Can you expand "PEC" on first use?=20
=20
Rehosting may also require changes to the RADIUS data model   which will af=
fect implementations that do not intend to support the   SDO specifications
Period needed at the end of the sentence.=20
=20
IDNITs check-------------
The tool found a few warnings:
=20
idnits 2.05.02=20
tmp/draft-ietf-radext-design-01.txt: - Failure fetching the file, proceedin=
g without it.)
  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748: =
 --------------------------------------------------------------------------=
--
     No issues found here.
  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:  =
---------------------------------------------------------------------------=
-
     No issues found here.
  Checking nits according to http://www.ietf.org/ID-Checklist.html:  ------=
----------------------------------------------------------------------
     No issues found here.
  Miscellaneous warnings:  ------------------------------------------------=
----------------------------
  =3D=3D Using lowercase 'not' together with uppercase 'MUST' is not an acc=
epted     usage according to RFC 2119.  Please use 'MUST NOT' (if that is w=
hat you     mean).          Found 'MUST not' in this paragraph:          Th=
is Attribute is available to allow vendors to support their own     extende=
d Attributes not suitable for general usage.  It MUST not affect     the op=
eration of the RADIUS protocol.
  Checking references for intended status: Proposed Standard  -------------=
---------------------------------------------------------------
     (See RFC 3967 for information about using normative references to     =
lower-maturity documents in RFCs)
  -- Looks like a reference, but probably isn't: '8' on line 1191     'The =
Text field consists of UTF-8 encoded 10646 [8] characters....'
  =3D=3D Unused Reference: 'RFC4005' is defined on line 795, but no explici=
t     reference was found in the text     '[RFC4005] Calhoun, P., Zorn, G.,=
 Spence, D., and D. Mitton, "Diamete...'
  -- No information found for draft-ietf-radext-extended-attributes - is th=
e     name correct?
     Summary: 0 errors (**), 2 warnings (=3D=3D), 2 comments (--).---------=
-----------------------------------------------------------------------=

--_60a8d9c3-4f9e-46f3-9371-bd3b267b2210_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
Review of draft-ietf-radext-design-01.txt<BR>
&nbsp;<BR>
Designation<BR>
&nbsp;<BR>
I thought that this document was a BCP, no?&nbsp; -01 states that<BR>it is =
"Standards Track".&nbsp;<BR>
&nbsp;<BR>
Sections 1 and 1.1<BR>
&nbsp;<BR>
There is some overlap in coverage.&nbsp; My recommendation is to reorganize=
<BR>the discussion as follows:<BR>
&nbsp;<BR>
"1.&nbsp; Introduction<BR>
&nbsp;&nbsp; This document provides guidelines for the design of RADIUS att=
ributes<BR>&nbsp;&nbsp; both within the IETF as well as within other Standa=
rds Development<BR>&nbsp;&nbsp; Organizations (SDOs).&nbsp; By articulating=
 RADIUS design guidelines, it <BR>&nbsp;&nbsp; is hoped that this document =
will encourage the development and<BR>&nbsp;&nbsp; publication of high qual=
ity RADIUS attribute specifications.<BR>
&nbsp;&nbsp; The advice in this document will not be helpful unless it is p=
ut to use.&nbsp; <BR>&nbsp;&nbsp; As with "Guidelines for Authors and Revie=
wers of MIB Documents"<BR>&nbsp;&nbsp; [RFC4181], it is expected that this =
document will enable authors to<BR>&nbsp;&nbsp; check their document agains=
t the guidelines prior to requesting a<BR>&nbsp;&nbsp; review (such an "Exp=
ert Review" described in [RFC3575]).&nbsp; Similarly,<BR>&nbsp;&nbsp; it is=
 hoped that this document will be of use to reviewers (such as<BR>&nbsp;&nb=
sp; WG participants or the AAA Doctors) in improving the consistency of<BR>=
&nbsp;&nbsp; reviews.<BR>
&nbsp;<BR>
&nbsp;&nbsp; In order to meet these objectives, this document needs to cove=
r not<BR>&nbsp;&nbsp; only the science of attribute design, but also the ar=
t.&nbsp; As a result,<BR>&nbsp;&nbsp; in addition to covering the most freq=
uently encountered issues, this<BR>&nbsp;&nbsp; document attempts to provid=
e some of the considerations motivating<BR>&nbsp;&nbsp; the guidelines.<BR>
&nbsp;<BR>
&nbsp;&nbsp; In order to characterize current attribute usage, both the bas=
ic and<BR>&nbsp;&nbsp; complex data types defined in the existing RADIUS RF=
Cs are reviewed,<BR>&nbsp;&nbsp; together with the ad-hoc extensions to tha=
t data model that have been<BR>&nbsp;&nbsp; used in Vendor-Specific Attribu=
tes.<BR>
&nbsp;<BR>
1.1.&nbsp; Applicability<BR>
&nbsp;&nbsp; As RADIUS has become more widely accepted as a management prot=
ocol,<BR>&nbsp;&nbsp; its usage has become more prevalent, both within the =
IETF as well as<BR>&nbsp;&nbsp; within other SDOs.&nbsp; Given the expanded=
 utilization of RADIUS,<BR>&nbsp;&nbsp; it has become apparent that requiri=
ng SDOs to accomplish all their <BR>&nbsp;&nbsp; RADIUS work within the IET=
F is inherently inefficient and unscalable.<BR>
&nbsp;&nbsp; By articulating guidelines for RADIUS attribute design, this d=
ocument <BR>&nbsp;&nbsp; enables SDOs to design their own RADIUS attributes=
 within the <BR>&nbsp;&nbsp; Vendor-Specific Attribute (VSA) space, seeking=
 review from the IETF.<BR>&nbsp;&nbsp; In order enable IETF review of SDO R=
ADIUS attribute specifications,<BR>&nbsp;&nbsp; the authors recommend:<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * Development of a program to encourage SDOs=
 to make their RADIUS<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; attribute specifica=
tions publicly available;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * Review of IETF and SDO specifications acco=
rding to the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; guidelines proposed in this =
document;<BR>
&nbsp;<BR>
&nbsp;&nbsp; The advice in this document applies to attributes used to enco=
de<BR>&nbsp;&nbsp; data.&nbsp; RADIUS protocol changes, or specification of=
 attributes that<BR>&nbsp;&nbsp; can be used to provide new RADIUS commands=
 (such as Service-Type) are<BR>&nbsp;&nbsp; out of scope.&nbsp; Since proto=
col changes require greater expertise and<BR>&nbsp;&nbsp; deeper review, su=
ch changes should not be undertaken outside the IETF<BR>&nbsp;&nbsp; and wh=
en handled within the IETF require "IETF Consensus" for<BR>&nbsp;&nbsp; ado=
ption, as noted in [RFC3575] Section 2.1.<BR>
&nbsp;<BR>
&nbsp;&nbsp; As with protocol changes, this document does not provide guida=
nce to<BR>&nbsp;&nbsp; document authors seeking to change the RADIUS operat=
ional model.<BR>&nbsp;&nbsp; While RADIUS server implementations may keep s=
tate, the RADIUS<BR>&nbsp;&nbsp; protocol is stateless, although informatio=
n may be passed from one<BR>&nbsp;&nbsp; protocol transaction to another vi=
a the State Attribute.&nbsp; As a<BR>&nbsp;&nbsp; result, documents which r=
equire stateful protocol behavior without<BR>&nbsp;&nbsp; use of the State =
Attribute are inherently incompatible with RADIUS as<BR>&nbsp;&nbsp; define=
d in [RFC2865], and need to be redesigned.<BR>
&nbsp;&nbsp; See [RFC5080] Section 2.1.1 for a more in-depth discussion of =
the use<BR>&nbsp;&nbsp; of the State Attribute."<BR>
&nbsp;<BR>
BTW, I would also suggest a statement that this document does not apply<BR>=
to new uses of RADIUS (e.g. uses of RADIUS that go beyond conversations<BR>=
between a RADIUS client and server). <BR>
Section 2.1.1<BR>
<BR>&nbsp;&nbsp; IPv6 address&nbsp;&nbsp; 128 bit value, most significant o=
ctet first.<BR>&nbsp;&nbsp; IPv6 prefix&nbsp;&nbsp;&nbsp; 8 bits of reserve=
d, 8 bits of prefix length, up to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 128 bits o=
f value, most significant octet first.<BR>
<BR>Judging by some recent specifications, there appears to be some confusi=
on<BR>between these two types.&nbsp; Should an IPv6 address type always be =
used to<BR>represent an address (as opposed to the prefix type).&nbsp; If s=
o, you might<BR>state this explicitly using some normative language. <BR>
&nbsp;<BR>
&nbsp;&nbsp; integer64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 64 bit unsigned value,=
 most significant octet first.<BR>
&nbsp;<BR>
I believe that this type has also been used to express an IPv6 Identifier<B=
R>value, no? <BR>
&nbsp;<BR>
Section 2.1.2<BR>
&nbsp;<BR>
"&nbsp; New attributes SHOULD NOT use this tagging method because of the<BR=
>&nbsp;&nbsp; limitatations described above."<BR>
&nbsp;<BR>
limitatations -&gt; limitations<BR>
&nbsp;<BR>
Section 2.1.3<BR>
&nbsp;<BR>
&nbsp;&nbsp; The only other exception to the recommendation against complex=
 types<BR>&nbsp;&nbsp; is for types that can be treated as opaque data by t=
he RADIUS server.<BR>&nbsp;&nbsp; For example, the EAP-Message attribute, d=
efined in [RFC3579] Section<BR>&nbsp;&nbsp; 3.1 contains a complex data typ=
e that is an EAP packet.&nbsp; Since these<BR>&nbsp;&nbsp; complex types do=
 not need to be parsed by the RADIUS server, the<BR>&nbsp;&nbsp; issues ari=
sing from policy language limitations do not arise.<BR>&nbsp;&nbsp; Similar=
ly, since attributes of these complex types can be configured<BR>&nbsp;&nbs=
p; on the server using a data type of String, dictionary limitations are<BR=
>&nbsp;&nbsp; also not encountered.&nbsp; Section A.1 below includes a seri=
es of<BR>&nbsp;&nbsp; checklists that may be used to analyze a design for R=
ECOMMENDED and<BR>&nbsp;&nbsp; NOT RECOMMENDED behavior in relation to comp=
lex types.<BR>
&nbsp;<BR>
I think it may be worth expanding this discussion of opaque data types<BR>s=
omewhat and covering additional implications, security related ones<BR>in p=
articular.&nbsp; In general, RADIUS servers are highly valued targets so<BR=
>that the introduction of complex data types brings with<BR>it the potentia=
l for introduction of security vulnerabilities such as<BR>buffer overflows.=
&nbsp; An extreme outcome would be a vulnerability that<BR>would allow an a=
ttacker to take over the RADIUS server.<BR>
&nbsp;<BR>
The use of attributes representing opaque data does not reduce this<BR>thre=
at, it merely moves it from the RADIUS server to an application<BR>that con=
sumes RADIUS attributes.&nbsp; Should this application not be<BR>properly i=
solated, or run with extended privileges, then the <BR>introduction of new =
opaque data types (or changes in the format<BR>of existing opaque types) ma=
y introduce serious new security <BR>vulnerabilities. <BR>
&nbsp;<BR>
Section 3.1.3<BR>
&nbsp;<BR>
&nbsp;&nbsp; This change control can be obtained by requesting a PEC from t=
he<BR>&nbsp;&nbsp; Internet Assigned Number Authority (IANA), for use as a =
Vendor-Id<BR>&nbsp;&nbsp; within a Vendor-Specific attribute.&nbsp; <BR>
&nbsp;<BR>
Can you expand "PEC" on first use? <BR>
&nbsp;<BR>
Rehosting may also require changes to the RADIUS data model<BR>&nbsp;&nbsp;=
 which will affect implementations that do not intend to support the<BR>&nb=
sp;&nbsp; SDO specifications<BR>
<BR>Period needed at the end of the sentence. <BR>
&nbsp;<BR>
<BR>IDNITs check<BR>-------------<BR>
The tool found a few warnings:<BR>
&nbsp;<BR>
idnits 2.05.02 <BR>
tmp/draft-ietf-radext-design-01.txt:<BR>&nbsp;- Failure fetching the file, =
proceeding without it.)<BR>
&nbsp; Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4=
748:<BR>&nbsp; ------------------------------------------------------------=
----------------<BR>
&nbsp;&nbsp;&nbsp;&nbsp; No issues found here.<BR>
&nbsp; Checking nits according to <A href=3D"http://www.ietf.org/ietf/1id-g=
uidelines.txt">http://www.ietf.org/ietf/1id-guidelines.txt</A>:<BR>&nbsp; -=
---------------------------------------------------------------------------=
<BR>
&nbsp;&nbsp;&nbsp;&nbsp; No issues found here.<BR>
&nbsp; Checking nits according to <A href=3D"http://www.ietf.org/ID-Checkli=
st.html">http://www.ietf.org/ID-Checklist.html</A>:<BR>&nbsp; -------------=
---------------------------------------------------------------<BR>
&nbsp;&nbsp;&nbsp;&nbsp; No issues found here.<BR>
&nbsp; Miscellaneous warnings:<BR>&nbsp; ----------------------------------=
------------------------------------------<BR>
&nbsp; =3D=3D Using lowercase 'not' together with uppercase 'MUST' is not a=
n accepted<BR>&nbsp;&nbsp;&nbsp;&nbsp; usage according to RFC 2119.&nbsp; P=
lease use 'MUST NOT' (if that is what you<BR>&nbsp;&nbsp;&nbsp;&nbsp; mean)=
.<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp; Found 'MUST not'=
 in this paragraph:<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp=
; This Attribute is available to allow vendors to support their own<BR>&nbs=
p;&nbsp;&nbsp;&nbsp; extended Attributes not suitable for general usage.&nb=
sp; It MUST not affect<BR>&nbsp;&nbsp;&nbsp;&nbsp; the operation of the RAD=
IUS protocol.<BR>
<BR>&nbsp; Checking references for intended status: Proposed Standard<BR>&n=
bsp; ----------------------------------------------------------------------=
------<BR>
&nbsp;&nbsp;&nbsp;&nbsp; (See RFC 3967 for information about using normativ=
e references to<BR>&nbsp;&nbsp;&nbsp;&nbsp; lower-maturity documents in RFC=
s)<BR>
&nbsp; -- Looks like a reference, but probably isn't: '8' on line 1191<BR>&=
nbsp;&nbsp;&nbsp;&nbsp; 'The Text field consists of UTF-8 encoded 10646 [8]=
 characters....'<BR>
&nbsp; =3D=3D Unused Reference: 'RFC4005' is defined on line 795, but no ex=
plicit<BR>&nbsp;&nbsp;&nbsp;&nbsp; reference was found in the text<BR>&nbsp=
;&nbsp;&nbsp;&nbsp; '[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mi=
tton, "Diamete...'<BR>
&nbsp; -- No information found for draft-ietf-radext-extended-attributes - =
is the<BR>&nbsp;&nbsp;&nbsp;&nbsp; name correct?<BR>
<BR>&nbsp;&nbsp;&nbsp;&nbsp; Summary: 0 errors (**), 2 warnings (=3D=3D), 2=
 comments (--).<BR>--------------------------------------------------------=
------------------------<BR></body>
</html>=

--_60a8d9c3-4f9e-46f3-9371-bd3b267b2210_--

Delivery-date: Mon, 03 Dec 2007 00:35:48 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Updated agenda for IETF 70
Date: Sun, 2 Dec 2007 16:33:48 -0800

--_b5e76d51-be6a-4d63-afc6-d42bb2bc5a7a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

IETF 70 RADEXT WG AgendaWednesday December 5, 20079 AM - 11:30 AM, Cypress =
Room 9 AM - 9:10 AM Preliminaries   Blue Sheets   Note Takers   Jabber Scri=
be   Agenda bashing   Document status Documents completing RADEXT WG last c=
all (10 minutes) 9:20 - 9:30 AM  RADIUS Design Guidelines, Alan DeKokhttp:/=
/www.ietf.org/internet-drafts/draft-ietf-radext-design-01.txt 9:30 - 9:40 A=
M   RADIUS Authorization for NAS Management, David Nelsonhttp://www.ietf.or=
g/internet-drafts/draft-ietf-radext-management-authorization-01.txt
=20
WG Work items 9:40 - 9:50 Extended RADIUS Attributes, Glen Zornhttp://www.i=
etf.org/internet-drafts/draft-ietf-radext-extended-attributes-00.txt   Pre-=
WG Work Item Review 9:50- 10:00 IEEE 802 Attributes, Bernard Abobahttp://ww=
w.watersprings.org/pub/id/draft-aboba-radext-wlan-04.txt
=20
10:00 - 10:10 RADIUS support for EAP Re-authentication, K. Gaonkarhttp://ww=
w.ietf.org/internet-drafts/draft-gaonkar-radext-erp-attrs-01.txt
RADIUS Crypto-Agility (50 minutes) 10:10 - 10:25 RADEXT Crypto-agility Requ=
irements and Selection Process, David Nelson 10:25 - 10:35 RADIUS + DTLS (A=
lan DeKok)http://www.watersprings.org/pub/id/draft-dekok-radext-dtls-00.txt=
 10:35 - 10:50 RADIUS Crypto-agility (Joe Salowey)http://www.watersprings.o=
rg/pub/id/draft-zorn-radius-keywrap-13.txthttp://www.watersprings.org/pub/i=
d/draft-zorn-radius-encattr-06.txt 10:50 - 11:10 Discussion Miscellaneous (=
10 minutes) 11:10 - 11:20 RADSEC (Stig Venaas)http://www.watersprings.org/p=
ub/id/draft-winter-radsec-00.txt Discussion & Wrapup (10 minutes)=

--_b5e76d51-be6a-4d63-afc6-d42bb2bc5a7a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
IETF 70 RADEXT WG Agenda<BR>Wednesday December 5, 2007<BR>9 AM - 11:30 AM, =
Cypress Room<BR>&nbsp;<BR>9 AM - 9:10 AM Preliminaries<BR>&nbsp;&nbsp; Blue=
 Sheets<BR>&nbsp;&nbsp; Note Takers<BR>&nbsp;&nbsp; Jabber Scribe<BR>&nbsp;=
&nbsp; Agenda bashing<BR>&nbsp;&nbsp; Document status<BR>&nbsp;<BR>Document=
s completing RADEXT WG last call (10 minutes)<BR>&nbsp;<BR>9:20 - 9:30 AM&n=
bsp; RADIUS Design Guidelines, Alan DeKok<BR><A href=3D"http://www.ietf.org=
/internet-drafts/draft-ietf-radext-design-01.txt">http://www.ietf.org/inter=
net-drafts/draft-ietf-radext-design-01.txt</A><BR>&nbsp;<BR>9:30 - 9:40 AM&=
nbsp;&nbsp; RADIUS Authorization for NAS Management, David Nelson<BR><A hre=
f=3D"http://www.ietf.org/internet-drafts/draft-ietf-radext-management-autho=
rization-01.txt">http://www.ietf.org/internet-drafts/draft-ietf-radext-mana=
gement-authorization-01.txt</A><BR>
&nbsp;<BR>
WG Work items<BR>&nbsp;<BR>9:40 - 9:50 Extended RADIUS Attributes, Glen Zor=
n<BR><A href=3D"http://www.ietf.org/internet-drafts/draft-ietf-radext-exten=
ded-attributes-00.txt">http://www.ietf.org/internet-drafts/draft-ietf-radex=
t-extended-attributes-00.txt</A><BR>&nbsp;&nbsp; <BR>Pre-WG Work Item Revie=
w<BR>&nbsp;<BR>9:50- 10:00 IEEE 802 Attributes, Bernard Aboba<BR><A href=3D=
"http://www.watersprings.org/pub/id/draft-aboba-radext-wlan-04.txt">http://=
www.watersprings.org/pub/id/draft-aboba-radext-wlan-04.txt</A><BR>
&nbsp;<BR>
10:00 - 10:10 RADIUS support for EAP Re-authentication, K. Gaonkar<BR><A hr=
ef=3D"http://www.ietf.org/internet-drafts/draft-gaonkar-radext-erp-attrs-01=
.txt">http://www.ietf.org/internet-drafts/draft-gaonkar-radext-erp-attrs-01=
.txt</A><BR>
RADIUS Crypto-Agility (50 minutes)<BR>&nbsp;<BR>10:10 - 10:25 RADEXT Crypto=
-agility Requirements and Selection Process, David Nelson<BR>&nbsp;<BR>10:2=
5 - 10:35 RADIUS + DTLS (Alan DeKok)<BR><A href=3D"http://www.watersprings.=
org/pub/id/draft-dekok-radext-dtls-00.txt">http://www.watersprings.org/pub/=
id/draft-dekok-radext-dtls-00.txt</A><BR>&nbsp;<BR>10:35 - 10:50 RADIUS Cry=
pto-agility (Joe Salowey)<BR><A href=3D"http://www.watersprings.org/pub/id/=
draft-zorn-radius-keywrap-13.txt">http://www.watersprings.org/pub/id/draft-=
zorn-radius-keywrap-13.txt</A><BR><A href=3D"http://www.watersprings.org/pu=
b/id/draft-zorn-radius-encattr-06.txt">http://www.watersprings.org/pub/id/d=
raft-zorn-radius-encattr-06.txt</A><BR>&nbsp;<BR>10:50 - 11:10 Discussion<B=
R>&nbsp;<BR>Miscellaneous (10 minutes)<BR>&nbsp;<BR>11:10 - 11:20 RADSEC (S=
tig Venaas)<BR><A href=3D"http://www.watersprings.org/pub/id/draft-winter-r=
adsec-00.txt">http://www.watersprings.org/pub/id/draft-winter-radsec-00.txt=
</A><BR>&nbsp;<BR>Discussion &amp; Wrapup (10 minutes)<BR></body>
</html>=

--_b5e76d51-be6a-4d63-afc6-d42bb2bc5a7a_--

Delivery-date: Sat, 01 Dec 2007 19:23:01 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Please send slides
Date: Sat, 1 Dec 2007 11:21:45 -0800

--_c2a0ec02-549c-4ff9-833b-ea517d635af3_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is a last call for agenda items for IETF 70.  If you are not on the ag=
enda and would like to present, please send email.=20

If you are on the agenda please confirm your availability and send slides A=
SAP.

--_c2a0ec02-549c-4ff9-833b-ea517d635af3_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
This is a last call for agenda items for IETF 70.&nbsp; If you are not on t=
he agenda and would like to present, please send email. <br><br>If you are =
on the agenda please confirm your availability and send slides ASAP.<br></b=
ody>
</html>=

--_c2a0ec02-549c-4ff9-833b-ea517d635af3_--