Subject: Re: Thoughts on Requirements for RADIUS crypto-agility
From: Hannes Tschofenig <[email-masked]>
To: "David B. Nelson" <[email-masked]>
Cc: 'radext mailing list' <[email-masked]>
Date: Wed, 28 Feb 2007 16:51:15 +0100

Hi David,

here are my thoughts. Let me start with a differentiation between
a) authentication and key exchange  (including the negotiation of 
algorithms)
b) protection of the messages.

As you mention one could use IPsec (together with IKE/IKEv2) to make the 
entire discussion irrelevant.

Assuming that IPsec is not used one obviously needs to consider (a) and 
(b) to offer a complete solution.
So, here are useful options:

1) DTLS
Provides (a) and (b) in one proposal.
2) IKEv1 + DoI for RADIUS packet protection security
Uses IKEv1 for (a) and per-packet protection for (b)
3) DTLS + sort-of-DoI for RADIUS packet protection security (as used 
with DTLS based media security proposal)
Uses DTLS handshake for (a) and per-packet protection for (b)

Do I entirely miss something here?

Ciao
Hannes

I would deprecate the per-packet David B. Nelson wrote:
> As noted in the previous message, the first stage in the development of 
> a RADIUS crypto-agility solution is to formulate a requirements statement. 
>
> A straw-man set of requirements is included below:
>
> OVERALL APPROACH
>
> 1. RADIUS crypto-agility solutions are not restricted to utilizing 
> technology described in existing RFCs.  Since RADIUS over IPsec is 
> already described in RFC 3162 and 3579, this technique is already 
> available to those who wish to use it.  Therefore it is expected that 
> proposals will utilize other techniques. 
>
> SECURITY SERVICES
>
> 2. Proposals MUST support the negotiation of cryptographic 
> algorithms for per-packet integrity/authentication 
> protection.  Support for confidentiality of entire RADIUS 
> packets is OPTIONAL.  However, proposals MUST support the negotiation of 
> algorithms for encryption (sometimes referred to as "hiding") of RADIUS 
> attributes.  If possible, it is desirable for proposals to provide for the 
> encryption of existing attributes.  This includes existing "hidden" 
> attributes as well as attributes (such as location attributes) that 
> require confidentiality. 
>
> 3. Proposals MUST support replay protection.  It has been noted that 
> existing mechanisms for replay protection of Accounting-Request/Response, 
> CoA-Request/Response and Disconnect-Request/Response messages are 
> inadequate.
>
> 4. Crypto-agility solutions need to specify mandatory-to-implement
> algorithms for each mechanism.
>
> BACKWARD COMPATIBILITY
>
> 5. Solutions to the problem need to demonstrate backward compatibility 
> with existing RADIUS implementations.  That is, a crypto-agility
> solution needs to be able to send packets that a legacy RADIUS 
> client or server will receive and process successfully.  Similarly, a 
> crypto-agility solution needs to be capable of receiving and processing 
> packets from a legacy RADIUS client or server. 
>  
> 6. Crypto-agility solutions need to avoid security compromise, even
> in situations where the existing cryptographic algorithms utilized by 
> RADIUS implementations are shown to be weak enough to provide little or no 
> security (e.g. in event of compromise of the RADIUS shared secret).  
> Included in this would be protection against bidding down attacks. 
>  
> INTEROPERABILITY AND CHANGE CONTROL
>
> 7. Proposals need to indicate a willingness to cede change control to the 
> IETF. 
>
> 8. Crypto-agility solutions need to be interoperable between independent 
> implementations based purely on the information provided in the 
> specification. 
>  
> SCOPE OF WORK
>
> 9. Crypto-agility solutions need to apply to all RADIUS packet types, 
> including Access-Request, Challenge, Reject & Accept, 
> Accounting-Request/Response, and CoA/Disconnect messages. 
>  
> 10. Proposals MUST include a Diameter compatibility section. 
>
> 11. Crypto-agility solutions should not require fundamental changes to the 
> RADIUS operational model, such as the introduction of new commands or 
> maintenance of state on the RADIUS server.  Similarly, the addition of 
> new capabilities to the RADIUS protocol is out of scope; a proposal should 
> focus on the crypto-agility problem and nothing else.  For example, 
> proposals should not require new attribute formats or include 
> definition of new RADIUS services.  Unless modified, the restrictions 
> in the RADEXT WG charter apply.  
>
> Note that for the purposes of this work, the RADEXT WG charter restriction
> against definition of "new security mechanisms" should be interpreted as
> prohibiting changes to the basic RADIUS packet format (e.g. headers), but
> permits new crypto-algorithms to be substituted for use in existing 
> security mechanisms.
>
> Regards,
>
> Bernard Aboba
> Dave Nelson
>
> RADEXT Co-Chairs
>
>
>
>
> --
> to unsubscribe send 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, 26 Feb 2007 13:36:39 +0000
Date: Mon, 26 Feb 2007 14:36:12 +0100
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: 'radext mailing list' <[email-masked]>,  'Bernard Aboba' <[email-masked]>
Subject: Re: Some important IETF-68 deadlines and request for agenda items

David B. Nelson wrote:
> Please let the chairs know if you have agenda items for discussion during
> the RADEXT session at IETF-68.  Please include in your request the topic
> description, name of the presenter, time requested, and any relevant
> Internet-Draft URL.

  I would like an item on the Agenda:

Topic: RADIUS + DTLS
Presenter: Alan DeKok
Time: 10 minutes (5 min presentation + 5 min discussion)
URL: http://deployingradius.com/ietf/draft-dekok-radext-dtls-00.txt

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog

--
to unsubscribe send 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, 26 Feb 2007 13:20:30 +0000
Date: Mon, 26 Feb 2007 14:19:23 +0100
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: RADIUS crypto-agility straw-man proposal

  I do not have significant comments on the straw-man set of
requirements.  Therefore, I have a straw-man proposal.

http://deployingradius.com/ietf/draft-dekok-radext-dtls-00.txt

  It was just submitted to the I-D editor, so it should make the -00
deadline.

  The content is a little rough, but the general idea should be
adequately covered.  In short, "RADIUS + DTLS" == "better security".

  Other groups are using DTLS for securing pre-existing UDP protocols.
One draft (draft-jennings-sip-dtls-00.txt) is about 3 pages long, and
says little other than "use DTLS".  That would appear to indicate that
it may be that easy to add DTLS support to RADIUS.

  Alan DeKok.

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

Delivery-date: Mon, 26 Feb 2007 10:10:15 +0000
Date: Mon, 26 Feb 2007 11:09:25 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked],  [email-masked]
Subject: Re: Thoughts on Requirements for RADIUS crypto-agility

Bernard Aboba wrote:
>>   I am sure we will get clarification on the issues. :)
> 
> Can you suggest improved text?

  It's hard to come up with something that's clear, and at the same time
descriptive.  The issue isn't maintenance of state, as servers already
maintain caches of sent packets, SSL information for ongoing EAP
sessions, and "live/dead" status of home servers when proxying.

  Those kinds of state are acceptable, and I would guess that minor
additions to those kinds of state is acceptable, also.  e.g. additional
information per home server such as the RFC 3539 watchdog timer intervals.

...
  11. Crypto-agility solutions should not require fundamental changes to
the RADIUS operational model, such as the introduction of new commands,
and should require maintenance of minimal additional state on the RADIUS
server.
...

  e.g. TCP has send/recv windows for bytes.  We could add packet
send/recv windows to RADIUS, which would also serve to limit the number
of outstanding packets to a server, and help manage load.  That may be
acceptable amounts of state, even if it doesn't solve the replay problem.

  Alan DeKok.

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

Delivery-date: Sun, 25 Feb 2007 18:39:38 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: Thoughts on Requirements for RADIUS crypto-agility
Date: Sun, 25 Feb 2007 10:38:35 -0800

Glen Zorn stated:

"I have no idea what you mean: does the replay protection stuff just apply 
to the crypto algorithm negotiation or RADIUS as a whole?"

Item 3 refers to replay protection of RADIUS messages, so that would appear 
to be covered:

"3. Proposals MUST support replay protection.  It has been noted that
existing mechanisms for replay protection of Accounting-Request/Response,
CoA-Request/Response and Disconnect-Request/Response messages are
inadequate."

Are you suggesting that replay protection of crypto-algorithm negotiation be 
added?

--
to unsubscribe send 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, 23 Feb 2007 19:23:31 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: RE: Thoughts on Requirements for RADIUS crypto-agility
Date: Fri, 23 Feb 2007 14:23:00 -0500

Avi Lior writes...

> Given the charter and specifically:
> 
> "- No new security mechanisms will be defined for protecting RADIUS."
> 
> Why do you think we can do this work?

Because crypto-agility is not being interpreted as a "new" security
mechanism, but an upgrade to existing ones.

Even if you don't personally accept that interpretation, the Security Area
Directorate has requested that IETF WGs undertake this analysis and provide
corrective action where feasible -- introduce crypto-algorithm negotiation.
Our Area Directors approved adding this work item to our charter.  The
chairs feel that this is sufficient permission to undertake the work.

--
to unsubscribe send 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, 23 Feb 2007 19:11:49 +0000
Subject: RE: Thoughts on Requirements for RADIUS crypto-agility
Date: Fri, 23 Feb 2007 14:11:18 -0500
From: "Avi Lior" <[email-masked]>
To: "David B. Nelson" <[email-masked]>, "radext mailing list" <[email-masked]>

Given the charter and specifically:

"- No new security mechanisms will be defined for protecting RADIUS."=20

Why do you think we can do this work?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David B. Nelson
Sent: Thursday, February 22, 2007 6:23 PM
To: 'radext mailing list'
Subject: Thoughts on Requirements for RADIUS crypto-agility

As noted in the previous message, the first stage in the development of
a RADIUS crypto-agility solution is to formulate a requirements
statement.=20

A straw-man set of requirements is included below:

OVERALL APPROACH

1. RADIUS crypto-agility solutions are not restricted to utilizing
technology described in existing RFCs.  Since RADIUS over IPsec is
already described in RFC 3162 and 3579, this technique is already
available to those who wish to use it.  Therefore it is expected that
proposals will utilize other techniques.=20

SECURITY SERVICES

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

3. Proposals MUST support replay protection.  It has been noted that
existing mechanisms for replay protection of
Accounting-Request/Response, CoA-Request/Response and
Disconnect-Request/Response messages are inadequate.

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

BACKWARD COMPATIBILITY

5. Solutions to the problem need to demonstrate backward compatibility
with existing RADIUS implementations.  That is, a crypto-agility
solution needs to be able to send packets that a legacy RADIUS client or
server will receive and process successfully.  Similarly, a
crypto-agility solution needs to be capable of receiving and processing
packets from a legacy RADIUS client or server.=20
=20
6. Crypto-agility solutions need to avoid security compromise, even in
situations where the existing cryptographic algorithms utilized by
RADIUS implementations are shown to be weak enough to provide little or
no security (e.g. in event of compromise of the RADIUS shared secret). =20
Included in this would be protection against bidding down attacks.=20
=20
INTEROPERABILITY AND CHANGE CONTROL

7. Proposals need to indicate a willingness to cede change control to
the IETF.=20

8. Crypto-agility solutions need to be interoperable between independent
implementations based purely on the information provided in the
specification.=20
=20
SCOPE OF WORK

9. Crypto-agility solutions need to apply to all RADIUS packet types,
including Access-Request, Challenge, Reject & Accept,
Accounting-Request/Response, and CoA/Disconnect messages.=20
=20
10. Proposals MUST include a Diameter compatibility section.=20

11. Crypto-agility solutions should not require fundamental changes to
the RADIUS operational model, such as the introduction of new commands
or maintenance of state on the RADIUS server.  Similarly, the addition
of new capabilities to the RADIUS protocol is out of scope; a proposal
should focus on the crypto-agility problem and nothing else.  For
example, proposals should not require new attribute formats or include
definition of new RADIUS services.  Unless modified, the restrictions in
the RADEXT WG charter apply. =20

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

Regards,

Bernard Aboba
Dave Nelson

RADEXT Co-Chairs

--

to unsubscribe send 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, 23 Feb 2007 17:58:06 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Review of draft-ietf-radext-rfc3576bis
Date: Fri, 23 Feb 2007 09:57:41 -0800

Section 1.3 Terminology

RFC 3576bis uses different terminology than the RFC 3576 MIBs.

Should we change the terminology in RFC 3576bis to utilize the terms defined 
in the RFC 3576 MIB documents?  This would involve changing uses of the term 
"RADIUS client"/"NAS" to "Dynamic Authorization Server (DAS)" and "RADIUS 
server" to "Dynamic Authorization Client (DAC)".    Here are the definitions 
of these terms from RFC 4673 Section 1.2:

   Dynamic Authorization Server (DAS)

   The component that resides on the NAS that processes the Disconnect
   and Change-of-Authorization (CoA) Request packets [RFC3576] sent by
   the Dynamic Authorization Client.

   Dynamic Authorization Client (DAC)

   The component that sends Disconnect and CoA-Request packets to the
   Dynamic Authorization Server.  Although this component often resides
   on the RADIUS server, it is also possible for it to be located on a
   separate host, such as a Rating Engine.

   Dynamic Authorization Server Port

   The UDP port on which the Dynamic Authorization Server listens for
   the Disconnect and CoA requests sent by the Dynamic Authorization
   Client.

Section 2.2

   The following attributes MAY be sent in a CoA-Request:

   Filter-ID (11) -        Indicates the name of a data filter list
                           to be applied for the session that the
                           identification attributes map to.

   NAS-Filter-Rule (TBD) - Provides a filter list to be applied
                           for the session that the identification
                           attributes map to.

Maybe we should include a reference to the NAS-Filter-Rule RFC?  Also, the 
TBD should be filled in when an attribute number is assigned.

Section 2.3

      Packets received with an invalid Code field MUST be
      silently discarded.  RADIUS codes (decimal) for this extension are
      assigned as follows:

      40 - Disconnect-Request [RFC2882]
      41 - Disconnect-ACK [RFC2882]
      42 - Disconnect-NAK [RFC2882]
      43 - CoA-Request [RFC2882]
      44 - CoA-ACK [RFC2882]
      45 - CoA-NAK [RFC2882]

Rather than citing RFC 2882 for the command allocation, RFC 3575 should be 
cited instead.  The reference to RFC 2882 can be removed.

Section 2.3

      In Disconnect and CoA-Request packets, all Attributes are treated
      as mandatory.  A NAS MUST respond to a CoA-Request containing one
      or more unsupported Attributes or Attribute values with a CoA-NAK;
      a Disconnect-Request containing one or more unsupported Attributes
      or Attribute values MUST be answered with a Disconnect-NAK.

RFC 3576 suggests use of the Event-Timestamp for replay protection.  This 
requires synchronized clocks, but even when that it is available, the replay 
window is quite large.  The solution (discussed in Issue 139) was to add a 
Nonce attribute.   However, the text above suggests that implementations 
sending a Nonce attribute to a legacy implementation in a 
CoA-Request/Disconnect-Request will receive a CoA-NAK or Disconnect-NAK in 
return.  Unfortunately, the Error-Cause attribute value Unsupported 
Attribute (401) doesn't provide a hint of what the offending attribute was.  
Maybe we should add text suggesting that a Nonce attribute should only be 
sent by a RADIUS server to a NAS that is known to support it?

      As a result, attributes
      beyond those specified in Section 3.5 SHOULD NOT be included
      within Disconnect or CoA packets, since this could produce
      unpredictable results.

Actually, the results are not unpredictable -- the NAS will send a 
Disconnect-NAK/CoA-NAK, right?  I would suggest that this sentence be 
replaced with "As a result, if attributes beyond those specified in Section 
3.5 are included with Disconnect-Request or CoA-Request packets, the RADIUS 
server may receive a Disconnect-NAK/CoA-NAK in response, possibly containing 
an Error-Cause attribute with value Unsupported Attribute (401)."

Section 3.3

      A summary of the Nonce Attribute format is shown below.  The
      fields are transmitted from left to right.

       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     |             Value
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Value (cont)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Is a 32-bit value large enough?  Shouldn't this be at least 64-bits and 
probably more like 128-bits?

Section 3.5

   [Note 8] A Nonce Attribute SHOULD be included in a CoA-Request or
   Disconnect-Request packet that is not protected by IPsec or does not
   contain an Event-Timestamp Attribute, so as to prevent replay
   attacks.  A Nonce Attribute MAY also be included in CoA-ACK, CoA-NAK,
   Disconnect-ACK, Disconnect-NAK, or Accounting-Request packets.

It seems like a bad idea for a NAS to include a Nonce attribute in a 
CoA-ACK, CoA-NAK, Disconnect-ACK or Disconnect-NAK if a Nonce attribue 
wasn't included in the corresponding CoA-Request or Disconnect-Request.

Section 4

    #    Error-Cause Attribute Value   Result-Code AVP
   ---   ---------------------------  ------------------------
   201   Residual Session Context     DIAMETER_SUCCESS
         Removed
   202   Invalid EAP Packet           DIAMETER_LIMITED_SUCCESS
         (Ignored)
   401   Unsupported Attribute        DIAMETER_AVP_UNSUPPORTED
   402   Missing Attribute            DIAMETER_MISSING_AVP
   403   NAS Identification           DIAMETER_REALM_NOT_SERVED
         Mismatch
   404   Invalid Request              DIAMETER_UNABLE_TO_COMPLY
   405   Unsupported Service          DIAMETER_COMMAND_UNSUPPORTED
   406   Unsupported Extension        DIAMETER_APPLICATION_UNSUPPORTED
   501   Administratively             DIAMETER_AUTHORIZATION_REJECTED
         Prohibited
   502   Request Not Routable         DIAMETER_UNABLE_TO_DELIVER
         (Proxy)
   503   Session Context Not Found    DIAMETER_UNKNOWN_SESSION_ID
   504   Session Context Not          DIAMETER_AUTHORIZATION_REJECTED
         Removable
   505   Other Proxy Processing       DIAMETER_UNABLE_TO_COMPLY
         Error
   506   Resources Unavailable        DIAMETER_RESOURCES_EXCEEDED
   507   Request Initiated            DIAMETER_SUCCESS

Is this mapping of Error-Cause attribute values to Result-Code AVPs correct?

Section 5 IANA Considerations

Much of this section can be deleted since the values were already allocated 
in RFC 3576.  The only text that seems necessary relates to an allocation 
for the Nonce attribute:

   This specification does not create any new registries.

   This document uses the RADIUS [RFC2865] namespace, see
   <http://www.iana.org/assignments/radius-types>.  Allocation of one
   update for the section "RADIUS Attribute Types" is requested. The
   RADIUS attribute for which a value is requested is:

   TBD - Nonce

Section 6.1

Alan DeKok has pointed out that the RPF check suggested in this section is 
somewhat cumbersome. Do we have an alternative to suggest?

--
to unsubscribe send 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, 23 Feb 2007 17:34:58 +0000
Content-class: urn:content-classes:message
Subject: RE: Thoughts on Requirements for RADIUS crypto-agility
Date: Fri, 23 Feb 2007 09:34:38 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Bernard Aboba <mailto:[email-masked]> allegedly scribbled on
Friday, February 23, 2007 9:14 AM:

>>   I am sure we will get clarification on the issues. :)
>=20
> Can you suggest improved text?

I could, but the problem is I have no idea what you mean: does the
replay protection stuff just apply to the crypto algorithm negotiation
or RADIUS as a whole?

--
to unsubscribe send 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, 23 Feb 2007 17:24:59 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: RE: Thoughts on Requirements for RADIUS crypto-agility
Date: Fri, 23 Feb 2007 12:06:29 -0500

Alan DeKok writes...

>   I am sure we will get clarification on the issues. :)

That's the purpose of a straw-man proposal, to spawn discussion on the list,
hopefully leading to WG consensus.

--
to unsubscribe send 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, 23 Feb 2007 17:14:21 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Thoughts on Requirements for RADIUS crypto-agility
Date: Fri, 23 Feb 2007 09:13:50 -0800

>   I am sure we will get clarification on the issues. :)

Can you suggest improved text?

--
to unsubscribe send 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, 23 Feb 2007 16:45:49 +0000
Date: Fri, 23 Feb 2007 17:45:06 +0100
From: Alan DeKok <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  radext mailing list <[email-masked]>
Subject: Re: Thoughts on Requirements for RADIUS crypto-agility

Glen Zorn (gwz) wrote:
> Initially, I agreed with you on this, bur re-reading David's message I
> wonder if the replay protection stuff just applies to the crypto
> algorithm negotiation mechanism?

  Perhaps.  I think there's also a need for replay protection in RADIUS.
 The suggested use of Event-Timestamp in Section 5.4 of RFC 3576 is
better than nothing.  But it doesn't protect the server from replay
attacks within a large window, so it's usefulness is limited.

>  If not, the straw-man requirements
> would appear to be self-contradictory since requirement 11 states
> "Similarly, the addition of new capabilities to the RADIUS protocol is
> out of scope; a proposal should focus on the crypto-agility problem and
> nothing else." yet (IMHO) strong replay protection is certainly a new
> capability for RADIUS & it is a crypto application, rather than an
> agility thing.

  I am sure we will get clarification on the issues. :)

  Alan DeKok.

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

Delivery-date: Fri, 23 Feb 2007 16:19:09 +0000
Content-class: urn:content-classes:message
Subject: RE: Thoughts on Requirements for RADIUS crypto-agility
Date: Fri, 23 Feb 2007 08:18:03 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "David B. Nelson" <[email-masked]>
Cc: "radext mailing list" <[email-masked]>

Alan DeKok <> allegedly scribbled on Friday, February 23, 2007 2:39 AM:

...

>=20
>   A NIT (or question):
>=20
> ...
>> 3. Proposals MUST support replay protection. ...
>> 11. Crypto-agility solutions should not require fundamental changes
>> to=20
>> the RADIUS operational model, such as the introduction of new
>> commands=20
>> or maintenance of state on the RADIUS server.
>=20
>   Most methods to obtain replay protection involve maintenance of
> some kind of state on the RADIUS server.  Maybe global server state,
> or per-client state. =20

Either that or globally synchronized clocks; do we really want to go
there?

>=20
>   I also see reply protection as being potentially independent of
> crypto work.=20

Initially, I agreed with you on this, bur re-reading David's message I
wonder if the replay protection stuff just applies to the crypto
algorithm negotiation mechanism?  If not, the straw-man requirements
would appear to be self-contradictory since requirement 11 states
"Similarly, the addition of new capabilities to the RADIUS protocol is
out of scope; a proposal should focus on the crypto-agility problem and
nothing else." yet (IMHO) strong replay protection is certainly a new
capability for RADIUS & it is a crypto application, rather than an
agility thing.

...

--
to unsubscribe send 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, 23 Feb 2007 11:57:21 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: Some important IETF-68 deadlines and request for agenda items
Date: Fri, 23 Feb 2007 06:57:09 -0500

February 26, Monday - Internet Draft submission cut-off for initial document
(-00) by 09:00 ET (14:00 UTC/GMT)

March 5, Monday - Internet Draft final (-01+) submission cut-off by 09:00 ET
(14:00 UTC/GMT)

March 7, Wednesday - Draft Working Group agendas due by 17:00 ET (22:00
UTC/GMT)

Please let the chairs know if you have agenda items for discussion during
the RADEXT session at IETF-68.  Please include in your request the topic
description, name of the presenter, time requested, and any relevant
Internet-Draft URL.

March 12, Monday - Revised Working Group agendas due by 12:00 ET (16:00
UTC/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: Fri, 23 Feb 2007 11:45:57 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: RADEXT session at IETF-68
Date: Fri, 23 Feb 2007 06:45:23 -0500

The most recent draft agenda for IETF-68 has the RADEXT WG meeting on
Wednesday morning.  This is still subject to change, of course, until the
final agenda is published.

WEDNESDAY, March 21, 2007 
0900-1130 Morning Session I 

Karlin II    OPS    radext    RADIUS EXTensions WG 

--
to unsubscribe send 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, 23 Feb 2007 10:40:23 +0000
Date: Fri, 23 Feb 2007 11:39:29 +0100
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: Thoughts on Requirements for RADIUS crypto-agility

David B. Nelson wrote:
> As noted in the previous message, the first stage in the development of 
> a RADIUS crypto-agility solution is to formulate a requirements statement. 
> 
> A straw-man set of requirements is included below:

  A NIT (or question):

...
> 3. Proposals MUST support replay protection.
...
> 11. Crypto-agility solutions should not require fundamental changes to the 
> RADIUS operational model, such as the introduction of new commands or 
> maintenance of state on the RADIUS server.

  Most methods to obtain replay protection involve maintenance of some
kind of state on the RADIUS server.  Maybe global server state, or
per-client state.

  I also see reply protection as being potentially independent of crypto
work.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog

--
to unsubscribe send 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, 22 Feb 2007 23:23:09 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: Thoughts on Requirements for RADIUS crypto-agility
Date: Thu, 22 Feb 2007 18:22:59 -0500

As noted in the previous message, the first stage in the development of 
a RADIUS crypto-agility solution is to formulate a requirements statement. 

A straw-man set of requirements is included below:

OVERALL APPROACH

1. RADIUS crypto-agility solutions are not restricted to utilizing 
technology described in existing RFCs.  Since RADIUS over IPsec is 
already described in RFC 3162 and 3579, this technique is already 
available to those who wish to use it.  Therefore it is expected that 
proposals will utilize other techniques. 

SECURITY SERVICES

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

3. Proposals MUST support replay protection.  It has been noted that 
existing mechanisms for replay protection of Accounting-Request/Response, 
CoA-Request/Response and Disconnect-Request/Response messages are 
inadequate.

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

BACKWARD COMPATIBILITY

5. Solutions to the problem need to demonstrate backward compatibility 
with existing RADIUS implementations.  That is, a crypto-agility
solution needs to be able to send packets that a legacy RADIUS 
client or server will receive and process successfully.  Similarly, a 
crypto-agility solution needs to be capable of receiving and processing 
packets from a legacy RADIUS client or server. 
 
6. Crypto-agility solutions need to avoid security compromise, even
in situations where the existing cryptographic algorithms utilized by 
RADIUS implementations are shown to be weak enough to provide little or no 
security (e.g. in event of compromise of the RADIUS shared secret).  
Included in this would be protection against bidding down attacks. 
 
INTEROPERABILITY AND CHANGE CONTROL

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

8. Crypto-agility solutions need to be interoperable between independent 
implementations based purely on the information provided in the 
specification. 
 
SCOPE OF WORK

9. Crypto-agility solutions need to apply to all RADIUS packet types, 
including Access-Request, Challenge, Reject & Accept, 
Accounting-Request/Response, and CoA/Disconnect messages. 
 
10. Proposals MUST include a Diameter compatibility section. 

11. Crypto-agility solutions should not require fundamental changes to the 
RADIUS operational model, such as the introduction of new commands or 
maintenance of state on the RADIUS server.  Similarly, the addition of 
new capabilities to the RADIUS protocol is out of scope; a proposal should 
focus on the crypto-agility problem and nothing else.  For example, 
proposals should not require new attribute formats or include 
definition of new RADIUS services.  Unless modified, the restrictions 
in the RADEXT WG charter apply.  

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

Regards,

Bernard Aboba
Dave Nelson

RADEXT Co-Chairs

--
to unsubscribe send 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, 22 Feb 2007 23:11:57 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: REMINDER:  RADEXT WG last call on the Issues & Fixes Document
Date: Thu, 22 Feb 2007 15:11:26 -0800

This is a reminder of the RADEXT WG last call on the Issues & Fixes 
Document, prior to sending the document to the IESG for consideration as a 
Proposed Standard.

The document is available on the IETF archive here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-01.txt

WG last call will last until March 15, 2007. Comments should be sent to the 
RADEXT WG mailing list ([email-masked]), in the format described on 
the RADEXT Issues list:
http://www.drizzle.com/~aboba/RADEXT/

--
to unsubscribe send 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, 22 Feb 2007 21:57:36 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: REMINDER: RADEXT WG Last Call on RFC 3576bis
Date: Thu, 22 Feb 2007 13:57:24 -0800

This is a reminder of the RADEXT WG last call on RFC 3576bis, prior to 
sending the document to the IESG for consideration as a Proposed Standard.

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-00.txt

WG last call will last until March 9, 2007. Comments should be sent to the 
RADEXT WG mailing list ([email-masked]), in the format described on 
the RADEXT Issues list:
http://www.drizzle.com/~aboba/RADEXT/

--
to unsubscribe send 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, 22 Feb 2007 21:56:50 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: REMINDER:  RADEXT WG last call on RFC 4590bis
Date: Thu, 22 Feb 2007 13:56:31 -0800

This is a reminder about the announcement of RADEXT WG last call on RFC 
4590bis, prior to sending the document to the IESG for consideration as a 
Proposed Standard.

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-00.txt

WG last call will last until March 9, 2007. Comments should be sent to the 
RADEXT WG mailing list ([email-masked]), in the format described on 
the RADEXT Issues list:
http://www.drizzle.com/~aboba/RADEXT/

--
to unsubscribe send 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, 22 Feb 2007 21:44:49 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Review of draft-ietf-radext-fixes-01.txt
Date: Thu, 22 Feb 2007 13:44:31 -0800

Aside from the comments included below, this document looks good.

Section 2.6

   Where a NAS offers multiple services, confusion may result with
   respect to interpretation of a Disconnect-Request [RFC3576].  In
   order to prevent confusion a RADIUS Server SHOULD identify the
   session that it desires to terminate as specifically as possible.
   For example, an Acct-Session-Id attribute SHOULD be included in
   Disconnect-Request and CoA-Request packets, rather than just the
   User-Name attribute.

I think this material might better belong in RFC 3576bis.

Section 2.11

   An ISP may desire to support Prefix Delegation at the same time that
   it would like to assign a prefix for the link between the NAS and the
   user.  The intent of the paragraph was to enable the NAS to advertise
   the prefix (such as via a Router Advertisement). If the Framed-
   Routing attribute is used, it is also possible that the prefix would
   be advertised in a routing protocol such as RIPNG.

You might include a reference to the RADIUS Prefix Delegation document
(now in the RFC Editor Queue).

   It appears that the Framed-IPv6-Prefix is used for the link between
   the NAS and CPE only if a /64 prefix is assigned.  When a larger
   prefix is sent, the intent is for the NAS to send a routing
   advertisement containing the information present in the Framed-
   IPv6-Prefix attribute.

Even if a /64 prefix is assigned, I think that the NAS is expected
to send an RA to the CPE, no?  Otherwise I'm not sure how the CPE
could learn the prefix.

The other issue is how the CPE obtains a prefix to use for its own
network, in the case that the CPE is decrementing TTL.  Prefix
Delegation is the mechanism created for that purpose.  If the CPE
is acting as a Bridge or ND-Proxy, then it does not need to request
that a prefix be delegated.  It might make sense to say a few words
about this.

--
to unsubscribe send 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, 22 Feb 2007 21:31:42 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: Thoughts on RADIUS Crypto-agility
Date: Thu, 22 Feb 2007 16:30:41 -0500

The RADEXT WG has a work item relating to RADIUS crypto-agility.  In 
looking at this work item and thinking about how to make progress on it, 
we would like to put forward some thoughts. 
 
RADIUS crypto-agility is about the ability of RADIUS implementations to 
negotiate cryptographic algorithms for use in RADIUS exchanges.  This 
includes the cryptographic algorithms used to protect RADIUS packets, 
as well as the algorithms used to hide RADIUS attributes. 

Today, RADIUS packets are protected by the calculation of an MD5-based 
message integrity check (MIC) within the Authenticator field of packets 
other than the Access-Request.  In addition, the Message-Authenticator 
attribute is available, which utilizes  HMAC-MD5 to authenticate and 
integrity protect RADIUS packets.

A number of RADIUS attributes today support "hiding", in order to prevent 
an attacker from snooping contents over the wire.  These attributes 
include the User-Password and Tunnel-Password attributes, in addition to 
vendor-specific attributes.  Generally the "hiding" mechanisms utilize a 
stream cipher based on MD5.  

It should be noted that the recent work on MD5 collisions does not appear 
to enable compromise of any of the MD5-based mechanisms described above, 
absent knowledge of the RADIUS shared secret.  However, the progress 
toward compromise of the basic cryptographic assumptions made by MD5 has 
lead to a movement toward deprecation of MD5 in many contexts. 

Therefore there appears to be good reason for the RADEXT WG to move 
forward toward development of a backward compatible, interoperable 
mechanism for the negotiation of cryptographic algorithms within RADIUS. 

In moving forward, the proposal is for the RADEXT WG to first discuss the 
requirements for RADIUS crypto-agility and come to consensus, and then to 
solicit proposals satisfying those requirements.   

In order to develop consensus on the requirements as well as 
potential solutions, we would propose that the RADEXT WG consider 
the following process:
 
1. Discuss and refine the requirements for a solution to the problem,
coming to consensus at IETF 68 in Prague.  
 
2. Issue a call for document submissions meeting the problem 
requirements, during IETF 68, requesting documents be submitted for 
consideration within 30 days; 
 
3. Discussion of the proposals on the RADEXT WG list; 
 
4. If consensus emerges, adoption of the winning proposal as a 
Standards Track  WG work item. 

5. If consensus does not emerge, acceptance of one or more documents
with substantial support as Experimental Track WG work items. 
 
6. Completion of work and submission of documents to the IESG. 
 
A separate message proposing a straw-man set of requirements will be posted
to the list to get the process started.

Regards,

Bernard Aboba
Dave Nelson

RADEXT Co-Chairs

--
to unsubscribe send 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, 18 Feb 2007 11:20:14 +0000
From: Peter Nixon <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS
Date: Sun, 18 Feb 2007 13:18:57 +0200
Cc: [email-masked], [email-masked], [email-masked]

On Sun 18 Feb 2007 02:13, Bernard Aboba wrote:
> Review of draft-ietf-geopriv-radius-lo-10.txt
>
> Overview comments:
>
> Overall, this document includes many normative statements relating
> to privacy in a number of sections.   As it stands, this makes it very
> difficult to understand exactly what privacy support will be provided
> in various scenarios.   I would strongly urge that these statements
> be consolidated into a single section.
>
> In terms of RADIUS protocol usage, there are a few problems
> (violation of a MUST NOT provision in RFC 3576, use of non-standard
> RADIUS data types, inappropriate use of complex attributes)
>
> There are also a lot of editorial issues that need to be cleaned up.
>
> Given everything, this  document requires substantial  work before
> it would be suitable for publication as an RFC.
>
> Section 1
>
>    Wireless LAN (WLAN) access networks are being deployed in public
>    places such as airports, hotels, shopping malls, and coffee shops by
>    a diverse set of operators such as cellular network operators (GSM
>    and CDMA), Wireless Internet Service Providers (WISPs), and fixed
>    broadband operators.
>
> As noted later on, these attributes are not limited to use with WLAN
> networks, but the relationship to user location is probably stronger
> with WLAN or LAN access than other access types.  I think you need
> to talk about this.
>
>    When a user executes the network access authentication procedure to
>    such a network, information about the location and ownership of this
>    network needs to be conveyed to the user's home network to which the
>    user has a contractual relationship.
>
> The use of the term "need" seems wrong here, since
> one of the goals of the document is to guard the privacy of location
> information, only providing it where there is "need to know".
>
>    This document describes AAA attributes, which are used by a AAA
>    client or a AAA proxy in an access network, to convey location-
>    related information to the user's home AAA server.
>
> The use of the term "AAA" here is a bit confusing.  If the attributes
> are applicable to both RADIUS and Diameter, this should be explicitly
> stated.
>
>    Although the proposed attributes in this draft are intended for
>    wireless LAN deployments, they can also be used in other types of
>    wireless and wired networks whenever location information is
>    required.
>
> I'd suggest this paragraph be combined with the first paragraph.
>
>    Location information needs to be protected against unauthorized
>    access and distribution to preserve the user's privacy. [10] defines
>    requirements for a protocol-independent model for the access to
>    geographic location information.  The model includes a Location
>    Generator (LG) that creates location information, a Location Server
>    (LS) that authorizes access to location information, a Location
>    Recipient (LR) that requests and receives information, and a Rule
>    Maker (RM) that provides authorization policies to the LS which
>    enforces access control policies on requests to location information.
>
> I would talk a bit more about the privacy model in general terms, such
> as what protections it is designed to provide.
>
> Section 2
>
>    Based on today's protocols we assume that the location information is
>    provided by the access network where the end host is attached.  As
>    part of the network attachment authentication to the AAA server
>    location information is sent from the AAA client to the AAA server.
>
> Earlier, the document refers to use by a AAA proxy.  Could you say
> a few words about where the information originates (e.g. may originate
> on the NAS, or may be added a proxy).  Somewhere it is also worth
> stating that existing RADIUS attributes may also provide location
> information (e.g. NAS-Identifier).
>
>    The authenticated identity might refer to a user, a device or
>    something else.  Although there might often be a user associated with
>    the authentication process (either directly or indirectly; indirectly
>    when a binding between a device and a user exists) there is no
>    assurance that a particular real-world entity (such as a person)
>    triggered this process.
>
> Is the distinction between a user, device or machine identity
> relevant for the purposes of a privacy discussion?  This paragraph
> leaves me wondering whether there is a legal distinction that
> is relevant to the protocol design.
>
>    Since location based authorization is
>    executed based on the network access authentication of a particular
>    "user" it might be reasonable to talk about user's privacy within
>    this document even though scenarios exist where this might not apply
>    (and device or network privacy might be the better term).
>
> Maybe you need to define the term "user" in the document as being
> either a user, device or machine identity in order to clarify this.
>
>    Furthermore, the authors believe that there is a relationship between
>    the NAS (or other nodes in the access network) and the location of
>    the entity that triggered the network access authentication, such as
>    the user.
>
> Why? If the NAS is a VPN server, then the user might be located halfway
> around the world.  Might make more sense to say "depending on the
> type of access being provided, there may be a close relationship...."
> You might give examples:
>
> 1) WLAN has limited range when deployed with an omni-directional
> antenna, so user is probably close to the NAS in geospatial
> (but not necessarily civil) terms.  Also, some WLAN
> access points can use "time of arrival" or other processing
> techniques to determine user location accurately;
> 2) In LAN access, the user can't be further away from the switch
> than cable length will permit.
> 3) Dialup or VPN user could be very far away from the NAS;
>
> If you talk about this a bit, it might help clarify why the document
> is mostly for WLAN/LAN access.
>
>    The NAS might in many cases know the location of the end
>    host through various techniques (e.g., wire databases, wireless
>    triangulation).  Knowing the location of a network (where the user or
>    end host is attached) might in many networks also reveal enough
>    information about the location of the user or the end host.  A
>    similar assumption is also made with regard to the location
>    information obtained via DHCP (see for example [4]).

Also, If you consider 3G/GPRS networks, the NAS that a user connects to is 
typically located in the main operations center of the operator which means 
that the users location if most likely somewhere inside that country, 
however when the user roams (A large and growing number of operator have 
GPRS/3G roaming agreements) they could in-fact be connecting via an operator 
on the other side of the world, yet the NAS at most will know the IP address 
of the SGSN (another device on GSM networks is involved in the whole GPRS 
process, of which each operator has at least one) and will not have an real 
idea where the user is at all...

Other devices in the network (Billing systems etc) may have an "better" idea 
of where the user is (the country for example..) but they also may not know 
this information until several weeks or months later (when billing 
information is exchanged between operators)

Cheers

-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc

--
to unsubscribe send 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, 18 Feb 2007 00:14:45 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS
Date: Sat, 17 Feb 2007 16:13:44 -0800

Review of draft-ietf-geopriv-radius-lo-10.txt

Overview comments:

Overall, this document includes many normative statements relating
to privacy in a number of sections.   As it stands, this makes it very
difficult to understand exactly what privacy support will be provided
in various scenarios.   I would strongly urge that these statements
be consolidated into a single section.

In terms of RADIUS protocol usage, there are a few problems
(violation of a MUST NOT provision in RFC 3576, use of non-standard
RADIUS data types, inappropriate use of complex attributes)

There are also a lot of editorial issues that need to be cleaned up.

Given everything, this  document requires substantial  work before
it would be suitable for publication as an RFC.

Section 1

   Wireless LAN (WLAN) access networks are being deployed in public
   places such as airports, hotels, shopping malls, and coffee shops by
   a diverse set of operators such as cellular network operators (GSM
   and CDMA), Wireless Internet Service Providers (WISPs), and fixed
   broadband operators.

As noted later on, these attributes are not limited to use with WLAN
networks, but the relationship to user location is probably stronger
with WLAN or LAN access than other access types.  I think you need
to talk about this.

   When a user executes the network access authentication procedure to
   such a network, information about the location and ownership of this
   network needs to be conveyed to the user's home network to which the
   user has a contractual relationship.

The use of the term "need" seems wrong here, since
one of the goals of the document is to guard the privacy of location
information, only providing it where there is "need to know".

   This document describes AAA attributes, which are used by a AAA
   client or a AAA proxy in an access network, to convey location-
   related information to the user's home AAA server.

The use of the term "AAA" here is a bit confusing.  If the attributes
are applicable to both RADIUS and Diameter, this should be explicitly
stated.

   Although the proposed attributes in this draft are intended for
   wireless LAN deployments, they can also be used in other types of
   wireless and wired networks whenever location information is
   required.

I'd suggest this paragraph be combined with the first paragraph.

   Location information needs to be protected against unauthorized
   access and distribution to preserve the user's privacy. [10] defines
   requirements for a protocol-independent model for the access to
   geographic location information.  The model includes a Location
   Generator (LG) that creates location information, a Location Server
   (LS) that authorizes access to location information, a Location
   Recipient (LR) that requests and receives information, and a Rule
   Maker (RM) that provides authorization policies to the LS which
   enforces access control policies on requests to location information.

I would talk a bit more about the privacy model in general terms, such
as what protections it is designed to provide.

Section 2

   Based on today's protocols we assume that the location information is
   provided by the access network where the end host is attached.  As
   part of the network attachment authentication to the AAA server
   location information is sent from the AAA client to the AAA server.

Earlier, the document refers to use by a AAA proxy.  Could you say
a few words about where the information originates (e.g. may originate
on the NAS, or may be added a proxy).  Somewhere it is also worth
stating that existing RADIUS attributes may also provide location
information (e.g. NAS-Identifier).

   The authenticated identity might refer to a user, a device or
   something else.  Although there might often be a user associated with
   the authentication process (either directly or indirectly; indirectly
   when a binding between a device and a user exists) there is no
   assurance that a particular real-world entity (such as a person)
   triggered this process.

Is the distinction between a user, device or machine identity
relevant for the purposes of a privacy discussion?  This paragraph
leaves me wondering whether there is a legal distinction that
is relevant to the protocol design.

   Since location based authorization is
   executed based on the network access authentication of a particular
   "user" it might be reasonable to talk about user's privacy within
   this document even though scenarios exist where this might not apply
   (and device or network privacy might be the better term).

Maybe you need to define the term "user" in the document as being
either a user, device or machine identity in order to clarify this.

   Furthermore, the authors believe that there is a relationship between
   the NAS (or other nodes in the access network) and the location of
   the entity that triggered the network access authentication, such as
   the user.

Why? If the NAS is a VPN server, then the user might be located halfway
around the world.  Might make more sense to say "depending on the
type of access being provided, there may be a close relationship...."
You might give examples:

1) WLAN has limited range when deployed with an omni-directional
antenna, so user is probably close to the NAS in geospatial
(but not necessarily civil) terms.  Also, some WLAN
access points can use "time of arrival" or other processing
techniques to determine user location accurately;
2) In LAN access, the user can't be further away from the switch
than cable length will permit.
3) Dialup or VPN user could be very far away from the NAS;

If you talk about this a bit, it might help clarify why the document
is mostly for WLAN/LAN access.

   The NAS might in many cases know the location of the end
   host through various techniques (e.g., wire databases, wireless
   triangulation).  Knowing the location of a network (where the user or
   end host is attached) might in many networks also reveal enough
   information about the location of the user or the end host.  A
   similar assumption is also made with regard to the location
   information obtained via DHCP (see for example [4]).

The DHCP case might be analagous to WLAN/LAN, but it is not analagous
to the case of VPN or dialup access where the NAS and user could be
separated by thousands of miles.

   This
   information might be used by applications in other protocols (such as
   SIP [11] with extensions [12]) to indicate the location of a
   particular user even though the location "only" refers to the
   location of the network or equipment within the network.  This
   assumption might not hold in all scenarios but seems to be reasonable
   and practicable.

I think you need to say that the assumption can be presumed to hold
for certain values of the NAS-Port-Type attribute (e.g. LAN or
WLAN access).  In others it may not hold.

Section 3

   Location Objects, which consist of location information and privacy
   rules, are transported via the RADIUS protocol from the AAA client to
   the AAA server.  A few attributes are introduced for this purpose, as
   listed in Section 5, whereby delivery to the RADIUS server can happen
   during the authentication/authorization phase (described in
   Section 3.1), or in the mid-session using the dynamic authorization
   protocol framework (described in Section 3.2).  This section
   describes messages flows for both delivery methods.

To me, it makes more sense to talk about what packets the location
information can be delivered in, rather than "phases".  For example,
location is delivered in Access-Request or Accounting-Request packets.
Whether the Access-Request was triggered by dynamic authorization or
a new user login is not important.  Also, this paragraph seems to suggest
that dynamic authorization is required to obtain mid-session location
information.  Since location can be provided interim accounting packets,
this is not really true.  Perhaps the point is that dynamic authorization
allows the information to be provided on demand.

Section 3.1

   Figure 1 shows an example message flow for delivering location
   information during the network access authentication and
   authorization procedure.  Upon a network authentication request from
   an access network client, the NAS submits a RADIUS Access-Request
   message that contains location information attributes among other
   required attributes.  These attributes are added based on various
   criteria (such as local policy, business relationship with
   subscriber's home network provider and in case of location
   information also by considering privacy policies).

Even though Figure 1 mentions "out of band agreement" the text doesn't
elaborate on what this means.

Since Figure 1 shows location information provided in
an Accounting-Request, the first sentence isn't quite right.
Given the privacy issues, I think you need to qualify what
"location information" means in the second sentence. Do you
mean that the user location is being supplied by the NAS?
I think you need to say something about the default settings
(e.g. location provided, or not?)  Backward compatiblity issues
also probably deserve some discussion here. You might say
a few words about when this flow might occur (e.g. challenge-incapable
NAS).

Figure 1 uses the term "Network Access Client" which isn't
defined in terminology or used in other RADIUS RFCs.  I would change
all uses of this term to "User".

   If the AAA server needs to obtain location information also in
   accounting messages then it needs to include a Requested-Info
   attribute to the Access-Accept to express that is desired (if privacy
   policy allow it) and the Network Access Server SHOULD then include
   location information to the RADIUS accounting messages .

I think you should say something about the packets within which the
location information can be delivered in Section 1.  Something like:
"This document enables a RADIUS server to request the delivery of
location information within Access-Request packets, or additionally,
within Accounting-Request packets."

Section 3.2

This section is problematic since it specifies RADIUS attribute
usage prohibited by RFC 3576 Section 3, which states:

   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 the desire is to change the location information being provided
(e.g. to turn on location in accounting packets, or deliver different
types of location) why couldn't a CoA-Request be sent without an
"Authorization-Only" Service-Type?  If the desire is to request
location immediately, couldn't this be encoded in the Request-Info
attribute?  There seem to be ways to achieve the goal without
violating RFC 3576.

Later on in the section, it is stated:

   Since location information can be sent in accounting records
   (including accounting interim records), RFC 3576 [5] is only needed
   for authorization changes.

Given this, it would appear that the need to obtain location mid-session
is best met by another technique, and that use of CoA-Request packets
is only a corner case.  Given that RFC 3576 is not widely implemented,
I'd expect the accounting approach to be more applicable, at least
without an explanation about why this isn't a good idea (e.g. might
not need location info with each interim accounting update).

Also, this section doesn't talk about when a RADIUS server can
send a CoA-Request containing a Request-Info attribute.  Wouldn't
this be restricted to cases where the NAS has previously included
a Location-Information or Challenge-Capable attribute?

Section 4

I'm not clear this section should exist as a standalone entity. It might
be best to delete Section 4.2 entirely and integrate Section 4.1 with
Sections 1 or 2.

Section 4.1

   The home network operator requires location information for
   authorization and billing purposes.  The operator may deny service if
   location information is not available, or it may offer limited
   service only.  The NAS delivers location information to the home AAA
   server.

   The location of the AAA client and/or the end host is transferred
   from the NAS to the RADIUS server (based on a pre-established
   agreement or if the RADIUS server asks for it under consideration of
   privacy policies).  The NAS and intermediaries (if any) are not
   allowed to use that information other than to forward it to the home
   network.

Are the terms "NAS" and "AAA client" used interchangeably here?  If so,
can we primarily use one term (NAS seems best)?

   The NAS and intermediaries (if any) are not
   allowed to use that information other than to forward it to the home
   network.

Intermediaries (e.g. AAA proxies) sometimes log Accounting-Request
packets, since they may need them for billing purposes.  Since billing is
one of the uses of location information, I don't think you can prohibit
that.  Also, what does it mean for the NAS to "use" location information?
Some NASes have stable storage, so they might write Accounting-Request
packets to stable storage prior to delivery.  Or they might retain
location information in memory.  Do you mean that that the NAS or proxies
can't provide the location information to unauthorized parties?  Or do you
mean that proxies MUST respect the privacy policies they receive from the
RADIUS server?

   The RADIUS server authenticates and authorizes the user requesting
   access to the network.  If the user's location policies are available
   to the RADIUS server, the RADIUS server MUST deliver those policies
   in an Access Accept to the RADIUS client.  This information MAY be
   needed if intermediaries or other elements want to act as Location
   Servers (see Section 4.2).  If the NAS or intermediaries do not
   receive policies from the RADIUS server (or the end host itself) then
   they MUST NOT make any use of the location information other than
   forwarding it to the user's home network.

I would name the specific attributes rather than just saying "location
policies".  You are essentially saying that some attributes MUST be
included in an Access-Accept packet.  The last sentence is somewhat
more specific than just saying "allowed to use that information".

   Location Information may also be reported in accounting messages.
   Accounting messages are generated when the session starts, stops and
   periodically.  Accounting messages may also be generated when the
   user roams during handoff.  This information may be needed by the
   billing system to calculate the user's bill.  For example, there may
   be different tariffs or tax rates applied based on the location.
   Unless otherwise specified by authorization rules, location
   information in the accounting stream MUST NOT be transmitted to third
   parties.

Most of this paragraph probably belongs in Section 1 of the document.
I'm unsure what the last sentence means.  I think that the part of
the last sentence from "location..." should probably be combined with
the next sentence, to clarify it:

   Location information in the accounting stream MUST only be sent in
   the proxy chain to the home network (unless specified otherwise).

For example, you might say "Location attributes contained within
Accounting-Request packets MUST only be made available to entities
on the proxy chain between the NAS and the home accounting
server."

Section 4.2

   Location Servers are entities that receive the user's location
   information and transmit it to other entities.  In this second
   scenario, Location Servers comprise also the NAS and the RADIUS
   server.  The RADIUS servers are in the home network, in the visited
   network, or in broker networks.

   Unless explicitly authorized by the user's location policy, location
   information MUST NOT be transmitted to other parties outside the
   proxy chain between the NAS and the Home RADIUS server.

   Upon authentication and authorization, the home RADIUS server MUST
   transmit the ruleset (if available) in an Access-Accept.  The RADIUS
   client, intermediate proxies are allowed to share location
   information if they received ruleset indicates that it is allowed.

Is a "Location Server" somehow different from an entity eligible
to receive location information as described in the previous section?
I'm unclear whether this section is saying anything different from
Section 4.1 with respect to handling of user location information.

Section 5.1

   The Operator-Name attribute SHOULD be sent in Access-Request, and
   Accounting-Request records where the Acc-Status-Type is set to Start,
   Interim, or Stop.

Is this attribute only sent in these packets?  If so, I would say:
"MAY only be sent in Access-Request and Accounting-Request..."

The Value type is restricted to use with Integers.  I think that we
are talking about a String here, no?

Section 5.2

   The Location-Information attribute SHOULD be sent in Access-Request
   and in Accounting-Request messages.  For the Accounting-Request
   message the Acc-Status-Type may be set to Start, Interim or Stop.

Is the intent that these attributes are only sent in Access-Request
and Accounting-Request messages?  If so, say "MAY only be sent in..."

I think you are talking about a String type attribute, not an integer,
right?

       The 16-bit unsigned integer value allows to associate
       the Location-Information attribute with
       Location-Info-Civic and Location-Info-Geo
       attributes.

This is not a complete sentence. I think you need to explain that
this attribute is used to provide information relating to the
information included in the Location-Info-Civic and
Location-Info-Geo attributes to which it refers (via the Index).

You should probably also state that this attribute is largely treated
as an opaque blob, like the Location-Info-Civic and Location-Info-Geo
attributes to which it refers.  As a result, it is not expected that
RADIUS servers will need to change code to receive this attribute
(although location applications would have to parse it).

Section 5.3

   Location-Info-Civic attribute SHOULD be sent in Access-Request and in
   Accounting-Request messages.  For the Accounting-Request message the
   Acc-Status-Type may be set to Start, Interim or Stop.

Change to "MAY only be sent..." if that is the intent.

Please change "Value" to "String".

       The 16-bit unsigned integer value allows to associate
       the Location-Info-Civic attribute with the
       Location-Information attributes.

Is there an implication that multiple Location-Information attributes
will have the same Index value?  That doesn't make sense to me.

Section 5.4

   Location-Info-Geo attribute SHOULD be sent in Access-Request, and
   Accounting-Request records where the Acc-Status-Type is set to Start,
   Interim or Stop if available.

Change to "MAY only be sent" if that is the intent.

Change "Value" to "String"

Section 5.5

Should the title be "Basic-Policy-Rules Attribute"?

   Policy rules control the distribution of location location
   information.  In some environments the the AAA client might know the
   privacy preferences of the user based on pre-configuration or the
   user communicated them as part of the network attachment.

This seems somewhat unlikely.  Do any existing access protocols support
user-provided privacy policies?  Or are we talking about generic
NAS privacy settings here?

   Basic-Policy-Rules attribute SHOULD be sent in an an Access-Request,
   Access-Accept, an Access-Challenge, an Access-Reject and an
   Accounting-Request message.

I think you mean "MAY be sent in an Access-Request..."

   o  The AAA client SHOULD NOT attach location information in the
      initial Access-Request message but should rather wait for the AAA
      server to receive a challenge for location information.

I think you mean "for the AAA server to send an Access-Challenge..."

I think you are instead saying that "absent NAS settings
to the contrary, the default is..."  This probably should be clarified.

   o  If a roamig agreement or legal circumstances require the AAA

roamig -> roaming

      client to transfer location information in the initial Access-
      Request message to the AAA server (even though user specific
      policies are not available to the AAA client) then the access
      network attaches default authorization policies.

Are you saying that a Basic Policy Rules attribute MUST accompany
a Location-Information, Location-Info-Geo or Location-Info-Civic
attribute?

      The 'retransmission-allowed' flag MUST be set to '0' meaning
      that the location must not be shared with other parties (other than
      forarding them to the user's home network).

Are we saying that sharing of location information is controlled by the
're-transmission-allowed' flag and that parties MUST respect the flag?
This seems to contradict earlier MUST statements (which seem to imply
that sharing is not permitted, regardless of the flag value).

      In case the home
      network knows the user's privacy policies then these policies
      SHOULD be sent from the RADIUS server to the RADIUS client in a
      subsequent response message and these policies will be applied to
      further location dissemination and in subsequent RADIUS
      interactions (e.g., when attaching location information to
      Accounting messages).

What kind of response message?  Do you mean Access-Challenge here
or Access-Accept? Is there a reason why a RADIUS server would refuse
to disclose the user's privacy policies?  Should those policies
ever be considered private?

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Flags                        | Retention Expires            ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Retention Expires                                            ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Retention Expires             | Note Well                    ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Note Well                                                    ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The design of this attribute is problematic.  It is different from
other complex attributes in that it is sent by the RADIUS server,
and the inclusion of timestamps implies that it needs to be computed
dynamically, rather than treated as an opaque blob.

Also, there is an implication elsewhere in the document that the
retransmission bit needs to be respected by RADIUS proxies.  Most
existing RADIUS proxies cannot be configured to look at a specific
octet in an attribute, so this will not be possible.

Is there a reason that this could not be split into separate
unitary attributes, say, one for Retransmission, one for
Retention-Expires and another for Privacy-Policy?  The "Retention Expires"
attribute would a 64-bit
Long Integer, the Flags would be a 32-bit integer
and the Note Well would be a string.

This would be much more compatible with the design of existing
RADIUS servers and proxies and would enable privacy policies to
be respected.

Section 5.6

   The Extended-Policy-Rules attribute SHOULD be sent in an Access-
   Request, an Access-Accept, an Access-Challenge, an Access-Reject and
   in an Accounting-Request message whenever location information is
   transmitted.

Do we mean "MAY be sent" here?

I think "String" should be used here instead of "Value"

Why is Length >=4 (rather than 3)?

Section 5.7

Why is the Challenge-Capable attribute defined if it is always
set to 0?  Is the presence of the attribute sufficient to indicate
that the NAS is capable of being challenged so that the value
is irrelevant?

It would make more sense for this to be a 32-bit integer value
that only has a single value defined (1) indicating that the
NAS is capable of being challenged.

Section 5.8

   The Requested-Info attribute allows the RADIUS server to indicate
   whether it needs civic and/or geospatial location information of the
   NAS or the end host (i.e., the entities that are indicated in the
   Entity field of the Location-Information attribute).

Can't the RADIUS server ask for both NAS and end host information?

      2.  If the RADIUS server does not receive the requested
          information in response to the Access-Challenge (including the
          Requested-Info attribute) then the RADIUS server responds with
          an Access-Reject with an Error-Cause attribute (including the
          "Location-Info-Required" value).  Note that an Access-Reject
          message SHOULD only be sent if the RADIUS server MUST use
          location information for returning a positive access control
          decision.

The combination of SHOULD and MUST is confusing.  I think you mean to
say that an Access-Reject MUST only be sent if the RADIUS server
requires location information, but does not receive it, right?

      This is typically the case when location
      information is used for inclusion to the user's bill only.

Rephrase to "is used only for billing".

   If the RADIUS server does not send a Requested-Info attribute then
   the RADIUS client MUST NOT attach location information to messages to
   the RADIUS server.  The user's authorization policies, if available,
   MUST be consulted by the RADIUS server before requesting location
   information delivery from the RADIUS client.

But earlier it is said that the NAS may send location information by
default,
correct?  Or is an exception being made?

Figure 11 probably belongs earlier in the document.

   The Requested-Info attribute MUST be sent by the RADIUS server if it
   wants the RADIUS client to return civic and/or geospatial
   information.  This Requested-Info attribute MAY appear in the Access-
   Accept or in the Access-Challenge message.

Earlier it seems to imply that the NAS could sent location information
by out-of-band agreement.  So do you mean to say "in the absence of
an out-of-band agreement..."?

     Requested-Info (64 bits):

       This text field contains an integer value that encodes the
       requested information attributes.
       Each capability value represents a bit position.

It would be clearer to just say that the Requested-Info attribute
defines a bit field, where the information on CIVIC_LOCATION,
GEO_LOCATION, USERS_LOCATION, and NAS_LOCATION can be requested.

BTW, why is a 64-bit value required?  wouldn't 32-bits do as well?

Section 6

   If multiple
   Location-Information attributes are sent then they MUST NOT contain
   the same information.

Does this mean "must not have the same Index field?" Or does it mean
that they must not be identical in all respects?

Section 8.2

   o  The visited network is able to learn the user's identity.

I think you need a reference to NAI privacy (e.g. RFC 4282 or 4372) here.

Section 8.3

This section interrupts the document flow; it would better belong in
an Appendix.

Section 9

   Two entities might act as Location Servers as shown in Section 4, in
   Figure 16 and in Figure 17:

I think the sentence should end with a period, not a colon, right?

Section 9.1

   In this scenario it is difficult to obtain authorization policies
   from the end host (or user) immediately when the user attaches to the
   network.  In this case we have to assume that the visited network
   does not allow unrestricted distribution of location information to
   other than the intended recipients (e.g., to third party entities).
   When the AAA messages traverses one or more broker networks, the
   broker network is bound by the same guidelines as the visited network
   with respect to the distribution of location information.

Are you just saying that proxies need to respect the 'retransmission' bit?
In practice, they won't be able to do that because their policy engines
operate at the attribute, not bit level.  You'll need to have an
individual attribute for retransmission if you want this to work.

   The visited network MUST behave according to the following
   guidelines:

   o  Per default only the home network is allowed to receive location
      information.  The visited network MUST NOT distribute location
      information to third parties without seeing the user's privacy
      rule set.

Are you saying that the lack of distribution is the default, absent
receipt of privacy policies to the contrary?  I'd suggest that this
be stated earlier on.

   o  If the RADIUS client in the visited network learns the basic rule
      set or a reference to the extended rule set by means outside the
      RADIUS protocol (e.g., provided by the end host) then it MUST
      include the Basic-Policy-Rules and the Extended-Policy-Rules
      attribute in the Access-Request message towards the home AAA
      server.  Furthermore, the visited network MUST evaluate these
      rules prior to the transmission of location information either to
      the home network or a third party.  The visited network MUST
      follow the guidance given with these rules.

This seems quite unlikely.  Is there a reference to a specification
where this is proposed?

   o  If the RADIUS client in the visited network receives the Basic-
      Policy-Rules attribute with Access-Accept or the Access-Challenge
      message then the Basic-Policy-Rules MUST be attach in subsequent
      RADIUS messages which contain the Location-Information attribute
      (such as interim accounting messages).

attach -> attached
You need to include this statement in the Attribute Table section 6.
Doesn't it apply to all NASes, not just a visited network?

   o  If the RADIUS client in the visited network receives the Extended-
      Policy-Rules attribute with Access-Accept or the Access-Challenge
      message then the Basic-Policy-Rules attribute MUST be attach in
      subsequent RADIUS messages which contain the Location-Information
      attribute (such as interim accounting messages).

attach -> attached

I think this needs to be included in the Attribute Table section 6.
Doesn't it apply to all NASes, not just a Visited network?

Section 10

   If no authorization information is provided by the user
   then the visited network MUST set the authorization policies to only
   allow the home AAA server to use the provided location information.

This seems to contradict Figure 1 which shows location
information sent by out-of-band agreement without any policy attributes.

   It is necessary to use authorization policies to limit the
   unauthorized distribution of location information.  The security
   requirements which are created based on [10] are inline with threats
   which appear in the relationship with disclosure of location
   information as described in [33].  PIDF-LO [21] proposes S/MIME to
   protect the Location Object against modifications.  S/SIME relies on
   public key cryptography which raises performance, deployment and size
   considerations.  Encryption would require that the local AAA server
   or the NAS knows the recipient's public key (e.g., the public key of
   the home AAA server).

So are we saying that the location information attributes can be encrypted
in some cases, so that the privacy concerns are not applicable? But the
attributes don't support this, right?

   Knowing the final recipient of the location
   information is in many cases difficult for RADIUS entities.

Specifically, RADIUS clients only deal with RADIUS servers that are one
hop away.

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

Delivery-date: Sat, 17 Feb 2007 08:31:39 +0000
Date: Sat, 17 Feb 2007 09:30:18 +0100
From: Alan DeKok <[email-masked]>
To:  [email-masked],  [email-masked]
Subject: Re: IETF last call on RADIUS GEOPRIV Document

  On page 22, the second bullet point has a type, "roaming" is spell
"roamig", without the 'n'.

  Alan DeKok.

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

Delivery-date: Fri, 16 Feb 2007 05:35:13 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG last call: Issues & Fixes Document
Date: Fri, 16 Feb 2007 00:34:01 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

I've read this revision. =20
The doc looks fine to me.

Greg=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Wednesday, February 14, 2007 12:09 AM
> To: [email-masked]
> Subject: RADEXT WG last call: Issues & Fixes Document
>=20
> This is an announcement of RADEXT WG last call on the Issues & Fixes=20
> Document, prior to sending the document to the IESG for=20
> consideration as a=20
> Proposed Standard.
>=20
> The document will be available on the IETF archive here:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-01.txt
>=20
> Until it arrives, it can be found here:
> http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-fixes-01.txt
>=20
> WG last call will last until March 15, 2007. Comments should=20
> be sent to the=20
> RADEXT WG mailing list ([email-masked]), in the=20
> format described on=20
> the RADEXT Issues list:
> http://www.drizzle.com/~aboba/RADEXT/
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Wed, 14 Feb 2007 20:51:00 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-fixes-01.txt 
Date: Wed, 14 Feb 2007 15:50:01 -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		: Common RADIUS Implementation Issues and Suggested Fixes
	Author(s)	: D. Nelson, A. DeKok
	Filename	: draft-ietf-radext-fixes-01.txt
	Pages		: 22
	Date		: 2007-2-14
	
This document describes common issues seen in RADIUS implementations
   and suggests some fixes.  Where applicable, ambiguities and errors in
   previous RADIUS specifications are clarified.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-fixes-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: Tue, 13 Feb 2007 18:40:02 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RADEXT WG last call: Issues & Fixes Document
Date: Tue, 13 Feb 2007 10:38:39 -0800

This is an announcement of RADEXT WG last call on the Issues & Fixes 
Document, prior to sending the document to the IESG for consideration as a 
Proposed Standard.

The document will be available on the IETF archive here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-01.txt

Until it arrives, it can be found here:
http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-fixes-01.txt

WG last call will last until March 15, 2007. Comments should be sent to the 
RADEXT WG mailing list ([email-masked]), in the format described on 
the RADEXT Issues list:
http://www.drizzle.com/~aboba/RADEXT/

--
to unsubscribe send 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, 09 Feb 2007 16:26:21 +0000
Date: Fri, 09 Feb 2007 17:26:01 +0100
From: Alan DeKok <[email-masked]>
CC:  [email-masked]
Subject: Re: ISSUE 107: proposed resolution text: CORRECTION

Bernard Aboba wrote:
> I think this resolution is generally OK.
> 
> Change "massage" to "message".
> Also change "NAS is not overloaded" to "NAS, network and RADIUS server
> are not overloaded".

  I have no objection to those comments.

  Alan DeKok.

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

Delivery-date: Fri, 09 Feb 2007 16:26:13 +0000
Date: Fri, 09 Feb 2007 17:25:21 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: ISSUE 146: proposed resolution text

Bernard Aboba wrote:
> Generally, this looks OK.
> 
> Some suggestions:

  OK.  I have no objection.

> You can the following paragraph:

  Delete, I presume.

  Alan DeKok.

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

Delivery-date: Fri, 09 Feb 2007 14:59:26 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: ISSUE 146: proposed resolution text
Date: Fri, 09 Feb 2007 06:58:47 -0800

Generally, this looks OK.

Some suggestions:

Change:

"   The RADIUS Authentication and Authorization Client MIB module
   [RFC2618], [RFC4668] includes counters of packet statistics. In the
   descriptive text of the MIB module, formulas are given to relative
   the values of certain counter objects.  Several commenters have noted
   that there appear to be inconsistencies in the formulas, as under
   certain circumstances negative values would seem to result.

   Discussion of these issues in the RADIUS Extensions Working Group did
   not bring about a consensus as to whether or not changes to the MIB
   module were warranted, and thus the formulas were included unmodified
   in the revised MIB module [RFC4668].  The original MIB module
   [RFC2618] has been widely implemented."

To:

"  The RADIUS Authentication and Authorization Client MIB module
   [RFC2618], [RFC4668] includes counters of packet statistics. In the
   descriptive text of the MIB module, formulas are provided for
   certain counter objects.  Implementers have noted apparent
   inconsistencies in the formulas, which could result in negative
   values.

   Since the original MIB module specified in [RFC2168] had been widely
   implemented, the RADEXT WG chose not to change the object
   definitions or create new ones within the revised MIB module [RFC4668].
   However, this section explains the issues and provides guidance for
   implementers regarding the interpretation of the textual descriptions
   and comments for certain MIB objects."

You can the following paragraph:

"
   In summary, this document provides guidance for implementers,
   regarding the interpretation of the textual descriptions and comments
   for certain MIB objects, but does not recommend revisions to the MIB
   modules."

--
to unsubscribe send 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, 09 Feb 2007 14:50:31 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: ISSUE 107: proposed resolution text: CORRECTION
Date: Fri, 09 Feb 2007 06:50:12 -0800

I think this resolution is generally OK.

Change "massage" to "message".
Also change "NAS is not overloaded" to "NAS, network and RADIUS server are 
not overloaded".

Alan DeKok said:

  The previous message quoted text from an earlier version of the
document in error.  The following text is the correct version.

S.s.s.  Interim-Accounting-Interval

   [RFC2869] Section 2.1 states:

      It is also possible to statically configure an interim value on
      the NAS itself. Note that a locally configured value on the NAS
      MUST override the value found in an Access-Accept.

   This requirement may be phrased too strongly.  It is conceivable that
   a NAS implementation has a setting for a "minimum" value of Interim-
   Accounting-Interval, based on resource constraints in the NAS, and
   network loading in the local environment of the NAS.  In such cases,
   the value administratively provisioned in the NAS should not be over-
   ridden by a smaller value from an Access-Accept massage. The NAS's
   value could be over-ridden by a larger one, however.  The intent is
   that the NAS sends accounting information at fixed intervals, short
   enough such that the potential loss of billable revenue is limited,
   but also that the accounting updates are infrequent enough such that
   the NAS is not overloaded.

--
to unsubscribe send 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, 09 Feb 2007 13:54:23 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RADEXT Last Call:  RFC 3576bis
Date: Fri, 09 Feb 2007 05:54:15 -0800

This is an announcement of RADEXT WG last call on RFC 3576bis, prior to 
sending the document to the IESG for consideration as a Proposed Standard.

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-00.txt

WG last call will last until March 9, 2007.  Comments should be sent to the 
RADEXT WG mailing list ([email-masked]), in the format described on 
the RADEXT Issues list:
http://www.drizzle.com/~aboba/RADEXT/

--
to unsubscribe send 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, 09 Feb 2007 13:54:09 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RADEXT WG Last Call: RFC 4590bis
Date: Fri, 09 Feb 2007 05:53:07 -0800

This is an announcement of RADEXT WG last call on RFC 4590bis, prior to 
sending the document to the IESG for consideration as a Proposed Standard.

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-00.txt

WG last call will last until March 9, 2007.  Comments should be sent to the 
RADEXT WG mailing list ([email-masked]), in the format described on 
the RADEXT Issues list:
http://www.drizzle.com/~aboba/RADEXT/

--
to unsubscribe send 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, 07 Feb 2007 20:17:56 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: IETF last call on RADIUS GEOPRIV Document
Date: Wed, 07 Feb 2007 12:16:41 -0800

The IESG has received a request from the Geographic Location/Privacy WG  
(geopriv) to consider the following document:

- 'Carrying Location Objects in RADIUS '
   <draft-ietf-geopriv-radius-lo-10.txt> as a Proposed Standard

This draft has a downref to RFC 3576 but 3576 is only used for an optional 
feature of "Mid-session Authorization".

The IESG plans to make a decision in the next few weeks, and solicits final 
comments on this action.  Please send substantive comments to the ietf at 
ietf.org mailing lists by 2007-02-19. Exceptionally,  comments may be sent 
to iesg at ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-10.txt

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

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

Delivery-date: Fri, 02 Feb 2007 06:31:54 +0000
Date: Fri, 02 Feb 2007 07:31:34 +0100
From: Alan DeKok <[email-masked]>
To: radext mailing list <[email-masked]>
Subject: ISSUE 146: proposed resolution text.

  The following is proposed text to resolve ISSUE 146.  If there are no
comments, the text will be included in the next revision of the document.

---
2.3.6.  Counter values in the RADIUS MIBs

   The RADIUS Authentication and Authorization Client MIB module
   [RFC2618], [RFC4668] includes counters of packet statistics. In the
   descriptive text of the MIB module, formulas are given to relative
   the values of certain counter objects.  Several commenters have noted
   that there appear to be inconsistencies in the formulas, as under
   certain circumstances negative values would seem to result.

   Discussion of these issues in the RADIUS Extensions Working Group did
   not bring about a consensus as to whether or not changes to the MIB
   module were warranted, and thus the formulas were included unmodified
   in the revised MIB module [RFC4668].  The original MIB module
   [RFC2618] has been widely implemented.

   The issues raised can be summarized as follows:

   Issue (1):

   -- TotalIncomingPackets = Accepts + Rejects + Challenges +
   UnknownTypes
   --
   -- TotalIncomingPackets - MalformedResponses - BadAuthenticators -
   -- UnknownTypes - PacketsDropped = Successfully received
   --
   -- AccessRequests + PendingRequests + ClientTimeouts =
   -- Successfully Received

   It appears that the value of "Successfully Received" could be
   negative, since various counters are subtracted from
   TotalIncomingPackets that are not included in the calculation of
   TotalIncomingPackets.

   It also appears that "AccessRequests + PendingRequests +
   ClientTimeouts = Successfully Received" should read "AccessRequests +
   PendingRequests + ClientTimeouts = Successfully Transmitted".

   "TotalIncomingPackets" and "Successfully Received" are temporary
   variables, i.e. not objects within the MIB module.  The comment text
   in the MIB modules is intended, therefore, to aid in understanding.
   What's of consequence is the consistency of values of the objects in
   the MIB module, and that does not appear to be impacted by the
   inconsistencies noted above.  It does appear, however, that the
   "Successfully Received" variable should be labeled "Successfully
   Transmitted".

   In addition, the definition of Accept, Reject or Challenge counters
   indicates that they MUST be incremented before the message is
   validated.  If the message is invalid, one of MalformedResponses,
   BadAuthenticators or PacketsDropped counters will be additionally
   incremented.  In that case the first two equations are consistent,
   i.e. "Successfully Received" could not be negative.

   Issue (2):

   It appears that the radiusAuthClientPendingRequests counter is
   decremented upon retransmission. That would mean a retransmitted
   packet is not considered as being as pending, although such
   retransmissions can still be considered as being pending requests.

   The definition of this MIB object in [RFC2618] is as follows:

      The number of RADIUS Access-Request packets destined for this
      server that have not yet timed out or received a response. This
      variable is incremented when an Access-Request is sent and
      decremented due to receipt of an Access-Accept, Access-Reject or
      Access-Challenge, a timeout or retransmission.

   This object purports to count the number of pending request packets.
   It is open to interpretation whether or not retransmissions of a
   request are to be counted as additional pending packets.  In either
   event, it seems appropriate to treat retransmissions consistently
   with respect to incrementing and decrementing this counter.

   In summary, this document provides guidance for implementers,
   regarding the interpretation of the textual descriptions and comments
   for certain MIB objects, but does not recommend revisions to the MIB
   modules.

--
to unsubscribe send 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, 02 Feb 2007 06:30:53 +0000
Date: Fri, 02 Feb 2007 07:30:38 +0100
From: Alan DeKok <[email-masked]>
CC: radext mailing list <[email-masked]>
Subject: Re: ISSUE 107: proposed resolution text: CORRECTION

  The previous message quoted text from an earlier version of the
document in error.  The following text is the correct version.

S.s.s.  Interim-Accounting-Interval

   [RFC2869] Section 2.1 states:

      It is also possible to statically configure an interim value on
      the NAS itself. Note that a locally configured value on the NAS
      MUST override the value found in an Access-Accept.

   This requirement may be phrased too strongly.  It is conceivable that
   a NAS implementation has a setting for a "minimum" value of Interim-
   Accounting-Interval, based on resource constraints in the NAS, and
   network loading in the local environment of the NAS.  In such cases,
   the value administratively provisioned in the NAS should not be over-
   ridden by a smaller value from an Access-Accept massage. The NAS's
   value could be over-ridden by a larger one, however.  The intent is
   that the NAS sends accounting information at fixed intervals, short
   enough such that the potential loss of billable revenue is limited,
   but also that the accounting updates are infrequent enough such that
   the NAS is not overloaded.

--
to unsubscribe send 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, 02 Feb 2007 06:24:17 +0000
Date: Fri, 02 Feb 2007 07:23:04 +0100
From: Alan DeKok <[email-masked]>
To: radext mailing list <[email-masked]>
Subject: ISSUE 107: proposed resolution text

  The following is proposed text to resolve ISSUE 107.  If there are no
comments, the text will be included in the next revision of the document.

---
S.s.s.  NAS handling of Acct-Interim-Update

   [RFC2869] Section 2.1 states

      It is also possible to statically configure an interim value on
      the NAS itself. Note that a locally configured value on the NAS
      MUST override the value found in an Access-Accept.

   This requirement may be too strong in practice.  If an implementator
   chooses to permit the Acct-Interim-Interval in an Access-Accept to
   override a global default for that value, then the implementation
   MUST enforce a minimum acceptable value on the Acct-Interim-Interval
   in an Access-Accept.  The alternative would be to accept
   inappropriately small values, which may have performance impact on
   the NAS.

   This minimum SHOULD be configurable on the NAS, as a "minimim
   acceptable Acct-Intim-Interval".

--
to unsubscribe send 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, 02 Feb 2007 01:42:56 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Question to WG re: Issues & Fixes
Date: Thu, 01 Feb 2007 17:42:38 -0800

Personally, I'm OK with the document being Standards Track, since the 
updates to RFC 2865 are modest and seem to be in keeping with existing 
practice.  The other documents are informational, so this document can 
update them without being Standards Track.

>From: Alan DeKok <[email-masked]>
>To: radext mailing list <[email-masked]>
>Subject: Question to WG re: Issues & Fixes
>Date: Thu, 01 Feb 2007 10:02:52 +0100
>
>   The original discussion around the document was that it was
>"Informational".  However, it also says:
>
>Updates: 2865, 2866, 2869, 3576, 3579
>
>   And:
>
>Category: Proposed Standard
>
>   Since RFC 2865 is Standards track, updating it via an informational
>RFC would not be permitted under the IETF process.  Although the WG
>accepted -03 as a work item, we would like to ensure that everyone is
>clear on the scope of the document.  We are therefore asking for WG
>consensus on the following question:
>
>Q:  Does the WG accept draft-ietf-radext-fixes-00.txt as Proposed
>Standard track?
>
>   Please respond in the affirmative or in the negative.
>
>   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/>

--
to unsubscribe send 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, 02 Feb 2007 01:27:32 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Question re: RFC 2865 and State attribute in table 5.44
Date: Thu, 01 Feb 2007 17:27:00 -0800

>   This seems to contradict the proposed text in section 2.1.1 of the
>Issues & Fixes draft:
>
>    An Access-Request sent as a result of a new or restarted
>    authentication run MUST NOT include the State attribute, even if the
>    State attribute has previously been received in an Access-Challenge
>    for the same user and port.
>
>   My preference is to keep the text from the Issues & Fixes document,
>with the idea that States are tied to a session, not to a user.

I think that's right, as long as we define a "Session" carefully.  For 
example, a re-authentication would result in a new session, whereas an RFC 
3576 CoA-Request would not, correct?  I was somewhat surprised to read the 
RFC 2865 text relating to use of State along with Termination-Action.

>   On going back and re-reading the Issues & Fixes document, I think the
>case I raised here is mostly covered by the existing text.

I think you're right.

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

Delivery-date: Thu, 01 Feb 2007 23:35:31 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: Tentative agenda for IETF 68
Date: Thu, 1 Feb 2007 18:34:41 -0500

Please note that the tentative agenda for IETF 68 has the RADEXT WG meeting
on Friday morning, instead of our more usual Monday or Tuesday AM slot.
Please take note, especially when planning your travel.  This agenda is
still subject to change.

FRIDAY, March 23, 2007 

0900-1130 Morning Session I 

Congress I        INT   dnsext    DNS Extensions WG  
Karlin I          OPS   radext    RADIUS EXTensions WG  
Grand Ballroom    RTG   rtgwg     Routing Area Working Group WG  
Congress III      TSV   tsvwg     Transport Area Working Group WG  

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

Delivery-date: Thu, 01 Feb 2007 09:03:52 +0000
Date: Thu, 01 Feb 2007 10:02:52 +0100
From: Alan DeKok <[email-masked]>
To: radext mailing list <[email-masked]>
Subject: Question to WG re: Issues & Fixes

  The original discussion around the document was that it was
"Informational".  However, it also says:

Updates: 2865, 2866, 2869, 3576, 3579

  And:

Category: Proposed Standard

  Since RFC 2865 is Standards track, updating it via an informational
RFC would not be permitted under the IETF process.  Although the WG
accepted -03 as a work item, we would like to ensure that everyone is
clear on the scope of the document.  We are therefore asking for WG
consensus on the following question:

Q:  Does the WG accept draft-ietf-radext-fixes-00.txt as Proposed
Standard track?

  Please respond in the affirmative or in the negative.

  Alan DeKok.

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

Delivery-date: Thu, 01 Feb 2007 06:03:44 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Question re: RFC 2865 and State attribute in table 5.44
Date: Wed, 31 Jan 2007 22:02:42 -0800

RFC 2865 Section 5.44 states:

   [Note 1] An Access-Request MUST contain either a User-Password or a
   CHAP-Password or State.  An Access-Request MUST NOT contain both a
   User-Password and a CHAP-Password.  If future extensions allow other
   kinds of authentication information to be conveyed, the attribute for
   that can be used in an Access-Request instead of User-Password or
   CHAP-Password.

This seems to imply that if an authentication attribute isn't present in an 
Access-Request, then a State attribute must be.  Presumably if a state 
attribute is present, the NAS must have gotten it from somewhere, and the 
somewhere is either an Access-Accept (e.g. for a CoA-Request or 
Disconnect-Request), or an Access-Challenge (for an Access-Request).   Since 
this is an either/or, it seems possible that a State attribute wouldn't be 
present in an Access-Challenge if it was instead obtained from a previous 
Access-Accept.

Also, Section 5.24 states the following:

      This Attribute is available to be sent by the server to the client
      in an Access-Accept that also includes a Termination-Action
      Attribute with the value of RADIUS-Request.  If the NAS performs
      the Termination-Action by sending a new Access-Request upon
      termination of the current session, it MUST include the State
      attribute unchanged in that Access-Request.

This seems to imply that an Access-Request could contain a State attribute 
without having obtained it from an Access-Challenge.  For example, an EAP 
re-authentication attempt (e.g. Access-Request containing one or more 
EAP-Message attributes) could contain a State attribute obtained from a 
previous Access-Accept.  In this case, it's not clear to me that the 
Access-Challenge would necessarily have to contain a State attribute.

With respect to RFC 3579, leaving it out of Section 3.3 only implies that 
the Table entry is the same as in RFC 2865.  If the logic above applies, 
then it is possible for a State attribute not to be present in an 
Access-Challenge, though that is something of a corner case.

My overall recommendation is not to change the table, but to include some 
text clarifying the situation.  In practice there have been some 
interoperability issues with Access-Request packets containing State 
attributes that were not obtained from an Access-Challenge.

Alan DeKok said:

  Table 5.44 lists 'State' as "0-1" for Access-Challenge.  Are there any
client and/or server implementations that *don't* send a State in an
Access-Challenge?  Section 4.4 says the Access-Challenge "MAY have a
single State Attribute, or none."  But it doesn't explain why.

  I note that RFC 3579, Section 3.3 doesn't list "State" as being
necessary for EAP conversations.  I can't even find *any* reference to
the attribute in RFC 3579, which seems a little odd.

  Is this something that needs to be addressed?  I'm not aware of any
EAP implementations that *don't* use State, so it would appear to be
required for Access-Challenge, where the packet contains an EAP-Message
that isn't an EAP Success or Failure.  Maybe the lack of use of the
State attribute is why section 2.6.1 (Identifier Space) describes such a
complicated mechanism for discriminating sessions.

  Are there any other use cases where it is not necessary to send the
State attribute in an Access-Challenge?  I can't recall seeing any, and
all of the clients & servers I've written require it.

  Is there a problem with requiring State in Access-Challenge?  I'm not
sure I should file an official ISSUE until I'm sure I understand what
the intent was.

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