Subject: RE: review of draft-ietf-radext-ieee802-01.txt
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: "Jari Arkko" <[email-masked]>, <[email-masked]>
Date: Tue, 31 Jan 2006 11:39:29 -0800

Jari commented...

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: Friday, January 27, 2006 4:15 AM
> To: [email-masked]
> Subject: review of draft-ietf-radext-ieee802-01.txt
> 
> I reviewed this draft. Overall, this draft is in good shape, 
> but some minor mistakes and question marks are noted below. 
> In addition, the document is silent on the use of these 
> attributes in Diameter, which needs further work.
> 
> The title should probably mention redirection, too.

Wouldn't this make the title too long?  Besides, redirection is action
taken by the filtering attribute. There is no standalone redirection
attribute.

> Is this for informational or standards track? In some sense 
> the latter would make more sense, as this is an important 
> functionality that many people will need.

Standards track. 

> 
> And please run ABNF checker from tools.ietf.org:

Which checker did you use?  I ran it through and it didn't pick up on
these errors.

> >   5.  IANA Considerations
> >
> Do you want to say something about allocation policy on new 
> enumerated values?

What do you think should be said?

> >   2.5.  NAS-Filter-Rule
> >
> This is quite complicated. Do we have implementation 
> experience that this works and is well defined?

What sort of proof points are you looking for?

> 
> >      The security mechanisms in [RFC2865] and [RFC3576] are 
> primarily 
> >      concerned with an outside attacker who modifies messages in 
> >      transit or inserts new messages. They do not prevent 
> an authorized 
> >      RADIUS server or proxy from inserting attributes with 
> a malicious 
> >      purpose in message it sends. 
> >  
> >
> Or deleting, for that matter...

Fair enough, easy enough to add. 

<...Removed DIAMETER discussion - being discussed in different thread>

> Editorial:
> 
> >      In this document when we refer to Blocking of IP 
> traffic we mean 
> >      Filtering of IP traffic.
> >
> Not sure if Capitalization is Needed.

Ok. Capitalization not necessary. 

> 
> >       0                   1                   2                   3 
> >       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 
> 7 8 9 0 1 
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >      |     Type      |    Length     |  Tag Option   |   
> Pad (12-bit)          
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >        Pad   |    VLANID (12-bit)    |  
> >      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> >      Type
> >    
> >         TBD
> >    
> >      Length
> >    
> >         6    
> >    
> >      Integer
> >    
> >
> The picture and text do not match. Show two pictures:
> one with "Integer" and then another one with the detailed 
> substructure.

Ok.

> 
> >         "l2:"       Prefix on any base encapsulation rule 
> to designate 
> >                     as rule as such. 
> >  
> >
> "a rule as such"?

Would the following be clearer?

'Prefix to designate rule as a base encapsulation rule.'

> 
> > TODO / TBD
> 
> Two different placeholders are used. Just use TBD, or better 
> yet, TBD-by-IANA so that they can better search for these.

Ok.

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

Delivery-date: Tue, 31 Jan 2006 19:12:02 +0000
Content-class: urn:content-classes:message
Subject: RE: Status of RADEXT Issues 115 and 116
Date: Tue, 31 Jan 2006 14:11:54 -0500
From: "Nelson, David" <[email-masked]>
To: "Sanchez, Mauricio \(PNB Roseville\)" <[email-masked]>, <[email-masked]>

Mauricio Sanchez writes...
 
> Would the addition of the following defintion to the terminology
section
> cover your concerns?
> 
> Terminal
> 	A terminal is an endpoint, such as an 802.1X supplicant,
>     attached to the NAS port.

Yes, that's fine.

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

Delivery-date: Tue, 31 Jan 2006 19:10:34 +0000
Content-class: urn:content-classes:message
Subject: RE: Status of RADEXT Issues 115 and 116
Date: Tue, 31 Jan 2006 11:10:20 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Dave,

Would the addition of the following defintion to the terminology section
cover your concerns?

Terminal
	A terminal is an endpoint, such as an 802.1X supplicant,
attached to the NAS port.  

Cheers,
MS
> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Thursday, January 26, 2006 4:30 PM
> To: Sanchez, Mauricio (PNB Roseville); [email-masked]
> Subject: RE: Status of RADEXT Issues 115 and 116
> 
> > Yes, this is know.  On 1/10/06 I wrote in response to your issue:
> 
> > "[ms] This sentence comes by way of the IPFilterRule 
> description found 
> > in Diameter [RFC3588].  What would you suggest we do for RADIUS? Is 
> > terminal not a globally known term in RADIUS, if not, is there any?
> > Perhaps can you suggest a definition to add to the 
> terminology section.
> > "
> 
> > I await your response.
>  
> Ah.  Brain fade...
> 
> Terminal may have been a well understood term in the days 
> when RADIUS was just for Terminal Servers.  I would recommend 
> either substituting another term in the text, or creating a 
> definition in the Terminology section.   Perhaps "network 
> device attached to the NAS port".  You might also mention (in 
> a definition) that "terminal" often means the "IEEE 802.1X 
> Supplicant".
> 
>  
> 
> 

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

Delivery-date: Tue, 31 Jan 2006 18:52:42 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 102 in ieee802-01
Date: Tue, 31 Jan 2006 10:52:16 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>

Pasi,

Would the following 'tunnel-id' syntax definition cover your concerns?

   tunnel-id      =  DQUOTE 1*(TEXTDATA /("%" 2HEXDIG)) DQUOTE

Thanks,
MS 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Wednesday, January 25, 2006 2:52 AM
> To: [email-masked]
> Subject: Issue 102 in ieee802-01
> 
> Hi,
> 
> It looks like version -01 of the IEEE attributes draft solved 
> my of my comments, but one resolution looks slightly buggy:
> 
> The ABNF includes two different ways to quoting "strange" 
> octets in tunnel-id (backslashes and percent-hex-hex), but 
> the text doesn't quite match the ABNF.
> 
> Also, I think we don't need two different quoting mechanisms; 
> the percent-hex-hex notation makes the backslashes redundant 
> (and is IMHO easier to implement in a way that really works 
> with arbitrary octets, such as LF (the rule delimeter!) and NUL).
> 
> Best regards,
> Pasi
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Tue, 31 Jan 2006 16:47:18 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Issue: Compatibility with RFC 2866 and RFC 3576
Date: Tue, 31 Jan 2006 08:46:48 -0800

Here is a suggested rewrite of the section:

1.4 Attribute Interpretation

   If a NAS conforming to this specification receives an Access-Accept
   packet containing an attribute defined in this document which it
   cannot apply, it MUST act as though it had received an Access-Reject.

   Similarly, [RFC3576] requires that a NAS receiving a  CoA-Request
   containing an unsupported attribute reply with a CoA-NAK.  It
   is recommended that an Error-Cause attribute with value set to
  "Unsupported Attribute" (401) be included in the packet.
   As noted in [RFC3576], authorization changes are atomic so
   that this situation does not result in session termination and the
   pre-existing configuration remains unchanged.  As a result, no
   accounting packets should be generated.

>From: "Bernard Aboba" <[email-masked]>
>To: [email-masked]
>Subject: Issue: Compatibility with RFC 2866 and RFC 3576
>Date: Tue, 31 Jan 2006 07:56:36 -0800
>
>Issue:  Compatibility with RFC 2866 and RFC 3576
>Submitter names: Bernard Aboba
>Submitter email address: [email-masked]
>Date first submitted: January 30, 2006
>Reference:
>Document: IEEE 802-01
>Comment type: Technical
>Priority: S
>Section: 1.4
>Rationale/Explanation of issue:
>
>Section 1.4 states:
>
>   1.4 Attribute Interpretation
>
>      Unless otherwise noted in the individual description of an
>      attribute contained herein, a NAS that conforms to this
>      specification and receives an Access-Accept message that contains
>      an attribute from this document that it cannot apply MUST
>      interpret this though an Access-Reject had been sent and MUST
>      terminate the session.  If accounting is enabled on the NAS, it
>      MUST generate an Accounting-Request(Stop) message upon session
>      termination.
>
>      Similarly, if a NAS conforming to this specification and also
>      conforming to RFC 3576 [RFC3576] receives a CoA message that
>      contains an attribute from this document that it cannot apply, it
>      MUST NOT terminate the session and MUST generate a CoA-NAK packet
>      with ERROR-CAUSE(101) set to "Unsupported Attribute"(401).  If
>      accounting is enabled on the NAS, it MUST NOT generate an
>      Accounting-Request(Stop) message in such instances.
>
>RFC 2866 does not specify the generation of Accounting Stop messages 
>resulting
>from Access-Reject packets.  This document is therefore requiring RADIUS
>accounting clients to generate accounting records in circumstances where
>they would not otherwise do so.  This raises the question of why
>this particular set of attributes would cause a special case modification
>to RFC 2866.
>
>Here is what RFC 3576 has to say about receipt of attributes in a 
>CoA-Request:
>
>   If one or more authorization changes specified in a CoA-Request
>   cannot be carried out, or if one or more attributes or attribute-
>   values is unsupported, a CoA-NAK MUST be sent.
>
>On inclusion of Error-Cause attributes:
>
>      It is possible that the NAS cannot honor Disconnect-Request or
>      CoA-Request messages for some reason.  The Error-Cause Attribute
>      provides more detail on the cause of the problem.  It MAY be
>      included within Disconnect-ACK, Disconnect-NAK and CoA-NAK
>      messages.
>
>Since inclusion of an Error-Cause attribute is generally optional, the
>second paragraph mandates behavior not required by RFC 3576.
>
>
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Tue, 31 Jan 2006 15:56:48 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Issue: Compatibility with RFC 2866 and RFC 3576
Date: Tue, 31 Jan 2006 07:56:36 -0800

Issue:  Compatibility with RFC 2866 and RFC 3576
Submitter names: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: January 30, 2006
Reference:
Document: IEEE 802-01
Comment type: Technical
Priority: S
Section: 1.4
Rationale/Explanation of issue:

Section 1.4 states:

   1.4 Attribute Interpretation

      Unless otherwise noted in the individual description of an
      attribute contained herein, a NAS that conforms to this
      specification and receives an Access-Accept message that contains
      an attribute from this document that it cannot apply MUST
      interpret this though an Access-Reject had been sent and MUST
      terminate the session.  If accounting is enabled on the NAS, it
      MUST generate an Accounting-Request(Stop) message upon session
      termination.

      Similarly, if a NAS conforming to this specification and also
      conforming to RFC 3576 [RFC3576] receives a CoA message that
      contains an attribute from this document that it cannot apply, it
      MUST NOT terminate the session and MUST generate a CoA-NAK packet
      with ERROR-CAUSE(101) set to "Unsupported Attribute"(401).  If
      accounting is enabled on the NAS, it MUST NOT generate an
      Accounting-Request(Stop) message in such instances.

RFC 2866 does not specify the generation of Accounting Stop messages 
resulting
from Access-Reject packets.  This document is therefore requiring RADIUS
accounting clients to generate accounting records in circumstances where
they would not otherwise do so.  This raises the question of why
this particular set of attributes would cause a special case modification
to RFC 2866.

Here is what RFC 3576 has to say about receipt of attributes in a 
CoA-Request:

   If one or more authorization changes specified in a CoA-Request
   cannot be carried out, or if one or more attributes or attribute-
   values is unsupported, a CoA-NAK MUST be sent.

On inclusion of Error-Cause attributes:

      It is possible that the NAS cannot honor Disconnect-Request or
      CoA-Request messages for some reason.  The Error-Cause Attribute
      provides more detail on the cause of the problem.  It MAY be
      included within Disconnect-ACK, Disconnect-NAK and CoA-NAK
      messages.

Since inclusion of an Error-Cause attribute is generally optional, the
second paragraph mandates behavior not required by RFC 3576.

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

Delivery-date: Tue, 31 Jan 2006 15:40:35 +0000
Content-class: urn:content-classes:message
Subject: RE: review of draft-ietf-radext-ieee802-01.txt
Date: Tue, 31 Jan 2006 07:39:23 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>

Sounds good to me...  We'll put it in the next draft.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Tuesday, January 31, 2006 4:39 AM
> To: Congdon, Paul T (ProCurve); [email-masked]
> Subject: RE: review of draft-ietf-radext-ieee802-01.txt
> 
> > Good point.  The redir-cnt approach is somewhat different 
> because it 
> > is set-up at the beginning of the session rather than removing the 
> > redirection explicitly mid-stream.  We should say something about 
> > redir-cnt here though...  How about the followign text?
> > 
> > 
> >  A.2.3  HTTP Redirection Removal
> > 
> >       HTTP Redirection rules can be automatically removed 
> when using 
> > the
> >       redir-cnt parameter or explicitly removed from the RADIUS 
> > server.
> > 
> >       The RADIUS server can explicitly turn HTTP redirection off 
> >       mid-session in two ways. It can push new redirection rules 
> > within a
> >       NAS-Filter-Rule(TBD) attribute using a CoA message or it can 
> > send the
> >       NAS a CoA message requesting it to re-authorize.  
> 
> This is much better. How about mentioning the mid-session for 
> redir-cnt as well? Something like:
> 
>      "HTTP Redirection rules can be automatically removed mid-session
>       from the NAS when using the redir-cnt parameter or explicitly
>       removed from the RADIUS server.
> 
>       ..."
> 
> /Jouni
> 
> > Paul
> 
> 

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

Delivery-date: Tue, 31 Jan 2006 12:40:17 +0000
Content-class: urn:content-classes:message
Subject: RE: review of draft-ietf-radext-ieee802-01.txt
Date: Tue, 31 Jan 2006 13:39:27 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

> Good point.  The redir-cnt approach is somewhat different 
> because it is
> set-up at the beginning of the session rather than removing the
> redirection explicitly mid-stream.  We should say something about
> redir-cnt here though...  How about the followign text?
> 
> 
>  A.2.3  HTTP Redirection Removal
> 
>       HTTP Redirection rules can be automatically removed 
> when using the
>       redir-cnt parameter or explicitly removed from the 
> RADIUS server.
> 
>       The RADIUS server can explicitly turn HTTP redirection off 
>       mid-session in two ways. It can push new redirection 
> rules within
> a
>       NAS-Filter-Rule(TBD) attribute using a CoA message or 
> it can send
> the
>       NAS a CoA message requesting it to re-authorize.  

This is much better. How about mentioning the mid-session for redir-cnt
as well? Something like:

     "HTTP Redirection rules can be automatically removed mid-session
      from the NAS when using the redir-cnt parameter or explicitly
      removed from the RADIUS server.

      ..."

/Jouni

> Paul

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

Delivery-date: Sun, 29 Jan 2006 20:15:32 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Issue: References
Date: Sun, 29 Jan 2006 12:15:27 -0800

Issue : References
Submitter names: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: January 29, 2006
Reference:
Document: IEEE 802-01
Comment type: Editorial
Priority: S
Section: Various
Rationale/Explanation of issue:

It is not clear to me why RFC 2868, 3162, 3576, 3579, 3580, 3748 are listed 
as  Normative References.  For example, an implementer would not be required 
to consult these documents in order to implement the specification.

On the other hand, it seems like RFC 2674 and 3629 are referenced in a 
normative way; for example, if UTF-8 is supported, then an implementer would 
need to consult RFC 3629, no?  The reference to IEEE 802 also seems to be 
normative.

Some of the references do not appear to be referenced in the specification.  
For example, there is no reference to RFC 1321, RFC 2866, RFC 2867, RFC 
3748.

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

Delivery-date: Sun, 29 Jan 2006 20:07:43 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Issue: Allowed Usage
Date: Sun, 29 Jan 2006 12:06:41 -0800

Issue : Allowed Usage
Submitter names: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: January 29, 2006
Reference:
Document: IEEE 802-01
Comment type: 'T'echnical |
Priority: S
Section: Various
Rationale/Explanation of issue:

In Section 4, the Table of Attributes states the following:

      The following table provides a guide to which attributes may be
      found in which kinds of packets, and in what quantity.

      Access- Access- Access- Access-   CoA-
      Request Accept  Reject  Challenge Req  #   Attribute
      0       0+      0       0         0+   TBD Egress-VLANID
      0       0-1     0       0         0-1  TBD Ingress-Filters
      0       0-1     0       0         0-1  TBD User-Priority-Table

The Egress-VLAN-Name attribute is not included in this table, nor is
it included in the IANA considerations section.

Section 2.1:

         Multiple Egress-VLANID attributes can be delivered in an
         authentication response; each attribute adds the specified VLAN
         to the list of allowed egress VLANs for the port.

This would appear to indicate that the Egress-VLAN-Name attribute is
allowed in Access-Challenge, Access-Reject and Access-Accept packets.
Yet, the attribute table in Section 4 does not seem to permit
inclusion in Reject or Challenge packets.

Section 2.3:

         Multiple Egress-VLAN-Name attributes can be delivered in an
         authentication response; each attribute adds the named VLAN to
         the list of allowed egress VLANs for the port.

This would appear to indicate that the Egress-VLAN-Name attribute is
allowed in Access-Challenge, Access-Reject and Access-Accept packets.
There is no entry in the Attribute Table to confirm this.

Section 2.4:

There is no material on permitted usage of the User-Priority-Table 
attribute.

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

Delivery-date: Sun, 29 Jan 2006 07:37:17 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Bernard Aboba <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: A plan for moving forward on the RFC 3576 MIB Documents
Date: Sun, 29 Jan 2006 08:36:03 +0100

If this is all we can find than an RFC-Editor note will work.

Bert

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Bernard Aboba
> Sent: Friday, January 27, 2006 10:27
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: A plan for moving forward on the RFC 3576 MIB Documents
> 
> 
> How about fixing this along with IETF last call comments?
> 
> >From: "Nelson, David" <[email-masked]>
> >To: <[email-masked]>,   "Bernard Aboba" 
> ><[email-masked]>
> >CC: <[email-masked]>
> >Subject: RE: A plan for moving forward on the RFC 3576 MIB Documents
> >Date: Fri, 27 Jan 2006 11:31:25 -0500
> >
> >
> > > The following I-D Nits issues were detected:
> > >
> > > idnits 1.85
> > >
> > > tmp/draft-decnodder-radext-dynauth-server-mib-03.txt:
> >
> >Upon further investigation, it appears that the I-D Nits tool is
> >tripping over the summary Copyright information in the DESCRIPTION
> >clause for the MODULE-IDENTITY.  The copyright date in that text is
> >2005, and should be 2006.  While all I-Ds sent to the IESG 
> for approval
> >are required to pass the I-D Nits tool, maybe we can fix this with a
> >simple RFC Editor note, assuming no other changes are required during
> >IETF Last Call and IESG review.
> >
> >
> >--
> >to unsubscribe send a message to [email-masked] with
> >the word 'unsubscribe' in a single line as the message text body.
> >archive: <http://psg.com/lists/radiusext/>
> 
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Envelope-to: [email-masked]
Delivery-date: Sun, 29 Jan 2006 02:35:39 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Issue: Some possible conflicts between RFC 2865 and RFC 3579 (fwd) 
Date: Sat, 28 Jan 2006 21:41:23 -0500
Message-Id: <[email-masked]>

Antonio Plaza and Alfonso Valero wrote:
> If an Access-Request is received in a RADIUS server with an
> encapsulated EAP-Message, and the shared secret is different in the
> server and the client, according to the section 3.2 in RFC 3579 the
> Access-Request should be silently discarded, because when the
> Message Authenticator is assessed by the RADIUS server it is
> different from the Message-Authenticator of the sent one, as it is
> calculated using the shared-secret as key. However, according to the
> section 4.3 in RFC 2865, the RADIUS server should send an
> Access-Reject because one attribute (Message Authenticator) is not
> acceptable.

  Yes.  There is some apparent inconsistency, doubly so because RFC
2865 is standards track, and RFC 3579 is information.  The security
considerations section of RFC 3579 doesn't highlight this issue, even
though the behavior of the protocol is changed by RFC 2579.

> We think there is some kind of ambiguous behaviour as the figure
> below shows, so, how should the RADIUS server act in this situation,
> the Access-Request should be discarded or an Access-Reject should be
> sent instead?

  (diagram shows client sending EAP-Message & Message-Authenticator,
where client & server have different shared secrets).

  The short answer is that I've never seen this ambiguity be a problem
in real deployments.  The long answer is given below.

  Before discussing recommended behavior, let's list the behavior of
current deployments:

  (1) If the server was written before RFC 3579 was published, it will
send an Access-Reject.  This is consistent with RFC 2865, and does not
cause interoperability problems with RFC 3579.  However, because the
Access-Reject is signed with the shared secret, the client will
silently discard the packet, as per section 4.2 of RFC 2865.

  (2) If the server was written after RFC 3579 was published, then
either it implements Message-Authenticator, or it does not.

    (a) If it doesn't implement Message-Authenticator, then it will
        send an Access-Reject, and the client will not see the EAP
        session proceed past the initial packet.  The Access-Reject
        will be discarded, as outlined above.

    (b) If the server implements Message-Authenticator, then it will
        silently discard the request, and the client will not see a
        reply.

  At no time will the inconsistency between RFC's lead to different
client behavior.  In all cases, the client will not obtain a valid
response from the server.  And this failure to obtain a valid response
is perfectly consistent with RFC 2865.

  The only effect this inconsistency has in real-world deployments is
the following.  When the client receives an Access-Reject with an
incorrect signature, and no valid Access-Accept or Access-Reject, then
the client may assume that the correct server is alive and responding,
but that the shared secret is incorrect.

  If the client receives no Access-Reject (as per RFC 3579), then it
cannot determine if the failure to receive a response is because the
server is down, or because the shared secret is incorrect.

  Finally, what "should" the client do in the situation you point out?
The only possible recommendation is that it should follow RFC 2865.

  Alan DeKok.

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

Delivery-date: Sat, 28 Jan 2006 23:18:51 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Issue: Some possible conflicts between RFC 2865 and RFC 3579 (fwd)
Date: Sat, 28 Jan 2006 15:18:03 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_7e74_166d_3082
Content-Type: text/plain; format=flowed

>-----Original Message-----
>From: Antonio Plaza [mailto:[email-masked]]
>Sent: Fri 1/27/2006 1:07 AM
>Cc: [email-masked]; [email-masked]; [email-masked]; 
>[email-masked]; Bernard Aboba; [email-masked]
>Subject: Some possible conflicts between RFC 2865 and RFC 3579
>
>Dear all,
>
>We are Antonio Plaza and Alfonso Valero from Spain. We are studying EAP 
>protocol over RADIUS protocol (RFC 3579) and we have found some possible 
>conflicts between RFC 2865 and RFC 3579. The details are in the attached 
>document.
>
>Thanks you in advance.
>

------=_NextPart_000_7e74_166d_3082
Content-Type: application/octet-stream; name="contradiction_RFCsv1.0.doc";
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="contradiction_RFCsv1.0.doc";

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB
AAAAJwAAAAAAAAAAEAAAKQAAAAEAAAD+////AAAAACYAAAD/////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////

------=_NextPart_000_7e74_166d_3082--

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

Delivery-date: Sat, 28 Jan 2006 18:57:25 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: review of draft-ietf-radext-ieee802-01.txt
Date: Sat, 28 Jan 2006 10:56:38 -0800

David Nelson writes:

>Given the ongoing work on RADIUS Design Guidelines to encompass additional 
>data types and foster greater compatibility with Diameter AVPs, and the 
>charter of the DIME WG, it is not inconceivable to come up with a single 
>"improved" filter
>rule that would make RADIUS-Diameter attribute translation much easier.
>It would, however, in all likelihood delay this work for many months.
>It seems to me we have to decide which we value more highly: a [more]
>unified data model between RADIUS and Diameter or timely delivery of the 
>802-related extensions in RADIUS.

I'm not sure we have to choose.  We can split the document, removing the 
filter attributes and progressing the rest.  From what I can see, there are 
no open issues relating to the VLAN/Priority attributes, so doing that could 
enable the VLAN/Priority document to be sent to the IESG
for review by IETF 65.

Unless we think that we can resolve the Diameter and Design Guidelines 
issues by the submission deadline for IETF 65, I  don't see what other paths 
are available to completing this milestone in a timely way.

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

Delivery-date: Fri, 27 Jan 2006 19:46:16 +0000
Content-class: urn:content-classes:message
Subject: RE: review of draft-ietf-radext-ieee802-01.txt
Date: Fri, 27 Jan 2006 11:45:43 -0800
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

> And then about the draft..
> 
> >   A.2.3  HTTP Redirection Removal
> >       
> >      The RADIUS serve can turn HTTP redirection off mid-session in
two 
> >      way. It can push new redirection rules within a NAS-Filter-
> >      Rule(TBD) attribute using a CoA message or it can send the NAS
a 
> >      CoA message requesting it to re-authorize.  
> 
> Aren't there three ways? The two as described above and the redir_cnt?
> 

Good point.  The redir-cnt approach is somewhat different because it is
set-up at the beginning of the session rather than removing the
redirection explicitly mid-stream.  We should say something about
redir-cnt here though...  How about the followign text?

 A.2.3  HTTP Redirection Removal

      HTTP Redirection rules can be automatically removed when using the
      redir-cnt parameter or explicitly removed from the RADIUS server.

      The RADIUS server can explicitly turn HTTP redirection off 
      mid-session in two ways. It can push new redirection rules within
a
      NAS-Filter-Rule(TBD) attribute using a CoA message or it can send
the
      NAS a CoA message requesting it to re-authorize.  

Paul

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

Delivery-date: Fri, 27 Jan 2006 18:48:16 +0000
Date: Fri, 27 Jan 2006 20:48:28 +0200
From: Jari Arkko <[email-masked]>
To: "Congdon, Paul T (ProCurve)" <[email-masked]>
CC: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>,  [email-masked]
Subject: Re: review of draft-ietf-radext-ieee802-01.txt

Congdon, Paul T (ProCurve) wrote:

>
>The changes we have made are not simply extensions and the attribute we
>are defining is not purely a superset. 
>
Can you list what the specific differences are?

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

Delivery-date: Fri, 27 Jan 2006 18:26:57 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: A plan for moving forward on the RFC 3576 MIB Documents
Date: Fri, 27 Jan 2006 10:26:47 -0800

How about fixing this along with IETF last call comments?

>From: "Nelson, David" <[email-masked]>
>To: <[email-masked]>,   "Bernard Aboba" 
><[email-masked]>
>CC: <[email-masked]>
>Subject: RE: A plan for moving forward on the RFC 3576 MIB Documents
>Date: Fri, 27 Jan 2006 11:31:25 -0500
>
>
> > The following I-D Nits issues were detected:
> >
> > idnits 1.85
> >
> > tmp/draft-decnodder-radext-dynauth-server-mib-03.txt:
>
>Upon further investigation, it appears that the I-D Nits tool is
>tripping over the summary Copyright information in the DESCRIPTION
>clause for the MODULE-IDENTITY.  The copyright date in that text is
>2005, and should be 2006.  While all I-Ds sent to the IESG for approval
>are required to pass the I-D Nits tool, maybe we can fix this with a
>simple RFC Editor note, assuming no other changes are required during
>IETF Last Call and IESG review.
>
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Fri, 27 Jan 2006 18:22:55 +0000
Content-class: urn:content-classes:message
Subject: RE: review of draft-ietf-radext-ieee802-01.txt
Date: Fri, 27 Jan 2006 13:22:28 -0500
To: <[email-masked]>

Paul Congdon writes...

> I agree with you that we do not want to make this the default behavior
> and we should strive to make consistent extensions.  I think the
> complexity of this attribute didn't allow us to follow that path.

Well, I think that's true in the face of the RADEXT milestones, and the
desire to see this draft advance rapidly.  Given the ongoing work on
RADIUS Design Guidelines to encompass additional data types and foster
greater compatibility with Diameter AVPs, and the charter of the DIME
WG, it is not inconceivable to come up with a single "improved" filter
rule that would make RADIUS-Diameter attribute translation much easier.
It would, however, in all likelihood delay this work for many months.

It seems to me we have to decide which we value more highly: a [more]
unified data model between RADIUS and Diameter or timely delivery of the
802-related extensions in RADIUS.

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

Delivery-date: Fri, 27 Jan 2006 17:06:37 +0000
Content-class: urn:content-classes:message
Subject: RE: review of draft-ietf-radext-ieee802-01.txt
Date: Fri, 27 Jan 2006 09:05:21 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Jari Arkko" <[email-masked]>, "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
Cc: <[email-masked]>

No, it was not you that argued for the new attributed.  Here is what I
remember of the meeting at IETF-64...

The changes we have made are not simply extensions and the attribute we
are defining is not purely a superset.  There is no RADIUS attribute for
this functionality and it has proven very difficult to take Diameter
AVPs and try to move them back into RADIUS (as was seen with
QoS-Filter-Rule) because of issues with data types, field lengths and
other subtle problems.  Also, I remember someone (maybe Glenn?) saying
that there were problems with the current definition of IP-Filter rule
that NAS-Filter-Rule in Diameter is based upon.  Finally, since Diameter
can much more easily support a Radius attribute than the other way
around, we agreed that we should create a new Radius attribute.

I agree with you that we do not want to make this the default behavior
and we should strive to make consistent extensions.  I think the
complexity of this attribute didn't allow us to follow that path.

Paul

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Friday, January 27, 2006 8:57 AM
> To: Sanchez, Mauricio (PNB Roseville)
> Cc: Congdon, Paul T (ProCurve); [email-masked]
> Subject: Re: review of draft-ietf-radext-ieee802-01.txt
> 
> 
> >Yes, this one fell through the cracks.  Are there any suggestions in 
> >terms of names?  How about something like  NAS-Traffic-Rule 
> or perhaps 
> >to reduce confusion possibility drop the 'NAS-' prefix and 
> just call it 
> >'Traffic-Rule'?
> >  
> >
> Before we start inventing new names, do you guys remember why 
> we decided in IETF-64 that the second approach, a different 
> attribute, was the right one? I'm hoping it was not me who 
> argued for that, but can't remember the discussion at all...
> 
> The reason I dislike new attributes because if we do it on 
> every extension, we'll end up with a messy attribute set. 
> From a RADIUS point of view this is a new attribute now, but 
> not from Diameter. What happens when you do the next filter 
> extension -- which IMHO seems likely? Yet another attribute? 
> I hope not.
> 
> --Jari
> 
> 

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

Delivery-date: Fri, 27 Jan 2006 16:56:39 +0000
Date: Fri, 27 Jan 2006 18:56:57 +0200
From: Jari Arkko <[email-masked]>
To: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
CC: "Congdon, Paul T (ProCurve)" <[email-masked]>,  [email-masked]
Subject: Re: review of draft-ietf-radext-ieee802-01.txt

>Yes, this one fell through the cracks.  Are there any suggestions in
>terms of names?  How about something like  NAS-Traffic-Rule or perhaps
>to reduce confusion possibility drop the 'NAS-' prefix and just call it
>'Traffic-Rule'?
>  
>
Before we start inventing new names, do you guys remember
why we decided in IETF-64 that the second approach, a
different attribute, was the right one? I'm hoping it was
not me who argued for that, but can't remember the
discussion at all...

The reason I dislike new attributes because if we
do it on every extension, we'll end up with a messy
attribute set. From a RADIUS point of view this is
a new attribute now, but not from Diameter. What happens
when you do the next filter extension -- which IMHO seems
likely? Yet another attribute? I hope not.

--Jari

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

Delivery-date: Fri, 27 Jan 2006 16:48:14 +0000
Content-class: urn:content-classes:message
Subject: RE: review of draft-ietf-radext-ieee802-01.txt
Date: Fri, 27 Jan 2006 08:48:00 -0800
To: "Congdon, Paul T (ProCurve)" <[email-masked]>, "Jari Arkko" <[email-masked]>, <[email-masked]>

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Congdon, 
> Paul T (ProCurve)
> Sent: Friday, January 27, 2006 5:54 AM
> To: Jari Arkko; [email-masked]
> Subject: RE: review of draft-ietf-radext-ieee802-01.txt
> 
> > Technically, we have two alternatives to get there. The first 
> > alternative is to make NAS-Filter-Rule(R) an extension of 
> > NAS-Filter-Rule(D). Given the same the same attribute name 
> we appear 
> > to intend to do this already... The other approach would be 
> to define 
> > NAS-Filter-Rule-Radius as a new Radius attribute and then allow its 
> > use in Diameter as well.
> > 
> 
> At IETF-64, I believe we agreed to do the latter.  I think 
> this draft was supposed to rename the attribute to make that 
> clear.  Looks like we forgot to do that.

Yes, this one fell through the cracks.  Are there any suggestions in
terms of names?  How about something like  NAS-Traffic-Rule or perhaps
to reduce confusion possibility drop the 'NAS-' prefix and just call it
'Traffic-Rule'?

Cheers,
MS

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

Delivery-date: Fri, 27 Jan 2006 16:31:52 +0000
Content-class: urn:content-classes:message
Subject: RE: A plan for moving forward on the RFC 3576 MIB Documents
Date: Fri, 27 Jan 2006 11:31:25 -0500
To: <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

> The following I-D Nits issues were detected:
> 
> idnits 1.85
> 
> tmp/draft-decnodder-radext-dynauth-server-mib-03.txt:

Upon further investigation, it appears that the I-D Nits tool is
tripping over the summary Copyright information in the DESCRIPTION
clause for the MODULE-IDENTITY.  The copyright date in that text is
2005, and should be 2006.  While all I-Ds sent to the IESG for approval
are required to pass the I-D Nits tool, maybe we can fix this with a
simple RFC Editor note, assuming no other changes are required during
IETF Last Call and IESG review.

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

Delivery-date: Fri, 27 Jan 2006 13:55:18 +0000
Content-class: urn:content-classes:message
Subject: RE: review of draft-ietf-radext-ieee802-01.txt
Date: Fri, 27 Jan 2006 05:54:24 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Jari Arkko" <[email-masked]>, <[email-masked]>

> Technically, we have two alternatives to get there. The first 
> alternative is to make NAS-Filter-Rule(R) an extension of 
> NAS-Filter-Rule(D). Given the same the same attribute name we 
> appear to intend to do this already... The other approach 
> would be to define NAS-Filter-Rule-Radius as a new Radius 
> attribute and then allow its use in Diameter as well.
> 

At IETF-64, I believe we agreed to do the latter.  I think this draft
was supposed to rename the attribute to make that clear.  Looks like we
forgot to do that.

Paul

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

Delivery-date: Fri, 27 Jan 2006 12:57:44 +0000
Content-class: urn:content-classes:message
Subject: RE: review of draft-ietf-radext-ieee802-01.txt
Date: Fri, 27 Jan 2006 13:57:27 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi,

I got few comments and additions to Jari's review.

>> This is OK, but the document is silent on what effect this
>> has in Diameter. These effects are important because, for
>> instance, 3GPP wireless LAN interworking is based on running
>> Diameter on the 3GPP operator side and RADIUS in the access network

Actually, RADIUS is now allowed end to end. So all possible combinations
exists (RADIUS or Diameter on AN, and RADIUS or Diameter on operator
size).

And then about the draft..

>   A.2.3  HTTP Redirection Removal 
>       
>      The RADIUS serve can turn HTTP redirection off mid-session in two

>      way. It can push new redirection rules within a NAS-Filter-
>      Rule(TBD) attribute using a CoA message or it can send the NAS a 
>      CoA message requesting it to re-authorize.  

Aren't there three ways? The two as described above and the redir_cnt?

Editorials:

A.2.3  HTTP Redirection Removal 

 "The RADIUS serve can" -> "The RADIUS server can"

Cheers,
	Jouni

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

Delivery-date: Fri, 27 Jan 2006 12:14:55 +0000
Date: Fri, 27 Jan 2006 14:14:53 +0200
From: Jari Arkko <[email-masked]>
To:  [email-masked]
Subject: review of draft-ietf-radext-ieee802-01.txt

I reviewed this draft. Overall, this draft is in good
shape, but some minor mistakes and question
marks are noted below. In addition, the document
is silent on the use of these attributes in Diameter,
which needs further work.

The title should probably mention redirection, too.

Is this for informational or standards track? In some
sense the latter would make more sense, as this is
an important functionality that many people will need.

Technical:

>         org-url        =  http_URL  
>                           ;Note: Syntax for http_URL defined in  
>                           ;[RFC2616], section 3.2.2 
>         redir-url      =  http_URL 
>  
>
s/_/-/g

And please run ABNF checker from tools.ietf.org:

l2-filter-body = ( l2-proto " from " l2-address " to " l2-address ) / l2-rmon-str
*; HEXDIG UNDEFINED*
l2-proto = "l2:ether2" [ ":0x" 1*4HEXDIG ]
*; DIGIT UNDEFINED*

l2-rmon-str = "l2:" 1*DIGIT *( "." 1*DIGIT )

*; DQUOTE UNDEFINED*
tunnel-id = DQUOTE *( TEXTDATA / ( "%" 2HEXDIG ) / ( "\" 1*( "\" ) *1*"\"* ) / ( "\" DQUOTE ) ) DQUOTE
log-rule = "cnt"
*; LF UNDEFINED*
rule-delim = LF****

**

I think it would be preferrable to employ a full BNF (with
the exception of http-url), i.e., define these four items, too.

>   5.  IANA Considerations 
>
Do you want to say something about allocation policy
on new enumerated values?

>   2.5.  NAS-Filter-Rule 
>
This is quite complicated. Do we have implementation
experience that this works and is well defined?

>      The security mechanisms in [RFC2865] and [RFC3576] are primarily 
>      concerned with an outside attacker who modifies messages in 
>      transit or inserts new messages. They do not prevent an authorized 
>      RADIUS server or proxy from inserting attributes with a malicious 
>      purpose in message it sends. 
>  
>
Or deleting, for that matter...

> The 
>      filtering attributes specified in this document enable explicit 
>      description of layer 2 and layer 3 filters as well as redirection, 
>      and therefore extend the filter language described in [RFC3588]. 
>
This is OK, but the document is silent on what effect this
has in Diameter. These effects are important because, for
instance, 3GPP wireless LAN interworking is based on running
Diameter on the 3GPP operator side and RADIUS in the access network
side. Also, the RADEXT charter says: "All RADIUS work MUST be
compatible with equivalent facilities in Diameter. Where possible,
new attributes should be defined so that the same attribute can
be used in both RADIUS and Diameter without translation. In
other cases a translation considerations section should be included
in the specification."

Technically, we have two alternatives to get there. The first
alternative is to make NAS-Filter-Rule(R) an extension of
NAS-Filter-Rule(D). Given the same the same attribute
name we appear to intend to do this already... The other
approach would be to define NAS-Filter-Rule-Radius as a
new Radius attribute and then allow its use in Diameter as
well.

I prefer the former approach. This is because I'd hate to see
incremental improvements in various things such as filters
always re-create new attributes upon every modification.
But we still need language in this draft to explain the
situation. And does that mean this document "updates RFC
3588 and 4005"?

Editorial:

>      In this document when we refer to Blocking of IP traffic we mean 
>      Filtering of IP traffic.
>
Not sure if Capitalization is Needed.

>       0                   1                   2                   3 
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>      |     Type      |    Length     |  Tag Option   |   Pad (12-bit)          
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>        Pad   |    VLANID (12-bit)    |  
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> 
>      Type 
>    
>         TBD 
>    
>      Length 
>    
>         6    
>    
>      Integer 
>    
>
The picture and text do not match. Show two pictures:
one with "Integer" and then another one with the
detailed substructure.

>         "l2:"       Prefix on any base encapsulation rule to designate 
>                     as rule as such. 
>  
>
"a rule as such"?

> TODO / TBD

Two different placeholders are used. Just use TBD, or better yet,
TBD-by-IANA so that they can better search for these.

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

Delivery-date: Fri, 27 Jan 2006 00:30:26 +0000
Content-class: urn:content-classes:message
Subject: RE: Status of RADEXT Issues 115 and 116
Date: Thu, 26 Jan 2006 19:29:57 -0500
To: "Sanchez, Mauricio \(PNB Roseville\)" <[email-masked]>, <[email-masked]>

> Yes, this is know.  On 1/10/06 I wrote in response to your issue:

> "[ms] This sentence comes by way of the IPFilterRule description found
> in Diameter [RFC3588].  What would you suggest we do for RADIUS? Is
> terminal not a globally known term in RADIUS, if not, is there any?
> Perhaps can you suggest a definition to add to the terminology section.
> "

> I await your response.
 
Ah.  Brain fade...

Terminal may have been a well understood term in the days when RADIUS was just for Terminal Servers.  I would recommend either substituting another term in the text, or creating a definition in the Terminology section.   Perhaps "network device attached to the NAS port".  You might also mention (in a definition) that "terminal" often means the "IEEE 802.1X Supplicant".

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

Delivery-date: Thu, 26 Jan 2006 23:30:14 +0000
Content-class: urn:content-classes:message
Subject: RE: Status of RADEXT Issues 115 and 116
Date: Thu, 26 Jan 2006 15:29:16 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Dave scribbled... 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Thursday, January 26, 2006 2:18 PM
> To: [email-masked]
> Subject: Status of RADEXT Issues 115 and 116
> 
> All the items included in RADEXT Issues 115 and 116 have been 
> resolved in the draft-ietf-radext-ieee802-01.txt revision, 
> with the exception of:
> 
>     The term "terminal" is not defined in the draft. I suspect
>     it identifies the network entity which contains the IEEE 
>     802.1X Supplicant function, but this should perhaps be 
>     clarified.
> 
> This issue still exists in the -01 draft, in Section 2.5.

Yes, this is know.  On 1/10/06 I wrote in response to your issue: 

"[ms] This sentence comes by way of the IPFilterRule description found
in Diameter [RFC3588].  What would you suggest we do for RADIUS? Is
terminal not a globally known term in RADIUS, if not, is there any?
Perhaps can you suggest a definition to add to the terminology section.
"

I await your response.

Cheers,
MS

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

Delivery-date: Thu, 26 Jan 2006 23:09:35 +0000
Content-class: urn:content-classes:message
Subject: RE: A plan for moving forward on the RFC 3576 MIB Documents
Date: Thu, 26 Jan 2006 18:09:18 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

The following I-D Nits issues were detected:

idnits 1.85 

tmp/draft-decnodder-radext-dynauth-server-mib-03.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
    
    Checking conformance with RFC 3978/3979 boilerplate...

  * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
    Acknowledgement. 

    RFC 3978 Section 5.1 text:
    "By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79."

  * The document seems to lack an RFC 3978 Section 5.4 Copyright Line --
    however, there's a paragraph with a matching beginning. Boilerplate
error?

    RFC 3978 Section 5.4 paragraph 1 text:
    "Copyright (C) The Internet Society (2006)."
  
    ... text found in draft:
    "Copyright (C) The Internet Society (2005).  This document is
subject
............................................^
    to the rights, licenses and restrictions contained in BCP 78, and
    except as set forth therein, the authors retain all their rights.")

  * The document seems to lack an RFC 3978 Section 5.4 Reference to BCP
78. 

    RFC 3978 Section 5.4 paragraph 2 text:
    "This document is subject to the rights, licenses and restrictions
    contained in BCP 78, and except as set forth therein, the authors
    retain all their rights."

  * The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
    instead of verbatim RFC 3978 boilerplate.  After 6 May 2005,
submission of
    drafts without verbatim RFC 3978 boilerplate is not accepted.

    The following non-3978 patterns matched text found in the document. 
    That text should be removed or replaced:

    "This document is an Internet-Draft and is subject to all provisions
    of [Ss]ection 3 of [RFC.3667]."

    "By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with [Ss]ection 6 of BCP 79."

  Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt:
    Nothing found here (but these checks do not cover all of
    1id-guidelines.txt yet).

  Miscellaneous warnings:
    None.

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

Delivery-date: Thu, 26 Jan 2006 22:17:58 +0000
Content-class: urn:content-classes:message
Subject: Status of RADEXT Issues 115 and 116
Date: Thu, 26 Jan 2006 17:17:31 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

All the items included in RADEXT Issues 115 and 116 have been resolved
in the draft-ietf-radext-ieee802-01.txt revision, with the exception of:

    The term "terminal" is not defined in the draft. I suspect
    it identifies the network entity which contains the IEEE 
    802.1X Supplicant function, but this should perhaps be 
    clarified.

This issue still exists in the -01 draft, in Section 2.5.

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

Delivery-date: Thu, 26 Jan 2006 20:50:50 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc2620bis-02.txt 
Date: Thu, 26 Jan 2006 15:50: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 Acct Client MIB (IPv6)
	Author(s)	: D. Nelson
	Filename	: draft-ietf-radext-rfc2620bis-02.txt
	Pages		: 22
	Date		: 2006-1-26
	
This memo defines a set of extensions which instrument RADIUS
   accounting client functions.  These extensions represent a portion of
   the Management Information Base (MIB) for use with network management
   protocols in the Internet community.  Using these extensions IP-based
   management stations can manage RADIUS accounting clients.

   This memo obsoletes RFC 2620 by deprecating the MIB table containing
   IPv4-only address formats and defining a new table to add support for
   version neutral IP address formats.  The remaining MIB objects from
   RFC 2620 are carried forward into this document.  This memo also adds
   UNITS and REFERENCE clauses to selected objects.

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

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Thu, 26 Jan 2006 20:50:39 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc2621bis-02.txt 
Date: Thu, 26 Jan 2006 15:50: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 Acct Server MIB (IPv6)
	Author(s)	: D. Nelson
	Filename	: draft-ietf-radext-rfc2621bis-02.txt
	Pages		: 24
	Date		: 2006-1-26
	
This memo defines a set of extensions which instrument RADIUS
   accounting server functions.  These extensions represent a portion of
   the Management Information Base (MIB) for use with network management
   protocols in the Internet community.  Using these extensions IP-based
   management stations can manage RADIUS accounting servers.

   This memo obsoletes RFC 2621 by deprecating the MIB table containing
   IPv4-only address formats and defining a new table to add support for
   version neutral IP address formats.  The remaining MIB objects from
   RFC 2621 are carried forward into this document.  This memo also adds
   UNITS and REFERENCE clauses to selected objects.

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

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Thu, 26 Jan 2006 16:06:47 +0000
Content-class: urn:content-classes:message
Subject: RE: Request for review
Date: Thu, 26 Jan 2006 11:06:20 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...
 
> A new version of the RADIUS location draft has been posted to the
Internet
> Drafts archive:
>
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-05.txt

I'm not sure this document has been submitted to the ID archive as of
this writing.  The e-mail you saw was probably the preview copy which
solicited comments from the authors prior to submission, and CC'ed the
RADEXT chairs as a courtesy.

It should be appearing shortly, however.

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

Delivery-date: Thu, 26 Jan 2006 13:21:25 +0000
Content-class: urn:content-classes:message
Subject: RE: Request for review
Date: Thu, 26 Jan 2006 15:20:38 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Bernard,

What is the status of this draft, has it been Last Called yet?

John 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Bernard Aboba
>Sent: 26 January, 2006 06:52
>To: [email-masked]
>Subject: Request for review
>
>A new version of the RADIUS location draft has been posted to 
>the Internet Drafts archive:
>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-05.txt
>
>Please review this document and post comments to the GEOPRIV 
>(and RADEXT) WG mailing lists.
>
>In particular, please review conformance to the framework 
>posted by Emile in this message to the list:
>http://ops.ietf.org/lists/radiusext/2006/msg00028.html
>
>FYI, the GEOPRIV WG issue tracker for this document is located at:
>http://www.tschofenig.com:8080/radius-geopriv/
>
>
>
>--
>to unsubscribe send a message to 
>[email-masked] with the word 'unsubscribe' in 
>a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>
>

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

Delivery-date: Thu, 26 Jan 2006 04:52:37 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Request for review
Date: Wed, 25 Jan 2006 20:51:57 -0800

A new version of the RADIUS location draft has been posted to the Internet 
Drafts archive:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-05.txt

Please review this document and post comments to the GEOPRIV (and RADEXT) WG 
mailing lists.

In particular, please review conformance to the framework posted by Emile in 
this message to the list:
http://ops.ietf.org/lists/radiusext/2006/msg00028.html

FYI, the GEOPRIV WG issue tracker for this document is located at:
http://www.tschofenig.com:8080/radius-geopriv/

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

Delivery-date: Wed, 25 Jan 2006 22:49:23 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Last look at RFC 2620bis and RFC 2621bis
Date: Wed, 25 Jan 2006 14:48:57 -0800

New versions of RFC 2620bis and 26821bis have been posted to the archive:

http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-02.txt

Please review these documents for resolution of the RADEXT WG last call 
issues and post comments to the RADEXT WG mailing list by Monday, February 
6, 2006.  These documents are being considered for publication as 
Informational RFCs.

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

Delivery-date: Wed, 25 Jan 2006 21:39:14 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: IETF 65 Deadlines
Date: Wed, 25 Jan 2006 13:38:41 -0800

January 16, Monday - Working Group and BOF scheduling begins
February 13, Monday - Cutoff date for requests to schedule Working Group
and BOF meetings at 17:00 ET (22:00 GMT)
February 17, Friday - Preliminary agenda published for comment
February 20, Monday - Working Group Chair approval for initial document
(Version -00) submissions appreciated by 09:00 ET (14:00 GMT)
February 22, Wednesday - Cutoff date for requests to reschedule Working
Group and BOF meetings 09:00 ET (14:00 GMT)
February 27, Monday - Final Working Group and BOF agenda to be published
February 27, Monday - Internet Draft Cut-off for initial document (-00)
submission by 09:00 ET (14:00 GMT)
March 6, Monday - Internet Draft final submission cut-off by 09:00 ET
(14:00 GMT)
March 8, Wednesday - Pre-Registration and Pre-payment cut-off at 12:00
noon ET (17:00 GMT)
March 13, Monday - Working Group agendas due date by 12:00 ET (17:00
GMT), upload using IETF Meeting Materials Management Tool
March 13, Monday - Registration cancellation cut-off at 17:00 ET (22:00 GMT)
March 19-24, 2006 - 65th IETF Meeting in Dallas, TX, USA

** Times are in US Eastern Time and GMT **

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

Delivery-date: Wed, 25 Jan 2006 11:42:51 +0000
Content-class: urn:content-classes:message
Subject: Diameter interop update
Date: Wed, 25 Jan 2006 13:41:41 +0200
From: <[email-masked]>
To: <[email-masked]>

(BCC:ed to RADext, AAA mailing lists and a few indivituals).

Hi all,

I've gotten a large number of responses - about 18 - for an interop, so
it looks like it's a go!

Ulticom is happy to sponser the interop event, in Mt. Laurel, NJ - which
is close to Philadelphia.  The current plan is to hold the event
starting on Monday April 24th.  This is due to the availability of the
testing facilities.  If this week is a problem for some of you, please
let me know immediately. I'm working with Ulticom on setting up a
registration page, so they can figure out how much space is needed.

Protocols that people have shown interest are:

 Diameter Base		
 Diameter Credit Control	
 Diameter SIP		
 3GPP interfaces (Cx)	
 Diameter EAP		
 Diameter NASREQ		
 Diameter MIP		

What is needed is a test plan, test cases.  A couple of you indicated
that you'd be interested in preparing this, so I think the best way to
do this would be do document them in an Internet Draft and submit them
before the draft cut-off date. As I guide, I'm looking at these pages,
from a past interop event:
http://standards.ericsson.net/diameter-bake-off/

I'd strongly suggest that all interested parties subscribe to the
Diameter Maintanence and Extentions WG mailing list, for discussions.

thanks,
John

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

Delivery-date: Wed, 25 Jan 2006 10:53:17 +0000
Content-class: urn:content-classes:message
Subject: Issue 102 in ieee802-01
Date: Wed, 25 Jan 2006 12:51:40 +0200
From: <[email-masked]>
To: <[email-masked]>

Hi,

It looks like version -01 of the IEEE attributes draft
solved my of my comments, but one resolution looks
slightly buggy:

The ABNF includes two different ways to quoting "strange" 
octets in tunnel-id (backslashes and percent-hex-hex),
but the text doesn't quite match the ABNF.

Also, I think we don't need two different quoting 
mechanisms; the percent-hex-hex notation makes the 
backslashes redundant (and is IMHO easier to implement
in a way that really works with arbitrary octets,
such as LF (the rule delimeter!) and NUL).

Best regards,
Pasi

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

Delivery-date: Mon, 23 Jan 2006 23:51:00 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc2619bis-02.txt 
Date: Mon, 23 Jan 2006 18:50: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 Auth Server MIB (IPv6)
	Author(s)	: D. Nelson
	Filename	: draft-ietf-radext-rfc2619bis-02.txt
	Pages		: 25
	Date		: 2006-1-23
	
This memo defines a set of extensions which instrument RADIUS
   authentication server functions.  These extensions represent a
   portion of the Management Information Base (MIB) for use with network
   management protocols in the Internet community.  Using these
   extensions IP-based management stations can manage RADIUS
   authentication servers.

   This memo obsoletes RFC 2619 by deprecating the MIB table containing
   IPv4-only address formats and defining a new table to add support for
   version neutral IP address formats.  The remaining MIB objects from
   RFC 2619 are carried forward into this document.  This memo also adds
   UNITS and Reference clauses to selected objects.

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

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Mon, 23 Jan 2006 23:50:53 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc2618bis-02.txt 
Date: Mon, 23 Jan 2006 18:50: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 Auth Client MIB (IPv6)
	Author(s)	: D. Nelson
	Filename	: draft-ietf-radext-rfc2618bis-02.txt
	Pages		: 23
	Date		: 2006-1-23
	
This memo defines a set of extensions which instrument RADIUS
   authentication client functions.  These extensions represent a
   portion of the Management Information Base (MIB) for use with network
   management protocols in the Internet community.  Using these
   extensions IP-based management stations can manage RADIUS
   authentication clients.

   This memo obsoletes RFC 2618 by deprecating the MIB table containing
   IPv4-only address formats and defining a new table to add support for
   version neutral IP address formats.  The remaining MIB objects from
   RFC 2618 are carried forward into this document.  The memo also adds
   UNITS and REFERENCE clauses to selected objects.

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

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Mon, 23 Jan 2006 15:56:23 +0000
Content-class: urn:content-classes:message
Subject: RE: Last Look at RFC 2618bis, 2619bis
Date: Mon, 23 Jan 2006 10:55:49 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> New versions of RFC 2618bis and 26819bis have been posted to the
archive:
> 
>
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-02.txt
>
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619bis-02.txt
> 
> Please review these documents for resolution of the RADEXT WG last
call
> issues and post comments to the RADEXT WG mailing list by Monday,
January
> 30, 2006.

Please note that Issue 146 (incorrect counter arithmetic) has not been
addressed.  The WG discussion of this issue did not yield a consensus
that I could detect.  Additionally, since this issue exists in widely
deployed MIBs, it may be better to deal this Issue 146 in the RADIUS
Issues and Fixes Draft.

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

Delivery-date: Sun, 22 Jan 2006 22:02:02 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: issue 163: Vendor-Specific Attribute with "Authorize-Only"  Service-Type
Date: Sun, 22 Jan 2006 14:01:45 -0800

The permitted attributes in a Disconnect-Request parallels the attributes 
permitted in a RADIUS Access-Reject to some extent.  The Disconnect-Request 
only includes session identification attributes since the goal is not to 
change the authorizations, but to terminate the user.  Therefore the only 
attributes needed are those that are used for user-identification.

RFC 2865 only enables Reply-Message and Proxy-State attributes in an 
Access-Reject;  Vendor-Specific attributes are prohibited.  RFC 2869 enables 
inclusion of Password-Retry, EAP-Message and Message-Authenticator 
attributes.  RFC 3579 enables inclusion of an Error-Cause attribute within 
an Access-Reject.  RFC 2868 and 3162 do not enable use of the attributes 
defined there within an Access-Reject.

So my take is that the omission of vendor-specific attributes from  a RFC 
3576 Disconnect-Request is intentional.

Of course, this begs the question of why a Service-Type value of "Authorize 
Only" is being used with a Disconnect-Request in the first place.  RFC 3576 
is in error in stating that this is useful for Diameter interoperability;  
in fact, Diameter disconnect requests are handled via request/response, not 
via generation of another Access-Request.

=============================Issue 163: Vendor-Specific Attribute with "Authorize-Only" Service-Type
Submitter names: Steven Xu
Submitter email address: [email-masked]
Date first submitted: January 20, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00034.html
Document: FIXES-01
Comment type: 'T'echnical |
Priority: S
Section: Various
Rationale/Explanation of issue:

I am looking for a clarification on "Vendor-Specific" attribute in 
Disconnect-Request when it is used for "Authorize Only".
 
In RFC3576 section 3.2, there is no Note for "Vendor-Specific" in Disconnect 
Request. (There is Note 3 for the COA). So when the Service-Type is 
"Authorize Only" in Disconnect-Request, can it have the Vendor-Specific 
attribute? The Note 3 says NO, but it is not added for DM.

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

Delivery-date: Sun, 22 Jan 2006 21:44:19 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Issue 161: Authorize-Only Service-Type
Date: Sun, 22 Jan 2006 13:43:56 -0800

RFC 3576 Section 4 allocates the "Authorize-Only" Service-Type value.

My take is that a State attribute is permited in a CoA/Disconnect-Request 
with Service-Type=Authorize-Only", and in fact RFC 2865 Section 4.1 suggests 
that it is required:

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

The RFC 3576 "Authorize-Only" Service-Type was originally created for the 
purpose of Diameter compatibility. However, Diameter compatibility issues 
only arise with the CoA-Request, and never with the Disconnect-Request.  
This is because a Disconnect-Request can always be handled as a single 
request/response sequence either in Diameter or RADIUS so it should never be 
necessary to include a Service-Type="Authorize-Only" within a 
Disconnect-Request.

Since a Diameter disconnect request will always generate an immediate 
response, and never another access request, including 
Service-Type="Authorize-Only" in a RADIUS Disconnect-Request can cause 
problems with Diameter compatibility, rather than enhancing it.

There are situations in which include a Service-Type="Authorize-Only" 
attribute in a RADIUS CoA-Request makes sense.  This can happen in 
situations where it is necessary to change an attribute which could 
potentially be interpretted as a session identification attribute.  This is 
the "semantic ambiguity" problem described in RFC 3576.  There are also 
situations in which this is needed for Diameter compatibility. For example, 
if there is a RADIUS client/NAS interacting with a Diameter Server, then it 
is possible that a Diameter change-of-authorization request will not be 
easily translatable to a standard RADIUS CoA-Request without use of 
Service-Type="Authorize-Only".

A number of issues can arise with respect to processing of an 
"Authorize-Only" Disconnect or CoA-Request:

a. Which RADIUS server to respond to.  While the CoA-NAK needs to be sent to 
the entity that sent the CoA-Request, it is not entirely clear who the 
Access-Request is to be sent to.  A RADIUS client is typically configured 
with one or more RADIUS servers, but the CoA-Request might have been sent by 
a different entity.  As a result, it is possible that the Access-Request 
will go to a different server than the one that sent the CoA-Request.

b. Security problems.  The RFC 2865 Section 4.1 text suggests that RADIUS 
requires Access-Request messages to contain either an authentication 
attribute or a state attribute.  Since "Authorize-Only" messages do not 
contain an authentication attribute, the only alternative is to include a 
State attribute, which presumably needs to be obtained from the CoA or 
Disconnect-Request.  This is why I believe that the State attribute needs to 
be allowed; there may even by RADIUS servers that will reject the 
Access-Request unless it is included.

However,  since the State attribute typically can only be interpretted 
locally, it may not be interprettable by a server other than the one that 
originated the CoA or Disconnect-Request, so if the Access-Request goes to a 
different server interoperability problems can result.

Therefore while there is no RFC 3576 requirement that the same process 
generating the Disconnect or CoA-NAK also generate the Access-Request, this 
might in fact be a good idea, since it could help guarantee that the 
Access-Request goes back to the same entity that sent the 
CoA/Disconnect-Request.

==============================
Issue 161: Authorize-Only Service-Type
Submitter name: Joe Urbasik
Submitter email address: [email-masked]
Date first submitted: January 12, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00030.html
Document: FIXES-01
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

I am looking at implementing a server for the protocol in RFC 3576, and I
have a few questions regarding the "Authorize-only" Service-type.

I have looked through the archives for this list, and have also browsed RFC
2865 and 4005, in trying to find answers.

RFC 3576 requires a conforming implementation to respond to a DM or CoA
request with Service-type Authoize-only with a NAK to the Initial Request,
followed by a RADIUS Access-request. I understand from the description in
RFC 3576 that this Access-request is meant to trigger a "reauthorization".

I am trying to understand this part of the protocol, in the case where the
Initial request is generated from a Radius server, as opposed to a
Radius/Diameter gateway.

I have these two general questions:

1a. What is the usage scenario for this feature, from a network management
perspective ?

I know the RFC says that "This enables a usage model akin to that supported
in Diameter, thus easing translation between the two protocols". but I am
not so familiar with Diameter, and I do not understand what the need is for
this feature - is this strictly for forward compatibility with Diameter ?

1b. What is the usage scenario, with radius servers ? (This may be the same
question from another perspective, but in case it isn't) :

>From the point of view of someone wanting to enhance a radius server, what
is the need or attraction for implementing/issuing the "Authorize-only"
requests within this protocol ?

2. The RFC states that the Radius Access-request is to be sent by the
RFC3576 Server. Implicit in this is that the RFC3576 server will get a
response - is it expected to act on that response message ?

Can the sending of the Access Request be performed by a different server
process, or must the Request come from the same process (or port) that
received the initial Authorize-only request, and that issued the NAK ? In
other words, is the Radius Server maintaining some sort of state between the
two messages ?

I also have 2 specific technical questions

1. I have assumed that the values for the Attributes are to be taken from
RFC 2865, yet in that RFC, "Service-type" has defined the value
"Authenticate-only", not "Authorize-only"

2. Regarding permitted attributes, the paragraph at the top of page 13 says:

   Where a Service-Type Attribute with value "Authorize Only" is
   included within a CoA-Request or Disconnect-Request, attributes
   representing an authorization change MUST NOT be included; only
   identification attributes are permitted.  If attributes other than
   NAS or session identification attributes are included in such a CoA-
   Request, implementations MUST send a CoA-NAK;

My interpretation of this statement is that only the (3) "NAS identification
attributes" and (12) "Session identification attributes", as listed at the
start of section 3, MAY be in the message. However that interpretation
excludes Service-type (trivial) and State (less trivial - see [Note 7] ).

Have I misinterpreted the paragraph, or are those actually the exceptions ?

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

Delivery-date: Sun, 22 Jan 2006 20:44:05 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Last Look at RFC 2618bis, 2619bis
Date: Sun, 22 Jan 2006 12:43:19 -0800

New versions of RFC 2618bis and 26819bis have been posted to the archive:

http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619bis-02.txt

Please review these documents for resolution of the RADEXT WG last call 
issues and post comments to the RADEXT WG mailing list by Monday, January 
30, 2006.

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

Delivery-date: Fri, 20 Jan 2006 15:36:29 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: digest-auth, nonce replay issue
Date: Fri, 20 Jan 2006 16:36:04 +0100

During the IESG review Glen Zorn pointed out, that the draft allows a nonce
replay attack as the RADIUS server can't tell how old a nonce is.

So I've added some sentence like 'the nonce MUST contain some kind of timestamp'.
Just before submitting -07, it dawned to me that this is not sufficient.

In scenario 1, the RADIUS client communicates the nonce to the RADIUS server.
As generator and consumer of the nonce are not the same system, we need to define
a nonce format. RfC 2617 proposes

time-stamp H(time-stamp ":" ETag ":" private-key)

This is fine, but many HTTP-style messages don't have an ETag header. Even if there
is one, the RADIUS server can't check it as there is no RADIUS attribute for ETag.
We might structure the nonce mentally in two parts:

nonce = concat(time-stamp, H(time-stamp ":" private-key), second-part)

time-stamp = minutes since Epoch in hexadecimal, padded to 8 digits
second-part = arbitrary data that might be interpreted by the nonce generator to check the authencity
              of the nonce.

One could argue that private-key is useless as Glen's attack requires that the attacker
has full access to the RADIUS client.

Is the granularity of minutes sufficient?

Wolfgang

--
T-Systems International GmbH
Technologiezentrum
Next Generation IP Services and Systems
+49 6151 9372863
Am Kavalleriesand 3
64295 Darmstadt

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

Delivery-date: Fri, 20 Jan 2006 10:14:57 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked]
Subject: FW: Looking for candidates for (co-)chairing the (new) DIME WG
Date: Fri, 20 Jan 2006 11:14:17 +0100

RADEXT WG members,
David Kessens (your primary AD) suggested that I also post this
email to this list since there might be potential candidates here.

So here it is.

Bert

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Wijnen, Bert (Bert)
Sent: Monday, January 16, 2006 12:04
To: Aaa-Wg (E-mail); [email-masked]; [email-masked]
Cc: David Kessens (E-mail)
Subject: Looking for candidates for (co-)chairing the (new) DIME WG

[posted to AAA, DIME and NSIS mailing lists since we expect that
 those mailing lists have the most relevant participants.]

All,

The new DIME WG (see charter at the bottom) has been approved by 
the IESG. The actual instantiation of the WG is pending the appointment
of WG chair(s). 

The ADs have decided to write down a brief profile for the WG chair(s).
We would like you to consider this profile and either nominate yourself 
or other people that you think that would fit well in this role by 
sending mail to the OPS ADs.
(<[email-masked]> and <[email-masked]>).

We do not intend to disclose the names of the nominees in public,
but we will probably sollicit for feedback with various other
people. If you have a problem with your name being mentioned
in this context, pls let us know.

Note that this profile is written for a somewhat ideal candidate. We
fully realize that such people are probably non-existent, so don't
hesitate to nominate somebody who in your opinion would fit this role
quite well but doesn't fit this profile 100%. And the intend is to
select two co-chairs that can complement each other and work together.

As for the profile:
 
- Good management and process skills, including but not limited to
  choosing and supervising editors, commitment and followthrough on
  the charter, active management of the working group discussions,
  and handling IETF process steps in prompt fashion.
- Good basic knowledge of the AAA protocols. That not only includes
  Diameter, but also Radius. 
- Understanding of the requirements/needs/applications of AAA protocols.
  Specifically, understanding the needs of other organizations (like 3GPP)
  is a useful asset.
- Operational background/experience is very desirable.
- Enough available time. For example, preferable not more than one
  other working chair role in IETF.
- There is no requirement that the candidate has been an IETF working
  group chair before, but it helps if there is some evidence that the
  candidate can fullfill such a role (eg. other management role in
  other places than IETF etc.)

We would like to receive your comments & nominations by Jan 30th 2006
and we plan to make a decision as soon as possible thereafter.
It will be helpful if you indicate in your nomination mail how
you or the nominated candidate fits this profile as best as possible.
 
And last but not least, we would like to thank John Loughney for 
leading/guiding the work to develop the DIME WG charter. He also
started a new mailing list: [email-masked]
 
David Kessens & Bert Wijnen

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

Delivery-date: Fri, 20 Jan 2006 03:27:17 +0000
Content-class: urn:content-classes:message
Subject: Clarification on "Vendor-Specific" in DM with "Authorize Only" 
Date: Fri, 20 Jan 2006 11:26:18 +0800
From: "Xu Steven-A13977" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C61D71.479B8F2E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi, all,
 
(Please forgive me if this has been discussed before.)
 
I am looking for a clarification on "Vendor-Specific" attribute in
Disconnect-Request when it is used for "Authorize Only".
 
In RFC3576 section 3.2, there is no Note for "Vendor-Specific" in
Disconnect Request. (There is Note 3 for the COA). So when the
Service-Type is "Authorize Only" in Disconnect-Request, can it have the
Vendor-Specific attribute? The Note 3 says NO, but it is not added for
DM. I appreciate for any response!

Regards 
Steven 

------------------------------------------------ 
POPI Classifications 
Motorola Confidential Proprietary  (   ) 
Motorola Internal Use Only         (  ) 
General Business Information       ( X ) 

------_=_NextPart_001_01C61D71.479B8F2E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2800.1528" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=549021603-20012006>Hi, 
all,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=549021603-20012006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=549021603-20012006>(Please forgive me 
if this has been discussed before.)</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=549021603-20012006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=549021603-20012006>I am looking for a 
clarification on "Vendor-Specific" attribute in Disconnect-Request when it is 
used for&nbsp;"Authorize Only".</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=549021603-20012006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=549021603-20012006>In RFC3576 section 
3.2, there is no Note for "Vendor-Specific" in Disconnect Request. (There is 
Note 3 for the COA). So when the Service-Type is "Authorize Only" in 
Disconnect-Request, can it&nbsp;have the Vendor-Specific attribute? The Note 3 
says NO, but it is not added for DM. I appreciate for any 
response!</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=549021603-20012006></SPAN></FONT><FONT 
face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV align=left>
<DIV><FONT size=2><FONT face=Arial>Regards</FONT> <BR><FONT 
face=Arial>Steven</FONT> </FONT></DIV>
<P><FONT size=2><FONT 
face=Arial>------------------------------------------------</FONT> <BR><FONT 
face=Arial>POPI Classifications</FONT> <BR><FONT face=Arial>Motorola 
Confidential Proprietary&nbsp; (&nbsp;&nbsp; )</FONT> <BR><FONT 
face=Arial>Motorola Internal Use 
Only&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (&nbsp; )</FONT> <BR><FONT 
face=Arial>General Business Information&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
(&nbsp;<SPAN class=549021603-20012006>X</SPAN> )</FONT> </FONT></P></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C61D71.479B8F2E--

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

Delivery-date: Wed, 18 Jan 2006 20:51:06 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-ieee802-01.txt 
Date: Wed, 18 Jan 2006 15:50: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		: VLAN, Priority, and Filtering Attributes
	Author(s)	: P. Congdon, et al.
	Filename	: draft-ietf-radext-ieee802-01.txt
	Pages		: 32
	Date		: 2006-1-18
	
In certain scenarios it is desirable to limit user access using      
      dynamic VLANs, reprioritization, filters, or redirection.  This 
      document proposes additional attributes for this purpose, for use 
      with the Remote Authentication Dial In User Server (RADIUS).  The 
      attributes described in this document are expected to be useful in 
      a variety of environments, including enterprise and service 
      provider scenarios.

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

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Wed, 18 Jan 2006 17:07:59 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Digest-07 Status (fwd)
Date: Wed, 18 Jan 2006 09:07:18 -0800

---------- Forwarded message ----------
Date: Wed, 18 Jan 2006 17:13:18 +0100
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: Digest-07 status

Bernard,

here's a brief status about which changes I've included in digest-07.

   o  clarified protection space usage with different HTTP-style
      protocols
[as requested by Kurt D Zeilenga]
   o  Mentioned Digest-Entity-Body-Hash in RADIUS Client Behavior
      section
[it was only mentioned in the attribute description and in the Server 
Behaviour
section]
   o  added a RADIUS client configuration section for scenario 1
      parameters
[see my mail 'digest negotation issues' on the list of 9 Jan 2006]
   o  Split Client/Server Behavior sections into subsection to enhance
      readability.
[I did not follow all of Alexey Melnikov's change requests, but he was right 
in
that the large blob of text was hard to follow. The structure is now

     3.2.  RADIUS Client Behavior . . . . . . . . . . . . . . . . . .  9
       3.2.1.  Credential Selection . . . . . . . . . . . . . . . . .  9
       3.2.2.  Constructing an Access-Request . . . . . . . . . . . . 10
       3.2.3.  Constructing an Authentication-Info header . . . . . . 10
       3.2.4.  Failed Authentication  . . . . . . . . . . . . . . . . 11
       3.2.5.  Obtaining Nonces . . . . . . . . . . . . . . . . . . . 12
     3.3.  RADIUS Server Behavior . . . . . . . . . . . . . . . . . . 12
       3.3.1.  General Attribute Checks . . . . . . . . . . . . . . . 13
       3.3.2.  Authentication . . . . . . . . . . . . . . . . . . . . 13
       3.3.3.  Constructing the Reply . . . . . . . . . . . . . . . . 14
]

   o  adjusted Table of Attributes entry for Digest-Qop to 0+, as it is
      only a SHOULD in the text.
   o  replace 'without quotes' with 'without surrounding quotes'
   o  removed redundant sentence from Digest-Domain description in 4.17
   o  removed more typos

I won't include Henrik Nordstrom's request to allow Digest-HA1 without
qop-int. His arguments were quite convinving, but it would be a major
change, and not everybody on the WG list seems to be happy about it.

Wolfgang

--
T-Systems
Next Generation IP Services and Systems
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany

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

Delivery-date: Tue, 17 Jan 2006 21:21:24 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Request to publish RFC 3576 MIBs as Informational RFCs
Date: Tue, 17 Jan 2006 13:20:52 -0800

This is a multi-part message in MIME format.

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

The RFC 3576 client and server MIBs have completed RADEXT WG last call, and
there are no open issues. We are therefore requesting that the IESG consider
these documents for publication as Informational RFCs.  

The documents are available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-03.
txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-03.
txt
 
These documents provide MIBs corresponding to the functionality defined in
RFC 3576. Our understanding is that the MIBs are in the process of being
implemented by at least two vendors.   The documents have been reviewed by
at least 5 members of the WG (including MIB Doctors) in addition to the
RADEXT WG chairs.  Discussion of the documents has occurred on the RADEXT WG
list with very little controversy, so that an appeal seems unlikely. Issues
filed and resolved relating to these specifications are available here:
 
http://www.drizzle.com/~aboba/RADEXT/

 

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

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

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

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><tt><font size=2 face="Courier New"><span style='font-size:
10.0pt'>The RFC 3576 client and server MIBs have completed RADEXT WG last call,
and there are no open issues. We are therefore requesting that the IESG
consider these documents for publication as Informational RFCs. &nbsp;</span></font></tt><o:p></o:p></p>

<pre><font size=2 face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>The documents are available here:<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><a
href="http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-03.txt">http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-03.txt</a><o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><a
href="http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-03.txt">http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-03.txt</a><o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>These documents provide MIBs corresponding to the functionality defined in RFC 3576. Our understanding is that the MIBs are in the process of being implemented by at least two vendors.&nbsp; &nbsp;The documents have been reviewed by at least 5 members of the WG (including MIB Doctors) in addition to the RADEXT WG chairs.&nbsp; Discussion of the documents has occurred on the RADEXT WG list with very little controversy, so that an appeal seems unlikely. Issues filed and resolved relating to these specifications are available here:<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><a
href="http://www.drizzle.com/~aboba/RADEXT/">http://www.drizzle.com/~aboba/RADEXT/</a><o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0004_01C61B68.D73066A0--

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

Delivery-date: Thu, 12 Jan 2006 22:42:12 +0000
From: Joe Urbasik <[email-masked]>
To: [email-masked]
Subject: Questions about handling of RFC 3576 Service-type Authorize-only
Date: Thu, 12 Jan 2006 17:41:34 -0500

Hello,

I am looking at implementing a server for the protocol in RFC 3576, and I
have a few questions regarding the "Authorize-only" Service-type.

I have looked through the archives for this list, and have also browsed RFC
2865 and 4005, in trying to find answers.

RFC 3576 requires a conforming implementation to respond to a DM or CoA
request with Service-type Authoize-only with a NAK to the Initial Request,
followed by a RADIUS Access-request. I understand from the description in
RFC 3576 that this Access-request is meant to trigger a "reauthorization".

I am trying to understand this part of the protocol, in the case where the
Initial request is generated from a Radius server, as opposed to a
Radius/Diameter gateway.

I have these two general questions:

1a. What is the usage scenario for this feature, from a network management
perspective ?

I know the RFC says that "This enables a usage model akin to that supported
in Diameter, thus easing translation between the two protocols". but I am
not so familiar with Diameter, and I do not understand what the need is for
this feature - is this strictly for forward compatibility with Diameter ?

1b. What is the usage scenario, with radius servers ? (This may be the same 
question from another perspective, but in case it isn't) :

>From the point of view of someone wanting to enhance a radius server, what
is the need or attraction for implementing/issuing the "Authorize-only"
requests within this protocol ?

2. The RFC states that the Radius Access-request is to be sent by the
RFC3576 Server. Implicit in this is that the RFC3576 server will get a
response - is it expected to act on that response message ? 

Can the sending of the Access Request be performed by a different server
process, or must the Request come from the same process (or port) that
received the initial Authorize-only request, and that issued the NAK ? In
other words, is the Radius Server maintaining some sort of state between the
two messages ?

I also have 2 specific technical questions

1. I have assumed that the values for the Attributes are to be taken from
RFC 2865, yet in that RFC, "Service-type" has defined the value
"Authenticate-only", not "Authorize-only"

2. Regarding permitted attributes, the paragraph at the top of page 13 says:

   Where a Service-Type Attribute with value "Authorize Only" is
   included within a CoA-Request or Disconnect-Request, attributes
   representing an authorization change MUST NOT be included; only
   identification attributes are permitted.  If attributes other than
   NAS or session identification attributes are included in such a CoA-
   Request, implementations MUST send a CoA-NAK;

My interpretation of this statement is that only the (3) "NAS identification
attributes" and (12) "Session identification attributes", as listed at the 
start of section 3, MAY be in the message. However that interpretation 
excludes Service-type (trivial) and State (less trivial - see [Note 7] ).

Have I misinterpreted the paragraph, or are those actually the exceptions ?

Thank you in advance, for any help that you are able to offer. 

Joe Urbasik
Senior Software Developer 

Chantry Networks.
Ph: 905-567-6900 x6484
Fax:905-567-0099

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

Delivery-date: Wed, 11 Jan 2006 22:04:09 +0000
Content-class: urn:content-classes:message
Subject: RE: Slides regarding GEOPRIV and RADIUS (orig. IETF 64)
Date: Wed, 11 Jan 2006 17:04:07 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Emile van Bergen writes...

> I've heard some people have started discussing my proposal regarding
> GEOPRIV and was asked to bring these slides under your attention again
> and solicit comments.

FYI, the GEOPRIV WG issue tracker for this issue (capabilities) is
located at:

http://www.tschofenig.com:8080/radius-geopriv/issue8

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

Delivery-date: Wed, 11 Jan 2006 21:54:28 +0000
Date: Wed, 11 Jan 2006 22:54:50 +0100
From: Emile van Bergen <[email-masked]>
To: [email-masked]
Subject: Slides regarding GEOPRIV and RADIUS (orig. IETF 64)
Mail-Followup-To: [email-masked]

Hi,

I've heard some people have started discussing my proposal regarding
GEOPRIV and was asked to bring these slides under your attention again
and solicit comments. 

  http://www.xs4all.nl/~evbergen/ietf/ietf64_radext_geopriv_challenges.pdf

The question is whether the proposal effectively addresses GEOPRIV's needs.
I had hoped to have them presented at IETF 64, but was way too late in
submitting them, for (positive) family reasons.

Kind regards,

Emile.

On Wed, Nov 09, 2005 at 10:22:46PM +0100, Emile van Bergen wrote:

> Slides regarding GEOPRIV are at
> http://www.xs4all.nl/~evbergen/ietf/ietf64_radext_geopriv_challenges.pdf
> 
> I was already way too late for IETF 64, and my message didn't reach the
> list either because I used the wrong sender address, but I still hope
> this may help GEOPRIV/RADIUS' progress.
> 
> Kind regards,
> 
> 
> Emile van Bergen.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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

Envelope-to: [email-masked]
Delivery-date: Tue, 10 Jan 2006 23:51:41 +0000
From: "Alan DeKok" <[email-masked]>
To: Henrik Nordstrom <[email-masked]>
Subject: Re: digest-auth negotiation issue 
cc: [email-masked]
Date: Tue, 10 Jan 2006 18:56:59 -0500
Message-Id: <[email-masked]>

Henrik Nordstrom <[email-masked]> wrote:
> Additionally the strength of the Digest hashing as such is also partly a 
> property of the how well the RADIUS client chooses it's nonces in this 
> mode of operation.. If the client is really poorly implemented and only 
> selects between a small set of nonces it could make Digest open to replay 
> attacks, no matter how good the RADIUS server implementation is. But the 
> opposite is also true in that in scenario 2 the client can not choose 
> stronger nonces if it is found the RADIUS server is poorly implemented...

  There are an order of magnitude or two fewer RADIUS server
implementations than clients.  For that alone, I would worry more
about poor client implementations than server implementations.

  Alan DeKok.

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

Delivery-date: Tue, 10 Jan 2006 23:33:48 +0000
Date: Wed, 11 Jan 2006 00:33:26 +0100 (CET)
From: Henrik Nordstrom <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
cc: [email-masked]
Subject: Re: digest-auth negotiation issue

On Mon, 9 Jan 2006, Beck01, Wolfgang wrote:

> RADIUS client configuration
>
> A RADIUS client choosing nonces has to maintain some configuration data 
> for each RADIUS server it may send requests to: - the algorithms (MD5, 
> MD5-sess, etc) supported by the RADIUS server

Indeed. It isn't too unlikely there will be radius servers only supporting 
MD5-sess, and additionally only in scenario 2 mode of operations. This 
would be due to second level user directory integration requirements where 
the radius server itself can not get raw access to the MD5 H(A1) as it is 
rather security sensitive piece of information, only session hashes 
coupled with a unique sesson nonce generated by the user directory 
service.

> - the quality of protection (qop) levels supported by the RADIUS server 
> This configuration may be done manually or by protocols not covered in 
> this document.

auth vs auth-int is mainly a property of the RADIUS client, not the RADIUS 
server. Having this decided by the RADIUS server in either mode would be a 
bit odd. But indeed possible in scenario 2 mode operations.

What is missing here is to clarify that in both cases the client should 
include a Digest-Qop attribute in the first message (or to be precise all 
messages) indicating which of auth or auth-int is desired. If not 
specified auth is assumed. The radius server MAY override the client 
wishes, but it can not be expected that all clients supports auth-int.

> can we add this without starting a new round of Last Calls?

Hope so.

> Proposal 2:
>
> remove scenario 1 from the draft, go back to WGLC

Hmm.. can't really make up my mind on this one. It is a quite useful 
optimization of the protocol, in lack of useable MD5-sess session 
support..

But at the same time it's a quite dangerous mode of operation if adding 
MD5-sess session support as it could allow theft of the session hash via 
another authorized RADIUS client.

Additionally scenario 1 mode of operations have a minor security issue in 
that it allows for probing to verify if the password is still the same by 
simply replaying the exact same digest message, provided one has gained 
authorization to talk to the RADIUS server directly.

Additionally the strength of the Digest hashing as such is also partly a 
property of the how well the RADIUS client chooses it's nonces in this 
mode of operation.. If the client is really poorly implemented and only 
selects between a small set of nonces it could make Digest open to replay 
attacks, no matter how good the RADIUS server implementation is. But the 
opposite is also true in that in scenario 2 the client can not choose 
stronger nonces if it is found the RADIUS server is poorly implemented...

Regards
Henrik

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

Delivery-date: Tue, 10 Jan 2006 21:02:18 +0000
Content-class: urn:content-classes:message
Subject: Diameter Maintanence & Extensions WG mailing lis
Date: Tue, 10 Jan 2006 23:01:46 +0200
To: <[email-masked]>
Cc: <[email-masked]>

Hi all,

There is a new Diameter Maintanence & Extensions WG mailing list.

Information can be found here:

https://www1.ietf.org/mailman/listinfo/dime

There is also an email-based interface for users of the list; you can
get info about using it by sending a message with just the word `help'
as subject or in the body, to:

    [email-masked]

To unsubscribe a user: from the mailing list 'listinfo' web page, click
on or enter the user's email address as if you were that user.

As Bert pointed out in his mail, the Area Directors are perparing a
profile for the new WG chairs and will then sollicit for candidates. 

Until then, you can post to this new working group mailing list various
issues and fixes for the current AAA RFCs.  My hope is that this working
group will meet at the next IETF.

thanks,
John

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

Delivery-date: Tue, 10 Jan 2006 18:44:28 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 129: Editorial nits
Date: Tue, 10 Jan 2006 10:43:55 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>

Paul stated some editorial nits a while back... 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Wednesday, September 07, 2005 11:40 PM
> To: [email-masked]
> Subject: Issue 129: Editorial nits
> 
> Issue 129:  Editorial NITs
> 1. Pg 3, end of second paragraph. Seems like a reference to 
> RFC3580 would be appropriate

[ms] Ok. 

> 
> 2. Pg 3, middle of sixth paragraph. We aren't providing the 'full set'
> of VLAN functionality either.  Suggest replacing "...the full 
> set of VLAN functionality" with "...a more complete set of 
> VLAN functionality as defined by IEEE 802.1Q-2003"

[ms] Ok. 

>  
> 3. Pg 3, end of sixth paragraph.  Reference to IEEE-802.1Q 
> should probably be the Bridge-MIB or RFC 2674

[ms] ok. 

> 
> 4. Pg 4. The following terms aren't really used and should be 
> removed; Access Point (AP), Association, Port Access Entity 
> (PAE), Stations (STA).

[ms] ok. 

> 
> 5. Pg 10, 3.4 User-Priority-Table. The reference to 802.1D 
> should probably be 802.1D-2004.

[ms] Propose to change 802.1D reference to [IEEE8021D], which is already
used in other sections of document. 

> 
> 6. Pg 10, 3.4 User-Priority-Table, 1st paragraph of String. 
> There are 8 regenerated priorities, not 7.

[ms] ok. 

> 
> 7. Pg 12, First item 2). The way this item is worded it makes 
> it sound like you must have a flush rule present and as the 
> first item.  Suggest rewording as follows: Base encapsulation 
> filter rules MUST appear after a flush rule (if present) and 
> before IP tunnel,...

[ms] I102 resolution already changed this text in substantial fashion.
See resolution for I102. 

> 
> 8. Pg 12, first paragraph after list. If you only wanted to 
> filter specific traffic, but allow other stuff you would want 
> the list to end with an 'accept all' rule.  The behavior we 
> have defined is more of a firewall type behavior rather than 
> a router behavior.  We should document a syntax for the 
> 'accept all' rule and make a note to the implementer of how 
> to do this.  Suggest adding a note that describes how to 
> terminate the list with a rule that allows all traffic.  I 
> believe the rule is: permit both ip from any to any.  We may 
> need an L2 rule as well.

[ms] Propose adding new rule statement that can be added to a rule list
that matches all traffic.  Propose the following rule statement 
"permit inout any from any to any"  

Description to be added that talks to the use case for this, as follows:

"Special rule that matches against all traffic. This allows the implicit
deny at the end of a filter list to be overridden."
 
> 9. Pg 12, last paragraph on Filter-ID and NAS-Filter-Rule.  
> The paragraph is clumsy.  Suggest replacing the start of the 
> second sentence with, "These attributes are not intended to 
> be used..."

[ms] ok. 

> 
> 10. Pg 15, Note: at top of page. Seems like a missing word or 
> something in the second sentence.  Suggest, "Also, [ports] 
> optional argument is not valid for ..."

[ms] nas-filter rule description changed substantially due to I102.
This specific text no longer appears. 

> 
> 11. Pg 17, Editorial note in Text section.  I think you can 
> just delete this now.  Isn't the text about fragmenting these below?

[ms] ok. 

> 
> 12. Pg 23, end of page. RFC 2866 and RFC 2867 are normative, 
> but never referenced.  Perhaps we should be referencing them 
> somewhere or move them to informative references.  Also, 
> IEEE802.11i reference should be IEEE80211i (all one word - no dot).

[ms] ok.

> 
> 13. Pg 28, Acknowledgments. Since all the wireless stuff has 
> been removed, we can remove Dorothy Stanley of Agere from 
> this list of names.

[ms] ok.

Cheers,
MS

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

Delivery-date: Tue, 10 Jan 2006 17:19:40 +0000
Content-class: urn:content-classes:message
Subject: Issue 116: Technical Comments
Date: Tue, 10 Jan 2006 09:19:32 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>
Cc: "Nelson, David" <[email-masked]>

Dave commented...

> Issue 116: Technical Comments
> Submitter name: David Nelson
> Submitter email address: [email-masked] Date first 
> submitted: August 11, 2005
> Reference: http://ops.ietf.org/lists/radiusext/2005/msg00643.html
> Section 2.2
> Text appears to create retroactive normative requirements on 
> existing implementations.
> 
> Requested changes:
> 
> Change:
> 
>       Similarly, if a NAS conforming to this specification receives a 
>       CoA message that contains an attribute from this 
> document that it 
>       does not recognize or cannot apply, it MUST NOT terminate the 
>       session and MUST generate a CoA-NAK packet with 
> ERROR-CAUSE(101) 
>       set to "Unsupported Attribute"(401).  
> 
> To:
> 
>       Similarly, if a NAS conforming to this specification and also
>       conforming to RFC 3576 [RFC3576] receives a CoA message that 
>       contains an attribute from this document that it does not 
>       recognize or cannot apply, it MUST NOT terminate the session and
>       MUST generate a CoA-NAK packet with Error-Cause (101) set to
>       "Unsupported Attribute"(401).  

[ms] Agree.  Document to be changed. 

< Second issue relating to data types has already been closed. >

Cheers,
MS

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

Delivery-date: Tue, 10 Jan 2006 17:14:49 +0000
Content-class: urn:content-classes:message
Subject: Issue 115: WGLC 
Date: Tue, 10 Jan 2006 09:14:27 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Dave pointed out many days ago a number of editorial comments...

> Issue 115: WG Last Call Comments
> Submitter name: David Nelson
> Submitter email address: [email-masked] Date first 
> (1) 
> 
> Within the confines of RADIUS authentication, authorization, 
> and accounting (AAA) environments, there is a general dearth 
> of standardized RADIUS attributes to limit user access using 
> dynamic VLANs, filters or redirection.
> 
> Could we change "a general dearth of" to "a requirement for"? 
> It sounds more positive.

[ms] Accepted. 

> 
> (2)
> 
> IEEE 802.1X-2004 [IEEE8021X] provides "network port 
> authentication" for IEEE 802 [IEEE802] media, including 
> Ethernet [IEEE8023], Token Ring and 802.11 wireless LANs [IEEE80211i].
> 
> Remove this sentence as it appears in the second paragraph as well.

[ms] Accepted. 

> 
> Section 1.1: The following definitions are not used in the draft:
> 
> Access Point
> Association
> Station
>  
> Requested change:
>  
> Please delete them.

[ms] Accepted.

> 
> Section 2: Better phrasing.
> 
> Requested changes:
> 
> (1) The first paragraph is awkwardly worded. Perhaps the 
> following would be an improvement. 
> 
> In this section we provide an elaboration of the requirements 
> briefly described in the Introduction.
> 
> (2)
> For example, the user maybe on
> a prepaid plan and all the resources have been used up.
> 
> Change "maybe" to "may be" and "resources have" to "credit 
> balance has".
> 
> (3)
> For example, the ability to block and
> redirect traffic is required for TCP users, cell phone users, 
> WiFi users.
> 
> Change "TCP users" to "IP users".
> 
> (4) Change:
> 
> As pointed out by [NASREQ] the use Filter-Id is not roaming 
> friendly and it is recommended that instead one should use NAS-
> Filter-Rule(TBD) AVP. For this reason, this document introduces
> NAS-Filter-Rule(TBD) to RADIUS.
> 
> To:
> 
> As pointed out by [NASREQ] the use Filter-Id is not roaming 
> friendly and it is recommended that instead one should adapt 
> the Diameter NAS-Filter-Rule AVP as a RADIUS 
> NAS-Filter-Rule(TBD) attribute.

[ms] Given the result of I114, section 2 may be eliminated entirely. 

> Section 2.1: This section seems out of place.
> 
> 2.1 Capability Advertisement
> 
> RADIUS does not currently define a method by which a NAS can 
> advertise its capabilities and in many instances, it would be 
> desirable for the home network to know what capabilities are 
> supported by the NAS to ensure proper operational behavior. 
> The attributes defined in this document are intended to be 
> used to enforce policy by the NAS. If a NAS does not 
> recognize these attributes it will most likely ignore them 
> and the desired policy will not be enforced. A method for the 
> NAS advertising the capability to support these attributes 
> would help the RADIUS server understand if the intended 
> policies can be enforced. As a result, the attributes in this 
> document, in particular NAS-Filter- Rule(TBD), can benefit 
> from capability advertisement, if available. 
> 
> Requested changes: 
> 
> Should this entire section perhaps be part of the Security 
> Considerations?

[ms]What is your rationale?

> 
> Section 3.5: Clarification of the text.
> 
> Requested changes:
> 
> Furthermore, the concatenated filter list must abide to the 
> following rules of precedence and ordering: 
> 
> 1) A flush rule MUST appear before all other rule types. 
> 
> Change "A flush rule" to "A flush rule, when present,".
> 
> 2) Base encapsulation filter rules MUST appear after a flush 
> rule and before IP tunnel, HTTP redirect, IP filter, and/or 
> HTTP filter rules.
> 
> Change "a flush rule" to "any flush rule".

[ms]This text changed due to actions decided upon for I102.  Take a look
at resolution for this issue. 

> 
> dir "in" is from the terminal, "out" is to the terminal, 
> "inout" is from and to the terminal.
> 
> The term "terminal" is not defined in the draft. I suspect it 
> identifies the network entity which contains the IEEE 802.1X 
> Supplicant function, but this should perhaps be clarified.

[ms] This sentence comes by way of the IPFilterRule description found in
Diameter [RFC3588].  What would you suggest we do for RADIUS. Is
terminal not a globally known term in RADIUS, if not, is there any?
Perhaps can you suggest a definition to add to the terminology section. 

> 
> General comment: I'd much rather that we use ABNF to define 
> the NAS-Filter-Rule formal syntax, however I'm not prepared 
> to submit that text just now. :-)

[ms] Agree. It has been done (or at least started) due to resolution of
I102. :)

> 
> Section 4.1
> 
> 4.1. Acct-NAS-Filter-Rule
> 
> The first eight octets of this string are used for a 64-bit 
> value of the rule counter. The remaining octets are used to 
> specify which filter rule the counter value is for. The rule 
> specification MUST conform to the syntax rules specified for 
> NAS-Filter-Rule[TODO].
> 
> [TODO] indicates an open action item.
> 
> Requested changes:
> 
> Provide the [TODO].

[ms] TODO should actually be TBD.  We don't have a IANA value associated
with this attribute, yet.  All TBD's will change to the IANA assigned
values as the right juncture. 

Cheers,
MS

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

Delivery-date: Tue, 10 Jan 2006 16:45:07 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 114: WGLC Review
Date: Tue, 10 Jan 2006 08:44:10 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Bernard submitted a while back...

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Subject: Issue 114: WGLC Review
> 
> I do not understand the purpose of the accounting 
> functionality in the draft.
> 
> The focus of this document is VLAN attribute, priority and 
> filtering. How does Acct-EAP-Auth-Method fit into that? I 
> think this is a leftover WLAN attribute which should be removed.

[ms] Agree. This was a vestiage from earlier days of document and was
left in error. 

> 
> Acct-NAS-Filter-Rule attribute. The purpose of this attribute 
> is to keep count of hits on filter rules. This duplicates 
> functionality under development in other WGs such as IPFIX, 
> and so I'd question whether this is appropriate functionality 
> for RADIUS accounting.

[ms] I see this accounting attribute as adding basic audit capability to
the authorization policy expressed through the NAS-Filter-Rule
attribute.  Surely you would agree that performing accounting/audit
functions is well within scope of RADIUS.  Accounting records already
have data counts for session use, so why not have filter hit counts
along with them?  A straightforward use case is an administrator that
has a (strict) filter policy for which he/she wishes to be notified
anytime a user tries to pass unauthorized traffic through the NAS.
Errant users could then be sanctioned in the future.

> 
> Overview
> 
> I do not understand the purpose of Section 2, Overview. Most 
> of it seems like it could be deleted without losing anything.

[ms] Other than the first paragraph, most of the material comes by way
of the old redirect draft Avi was stewarding.  If he has no objection,
we can see about removing text from this section. 

Cheers,
MS

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

Delivery-date: Tue, 10 Jan 2006 04:09:13 +0000
Content-class: urn:content-classes:message
Subject: Issue 102: IEEE RFC (WG Last Call Review) Status Recap
Date: Mon, 9 Jan 2006 20:08:43 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>

This is a recap of status for Issue 102 (raised by Pasi Eronen), which
consists of a number of sub-issues.  We believe all issues have
acceptable action recommendations and unless we hear otherwise, the
action noted will be taken. 

102-1
Description:  Section 3.5 is currently quite difficult to follow since
it mixes L2, IP, tunneling and HTTP redirect rules... It's not always
even clear when some element is just a name for a rule (like "ipno") and
when it's a literal string (like "from").  So some editing work is
needed here. Maybe describing the L2,  IP filtering, IP tunneling and
HTTP rules one-by-one(instead of mixing their descriptions) would make
this moreunderstandable. (The IPFilterRule description in RFC3588 isn't
nearly ascomplicated as this, since it doesn't have the L2, tunneling or
HTTP rules.)

Discussion: 9/23 - Paul Congdon suggests that this issue be solved
through description of nas-filter-rule using ABNF. No additional
discussion generated on this sub-issue.

Action: Replace current 'nas-filter-rule' description that uses
non-standard syntax language to use ABNF.
---------------------------------------------------
102-2
Description: Use ABNF to describe 'nas-filter-rule'

Discussion: 9/23 - Paul accepts Posi's suggestion to use ABNF and
questions whether it should replace existing non-standard syntax
description or appended to it. 9/26 - Posi says that regardless of the
way, multiple syntax descriptions should not be in conflict. No
additional discussion.

Action: Replace current 'nas-filter-rule' description that uses
non-standard syntax language to use ABNF.
---------------------------------------------------
102-3
Description: Example of "macaddr/mask": The example should use some
other width than /24 to make it clearer how the counting works. Also,
the example given is an invalid one, since it does not meet the "The MAC
address MUST NOT have bits set beyond the mask" requirement. Suggested
change: use 00-10-A4-23-00-00/32 as the
example.

Discussion: 9/23 - Paul accepts suggestion to change example.

Action: Change example to use 00-10-A4-23-00-00/32 
---------------------------------------------------
102-4 
Description: Description of "ipno/bits" says "the IP number MUST NOT
have bits set beyond the mask", but the example given, "1.2.3.4/24",
does not follow this. Suggested change: use 192.0.2.0/24 as the example.

Discussion: 9/23 - Paul accepts suggestion to change example. Also
suggests a different addres example. 9/26 - Pasi asserts RFC3330
mandates given address example. 

Action: Change example to use 192.0.2.0/24 .
---------------------------------------------------
102-5
Description: Description of tunnel_id: according to RFC 2868, there are
no restrictions on the format of the Tunnel-Assignment-ID. Currently
it's not clear if the NAS-Filter-Rule syntax supports correctly parsing
arbitrary IDs (what happens if the ID
includes spaces, for instance?)

Discussion: 9/23 - Paul suggests use of escaping function, since there
are no restrictions on the format of the string used in
Tunnel-Assignment-ID we MUST provide a way to parse it as a single
element in the entire attribute string. Of course, the
Tunnel-Assignment-ID could itself contain quotes, so we will also need
to describe some escaping function before including them in the rule.
The escaping function would be: For all occurrence of " replace with \"
and for all occurrence of \ replace with \\.

Action: Modify paragraph describing role of 'tunnel-id' parameter for
nas-filter-rule as follows: 

"A tunnel id. When the 'tunnel' rule matches, traffic is redirected over
the tunnel with the specified tunnel_id. Traffic can only be redirected
to or from named tunnels that have been established per [RFC2868] and
named using the Tunnel-Assignment-ID attribute described therein. 

The tunnel id MUST be encapsulated in double quotes and use the
following escape functions in case the tunnel id itself contains any
quotes:

For all occurances of " replace with \"
For all occurances of \ replace with \\

Example: A tunnel with the name of tunnel "ppp1" would be specified as
"tunnel /"pp1/"" within the rule."
------------------------------------------------------
102-6
Description: Near the end of Section 3.5: The "concise syntax
statements" don't exactly match the definitions earlier. I catched at
least these:
- IP rule is missing "[ports]" before "to"
- IP rule is missing "|" after "redirect"
- HTTP redirect rule is missing the "proto" part after the direction
- HTTP redirect rule does not have "[ports]"

Discussion: 9/23 - Paul accepts change 

Action: Per sub-issue 102-2 the description of nas-filter-rule will be
using ABNF.  The need for concise syntax statements no longer exists and
will be removed from document.  
------------------------------------------------------
102-7
Description: The document does not seem to describe what HTTP filter
rules are or how they work (HTTP redirect rules are explained, but not
HTTP filter rules).

Discussion: 9/23 - Paul agrees better description necessary. 12/2 -
Mauricio responds with new text proposal to list.

Action: Replace existing HTTP filter description with new text proposed
on 12/2.
------------------------------------------------------
102-8
Description: The document allows an IP tunnel rule with direction "out",
but does not describe what such a rule means (the description seems to
apply only to rules with direction "in")

Discussion: 9/23 - Paul posted Avi's tunneling document 9/26 - Posi
found the document useful 11/18 - Mauricio asked Posi for guidance on
what to add to the document from Avi's document. 11/22 - Posi suggest
inclusion of a portion of Avi's tunneling document as an Appendix to
draft 12/13 - Paul posts to radext email list new proposed text for
appendix A.

Action: Add Paul's suggested text from 12/13 to appendix A.
------------------------------------------------------
102-9
Description: Currently the text says "A flush rule MUST appear before
all other rule types." I first read this to mean that a flush rule must
always be present, but I guess that was not what was
meant. Furthermore, it's not easy to parse the ordering requirements.

Rewrite that paragraph to "Furthermore, if the list contains different
types of rules, they MUST appear in the following order: flush rules,
base encapsulation filter rules, IP tunnel rules, HTTP redirect rules,
IP filter rules, and HTTP filter rules."

Discussion: 9/23 - Paul accepts change.

Action: Replace paragraph in question with Pasi's suggested text. 
------------------------------------------------------
102-10
Description: The document should explain why different types of rules
must be given in exactly that order. Placing L2 rules before IP is
understandable, but for some of the other cases it's not totally
obvious why other orderings need to be forbidden.

Discussion: 9/23 - Paul asserts proposed ordering rules are to maxium
interoperability 9/26 - Pasi accepts 

Action: None
------------------------------------------------------
102-11
Description: The document should have some examples of NAS filter rules,
preferably showing most of the different features at least once.

Discussion: 9/23 - Paul accepts Pasi's recommendation.  

Action: Add several example of NAS filter rules per Pasi's
recommendation.
------------------------------------------------------
102-12
Description: The document should somewhere describe the differences to
Diameter's NAS-Filter-Rule syntax.

Discussion: 9/23 - Paul accepts Pasi's recommendation

Action: Add paragraph to description section detailing differences to
Diameter's NAS-Filter-Rule
------------------------------------------------------
102-13
Description: If the NAS just concatenates all the NAS-Filter-Rule (or
QoS-Filter-Rule) attributes together to overcome the 255-byte attribute
length limit, then boundaries between individual rules
are lost. Parsing may be ambiguous.

Discussion: 9/23 - Paul asserts that this should not be a problem. No
action proposed. 9/26 - Pasi states that dependancies exist on grammer
to be parsable in non-ambigous manner. Current grammer seems to have no
opportunities for ambiguity. 9/26 - Paul agrees it would be nice to have
a rule delimeter 9/26 - Pasi agrees with Paul.  Pasi goes on to suggest
usage of a rule delimeter field.

Action: Add rule delimeter to filter syntax.

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
Procurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5555
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
[email-masked]
--------------------------------------------   

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

Delivery-date: Mon, 09 Jan 2006 21:44:04 +0000
Content-class: urn:content-classes:message
Subject: [Issue] multiple source addresses
Date: Mon, 9 Jan 2006 16:43:17 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

Description of issue: Multiple NAS address options
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: 1/9/06
Reference: n/a
Document: draft-aboba-radext-fixes-01.txt
Comment type: T/E
Priority: 1
Section: 2.7.2
Rationale/Explanation of issue:

Regarding this text:
   There are situations in which a RADIUS client or server may have
   multiple addresses.  For example, a dual stack host can have both
   IPv4 and IPv6 addresses; a host that is a member of multiple VLANs
   could have IPv4 and/or IPv6 addresses on each VLAN; a host can have
   multiple IPv4 or IPv6 addresses on a single interface.  However,
   [RFC2865] Section 5.44 only  permits zero or one NAS-IPv4-Address
   attributes within an Access-Request and [RFC3162] Section 3 only
   permits zero or one NAS-IPv6-Address attributes within an Access-
   Request.  Where a NAS has more than one global address, it is
   RECOMMENDED that the NAS include the NAS-Identifier attribute in an
   Access-Request in order to identify itself to the RADIUS server.

More typically, this situation has been addressed by allowing the NAS 
RADIUS client implementation to specify which address should be used 
(either globally or perhaps based on additional information about the
type of request).  

Requested change:
Can we change the condition on the RECOMMENDATION to something
like 'When a NAS has more than one global address and no ability
to determine which is used for identification in a particular 
request, ...'.

Also, can you change:
  "NAS-IPv4-Address" -> "NAS-IP-Address" and
  "Account-Session-ID" -> "Acct-Session-Id" in the doc.

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

Delivery-date: Mon, 09 Jan 2006 16:54:36 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: digest-auth negotiation issue
Date: Mon, 9 Jan 2006 17:53:45 +0100 

Following the contributions of Alexey Melnikov and Hendrik Nordstrom,
I think we have also a negotiation problem.

In scenario 1 -- RADIUS client chooses nonces -- the RADIUS client has to know
what RfC2617 features the responsible RADIUS server supports. 

The trouble is, that an HTTP Digest server not only sends the nonce but also the supported
protocol features in its initial response. The RADIUS client can invent a nonce but does
not necessarily know the features of the RADIUS servers.

The draft mentions only the AKA case and requests manual configuration. MD5, MD5-sess, auth,
auth-int are not covered.

Proposal 1:
clarify by adding a new section:

	RADIUS client configuration
	
	A RADIUS client choosing nonces has to maintain some configuration data for each
	RADIUS server it may send requests to:
	- the algorithms (MD5, MD5-sess, etc) supported by the RADIUS server
	- the quality of protection (qop) levels supported by the RADIUS server
	This configuration may be done manually or by protocols not covered in this document.

can we add this without starting a new round of Last Calls?

Proposal 2:

remove scenario 1 from the draft, go back to WGLC

Wolfgang
--
T-Systems International GmbH
Technologiezentrum
Next Generation IP Services and Systems
+49 6151 9372863
Am Kavalleriesand 3
64295 Darmstadt

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

Delivery-date: Sat, 07 Jan 2006 06:33:19 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Reminder:  Outstanding Review Requests
Date: Fri, 06 Jan 2006 22:32:44 -0800

The following Requests for Review are still outstanding:

RADIUS Prefix Delegation
-----------------------------------

RADEXT WG has received a request for review of RADIUS Prefix Delegation from 
the DHC WG Chair, Ralph Droms.  The document is available for inspection 
here:
http://www.ietf.org/internet-drafts/draft-salowey-radext-delegated-prefix-01.txt

Since this document represents a clarification of RFC 3162 which is relevant 
to ongoing IPv6 deployments, it is considered URGENT.

A pointer to the original review request is located here:
http://ops.ietf.org/lists/radiusext/2005/msg01094.html

Some comments relevant to the topic are located here:
http://ops.ietf.org/lists/radiusext/2005/msg01095.html
http://ops.ietf.org/lists/radiusext/2005/msg01096.html

Review comments should be sent to the RADEXT WG mailing list.

RADIUS Issues & Fixes Document
----------------------------------------------

A pre-work item review of the Issues & Fixes document has been requested.  
The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-01.txt

The original review request is available here:
http://ops.ietf.org/lists/radiusext/2005/msg01010.html

IEEE 802.11u Liaison Request
-----------------------------------------

The RADEXT WG has received a liaison request from IEEE 802.11u, requesting 
review of the IEEE 802.11u requirements specification.  The original review 
request is described here:
http://ops.ietf.org/lists/radiusext/2005/msg01080.html

Review comments are available here:
http://lists.frascone.com/pipermail/eap/msg03765.html
http://lists.frascone.com/pipermail/eap/msg03831.html
http://lists.frascone.com/pipermail/eap/msg03832.html

Review comments should be sent to the RADEXT WG mailing list.

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

Delivery-date: Sat, 07 Jan 2006 03:47:59 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Last look: RFC 3576 Client and Server MIBs
Date: Fri, 06 Jan 2006 19:47:08 -0800

The RFC 3576 client and server MIBs have completed RADEXT WG last call, and 
there are no open issues remaining.  We are therefore asking the WG to 
examine the drafts one last time before sending them on to the IESG for 
consideration as Informational RFCs.

The documents are available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-03.txt

Please send your comments, if any, to the RADEXT WG mailing list by Friday, 
January 13, 2006.

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

Delivery-date: Fri, 06 Jan 2006 16:39:55 +0000
Content-class: urn:content-classes:message
Subject: RE: issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess
Date: Fri, 6 Jan 2006 11:41:33 -0500
From: "Avi Lior" <[email-masked]>
To: "Henrik Nordstrom" <[email-masked]>, <[email-masked]>

Hi Henrik,

Personally I have no issue with doing what you want.  I actually think
that it makes sense.  However, the problem I have is that we need this
work to finish ASAP.

In fact, it is my working in 3GPP2 that is waiting for this work to
complete.

I don't mind if we add this facilities providing it will not further
delay this document.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Henrik Nordstrom
> Sent: Thursday, January 05, 2006 7:12 PM
> To: [email-masked]
> Subject: RE: issue: draft-ietf-radext-digest-auth-06.txt 
> Digest MD5-sess
> 
> On Thu, 5 Jan 2006, Avi Lior wrote:
> 
> > So one example is in Mobile IP.  Once the HA has validated the 
> > Registration Request or Binding Update with RADIUS.  It can 
> continue 
> > to authentication subsequent bind request or Registration Request 
> > received from that user. This is only limited by a lifetime 
> received 
> > from the AAA server.
> 
> Which is very similar to what is provided by Digest MD5-sess. 
> The credentials given to the RADIUS client is only good for 
> validating within a good credibility that next messages is in 
> the same user session. It can not be reused in authentication 
> to any other service, or even to start a new session or renew 
> the existing session to the same service.
> 
> Giving avay the non-session Digest MD5 HA1 is a completely 
> different think. It's in the Digest world almost equivalent 
> to giving away the users plaintext password.
> 
> The only security issue with the MD5-sess HA1 in session mode 
> that I can see is it SHOULD be transmitted securely IF 
> MD5-sess is used in session mode or if message integrity 
> protection is used as knowledge of the MD5-sess HA1 hash 
> allows for limited session theft, limited by session nonce 
> count and time limits enforced by the service. But as soon as 
> the server-side nonce expires the hash is completely useless 
> for any meaningful purposes.
> 
> 
> 
> My notes on security issues of the Digest-HA1 attribute in 
> general and it's use in Digest session authentication in particular:
> 
> 
> MD5, any mode of operation:
> 
> Equivalent to plaintext for any service using Digest authentication. 
> Knowledge of the MD5 HA1 allow for full theft of the account on the 
> service/realm until the password or realm is changed, and 
> consequently 
> also full control of integrity protection of both requests 
> and responses.
> 
> MD5-sess, one request per nonce:
> 
> No session theft is possible as the sessions only last for a single 
> message.
> 
> But knowing the HA1 allows breaking any response integrity 
> protection. 
> Request integrity is protected however as the HA1 is only 
> known after the 
> request has been received and processed by the service.
> 
> MD5-sess, session based:
> 
> In addition to the above it allows for session theft for as 
> long as that 
> session is considered valid by the service, including 
> request/response 
> integrity protection (except for the first message). Session 
> length is 
> usually limited by both nonce count (number of requests) and 
> time. The 
> RADIUS server may hint both session limits to the client, but can not 
> enforce it.
> 
> 
> Senario 1 mode of operation:
> 
> If Senario 1 mode of operation is allowed then it mau be considerably 
> easier for an attacker to gain access to the HA1. If Scenario 
> 1 mode of 
> operation is allowed then he only needs to be able to see the 
> application 
> protocol traffic and have access to any RADIUS client allowed 
> to query the 
> RADIUS server in this mode to gain access to the Digest-HA1 
> by replaying 
> the seen Digest message details to the RADIUS server. 
> Transport protection 
> of the Digest-HA1 attribute does not help against this.
> 
> 
> 
> Regards
> Henrik
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Fri, 06 Jan 2006 10:58:55 +0000
Date: Fri, 06 Jan 2006 11:57:48 +0100
From: [email-masked]
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: A plan for moving forward on the RFC 3576 MIB Documents

Hi,

Version 03 of the RFC 3576 MIBs are available now:

http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-03.txt

All open issues (issues 137, 143, 145, and 149) should be solved.

regards,
Stefaan

Bernard Aboba wrote:

> These documents have completed WG last call, and from what I can tell 
> there is only a single open Issue (149).  I would therefore propose that 
> the editors prepare a new version of these documents by next week, so 
> that we can get the RFC 3576 MIBs on the IESG agenda immediately.
> 
> The RFC 3576 MIBs are only a month behind schedule, but there seems to 
> be little reason for further delay.  Let's wrap this up ASAP.
> 
> 
> 
> -- 
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Fri, 06 Jan 2006 01:35:08 +0000
Date: Fri, 6 Jan 2006 01:12:17 +0100 (CET)
From: Henrik Nordstrom <[email-masked]>
To: [email-masked]
Subject: RE: issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess

On Thu, 5 Jan 2006, Avi Lior wrote:

> So one example is in Mobile IP.  Once the HA has validated the
> Registration Request or Binding Update with RADIUS.  It can continue to
> authentication subsequent bind request or Registration Request received
> from that user. This is only limited by a lifetime received from the AAA
> server.

Which is very similar to what is provided by Digest MD5-sess. The 
credentials given to the RADIUS client is only good for validating within 
a good credibility that next messages is in the same user session. It can 
not be reused in authentication to any other service, or even to start a 
new session or renew the existing session to the same service.

Giving avay the non-session Digest MD5 HA1 is a completely different 
think. It's in the Digest world almost equivalent to giving away the users 
plaintext password.

The only security issue with the MD5-sess HA1 in session mode that I can 
see is it SHOULD be transmitted securely IF MD5-sess is used in session 
mode or if message integrity protection is used as knowledge of the 
MD5-sess HA1 hash allows for limited session theft, limited by session 
nonce count and time limits enforced by the service. But as soon as the 
server-side nonce expires the hash is completely useless for any 
meaningful purposes.

My notes on security issues of the Digest-HA1 attribute in general and 
it's use in Digest session authentication in particular:

MD5, any mode of operation:

Equivalent to plaintext for any service using Digest authentication. 
Knowledge of the MD5 HA1 allow for full theft of the account on the 
service/realm until the password or realm is changed, and consequently 
also full control of integrity protection of both requests and responses.

MD5-sess, one request per nonce:

No session theft is possible as the sessions only last for a single 
message.

But knowing the HA1 allows breaking any response integrity protection. 
Request integrity is protected however as the HA1 is only known after the 
request has been received and processed by the service.

MD5-sess, session based:

In addition to the above it allows for session theft for as long as that 
session is considered valid by the service, including request/response 
integrity protection (except for the first message). Session length is 
usually limited by both nonce count (number of requests) and time. The 
RADIUS server may hint both session limits to the client, but can not 
enforce it.

Senario 1 mode of operation:

If Senario 1 mode of operation is allowed then it mau be considerably 
easier for an attacker to gain access to the HA1. If Scenario 1 mode of 
operation is allowed then he only needs to be able to see the application 
protocol traffic and have access to any RADIUS client allowed to query the 
RADIUS server in this mode to gain access to the Digest-HA1 by replaying 
the seen Digest message details to the RADIUS server. Transport protection 
of the Digest-HA1 attribute does not help against this.

Regards
Henrik

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

Delivery-date: Thu, 05 Jan 2006 22:27:17 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess
Date: Thu, 5 Jan 2006 17:28:28 -0500
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>

See inline: 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Friday, December 30, 2005 12:51 PM
> To: [email-masked]
> Subject: Re: Issue: draft-ietf-radext-digest-auth-06.txt 
> Digest MD5-sess
> 
> Henrik Nordstrom <[email-masked]> wrote:
> > I brought up this question mainly to ask if the Digest extension to 
> > Radius intentionally blocks session based Digest authentication 
> > (MD5-sess with offload of authentication of further requests within 
> > the same session), or if it is just an oversight thinking 
> that Digest 
> > is only per-reqest authentication.
> 
>   RADIUS *is* per-request authentication.  

Lets not get dogmatic here.  At the RADIUS level perhaps this is true
but certainly there are scenarios where once the NAS has received a
positive repsonse, the NAS can continue to authenticate without relying
on RADIUS.

So one example is in Mobile IP.  Once the HA has validated the
Registration Request or Binding Update with RADIUS.  It can continue to
authentication subsequent bind request or Registration Request received
from that user. This is only limited by a lifetime received from the AAA
server.

I can give you more examples if you want.

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

Delivery-date: Thu, 05 Jan 2006 20:51:27 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-dynauth-client-mib-03.txt 
Date: Thu, 05 Jan 2006 15:50: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		: Dynamic Authorization Client MIB
	Author(s)	: S. De Cnodder, et al.
	Filename	: draft-ietf-radext-dynauth-client-mib-03.txt
	Pages		: 27
	Date		: 2006-1-5
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes the Remote Authentication Dial In User
   Service (RADIUS) [RFC2865] Dynamic Authorization Client (DAC)
   functions that support the dynamic authorization extensions as
   defined in RFC 3576.

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-dynauth-client-mib-03.txt

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Thu, 05 Jan 2006 20:51:19 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-dynauth-server-mib-03.txt 
Date: Thu, 05 Jan 2006 15:50: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		: Dynamic Authorization Server MIB
	Author(s)	: S. De Cnodder, et al.
	Filename	: draft-ietf-radext-dynauth-server-mib-03.txt
	Pages		: 26
	Date		: 2006-1-5
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes the Remote Authentication Dial In User
   Service (RADIUS) [RFC2865] Dynamic Authorization Server (DAS)
   functions that support the dynamic authorization extensions as
   defined in RFC 3576.

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-dynauth-server-mib-03.txt

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Tue, 03 Jan 2006 06:06:34 +0000
Content-class: urn:content-classes:message
Subject: RE: A Proposal for Moving Forward on draft-ietf-radext-ieee802
Date: Mon, 2 Jan 2006 22:05:42 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>, "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>, "Glen Zorn (gwz)" <[email-masked]>

At the last meeting we decided to remove QoS-Filter-Rule from the draft.

The next draft is very nearly ready to go. Mauricio is on vacation until
the 9th, so it should be out very shortly after that.  We were waiting
to resolve all issues before publishing another version, but perhaps
that isn't be best approach.

Paul  

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Monday, January 02, 2006 12:30 PM
> To: Congdon, Paul T (ProCurve)
> Cc: Bernard Aboba; [email-masked]; Sanchez, Mauricio 
> (PNB Roseville)
> Subject: Re: A Proposal for Moving Forward on 
> draft-ietf-radext-ieee802
> 
> Hi Paul,
> 
> what are your plans regarding the usage of the 
> QoS-Filter-Rule described in Section 3.6 of 
> <draft-ietf-radext-ieee802-00.txt>?
> 
> Currently the draft only points to Section 4.3 of RFC 3588. 
> RFC 3588, however, only specifies the ability to carry a flow 
> identifier (referred as IPFilterRule) with a DiffServ Code Point.
> 
> At the last IETF meeting I got the impression that more 
> detailed QoS parameters should be discussed in another 
> document. In fact there is already one that proposes more 
> detailed parameters.
> 
> Ciao
> Hannes
> 
> Congdon, Paul T (ProCurve) wrote:
> > We are very near publishing the next version with all of 
> the filtering 
> > issues resolved.  I would like to publish this version and see how 
> > well that draft proceeds.  If the filtering function 
> continues to hold 
> > up this version, then we should consider your proposal.  
> I'll will get 
> > a firm date on when the next version will be published.
> > 
> > Paul
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked]
> >>[mailto:[email-masked]] On Behalf Of Bernard Aboba
> >>Sent: Monday, January 02, 2006 1:08 AM
> >>To: [email-masked]
> >>Subject: A Proposal for Moving Forward on draft-ietf-radext-ieee802
> >>
> >>It is now more than 6 months since draft-ietf-radext-ieee802 went 
> >>through WG last call, and progress on resolving the Issues from WG 
> >>last call has been slow.  This document is now a year 
> behind schedule 
> >>-- and
> >>counting.   We 
> >>need to find a way to make more rapid progress.
> >>
> >>Looking over the Last Call issues, it would appear that the 
> majority 
> >>of them relate to the filtering functionality, and relatively few 
> >>comments relate to the VLAN and Priority functionality.
> >>
> >>In order to enable this document to be completed without further 
> >>delays, I would like to propose that the Filtering functionality be 
> >>removed from this document, and allowed to progress separately.
> >>
> >>This would allow for an -01 version of this documented to be posted 
> >>within the next two weeks, followed by a two week WG last call, and 
> >>submission to the IESG by IETF 65.
> >>
> >>
> >>
> >>--
> >>to unsubscribe send a message to
> >>[email-masked] with the word 'unsubscribe' 
> in a single 
> >>line as the message text body.
> >>archive: <http://psg.com/lists/radiusext/>
> >>
> > 
> > --
> > to unsubscribe send a message to 
> [email-masked] with 
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> > 
> > 
> 
> 

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

Delivery-date: Mon, 02 Jan 2006 21:03:53 +0000
Content-class: urn:content-classes:message
Subject: RE: A Proposal for Moving Forward on draft-ietf-radext-ieee802
Date: Mon, 2 Jan 2006 13:02:44 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Bernard Aboba <> supposedly scribbled:

> It is now more than 6 months since draft-ietf-radext-ieee802 went
> through WG last call, and progress on resolving the Issues from WG
> last call has been  
> slow.  This document is now a year behind schedule -- and counting.  
> We 
> need to find a way to make more rapid progress.

One thing that might be helpful is if the authors would actually publish a new version once in a while...

> 
> Looking over the Last Call issues, it would appear that the majority
> of them relate to the filtering functionality, and relatively few
> comments relate to the VLAN and Priority functionality.  
> 
> In order to enable this document to be completed without further
> delays, I would like to propose that the Filtering functionality be
> removed from this document, and allowed to progress separately.  
> 
> This would allow for an -01 version of this documented to be posted
> within the next two weeks, followed by a two week WG last call, and
> submission to the IESG by IETF 65.  

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Mon, 02 Jan 2006 20:30:27 +0000
Date: Mon, 02 Jan 2006 21:29:55 +0100
From: Hannes Tschofenig <[email-masked]>
To: "Congdon, Paul T (ProCurve)" <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked],  "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
Subject: Re: A Proposal for Moving Forward on draft-ietf-radext-ieee802

Hi Paul,

what are your plans regarding the usage of the QoS-Filter-Rule
described in Section 3.6 of <draft-ietf-radext-ieee802-00.txt>?

Currently the draft only points to Section 4.3 of RFC 3588. RFC 3588,
however, only specifies the ability to carry a flow identifier (referred 
as IPFilterRule) with a DiffServ Code Point.

At the last IETF meeting I got the impression that more detailed QoS 
parameters should be discussed in another document. In fact there is 
already one that proposes more detailed parameters.

Ciao
Hannes

Congdon, Paul T (ProCurve) wrote:
> We are very near publishing the next version with all of the filtering
> issues resolved.  I would like to publish this version and see how well
> that draft proceeds.  If the filtering function continues to hold up
> this version, then we should consider your proposal.  I'll will get a
> firm date on when the next version will be published.
> 
> Paul 
> 
> 
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Bernard Aboba
>>Sent: Monday, January 02, 2006 1:08 AM
>>To: [email-masked]
>>Subject: A Proposal for Moving Forward on draft-ietf-radext-ieee802
>>
>>It is now more than 6 months since draft-ietf-radext-ieee802 
>>went through WG last call, and progress on resolving the 
>>Issues from WG last call has been 
>>slow.  This document is now a year behind schedule -- and 
>>counting.   We 
>>need to find a way to make more rapid progress.
>>
>>Looking over the Last Call issues, it would appear that the 
>>majority of them relate to the filtering functionality, and 
>>relatively few comments relate to the VLAN and Priority functionality.
>>
>>In order to enable this document to be completed without 
>>further delays, I would like to propose that the Filtering 
>>functionality be removed from this document, and allowed to 
>>progress separately.
>>
>>This would allow for an -01 version of this documented to be 
>>posted within the next two weeks, followed by a two week WG 
>>last call, and submission to the IESG by IETF 65.
>>
>>
>>
>>--
>>to unsubscribe send a message to 
>>[email-masked] with the word 'unsubscribe' in 
>>a single line as the message text body.
>>archive: <http://psg.com/lists/radiusext/>
>>
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 
> 

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

Delivery-date: Mon, 02 Jan 2006 16:51:29 +0000
Content-class: urn:content-classes:message
Subject: RE: A Proposal for Moving Forward on draft-ietf-radext-ieee802
Date: Mon, 2 Jan 2006 08:50:52 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>

We are very near publishing the next version with all of the filtering
issues resolved.  I would like to publish this version and see how well
that draft proceeds.  If the filtering function continues to hold up
this version, then we should consider your proposal.  I'll will get a
firm date on when the next version will be published.

Paul 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Monday, January 02, 2006 1:08 AM
> To: [email-masked]
> Subject: A Proposal for Moving Forward on draft-ietf-radext-ieee802
> 
> It is now more than 6 months since draft-ietf-radext-ieee802 
> went through WG last call, and progress on resolving the 
> Issues from WG last call has been 
> slow.  This document is now a year behind schedule -- and 
> counting.   We 
> need to find a way to make more rapid progress.
> 
> Looking over the Last Call issues, it would appear that the 
> majority of them relate to the filtering functionality, and 
> relatively few comments relate to the VLAN and Priority functionality.
> 
> In order to enable this document to be completed without 
> further delays, I would like to propose that the Filtering 
> functionality be removed from this document, and allowed to 
> progress separately.
> 
> This would allow for an -01 version of this documented to be 
> posted within the next two weeks, followed by a two week WG 
> last call, and submission to the IESG by IETF 65.
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Mon, 02 Jan 2006 09:17:37 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: A plan for moving forward on RFC 2618bis-2621bis
Date: Mon, 02 Jan 2006 01:17:33 -0800

These documents have now completed WG last call, with 5 issues being raised, 
three of which are closed.  I'd like to propose that the editors close all 
the open issues within two weeks so that we can spin a new version and get 
the documents on the IESG agenda for the next teleconference.

These documents are now more than a year behind schedule for what was to be 
a relatively minor update.  It's time to move on.

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

Delivery-date: Mon, 02 Jan 2006 09:15:26 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: A plan for moving forward on the RFC 3576 MIB Documents
Date: Mon, 02 Jan 2006 01:15:21 -0800

These documents have completed WG last call, and from what I can tell there 
is only a single open Issue (149).  I would therefore propose that the 
editors prepare a new version of these documents by next week, so that we 
can get the RFC 3576 MIBs on the IESG agenda immediately.

The RFC 3576 MIBs are only a month behind schedule, but there seems to be 
little reason for further delay.  Let's wrap this up ASAP.

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

Delivery-date: Mon, 02 Jan 2006 09:11:57 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: A proposal for moving forward on draft-ietf-radext-digest-auth-06.txt
Date: Mon, 02 Jan 2006 01:11:55 -0800

This document has now gone through IESG review, with 4 issues being raised: 
Issues 150, 151, 152 and 157 (possible reject).

Given that 3GPP2 depends on this document which is already more than a year 
behind schedule, I would like to propose that the editors focus on resolving 
the four open issues within the next two weeks, so that an -07 version of 
this document can be submitted by the end of January.  This would enable the 
Digest Authentication document to enter the RFC Editor queue by IETF 65.

The RADIUS Digest Authentication document has been "in progress" for long 
enough.  It's time to wrap it up.

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

Delivery-date: Mon, 02 Jan 2006 09:08:26 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: A Proposal for Moving Forward on draft-ietf-radext-ieee802
Date: Mon, 02 Jan 2006 01:08:03 -0800

It is now more than 6 months since draft-ietf-radext-ieee802 went through WG 
last call, and progress on resolving the Issues from WG last call has been 
slow.  This document is now a year behind schedule -- and counting.   We 
need to find a way to make more rapid progress.

Looking over the Last Call issues, it would appear that the majority of them 
relate to the filtering functionality, and relatively few comments relate to 
the VLAN and Priority functionality.

In order to enable this document to be completed without further delays, I 
would like to propose that the Filtering functionality be removed from this 
document, and allowed to progress separately.

This would allow for an -01 version of this documented to be posted within 
the next two weeks, followed by a two week WG last call, and submission to 
the IESG by IETF 65.

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

Envelope-to: [email-masked]
Delivery-date: Mon, 02 Jan 2006 07:16:32 +0000
From: "Alan DeKok" <[email-masked]>
To: Henrik Nordstrom <[email-masked]>
Subject: Re: draft-ietf-radext-digest-auth06.txt Digest MD5-sess 
Cc: [email-masked]
Date: Mon, 02 Jan 2006 02:21:23 -0500
Message-Id: <[email-masked]>

Henrik Nordstrom <[email-masked]> wrote:
> Has there been any thought of allowing RADIUS to be used for session based 
> MD5-Sess authentication, where processing of further authentication within 
> the same session is carried out by the radius client (i.e. HTTP 
> server/proxy) rather than the RADIUS server?

  Not really.  The discussion surrounding the Digest-HA1 attribute was
about solving a different problem.

  http://www.drizzle.com/~aboba/RADEXT/.  See the discussion in "Issue
8: Rspauth generation...".

> This is quite interesting in HTTP applications, where quite many requests 
> can be seen within the same session and at a relatively high rate. (i.e. 
> thousands of requests/second, for a active end-user population of a few 
> thousands). Having the bulk of the authentication verifications carried 
> out in the RADIUS client (HTTP server/proxy) can significantly reduce the 
> load on the RADIUS server and greatly improve the request latency 
> (quality) of the service provided.

  I don't think there's any objection to that point.  The objection is
elsewhere, to the change in the security model of RADIUS.

  RADIUS is intended to have the RADIUS server perform authentication.
If the RADIUS client caches information and "short-circuits"
subsequent authentication requests from the user, then I would say
that such behavior is outside of the scope of the RADIUS standards.
Implementations may choose to do what they want, but the standards
should follow design goals and best practices.

  Alan DeKok.

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

Delivery-date: Mon, 02 Jan 2006 01:00:53 +0000
Date: Thu, 29 Dec 2005 05:32:03 +0100 (CET)
From: Henrik Nordstrom <[email-masked]>
To: [email-masked]
Subject: draft-ietf-radext-digest-auth06.txt Digest MD5-sess

Has there been any thought of allowing RADIUS to be used for session based 
MD5-Sess authentication, where processing of further authentication within 
the same session is carried out by the radius client (i.e. HTTP 
server/proxy) rather than the RADIUS server?

This is quite interesting in HTTP applications, where quite many requests 
can be seen within the same session and at a relatively high rate. (i.e. 
thousands of requests/second, for a active end-user population of a few 
thousands). Having the bulk of the authentication verifications carried 
out in the RADIUS client (HTTP server/proxy) can significantly reduce the 
load on the RADIUS server and greatly improve the request latency 
(quality) of the service provided.

The principle behind this is that the MD5-sess hash A1 (Digest-HA1, aka 
'session key' in RFC2617) attribute is given to the client (HTTP 
server/proxy) even if qop=auth (or perhaps even missing). This allows the 
HTTP server/proxy to internally process further requests in the same 
session (same server side nonce), considerably reducing the load on the 
RADIUS server.

Today the wordings in draft-ietf-radext-digest-auth06.txt forbids this 
mode of operation, and one has to loop via qop=auth-int to fool the RADIUS 
server into a mode allowing for this, even if . The following quite modest 
changes is needed to 
allow for RADIUS to be used in such conditions:

1.3.  Overview
3.1.  RADIUS Client Behavior

here one may want to add a section describing this optional behavior of 
the client.

3.2.  RADIUS Server Behavior

Add the following condition

     o  If the Digest-Qop attribute's value is 'auth' and the
        Digest-Algorithm attribute's value is 'MD5-sess' the RADIUS
        server MAY add a Digest-HA1 attribute into the Access-Accept
        packet to allow the client to process further authentication
        requests within the same session.

4.19.  Digest-HA1 attribute

Here the qop related restriction on when this attribute may be sent needs 
to be dropped. Having restrictions here is also in large redundant with 
section 3.2 I think.

For security reasons I would also add a recommendation to restrict the 
MD5-sess case (including qop=auth-int) to when the RADIUS server has 
generated the Digest-Nonce. Sending MD5-sess Digest-HA1 in the mode where 
the RADIUS client has generated the nonce allows for session theft if the 
attacker can listen to the external traffic and also query the RADIUS 
server, even if he can not see the traffic between the actual RADIUS 
client used and the RADIUS server.

Regards
Henrik

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