Subject: Re: Issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Date: Fri, 30 Dec 2005 12:50:53 -0500

Henrik Nordstrom <[email-masked]> wrote:
> I brought up this question mainly to ask if the Digest extension to Radius 
> intentionally blocks session based Digest authentication (MD5-sess with 
> offload of authentication of further requests within the same session), or 
> if it is just an oversight thinking that Digest is only per-reqest 
> authentication.

  RADIUS *is* per-request authentication.  The dissonance here is that
HTTP has multiple "requests" for one "session".  We're trying to have
two different paradigms interact, which means one of them has to give.

> Personally I do not onsider cookie based session management approaches as 
> a viable alternative to Digest MD5-sess. Digest MD5-sess is a fully 
> specified protocol, while each cookie based session management apart from 
> requiring cookie support (which not all useragents supports or are willing 
> to support) each is implemented differently, and does not and will not 
> integrate well with non-interactive agents as the authentication is 
> effectively "out-of-band" in custom coded forms etc.

  Sure.  And RADIUS is a fully specified protocol with fully specified
behavior.  Pushing authentication credentials from the RADIUS server
to the client is a *major* change of the security model of RADIUS.

  If nothing else, I would like to know the full impact of making that
change to RADIUS before standardizing it.

> Digest MD5-sess has the opportunity of becoming a very functional 
> authentication model for HTTP only relying on standards. But enforcing a 
> roundtrip to the Radius server on each and every request is in my opinion 
> not an option as it is very unlikely to scale, and adds significant 
> latency to the provided service.

  I agree.

>  RADIUS is designed primarily with session authentication in mind,
> not message authentication. Digest MD5-sess unlike the other
> available authentication schemes for HTTP provides session based
> authentication within HTTP.

  Yes, but as I said previously, RADIUS currently authenticates a
session once.  There is *no* provision in RADIUS for a NAS re-sending
authentication requests for one session.  Therefore, the historical
method of mapping HTTP "sessions" to RADIUS was to treat each HTTP
request as a RADIUS "session", and send an authentication request.

  This doesn't scale, as you said.  Now, one protocol or the other has
to give, which is the source of the current discussion.

> It has been selected to at all include support for the Digest-HA1 
> attribute, opening the whole can of security issues involved here. As soon 
> as this is supported all the security implications of supporting MD5-sess 
> correctly is already there.

  Then maybe we need to re-visit the decision to include support for a
Digest-HA1 attribute.  I'm not flat-out opposed to it, but I am
opposed to changing the RADIUS security model without performing due
diligence.

> But perhaps it's due to different views of what MD5-sess is. In my view 
> MD5-sess allows for session based authentication within the message based 
> Digest protocol. The RADIUS server authenticates the session on the first 
> message exchange, and the "client" then verifies the validity of the 
> session in further message exchanges. I do not view this as pushing 
> authentication to the client, even if technically the algorithm used is 
> mostly the same but based on the authenticated MD5-sess H(A1) session key 
> rather than the plain password.

  It is giving the client access to authentication credentials it did
not previously have.  This *is* a change in behavior.

  The only reason that this method is being proposed is that one HTTP
"session" can involve multiple TCP/IP connections, spread over time.
Normal RADIUS client behavior is that the user session *is* the
connection to the user.  When the connection goes down, the session is
over.

> gaping security holes due to lack of standards and awareness on session 
> security, or be forced to have huge RADIUS server farms (including 
> directory backends) only to handle the authentication load.

  That's not fair.  If the HTTP server can cache H(A1), then the
RADIUS servers can, too.  There's no need to go to a directory
back-end for every request.  Give me 1/2 hour, and I can have that
implemented in FreeRADIUS, and people will be testing it in
deployments next week.

> ...
> sufficient grounds that it should be standardized. If not there is a high 
> risk many implementations gets it done wronly (such as exchanging H(A1) in 
> plain over untrusted links, or screwing up the nonce security 
> requirements).

  Such as sending H(A1) in the clear in a RADIUS packet?  The only
security difference between that and using a cookie is that the cookie
goes over the net, while the Digest-HA1 attribute is (generally) sent
within a controlled network.

  My reading of the radext issues archive indicates that there hasn't
been consensus over whether Digest-HA1 is a good idea.  It's *useful*,
there's no question there, but it has security issues, as the
discussion in the archive says.  The text that the attribute MUST NOT
be sent unless the RADIUS traffic is protected from eavesdropping is
just wishful thinking.  People will make the same mistakes deploying
this as they currently do for HTTP cookies.

  I wasn't following that conversation earlier, otherwise I probably
would have jumped in then.

  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, 30 Dec 2005 01:48:47 +0000
Date: Fri, 30 Dec 2005 02:48:15 +0100 (CET)
From: Henrik Nordstrom <[email-masked]>
To: [email-masked]
Subject: Re: Issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess 

On Thu, 29 Dec 2005, Alan DeKok wrote:

>  As for the digest nonce replay protection, the goal of the cookie
> scheme isn't to re-authenticate the user every time, but instead, to
> validate their possession of a "magic token" that allows them access.
> (And to avoid all evaluating subsequent authentications). The
> authentication method used prior to giving them a magic token is
> almost irrelevant.

Sort of the same as for Digest MD5-sess. It shouldn't be viewed as 
authenticating the user on each and every request, only verifying the 
validity of the session.

It should be noted that the absolute majority of the people implementing 
cookie based authentication ontop of HTTP does not realize that the cookie 
as well is sensitive and access to the cookie allows for session theft. If 
you browse around a bit on sites implementing such schemes you will 
quickly find that while they often protect the authentication as such with 
transport level security (https) the session then most often continues 
without any encryption. Digest authentication does not share this problem 
as the security of the authentication is not relying on any transport 
level security.

Similarily there is a lot of places where end-to-end transport level 
security is not allowed. This includes several major corporations having 
as policy that all traffic must be decrypted at the border for inspection. 
Digest allows for this without any risk of compromise of the 
authentication as such, which is a big win compared to cookie based 
authentication.

>  Used in conjunction with https, this method would have minimal
> effect on security, and wouldn't require changes to RADIUS.

I brought up this question mainly to ask if the Digest extension to Radius 
intentionally blocks session based Digest authentication (MD5-sess with 
offload of authentication of further requests within the same session), or 
if it is just an oversight thinking that Digest is only per-reqest 
authentication.

Personally I do not onsider cookie based session management approaches as 
a viable alternative to Digest MD5-sess. Digest MD5-sess is a fully 
specified protocol, while each cookie based session management apart from 
requiring cookie support (which not all useragents supports or are willing 
to support) each is implemented differently, and does not and will not 
integrate well with non-interactive agents as the authentication is 
effectively "out-of-band" in custom coded forms etc.

Digest MD5-sess has the opportunity of becoming a very functional 
authentication model for HTTP only relying on standards. But enforcing a 
roundtrip to the Radius server on each and every request is in my opinion 
not an option as it is very unlikely to scale, and adds significant 
latency to the provided service.  RADIUS is designed primarily with 
session authentication in mind, not message authentication. Digest 
MD5-sess unlike the other available authentication schemes for HTTP 
provides session based authentication within HTTP.

However Digest authentication and MD5-sess session based authentication in 
particular has for a long time been held back mainly due to the lack of 
integration with authentication backends. It is my clear opinion that it 
would be very sad to pass this opportunity of finally standardizing an 
authentication integration method capable of supporting Digest MD5-sess, 
allowing HTTP authentication to finally evolve into something reliable, 
secure and performing, without having to resort to transport level 
encryption of plain text passwords and custom session management.

>  I'm not opposed to people doing it in site-local deployments.  I
> think it can have significant benefits in controlled environments.  I
> *am* opposed to standardizing it.

And I just don't get the reasoning behind this.

It has been selected to at all include support for the Digest-HA1 
attribute, opening the whole can of security issues involved here. As soon 
as this is supported all the security implications of supporting MD5-sess 
correctly is already there.

But perhaps it's due to different views of what MD5-sess is. In my view 
MD5-sess allows for session based authentication within the message based 
Digest protocol. The RADIUS server authenticates the session on the first 
message exchange, and the "client" then verifies the validity of the 
session in further message exchanges. I do not view this as pushing 
authentication to the client, even if technically the algorithm used is 
mostly the same but based on the authenticated MD5-sess H(A1) session key 
rather than the plain password.

HTTP Digest MD5-sess is a standard, and with this radius extension we have 
the ability to let this authentication mode florish. If support for this 
does not get into RADIUS then MD5-sess will almost certainly never ever 
become what it was intended, and we all have to live with either custom 
session management systems with all the drawbacks, incompabilities, and 
gaping security holes due to lack of standards and awareness on session 
security, or be forced to have huge RADIUS server farms (including 
directory backends) only to handle the authentication load.

I think the evidence that there is a lot of people already doing MD5-sess 
session authentication using RADIUS, and even more planning to do so, and 
the fact that the proposed draft already have full support for MD5-sess 
authentication provided one knows the Digest protocol sufficiently well is 
sufficient grounds that it should be standardized. If not there is a high 
risk many implementations gets it done wronly (such as exchanging H(A1) in 
plain over untrusted links, or screwing up the nonce security 
requirements).

Regards
Henrik

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

Envelope-to: [email-masked]
Delivery-date: Fri, 30 Dec 2005 00:29:01 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked], Henrik Nordstrom <[email-masked]>
Subject: Re: Issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess 
Date: Thu, 29 Dec 2005 19:33:57 -0500
Message-Id: <[email-masked]>

Henrik Nordstrom <[email-masked]> wrote:
> I assume you are aware that Digest MD5-sess iss running circles around the 
> above scheme in terms of security thanks to the replay protection provided 
> by the nonce-count in the Digest protocol. The above proposed scheme can 
> only be considered reasonably secure if combined with end-to-end transport 
> security (i.e. https for encryption). Even if using a more secure hash 
> than MD5 in your cookie is taken into account.

  It's security is limited by the fact that non-digest HTTP
authentication already sends the password in the clear.  So adding a
cookie to that changes little of the security, but lowers the
authentication impact on the RADIUS servers.  Breaking the cookie hash
depends on the size of the salt used, which can be large.  Once the
salt is past a certain size, other attacks become cheaper.

  As for the digest nonce replay protection, the goal of the cookie
scheme isn't to re-authenticate the user every time, but instead, to
validate their possession of a "magic token" that allows them access.
(And to avoid all evaluating subsequent authentications). The
authentication method used prior to giving them a magic token is
almost irrelevant.

  Used in conjunction with https, this method would have minimal
effect on security, and wouldn't require changes to RADIUS.

> I can do what I want with the proposed radius digest draft already, just 
> has to bend the RADIUS exchanges slightly as explained a few minutes ago. 
> The proposed changes is only to allow this to be done without lying to the 
> RADIUS server, and only as an optional feature.

  I'm not opposed to people doing it in site-local deployments.  I
think it can have significant benefits in controlled environments.  I
*am* opposed to standardizing it.

  Alan DeKok.

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

Delivery-date: Thu, 29 Dec 2005 22:39:04 +0000
Date: Thu, 29 Dec 2005 23:38:48 +0100 (CET)
From: Henrik Nordstrom <[email-masked]>
To: [email-masked]
Subject: Re: Issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess 

On Thu, 29 Dec 2005, Alan DeKok wrote:

>  That's what cookies are for.  See my "mod_auth_radius" for an
> implementation that authenticates the user once, and uses a cookie for
> the following HTTP sessions.  The module isn't perfect (by any means),
> but the general concept goes like this:
>
>  Session1 : get authentication data from the user
>             pass to radius server
> 	     if access-accept
> 		cookie = MD5(authentication data + secret + timestamp) + ...
>
>  SessionN : get authentication data from the user
> 	      validate cookie
> 	      if cookie has expired or is invalid, re-auth the user
> 	      else let them in.

I assume you are aware that Digest MD5-sess iss running circles around the 
above scheme in terms of security thanks to the replay protection provided 
by the nonce-count in the Digest protocol. The above proposed scheme can 
only be considered reasonably secure if combined with end-to-end transport 
security (i.e. https for encryption). Even if using a more secure hash 
than MD5 in your cookie is taken into account.

>  I would very, very, much recommend against pushing authentication
> data to the client without a detailed security review of the
> implications.  Since there are pre-existing methods for implementing
> what you want without changing RADIUS, I would recommend against
> changing RADIUS.

I can do what I want with the proposed radius digest draft already, just 
has to bend the RADIUS exchanges slightly as explained a few minutes ago. 
The proposed changes is only to allow this to be done without lying to the 
RADIUS server, and only as an optional feature.

Regards
Henrik

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

Delivery-date: Thu, 29 Dec 2005 22:23:24 +0000
Date: Thu, 29 Dec 2005 23:22:51 +0100 (CET)
From: Henrik Nordstrom <[email-masked]>
To: [email-masked]
Subject: Re: Issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess

On Thu, 29 Dec 2005, Jo Hermans wrote:

> I've implemented a scheme like this before, and will have to do soon
> again (both in VOIP applications), but only when there was a strong
> trust relationship between the radius client and the server, and only
> to improve authentication-latency. There are serious security
> implications caused by this. The transport can be protected with
> IPSEC, and/or the attribute can be additionally encrypted or signed to
> prevent snooping or spoofing. But that's not enough.

In this regard it's no different than qop=auth-int in my view.

> It should not be used together with MD5, since A1 is then
> "user:password:realm", and this makes it too easy to use in later
> authentications. MD5-sess is better, but the RADIUS-server can't know
> how long the client is planning to use this session-key. Too bad we
> can't use hashes that are only valid for a certain time.

Granted, and is why my message was about MD5-sess only, and worded
carefully to restrict it to MD5-sess only.

Regarding session time, in setups using session authentication this is 
generally configured in the access server today anyway. The Radius 
authentication is for authenticating the session as such, not the 
individual requests. Digest as such already protects from replay attacs 
thanks to the nonce count (which any decent Digest implementation should 
track carefully), so the only real security threat here is eavesdropping 
of the MD5-sess hash between the RADIUS client and server as this could 
allow for session theft. This is no different from the qop=auth-int case 
already covered by the draft

Exception to the above: The combination of qop=auth-int + 
algorithm=MD5-sess and a Radius server (or client depending on mode of 
operation) only allowing a single request per nonce implicitly blocks any 
replay attacks thanks to the per request randomisation of the MD5-sess 
H(A1).

> Although it can be a good improvement in latency, I don't think that
> we should standardize this.

Any reasons besides the security implications which already exists in 
qop=auth-int exchanges of Digest-HA1?

Small sidenote fact: The RADIUS client can already gain access to what is 
required for MD5-sess session based authentication by faking the digest 
RADIUS request using qop=auth-int even if qop=auth is used in the 
communication to the end user agent. As this delegates the responsibility 
of creating the Digest-Response to the RADIUS client it is able to modify 
the qop (and even MD5/MD5-sess) to it's liking. The proposed change in 
wording only makes this support more explicitly visible without having to 
modify the digest parameters while talking to the RADIUS server to work 
around the restrictions in the draft..

Regards
Henrik

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

Delivery-date: Thu, 29 Dec 2005 19:54:18 +0000
Date: Thu, 29 Dec 2005 20:53:50 +0100
From: Jo Hermans <[email-masked]>
To: [email-masked]
Subject: Re: Issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess

On 12/29/05, Bernard Aboba <[email-masked]> wrote:
> Date: Thu, 29 Dec 2005 05:29:59 +0100 (CET)
> From: Henrik Nordstrom <[email-masked]>
> To: [email-masked]
> Subject: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess
>
> Has there been any thought of allowing RADIUS to be used for session base=
d
> MD5-Sess authentication, where processing of further authentication withi=
n
> the same session is carried out by the radius client (i.e. HTTP
> server/proxy) rather than the RADIUS server?

I've implemented a scheme like this before, and will have to do soon
again (both in VOIP applications), but only when there was a strong
trust relationship between the radius client and the server, and only
to improve authentication-latency. There are serious security
implications caused by this. The transport can be protected with
IPSEC, and/or the attribute can be additionally encrypted or signed to
prevent snooping or spoofing. But that's not enough.

It should not be used together with MD5, since A1 is then
"user:password:realm", and this makes it too easy to use in later
authentications. MD5-sess is better, but the RADIUS-server can't know
how long the client is planning to use this session-key. Too bad we
can't use hashes that are only valid for a certain time.

Although it can be a good improvement in latency, I don't think that
we should standardize this.

>
> This is quite interesting in HTTP applications, where quite many requests
> can be seen within the same session and at a relatively high rate. (i.e.
> thousands of requests/second, for a active end-user population of a few
> thousands). Having the bulk of the authentication verifications carried
> out in the RADIUS client (HTTP server/proxy) can significantly reduce the
> load on the RADIUS server and greatly improve the request latency
> (quality) of the service provided.
>
> The principle behind this is that the MD5-sess hash A1 (Digest-HA1, aka
> 'session key' in RFC2617) attribute is given to the client (HTTP
> server/proxy) even if qop=3Dauth (or perhaps even missing). This allows t=
he
> HTTP server/proxy to internally process further requests in the same
> session (same server side nonce), considerably reducing the load on the
> RADIUS server.
>
> Today the wordings in draft-ietf-radext-digest-auth06.txt forbids this
> mode of operation, and one has to loop via qop=3Dauth-int to fool the RAD=
IUS
> server into a mode allowing for this, even if . The following quite modes=
t
> changes is needed to allow for RADIUS to be used in such conditions:
>
> 1.3.  Overview
> 3.1.  RADIUS Client Behavior
>
> here one may want to add a section describing this optional behavior of
> the client.
>
> 3.2.  RADIUS Server Behavior
>
> Add the following condition
>
>     o  If the Digest-Qop attribute's value is 'auth' and the
>        Digest-Algorithm attribute's value is 'MD5-sess' the RADIUS
>        server MAY add a Digest-HA1 attribute into the Access-Accept
>        packet to allow the client to process further authentication
>        requests within the same session.
>
> 4.19.  Digest-HA1 attribute
>
> Here the qop related restriction on when this attribute may be sent needs
> to be dropped. Having restrictions here is also in large redundant with
> section 3.2 I think.
>
> For security reasons I would also add a recommendation to restrict the
> MD5-sess case (including qop=3Dauth-int) to when the RADIUS server has
> generated the Digest-Nonce. Sending MD5-sess Digest-HA1 in the mode where
> the RADIUS client has generated the nonce allows for session theft if the
> attacker can listen to the external traffic and also query the RADIUS
> server, even if he can not see the traffic between the actual RADIUS
> client used and the RADIUS server.
>
> Regards
> Henrik
>
>
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

--
Jo Hermans

"Eagles may soar, but weasels aren't sucked into jet engines"

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

Envelope-to: [email-masked]
Delivery-date: Thu, 29 Dec 2005 18:14:34 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess 
Date: Thu, 29 Dec 2005 13:19:24 -0500
Message-Id: <[email-masked]>

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

  I don't think there's any precedent in RADIUS for pushing
authentication data to the client.  I think it would be a significant
change to the security model of the protocol.

> This is quite interesting in HTTP applications, where quite many requests
> can be seen within the same session and at a relatively high rate. (i.e.
> thousands of requests/second, for a active end-user population of a few
> thousands).

  That's what cookies are for.  See my "mod_auth_radius" for an
implementation that authenticates the user once, and uses a cookie for
the following HTTP sessions.  The module isn't perfect (by any means),
but the general concept goes like this:

  Session1 : get authentication data from the user
             pass to radius server
	     if access-accept
		cookie = MD5(authentication data + secret + timestamp) + ...

  SessionN : get authentication data from the user
	      validate cookie
	      if cookie has expired or is invalid, re-auth the user
	      else let them in.

  The cookie is formed as follows: an MD5 of data followed by some
clear-text data used in the MD5 hash.  I'd suggest using HMAC rather
than MD5, though.

  The hash needs to contain the authentication data, to tie it to the
session.  It also needs to contain a per-server secret (e.g. data read
from /dev/urandom at initialization time).  The secret is really a
salt, and ensures that the cookie can't be discovered via dictionary
attacks.  It also ties the cookie to an instance of the server, so if
it restarts, the user must authenticate.  The cookie also contains a
timestamp, so that the server can force it to expire, because you
don't trust the client to honor the expiry time.  The timestamp is in
the clear in the cookie, so that the server doesn't have to keep any
per-session data.  The timestamp is also used in the hash, to ensure
that the client can't undetectably change the clear-text version of
the timestamp.

  If the cookie gets too long, you can include only a portion of the
hash in the cookie.

  That's a long-winded explanation, but I think it addresses your
situation.

  I would very, very, much recommend against pushing authentication
data to the client without a detailed security review of the
implications.  Since there are pre-existing methods for implementing
what you want without changing RADIUS, I would recommend against
changing 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: Thu, 29 Dec 2005 09:51:49 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess
Date: Thu, 29 Dec 2005 01:50:59 -0800

Date: Thu, 29 Dec 2005 05:29:59 +0100 (CET)
From: Henrik Nordstrom <[email-masked]>
To: [email-masked]
Subject: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess

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

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

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

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

1.3.  Overview
3.1.  RADIUS Client Behavior

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

3.2.  RADIUS Server Behavior

Add the following condition

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

4.19.  Digest-HA1 attribute

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

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

Regards
Henrik

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

Delivery-date: Thu, 22 Dec 2005 14:10:46 +0000
Content-class: urn:content-classes:message
Subject: RE: RFC 4282 (NAI, revised) [fwd]
Date: Thu, 22 Dec 2005 16:10:17 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba wrote:

> I think we also need to check that the ABNF in RFC 4282 is=20
> compatible with RFC 2821 ABNF (Section 4.1.2).

It's not -- as we found out when discussing what IKEv2 ID
payload type should be used for NAIs.

But this is not really a problem. It's not necessary that=20
all valid SMTP email addresses are usable as NAIs or vice=20
versa.

(Couple of examples: "joe@[1.2.3.4]", "foo"@example.com,=20
"joe", "@example.com", and everything containing UTF-8.)

Best regards,
Pasi

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

Delivery-date: Wed, 21 Dec 2005 17:09:42 +0000
Date: Wed, 21 Dec 2005 19:08:28 +0200
From: Jari Arkko <[email-masked]>
To: "Nelson, David" <[email-masked]>
CC:  [email-masked]
Subject: Re: Issue: Treatment of null Identity Response

>>So Proposed text:
>>
>>Type: TBD for Chargeable-User-Identity.
>>
>>   Length: >= 3
>>
>>   String:
>>
>>      The string identifies the CUI of the end-user.
>>    
>>
>
>Works for me.
>  
>
Me too.

>Maybe we should also add the standard tag line about "... and robust
>implementations should treat the string as undistinguished octets.",
>unless this is already in the document someplace else.
>  
>
RFC 2865 is quite clear on this, IMHO :-)

(But the name of the datatype was badly chosen.)

--Jari

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

Delivery-date: Wed, 21 Dec 2005 17:06:27 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Treatment of null Identity Response
Date: Wed, 21 Dec 2005 12:06:27 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> So Proposed text:
>=20
> Type: TBD for Chargeable-User-Identity.
>=20
>    Length: >=3D 3
>=20
>    String:
>=20
>       The string identifies the CUI of the end-user.

Works for me.

Maybe we should also add the standard tag line about "... and robust
implementations should treat the string as undistinguished octets.",
unless this is already in the document someplace else.

--
to unsubscribe send a message 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, 21 Dec 2005 16:57:17 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Treatment of null Identity Response
Date: Wed, 21 Dec 2005 11:58:44 -0500
From: "Avi Lior" <[email-masked]>
To: "Emile van Bergen" <[email-masked]>, "Jari Arkko" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, <[email-masked]>

The CUI should be of Type String.

And actually it is and it isn't and we need to fix the text.

Current text:

Type: TBD for Chargeable-User-Identity.

   Length: >=3D 3

   String:

      The string identifies the CUI of the end-user and is of type
      UTF8String.=20

It says its of type "String" but then it says it is a UTF8String.  This
is because in the early days it was probably of type Text and not string
but then we added the opaque handle....

So Proposed text:

Type: TBD for Chargeable-User-Identity.

   Length: >=3D 3

   String:

      The string identifies the CUI of the end-user.

We should get this in AUTH48.=20

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Emile van Bergen
> Sent: Saturday, December 17, 2005 1:01 PM
> To: Jari Arkko
> Cc: Nelson, David; [email-masked]
> Subject: Re: Issue: Treatment of null Identity Response
>=20
> Hi,
>=20
> Sorry to break in, but I need to support Jari in this:
>=20
> On Thu, Dec 15, 2005 at 05:42:00PM +0200, Jari Arkko wrote:
>=20
> > Nelson, David wrote:
> >=20
> > >Jari Arkko writes...
> > >
> > >=20
> > >
> > >>>The text in the CUI draft indicates that the NUL CUI includes a
> > >>>    =20
> > >>>
> > >single
> > >=20
> > >
> > >>>'NUL' character.
> > >>>    =20
> > >>>
> > >>Right. This is correct, and we do not have a problem with=20
> the empty=20
> > >>string rule.
> > >>  =20
> > >>
> > >
> > >Since counted strings can have embedded NUL characters,=20
> that's true. =20
> > >It obviously requires special handling in the C-style string to=20
> > >RADIUS string conversion, though.
> >
> > Well, if its a "string" in RADIUS terminology then its=20
> really an octet=20
> > string in more general terminology, and implementations=20
> already have=20
> > to support embedded  00s.
>=20
> Fully agreed.=20
>=20
> And in C, people routinely work with length-defined strings=20
> as well as NUL-terminated strings, by the way.
>=20
> > >I agree, although if the type is intended to be a UTF-8 printable=20
> > >string, the correct RADIUS type would be "text", not "string.  If=20
> > >there is consensus on that, it could be fixed in AUTH48.
> > >=20
> > >
> > Yes. To me the CUI function is more of a binary handle than a=20
> > printable string. But I'm not sure if others agree.
>=20
> Fully agreed again.
>=20
> Cheers,
>=20
>=20
> Emile.
>=20
> --=20
> E-Advies - Emile van Bergen           [email-masked]     =20
> tel. +31 (0)78 6136282           http://www.e-advies.nl   =20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Wed, 21 Dec 2005 01:19:12 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: [eap] Review of the IEEE 802.11u Requirements Document
Date: Tue, 20 Dec 2005 17:18:31 -0800

During the review of 'EAP Network Selection' questions arose about the 
backend implications on protocols such as RADIUS, as well as the EAP side of 
things.  Since 'EAP Network Selection' was considered a short term solution, 
it was not considered to extend it to handle additional parameters such as 
'cost'.

Yet the requirements document seems to make an architectural assumption that 
solutions such as 'EAP Network Selection' are available, and can be used to 
allow the AP to discovery properties of downstream realms.   This is of 
concern since it would be basing the long term solution on what was 
originally considered to be a short-term fix.

Rather than making architectural assumptions that may or may not be 
required, it may make moe sense to focus on the requirements that are truly 
fundamental such as scalability.

For example, if a proposal could meet the scalability requirements, allowing 
a STA to connect to hundreds or even thousands of SSIDs, then it might be 
possible for each NAI realm to have its own SSID.  This considerably 
simplifies the architecture, and gets around some very thorny problems that 
are created by 'EAP Network Selection'.

>[Mike Moreton] When a problem is best solved by a multi-layer
>solution there's always going to be a chicken and egg type
>problem.  I don't believe 802.11u is trying to solve the complete
>problem - just to "do our bit".
>
>I think everyone in 802.11u is hoping that "someone else" will do
>the bits required at other layers - it's clearly not
>desirable for the AP to have the information to answer such a
>query (other than perhaps by caching).  But we can't start
>liaising with other organisations until we have accepted a
>proposal, and hence know what is needed. In case anyone
>reading this thinks that 802.11u will be useless without such a
>higher layer I guess I should say the following.  I would
>expect most proposed solutions to our requirements could work
>in limited scenarios by hard configuration of the APs, or by
>proprietary protocols.  So 802.11u is still useful in that case -
>but to gain its full utility we need someone else to develop
>open backend protocols.

I think the question arises as to how the "backend protocol" would be 
expected to work.  As mentioned earlier, NAS devices are not expected to 
participate in the realm routing mesh, so that there really is no effective 
way for them to obtain a full realm routing table from downstream proxies.  
This is a fundamental aspect of the architecture, not just a limitation of 
current technology.

During IETF 64, it was suggested that the AP could forge 
EAP-Response/Identity packets in order to obtain "realm hints" as specified 
by 
http://www.watersprings.org/pub/id/draft-adrangi-eap-network-discovery-14.txt.

This raised a number of concerns, such as the potential for unauthenticated 
users to do a DoS attack on the AAA infrastructure.  Some of the cautions 
included in RFC 2865 Section 2.6 may apply here:

2.6.  Keep-Alives Considered Harmful

   Some implementers have adopted the practice of sending test RADIUS
   requests to see if a server is alive.  This practice is strongly
   discouraged, since it adds to load and harms scalability without
   providing any additional useful information.  Since a RADIUS request
   is contained in a single datagram, in the time it would take you to
   send a ping you could just send the RADIUS request, and getting a
   reply tells you that the RADIUS server is up.  If you do not have a
   RADIUS request to send, it does not matter if the server is up or
   not, because you are not using it.

   If you want to monitor your RADIUS server, use SNMP.  That's what
   SNMP is for.

> > Much as an Internet host determines whether another host is
> > reachable by sending an IP packet to it, a network peer
> > determines whether it can authenticate to a realm by
> > attempting to communicate with it.  If a peer attempts to
> > authenticate to an unreachable realm, the problem may not be
> > diagnosed until the request has traversed a core proxy with
> > full knowledge of the realm routing table, much as a "ping"
> > may not generate an ICMP network unreachable message until
> > the request has reached a core router.
> >
> > As a result, it appears that much of the functionality
> > required by IEEE 802.11u cannot be provided in situations
> > where a single SSID is used to access an indetermine number
> > of NAI realms.  In such situations,
> > the AP cannot easily obtain the required information relating
> > to the availability and capabilities of reachable realms.
> >
> > The problem would be more tractable were IEEE 802.11u to
> > focus on development of a more scalable "Virtual AP" model
> > for IEEE 802.11.  In such a model, a determinate number of
> > NAI realms (perhaps only one) would correspond to an SSID,
> > enabling the AP to be preconfigured with the capabilities
> > associated with each configured SSID.  This would enable the
> > communication of available "Virtual APs" and capabilities to
> > the STA without relying on facilities which are difficult for
> > EAP or the AAA infrastructure to provide.
> >
>
>[Mike Moreton] One of the things there seems general agreement within
>802.11u over is that we have to avoid the multiple SSID situation
>- it just isn't scalable enough.
>I'm also not sure how having multiple SSIDs, each of which
>mapped to a single NAI would actually be any easier than just
>having multiple NAIs.

[BA] I'd suggest that scalability be considered as one of the requirements.  
As I understand it, there are proposals on the table (including support for 
'hidden SSIDs', multiple SSIDs/Beacon, etc.) that would improve scalability.

>[Stephen McCann] Looking ahead to carrier grade 802.11 access networks,
>I don't see how the mapping of SSIDs and NAIs can be managed, especially
>if 'virtual realms' are introduced.

Question:  What is a 'virtual realm'?

> > R8E1 - Required
> >
> > "Define functionality by which the STA is able to determine
> > what online enrolment (also called online subscription)
> > methods are supported by the network"
> >
> > In large scale roaming deployments, an AP will typically not
> > have knowledge of all the potential roaming realms which
> > customers may be able to authenticate to.  For example, an AP
> > typically is not configured with a realm routing table, but
> > just a "default route" to the local AAA proxy or server.  The
> > local AAA proxy in turn may also be configured with a "default route".
> >
> > As a result, the AP may not know what realms are available,
> > nor may it have information on the services (such as
> > enrollment) provided by those realms.  The AP may not be able
> > to inform the STA whether online enrollment is supported by a
> > realm, or even if a realm is reachable by the STA.
> >
> > Note that this problem cannot be solved by introduction of a
> > "realm routing" protocol, since it would be unlikely that
> > such a protocol would
> >
> > be supported by an AP, or even a local AAA proxy.  Due to the
> > memory and
> >
> > CPU requirements, it would be likely to only be supported
> > on "core proxies", much as BGP is only run on core routers.
> >
> > As a result, an AP can only be presumed to have knowledge of
> > a realm if that realm is configured into the AP, potentially
> > as a "Virtual AP".
>
>[Mike Moreton] I think the core assumption within
>802.11u is that the user device knows the identity (NAI etc) of
>the network it wants to connect to.  When considering
>enrolment, it's easy enough for the device to discover the
>identity of the local network, so enrolment with the local
>network should not be a problem.  As you say, enrolment with
>remote networks would be challenging, but I'm not sure anyone
>was imagining that case when the requirement was written.

There is an important distinction between a 'network' and a 'realm'.  An NAI 
realm is used to identify the home AAA server that the user authenticates 
to.  As a result of that authentication and subsequent authentication, the 
user offered access.  The parameters of that service may include tunneling 
(RFC 2868), VLAN tagging (RFC 3580), or more advanced VLAN processing 
(VLAN/Priority attributes draft).  However, users in different realms may 
receive the same service, and thereby may be able to access the same 
network.  So 'network' and 'realm' are really orthogonal concepts.

> > Where a single physical or virtual AP is configured to enable
> > access to multiple realms, the only way a STA can determine
> > whether the realm supports an enrolment method is via an EAP
> > exchange with that realm.
> >
> > While a partial solution is provided within "Identity
> > selection hints for EAP"
> > http://www.watersprings.org/pub/id/draft-adrangi-eap-network-d
> > iscovery-14.txt
> > this solution requires the STA to associate with an AP prior
> > to discovering the supported realms.
> >
> > As a result, where an indetermine number of realms are
> > reachable via a single "Virtual AP", the requirement
> > specified in R8E1 may not be satisfiable by an exchange
> > occurring solely within IEEE 802.11.
> >
> > R8E2 - Optional
> >
> > "Define functionality for online enrolment"
> >
> > During the recent EMU BOF, there was discussion of enrolment
> > support within EAP.  Rohan Mahy has submitted a draft on this
> > subject:
> > http://www.watersprings.org/pub/id/draft-mahy-eap-enrolment-00.txt
> >
> > This would support the document's assertion that "a solution
> > may be outside the scope of this task group".
> >
> > However the current EMU WG Charter does not include a work
> > item on enrolment.
>
>[Stephen McCann] Rohan previously has presented some interesting
>material in 802.11u and I suggest that 802.11u reviews this draft, to 
>identify
>any useful ideas.

Since EMU is not being chartered to handle this work, if 802.11u has 
identified a need for this, then it would be appropriate to communicate that 
need.

> > R8E4 - Optional
> >
> > "Functionality shall be provided by which APs can advertise (before
> > connection) the charges that will be made for use of the
> > network if a user enrolls with it."
> >
> > The charges associated with access to a realm may vary not
> > only with the realm but also with the path by which the realm is 
>accessed
> > -- the "decorated NAI". Since charges may also vary by time
> > of day or day of the week, the information required to fully
> > inform the STA may be quite complex.
> >
> > For the reasons described in R8E1, an AP may not know the
> > realms accessible from within a given "Virtual AP", or the
> > charges associated with access to that realm via any path, at
> > any time.
> >
> > Since neither EAP nor AAA provides a mechanism for
> > communication of charges, it is not clear how this
> > requirement can be satisfied other than by manual
> > configuration of an AP.
> >
> > We concur with the document characterization of this
> > requirement as "optional".
> >
> > R8N1 - Required
> >
> > "Define functionality by which a STA can determine whether
> > its subscription to an SSPN would allow it to access a
> > particular 802.11AN before actually joining a BSS within that
> > 802.11 AN. Proposals must describe their consideration of
> > scalability."
> >
> > As described in the analysis of R8E1, where a single
> > physical/virtual AP
> >
> > provides access to an indetermine number of realms an AP may
> > not know what realms are accessible from a given "virtual
> > AP".  As a result, the AP may not have the information
> > available to satisfy this requirement.
>
>[Mike Moreton] My assumption is that this information would either
>be hard configured into the AP (not desirable) or that the
>query would be passed on to some other device using some
>protocol designed by another standards organisation (much more
>desirable).

As noted above, at IETF 64, there was concern expressed about the security 
aspects of proposals for the 'other protocol'.

> > R8N2 - Required
> >
> > "The mechanism described in requirement R8N1 must allow a STA
> > that has multiple credentials with an SSPN to select the
> > correct credentials when authenticating with a Local Network."
> >
> > For a STA to select the correct credentials, it needs to be
> > aware of the realms available to it, as well as the EAP method to be 
>used
> > with the desired realm. Once a STA has enrolled in a realm,
> > it presumably is configured with the EAP method to be used
> > for that realm, so that the problem comes down to determining
> > which realms are available.
> >
> > Therefore the issues inherent in realm discovery (see R8E1)
> > are applicable to this requirement as well.
>
>[Mike Moreton] I've never quiet understood this requirement, but my
>assumption is that the response to a "Do you provide connection
>to this NAI?" question would also include an optional field
>that could be used to indicate the realm within the network
>indicated by that NAI.  How that information gets to the AP
>is again out of our scope.
>
> > R8N3 - Required
> >
> > "Define functionality to support authentication with multiple
> > SSPNs through a single AP."
> >
> > That document indicates that "Its not acceptable to require a
> > separate "virtual" AP for each SSPN", but does not provide
> > more detail on how this statement was arrived at.  Certainly,
> > existing "Virtual AP" mechanisms do not scale much beyond a
> > dozen "Virtual APs" per physical AP.  However, recent
> > submissions within IEEE 802.11 appear to be aimed at removing
> > those limitations, by enabling multiple "Virtual APs" to be
> > supported within a
> >
> > single Beacon/Probe Response, as well as by enabling support
> > of "hidden virtual APs" that are not advertised.
> >
> > It would therefore appear that in the long term it may be
> > possible to remove many of the "virtual AP" scaling limitations.
> >
> > It is suggested that IEEE 802.11u re-examine whether R8N3 is
> > really required.
>
>[Mike Moreton] I think the consensus within 802.11u has
>always been that we're willing to consider any proposal that
>solves the problem, even if that proposal is "Don't do
>anything - it's already solved elsewhere".  The notes are
>meant to be explanatory of the requirement and are not
>limiting. But some of the 802.11u contributors are keen to
>support architectures where 100s of different home networks
>can be accessed - this is way beyond what can be achieved by
>putting multiple SSIDs in the same beacon (and would in any
>case have the sort of configuration issues you describe earlier).
>
>[Stephen McCann] Again Mike is referring to 'carrier grade'
>installations, which some members of 802.11u are very concerned about.
>
> >
> >
> > R8N5,  R8N6 - Optional
> >
> > The issues described with respect to R8E4 apply here as well.
> > We concur with the characterization of this requirement as "optional".
> >
> > R8N7 - Not Required
> >
> > "It should be possible to inform a STA about unbroadcasted
> > SSIDs without
> >
> > causing the STA to probe for each preferred SSID."
> >
> > Unbroadcasted or "hidden" SSIDs are one mechanism by which
> > the scalability of 802.11 advertisement mechanisms may be
> > improved.  In a large scale roaming deployment, presumably
> > many of the SSIDs would be "hidden", since even support for
> > multiple "virtual AP" advertisements per Beacon might not be
> > sufficient.
> >
> > Since a "hidden" SSID is by definition not advertised, a
> > Probe Request/Response exchange is typically necessary to
> > determine whether it
> >
> > is supported.  If a STA has multiple SSIDs in its preference
> > list which could conceivably be "hidden" then it is not clear
> > how it can determine whether they are present without probing
> > for them.
> >
> > We concur with the document characterization of this
> > requirement as "not required".
>
>[Stephen McCann] For readers not familiar with 802.11u, Bernard
>correctly states that this requirement is now out of scope of 802.11u.
>However, for historical reasons we have kept it in our requirements
>document.

I do think that the topic of 'hidden SSIDs' is worth investigating though, 
because this does address many of the Beacon scalability issues that lead to 
the development of draft-adrangi-eap-network-discovery.  That document was 
understood at the time to be an interim solution that would be superceded by 
a better solution developed within IEEE 802.11u.

Because it was supposed to be an 'interim solution', draft-adrangi did not 
deal with issues such as caching/TTL, addition of parameters such as cost, 
etc.  During the discussion of draft-adrangi, there was concern about going 
down that road. So if the 'long term' solution will now rely on 
draft-adrangi, and attempt to introduce extensions that were considered out 
of scope (cost, TTL, etc.), then I think that would be a cause for concern, 
along with allowing 'realm discovery' to be triggered by an unauthenticated 
Probe Request.

> > R8P2 - Required
> >
> > "Define functionality to prevent hijack of MAC addresses."
> >
> > RFC 4017 requires EAP methods supporting "mutual
> > authentication" and "key derivation" so that a STA supporting
> > IEEE 802.11i can determine whether an AP to which it has
> > associated has been authorized by the AAA server.
> >
> > RFC 4017 also includes "Channel Binding" as an optional
> > security claim. Among other things, support for channel
> > bindings enables a STA to check with the AAA server whether
> > an AP is impersonating another AP to the STA.
> >
> > More recently, IEEE 802.1ar "Secure Identity" has been
> > chartered in order to enable verification of ownership of MAC
> > addresses.
> >
> > Therefore there appears to be work in progress relevant to
> > this requirement.
>
>[Mike Moreton] Good!  If we can reference other
>people's work then I'm all in favour of it.  We need to keep
>it as a requirement even if that will end up being the case.
>Note that there are also traffic segmentation solutions to
>this problem that may be equally beyond our scope.
>
> >
> > R8A1 - Required
> >
> > "A STA shall be able to authenticate with different SSPNs
> > simultaneously, in order to gain simultaneous access to
> > multiple Destination Networks."
> >
> > Simultaneous access to multiple wireless networks has been
> > demonstrated using existing standards:
> > http://research.microsoft.com/~bahl/MS_Projects/MultiNet/default.htm
> >
> > As a result, new functionality may not be required to satisfy
> > this requirement, if a scalable "Virtual AP" model is
> > available.
>
>[Mike Moreton] And if we come up with a proper solution to
>the MAC address anonymity problem it may be impossible to
>prevent the STAs doing this.  Note that some operators have a
>big issue with this requirement.
>
> > R8I1 -  Required
> >
> > "Define IEEE 802.11TM functionality which would be required
> > to support an Emergency Call (e.g. E911) service as part of
> > an overall, multi-layer solution. Specifically: Capability
> > Advertisement Authentication issues"
> >
> > Multiple IEEE 802 groups have already become involved in the
> > specification of Emergency Service capability -- IEEE
> > 802.11k, 802.11v, 802.1AB (via TIA LLDP MED), raising
> > questions about the overall coherence of the
> >
> > effort, let alone compatibility with the work of IETF WGs
> > such as ECRIT and GEOPRIV.
> >
> > IEEE 802.11u may therefore wish to consider whether addition
> > of another group will help or hinder the effort to develop a
> > coherent Emergency Services architecture.
>
>[Mike Moreton] 802.11 WG is
>co-ordinating the work of the various 802.11 task groups
>interested in the Emergency Call Service.  A final decision
>has not yet been taken whether to place the bulk of this work
>within 802.11u or 802.11v but I can assure you that the
>intention is definitely not to have competing solutions.  The
>802.11k contribution is likely to be limited to provision of
>location information, and hence will be part of the overall
>solution rather than an alternative solution.
>
>[Stephen McCann] Specifically 802.11u feels that it should address
>the network advertisement of emergency call capability and
>subsequent admission control issues, as these are essentially
>interworking issues. It will not consider any location requirements.

--
to unsubscribe send a message 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, 19 Dec 2005 19:24:48 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: RFC 4282 (NAI, revised) [fwd]
Date: Mon, 19 Dec 2005 11:24:22 -0800

>This is indeed an oversight. Too bad you did not tell us about it
>a few days earlier... and I'm kind of surprised this does not
>happen at the RFC editor side automatically.

Part of the problem is that RFC 1123 does not state that it updates RFC 821, 
although RFC 2821 does state that it obsoletes 821, 974, 1869 and updates 
1123.

>Anyway, as a conclusion I'm suggesting we send an errata
>entry to the RFC Editor that shows the 821 update and 2.6
>new situation.

I think we also need to check that the ABNF in RFC 4282 is compatible with 
RFC 2821 ABNF (Section 4.1.2).

--
to unsubscribe send a message 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, 19 Dec 2005 08:34:42 +0000
Date: Mon, 19 Dec 2005 10:33:42 +0200
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>,  [email-masked]
CC:  [email-masked]
Subject: Re: RFC 4282 (NAI, revised)  [fwd]

Hi Alfred,

> Unfortunately, the text of that RFC does not fully reflect the
> established state of the IETF standards, by referring to obsolete
> documents (e.g., ex STD 10, RFC 821) and ignoring effective updates,
> e.g., STD 3, RFC 1123, and RFC 2821.

This is indeed an oversight. Too bad you did not tell us about it
a few days earlier... and I'm kind of surprised this does not
happen at the RFC editor side automatically.

We could make an errate entry for this.

> In particular, the text of RFC 4282 repeatedly (e.g. in Section
> 2.6.) emphasizes making a deviation from established standards
> for host / domain names.
>
> This is not true!
> The pretended deviation in fact reflects the current standards.

Right. Material for an errata.

> The modification to RFC 952, RFC 821, et al. has already been
> introduced into the IETF Standards by STD 3, RFC 1123 (Host
> Requirements, Part II), published 16 years ago, in October 1989.
> Section 2.1 of that RFC, on page 13, says:
>
>    "One aspect of host name syntax is hereby changed: the
>     restriction on the first character is relaxed to allow
>     either a letter or a digit. Host software MUST support
>     this more liberal syntax."
>
> and continues saying:
>
>    "Host software MUST handle host names of up to 63 characters
>     and SHOULD handle host names of up to 255 characters."
>
> Therefore, it would have been strongly advisable to point out
> on page 6 of RFC 4282, in Section 2.2, first bullet, that the
> named rules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!

This is true, but IMHO not the task of this RFC to complain.
There is ongoing work in the RADEXT WG on documenting
issues with the RADIUS protocol, and it might be good to
take care of this issue in there.

> Note: IMHO, it is a fundamental design flaw of RADIUS and certain
> other protocols using TLVs, AVPs, -- or however similar protocol
> objects are named -- to specify that the 'length' information
> (being stored in a single octet) is to comprise the cumulative
> size of the Type, Length and Value fields, instead of just giving
> the size of the Value (payload) field; the latter solution would
> always allow to fully exhaust the total range of an 8-bit unsigned
> Length and thereby allow payload octet strings of size 0..255 !

Yeah. But we have to live with it.

> Similarly, RFC 4282 ignores the standardization state of the
> proprietary historic tunnelling protocols that have served as
> 'precursors with major deficiencies to learn from' for the
> development of L2TP, the only comparable protocol named in
> RFC 4282 that is on the IETF Standards Track.
>
>  o   L2F [RFC2341] has been published for information only
>      as a Historic RFC 'ab initio'.
>
>  o   PPTP [RFC2637] has purposely been rejected by the IETF --
>      because of its well known significant security flaws, among
>      other issues, and the Informational RFC 2637 has been
>      published with a very clear IESG Note to this end.
>
> I am surprised that a new Standards Track RFC is getting published
> that repeatedly refers to obsolete protocols equally as to official
> protocols, in a manner that does not make clear the distinction.
> The continued unreflected use of PPTP, in particular, is seen by
> major security consultants as 'one of the most widespread trojan
> horses' in the current Internet.  We should do everything to
> communicate and emphasize the 1998/1999 decisions of the IETF and
> IESG and the reasons behind it, and push the evolved standards!

This text was inherited from RFC 2486. But again, while I agree
with some of the issues in these non-IETF protocols, I'm not sure
the NAI RFC is the right place to discuss such issues. I agree that
if the text had been written from scratch, it probably would have
been better to keep the tunneling protocol text to a minimum.
Still, I happen to believe in pointing to usage as opposed to
not mentioning this. It would be good to be able to separate standards
from non-standards in references, but I'm not sure how to do
that easily. Its easy most of the time to separate the normative
and informational references, as we do here too, but your
issue is with the separation between standards-track and
individual submission RFCs. Unfortunately, the current
designations in the references section do not make a clear
distinction here. For instance, since 2661 is only a Proposed
Standard, the reference entry looks the same as 2637, which
is an individual submission RFC. Thoughts?

Anyway, as a conclusion I'm suggesting we send an errata
entry to the RFC Editor that shows the 821 update and 2.6
new situation.

--Jari

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

Delivery-date: Mon, 19 Dec 2005 03:34:20 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RFC 4282 (NAI, revised)  [fwd]
Date: Sun, 18 Dec 2005 19:33:41 -0800

-----Original Message-----
From: Alfred HÃnes [mailto:[email-masked]]
Sent: Sun 12/18/2005 10:18 AM
To: Bernard Aboba; [email-masked]; [email-masked]; 
[email-masked]
Cc: [email-masked]
Subject: RFC 4282 (NAI, revised)

I just read the recently published RFC 4282 (revised NAI spec)
authored by you and would like to submit a few comments.

Unfortunately, the text of that RFC does not fully reflect the
established state of the IETF standards, by referring to obsolete
documents (e.g., ex STD 10, RFC 821) and ignoring effective updates,
e.g., STD 3, RFC 1123, and RFC 2821.

In particular, the text of RFC 4282 repeatedly (e.g. in Section
2.6.) emphasizes making a deviation from established standards
for host / domain names.

This is not true!
The pretended deviation in fact reflects the current standards.

The modification to RFC 952, RFC 821, et al. has already been
introduced into the IETF Standards by STD 3, RFC 1123 (Host
Requirements, Part II), published 16 years ago, in October 1989.
Section 2.1 of that RFC, on page 13, says:

    "One aspect of host name syntax is hereby changed: the
     restriction on the first character is relaxed to allow
     either a letter or a digit. Host software MUST support
     this more liberal syntax."

and continues saying:

    "Host software MUST handle host names of up to 63 characters
     and SHOULD handle host names of up to 255 characters."

Therefore, it would have been strongly advisable to point out
on page 6 of RFC 4282, in Section 2.2, first bullet, that the
named rules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!

Note: IMHO, it is a fundamental design flaw of RADIUS and certain
other protocols using TLVs, AVPs, -- or however similar protocol
objects are named -- to specify that the 'length' information
(being stored in a single octet) is to comprise the cumulative
size of the Type, Length and Value fields, instead of just giving
the size of the Value (payload) field; the latter solution would
always allow to fully exhaust the total range of an 8-bit unsigned
Length and thereby allow payload octet strings of size 0..255 !

Similarly, RFC 4282 ignores the standardization state of the
proprietary historic tunnelling protocols that have served as
'precursors with major deficiencies to learn from' for the
development of L2TP, the only comparable protocol named in
RFC 4282 that is on the IETF Standards Track.

  o   L2F [RFC2341] has been published for information only
      as a Historic RFC 'ab initio'.

  o   PPTP [RFC2637] has purposely been rejected by the IETF --
      because of its well known significant security flaws, among
      other issues, and the Informational RFC 2637 has been
      published with a very clear IESG Note to this end.

I am surprised that a new Standards Track RFC is getting published
that repeatedly refers to obsolete protocols equally as to official
protocols, in a manner that does not make clear the distinction.
The continued unreflected use of PPTP, in particular, is seen by
major security consultants as 'one of the most widespread trojan
horses' in the current Internet.  We should do everything to
communicate and emphasize the 1998/1999 decisions of the IETF and
IESG and the reasons behind it, and push the evolved standards!

Best regards,
  Alfred HÃnes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

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

Delivery-date: Sat, 17 Dec 2005 18:01:24 +0000
Date: Sat, 17 Dec 2005 19:01:16 +0100
From: Emile van Bergen <[email-masked]>
To: Jari Arkko <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: Issue: Treatment of null Identity Response
Mail-Followup-To: Jari Arkko <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]

Hi,

Sorry to break in, but I need to support Jari in this:

On Thu, Dec 15, 2005 at 05:42:00PM +0200, Jari Arkko wrote:

> Nelson, David wrote:
> 
> >Jari Arkko writes...
> >
> > 
> >
> >>>The text in the CUI draft indicates that the NUL CUI includes a
> >>>     
> >>>
> >single
> > 
> >
> >>>'NUL' character.
> >>>     
> >>>
> >>Right. This is correct, and we do not have a problem with the empty
> >>string rule.
> >>   
> >>
> >
> >Since counted strings can have embedded NUL characters, that's true.  It
> >obviously requires special handling in the C-style string to RADIUS
> >string conversion, though.
>
> Well, if its a "string" in RADIUS terminology then its
> really an octet string in more general terminology, and
> implementations already have to support embedded  00s.

Fully agreed. 

And in C, people routinely work with length-defined strings as well as
NUL-terminated strings, by the way.

> >I agree, although if the type is intended to be a UTF-8 printable
> >string, the correct RADIUS type would be "text", not "string.  If there
> >is consensus on that, it could be fixed in AUTH48.
> > 
> >
> Yes. To me the CUI function is more of a binary handle
> than a printable string. But I'm not sure if others agree.

Fully agreed again.

Cheers,

Emile.

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

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

Delivery-date: Fri, 16 Dec 2005 12:17:54 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Treatment of null Identity Response
Date: Fri, 16 Dec 2005 13:16:08 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi,=20

The original intention was to have an UTF-8 text string. The
implementations
I know of treat the CUI as 'text' type (none of them implement the nul
CUI
yet though). However, having it defined as String type would be OK with
me
(for the reasons Jari & you pointed out).

Cheers,
	Jouni

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: 15. joulukuuta 2005 17:54
> To: [email-masked]
> Subject: RE: Issue: Treatment of null Identity Response
>=20
> Jari Arkko writes...
>=20
> > Well, if its a "string" in RADIUS terminology then its
> > really an octet string in more general terminology, and
> > implementations already have to support embedded  00s.
>=20
> Agreed, but see below.
>=20
> > To me the CUI function is more of a binary handle
> > than a printable string. But I'm not sure if others agree.
>=20
> It is defined as a cookie, opaque to all but the issuer (home AAA
> server), so it could be a RADIUS "string" type (binary string).  I
> surmise that the reason that a UTF-8 printable string type=20
> was specified
> has to do with ease of debugging (human readable characters in the
> packet trace).
>=20
> I don't think it matters very much.  If it is to be UTF-8, then it
> should be a RADIUS "text" type, and if it's to be binary, we should
> remove the reference to UTF-8.

--
to unsubscribe send a message 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, 15 Dec 2005 22:16:26 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: IESG Review of draft-ietf-radext-digest-auth-06.txt
Date: Thu, 15 Dec 2005 14:15:50 -0800

>From: Alexey Melnikov <[email-masked]>
>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2)
>             Gecko/20040804 Netscape/7.2 (ax)
>X-Accept-Language: en-us, en
>To: "Beck01, Wolfgang" <[email-masked]>
>CC: [email-masked], [email-masked], 
>[email-masked]
>Subject: Re: IESG Review of draft-ietf-radext-digest-auth06.txt (fwd)

>
>Beck01, Wolfgang wrote:
>
> >Alexey Melnikov wrote:
> >
> >
> >>General comments on the document:
> >>1). sections 3.1 and 3.2 are too complex to follow, because
> >>they allow for so many different modes of operations: nonce
> >>generated on the RADIUS client or the RADIUS server, hash is
> >>calculated on the RADIUS client or the RADIUS server, etc. I
> >>understand why the document is trying to be so flexible, but
> >>the text suffers as the result. I would suggest to separately
> >>talk about scenarios described in sections 1.3.1 and 1.3.2.
> >>
> >>
> >This would introduce some redundancy. A developer implementing
> >the draft for both modes would have to join those sections anyway.
> >
> >
>See also my comment about examples for both scenarios.
>
> >>2). everywhere in section 4: all references to "without
> >>quotes" has to be replaced with "unquoted" or similar.
> >>"Without quotes" can be interpreted as just blindly removing
> >>the surrounding quote characters, however many attribute
> >>values are allowed to contain quoted (escaped) "\" and <">,
> >>so just removing the quotes will not produce proper result.
> >>
> >>
> >>
> >Blindly removing the surrounding quotes is exactly
> >what was meant. quoted-string is used to allow characters
> >that would break the HTTP syntax. This is not relevant for RADIUS,
> >as we have TLV. (Un-)Escaping the actual value would not save very
> >much space (I'd guess that escapes are rare) but complicate the
> >implementation.
> >
> >
>I think you are missing the point. Unescaping is not an optional HTTP
>feature. An HTTP Digest username can contain "\" or <"> characters. They
>must be escaped as per HTTP quoted string syntax. For example if you
>have a username 'domain\user' it will be represented in HTTP Digest as
>"domain\\user". If a naive implementation just strips the quotes it will
>end up with 2 slashes and not 1, which will lead to digest verification
>failure.
>
>This comment applies to at least to username, realm, nonce and cnonce.
>
> >>3). It would be nice to see examples of both scenario 1 and 2
> >>in the document. I think it will clean up a lot of confusion.
> >>
> >>
> >What's wrong with message flow given in 1.3.1 figure 2?
> >
> >
>The message flow is fine, but there are so many optional RADIUS options
>that a regular reader will be easily lost. An additional example can
>also help verify that your description is actually correct. I had to
>reread section 3.1 multiple times to understand how it relates to the
>two scenarios.
>
> >[...]
> >
> >>[...]l
> >>
> >> >   If the RADIUS client recognizes the nonce or does not generate
> >> >   nonces,
> >>
> >>Regarding "does not generate nonces" case - does this
> >>paragraph talk about scenario 2 step 2, or scenario 2 step 6?
> >>I think the latter, but the text is no clear.
> >>
> >>
> >>
> >The paragraph talks about the handling of an HTTP-style request
> >containing an Authorization header. Scenario 2 Step 2 follows an
> >HTTP-style request without an Authorization header. Is this really
> >that unclear?
> >
> >
>IMHO, if somebody is reading the document for the first time, it might
>be confusing a bit.
>
>One way to address that is to move the discussion of nonce generation
>(which is later in the same section) to the front of the section.
>
> > [...]
> >
> >> >3.2.  RADIUS Server Behavior
> >>[...]
> >> >   A RADIUS server MUST check if the RADIUS client is authorized to
> >> >   serve users of the realm mentioned in the Digest-Realm attribute.  
>If
> >> >   the RADIUS client is not authorized, the RADIUS server MUST send an
> >> >   Access-Reject.  The RADIUS server SHOULD log the event so as to
> >> >   notify the operator, and MAY take additional action such as sending
> >> >   an Access-Reject in response to all future requests from this 
>client,
> >> >   until this behavior is reset by management action.
> >>
> >>If the server follow the last MAY, this can be used by DOS
> >>attacks, so I think this should be pointed out.
> >>
> >>
> >In this paragraph or in the Security Considerations section?
> >
> >
>In this section.
>
> >> >   If the RADIUS server does not accept the nonce received in an 
>Access-
> >> >   Request packet but authentication was successful,
> >>
> >>Does the server always have to check that the authentication
> >>was successful before reporting nonce mismatch? Are there any
> >>security implications?
> >>
> >>
> >This is defined in RfC 2617.
> >
>Ok.
>
> >If the HTTP-style client receives
> >a 'stale' directive, it does not need to prompt the user for the
> >password again.
> >
> >
>My question was if nonce verification should be done before or after
>client response verification. (I don't know the answer.)
>
> >> > the RADIUS server
> >> >   MUST send an Access-Challenge packet containing a Digest-Stale
> >> >   attribute set to 'true' (without quotes).  The RADIUS server MUST 
>add
> >> >   Message-Authenticator (see [RFC3579]), Digest-Nonce, Digest-Realm,
> >> >   SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add
> >> >   Digest-Domain, Digest-Opaque attributes to the Access-Challenge
> >> >   packet.
> >>
> >> >4.4.  Digest-Response-Auth attribute
> >> >
> >> >   Description
> >> >         This attribute enables the RADIUS server to prove possession 
>of
> >> >         the password.  If the previously received Digest-Qop 
>attribute
> >> >         was 'auth-int' (without quotes), the RADIUS server MUST send 
>a
> >> >         Digest-HA1 attribute instead of a Digest-Response-Auth
> >> >         attribute.
> >>
> >>This MUST is confusing, as other sections say that both
> >>Digest-Response-Auth and Digest-HA1 are optional.
> >>
> >>
> >This is a conditional MUST. Digest-HA1 is mandatory, if Digest-Qop was
> >auth-int.
> >
> >
>The following text from section 3.1 suggests that Digest-HA1 is truly
>optional:
>    o  If the Access-Accept packet contains neither a Digest-Response-
>       Auth nor a Digest-HA1 attribute, the RADIUS client will not create
>       an Authentication-Info header for its HTTP-style response.
>
> >> >  The Digest-Response-Auth attribute MUST only be
> >> >         used in Access-Accept packets.  The RADIUS client puts the
> >> >         attribute value without quotes into the rspauth directive of
> >> >         the Authentication-Info header.
> >>
> >> >4.8.  Digest-Qop attribute
> >> >
> >> >   Description
> >> >         This attribute holds the Quality of Protection parameter that
> >> >         influences the HTTP Digest calculation.  This attribute MUST
> >> >         only be used in Access-Request and Access-Challenge packets.  
>A
> >> >         RADIUS client SHOULD insert one of the Digest-Qop attributes 
>it
> >> >         has received in a previous Access-Challenge packet.
> >>
> >>I was under impression that the HTTP[-like] client is the one
> >>choosing Qop from the list of Qops specified by the RADIUS server.
> >>
> >>
> >I don't understand the problem.
> >
> >
>The last sentence "A RADIUS client SHOULD insert one of the Digest-Qop
>attributes it has received in a previous Access-Challenge packet."
>implies that the RADIUS client (== HTTP server) is the one picking the
>Qop. I think the last sentence can say:
>
>"A RADIUS client sends the Qop value received from the HTTP client in the 
>Digest-Qop attribute."
>
> >> >RADIUS
> >> >         servers SHOULD insert at least one Digest-Qop attribute in an
> >> >         Access-Challenge packet.  Digest-Qop is optional in order to
> >> >         preserve backward compatibility with a minimal implementation
> >> >         of [RFC2069].
> >> >   Type
> >> >         [IANA: use 109 if possible] for Digest-Qop
> >> >   Length
> >> >         >=3
> >> >   Text
> >> >         In Access-Requests, the RADIUS client takes the value of the
> >> >         qop directive (qop-value as described in [RFC2617]) without 
>the
> >> >         quotes from the HTTP-style request it wants to authenticate.
> >> >         In Access-Challenge packets, the RADIUS server puts a desired
> >> >         qop-value into this attribute.  If the RADIUS server supports
> >> >         more than one "quality of protection" value, it puts each 
>qop-
> >> >         value into a separate Digest-Qop attribute.
> >>
> >>As per my comment above - if multiple Qop values were
> >>specified by the RADIUS server, the RADIUS client needs to
> >>put them into a single "qop" directive containing comma
> >>separated list of Qop values.
> >>
> >>
> >This is one possibility. I've chosen a different one: "If the RADIUS 
>server
> >supports more than one "quality of protection" value, it puts each 
>qop-value into
> >a separate Digest-Qop attribute."
> >Do you object to splitting up the qop directive into various TLVs?
> >
> >
>I think this will break existing HTTP Digest and/or DIGEST-MD5 (which is
>backward compatible with HTTP Digest) implementations.
>The problem is that the behavior you propose was never explicitly
>allowed or disallowed in the HTTP Digest document.
>
> >> >4.13.  Digest-Username attribute
> >> >
> >> >   Description
> >> >         This attribute holds the user name used in the HTTP digest
> >> >         calculation.  The RADIUS server MUST use this attribute only
> >> >         for the purposes of calculating the digest.  In order to
> >> >         determine the appropriate user credentials, the RADIUS server
> >> >         MUST use the User-Name (1) attribute, and MUST NOT use the
> >> >         Digest-Username attribute.  This attribute MUST only be used 
>in
> >> >         Access-Request packets.
> >>
> >>I am still not convinced that the Digest-Username is ever
> >>different from the User-Name attribute. I would like to see
> >>an example when they would be different.
> >>
> >>
> >What if your current policy was to assign HTTP user names containing '@'
> >signs? A RADIUS infrastructure would interpret those User-Names as NAIs
> >which may lead to undesired effects.
> >
> >
>I think giving this example in the document would explain why they may
>be different.
>You also need to add some text explaining how User-Name can be derived
>from the Digest-Username.
>
>Cheers,
>Alexey
>

--
to unsubscribe send a message 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, 15 Dec 2005 16:09:39 +0000
Date: Thu, 15 Dec 2005 18:08:56 +0200
From: Jari Arkko <[email-masked]>
To: "Nelson, David" <[email-masked]>
CC:  [email-masked]
Subject: Re: Issue: Treatment of null Identity Response

Yes.

Nelson, David wrote:

>Jari Arkko writes...
>
>  
>
>>Well, if its a "string" in RADIUS terminology then its
>>really an octet string in more general terminology, and
>>implementations already have to support embedded  00s.
>>    
>>
>
>Agreed, but see below.
>
>  
>
>>To me the CUI function is more of a binary handle
>>than a printable string. But I'm not sure if others agree.
>>    
>>
>
>It is defined as a cookie, opaque to all but the issuer (home AAA
>server), so it could be a RADIUS "string" type (binary string).  I
>surmise that the reason that a UTF-8 printable string type was specified
>has to do with ease of debugging (human readable characters in the
>packet trace).
>
>I don't think it matters very much.  If it is to be UTF-8, then it
>should be a RADIUS "text" type, and if it's to be binary, we should
>remove the reference to UTF-8.
>
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>
>
>
>  
>

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

Delivery-date: Thu, 15 Dec 2005 15:53:54 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Treatment of null Identity Response
Date: Thu, 15 Dec 2005 10:53:45 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Jari Arkko writes...

> Well, if its a "string" in RADIUS terminology then its
> really an octet string in more general terminology, and
> implementations already have to support embedded  00s.

Agreed, but see below.

> To me the CUI function is more of a binary handle
> than a printable string. But I'm not sure if others agree.

It is defined as a cookie, opaque to all but the issuer (home AAA
server), so it could be a RADIUS "string" type (binary string).  I
surmise that the reason that a UTF-8 printable string type was specified
has to do with ease of debugging (human readable characters in the
packet trace).

I don't think it matters very much.  If it is to be UTF-8, then it
should be a RADIUS "text" type, and if it's to be binary, we should
remove the reference to UTF-8.

--
to unsubscribe send a message 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, 15 Dec 2005 15:42:34 +0000
Date: Thu, 15 Dec 2005 17:42:00 +0200
From: Jari Arkko <[email-masked]>
To: "Nelson, David" <[email-masked]>
CC:  [email-masked]
Subject: Re: Issue: Treatment of null Identity Response

Nelson, David wrote:

>Jari Arkko writes...
> 
>  
>
>>>The text in the CUI draft indicates that the NUL CUI includes a
>>>      
>>>
>single
>  
>
>>>'NUL' character.
>>>      
>>>
>>Right. This is correct, and we do not have a problem with the empty
>>string rule.
>>    
>>
>
>Since counted strings can have embedded NUL characters, that's true.  It
>obviously requires special handling in the C-style string to RADIUS
>string conversion, though.
>  
>
Well, if its a "string" in RADIUS terminology then its
really an octet string in more general terminology, and
implementations already have to support embedded  00s.

>I agree, although if the type is intended to be a UTF-8 printable
>string, the correct RADIUS type would be "text", not "string.  If there
>is consensus on that, it could be fixed in AUTH48.
>  
>
Yes. To me the CUI function is more of a binary handle
than a printable string. But I'm not sure if others agree.

--Jari

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

Delivery-date: Thu, 15 Dec 2005 15:39:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Treatment of null Identity Response
Date: Thu, 15 Dec 2005 10:38:32 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Jari Arkko writes...
=20
> >The text in the CUI draft indicates that the NUL CUI includes a
single
> >'NUL' character.
>
> Right. This is correct, and we do not have a problem with the empty
> string rule.

Since counted strings can have embedded NUL characters, that's true.  It
obviously requires special handling in the C-style string to RADIUS
string conversion, though.

> >I recall that representation originates from Diameter specs. As at
some
> >early phases of the CUI there was direct linkage to Diameter CC
> >Subscription-Id-data, which is defined as UTF8String. A definition
for
> >UTF8String is in RFC3588 (using UTF-8 transformation format as
described
> >in RFC2279) -- not in RADIUS RFCs though.
> >
> I would prefer fixing the type to a RADIUS type (string).

I agree, although if the type is intended to be a UTF-8 printable
string, the correct RADIUS type would be "text", not "string.  If there
is consensus on that, it could be fixed in AUTH48.

--
to unsubscribe send a message 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, 15 Dec 2005 11:32:29 +0000
Date: Thu, 15 Dec 2005 13:31:50 +0200
From: Jari Arkko <[email-masked]>
To:  [email-masked]
CC:  [email-masked],  [email-masked]
Subject: Re: Issue: Treatment of null Identity Response

[email-masked] wrote:

>>>I believe the CUI was to be a single byte of 0-bits, thus NUL rather
>>>than NULL and not a violation.
>>>      
>>>
>>I don't believe so.  The intent of the "hint" flavor of CUI was not to
>>change the underlying base type from printable-string to 
>>binary-string.
>>Sending a single byte of value zero would only be permissible for a
>>binary-string and not a UTF-8 printable-string.
>>    
>>
>
>The text in the CUI draft indicates that the NUL CUI includes a single
>'NUL' character.
>
>"...
> For the initial authentication, the CUI attribute will include a
> single NUL character (referred to as a nul CUI).  And, during re-
> authentication, the CUI attribute will include a previously received
> ..."
>
>  
>
Right. This is correct, and we do not have a problem
with the empty string rule.

>>The CUI type is defined as: "The string identifies the CUI of the
>>end-user and is of type UTF8String."  Of course, type 
>>UTF8String is not
>>a recognized data type in RFC 2865.  Can anyone point me to a formal
>>definition of this, within a RADIUS RFC? 
>>    
>>
>
>I recall that representation originates from Diameter specs. As at some
>early phases of the CUI there was direct linkage to Diameter CC
>Subscription-Id-data, which is defined as UTF8String. A definition for
>UTF8String is in RFC3588 (using UTF-8 transformation format as described
>in RFC2279) -- not in RADIUS RFCs though.
>  
>
I would prefer fixing the type to a RADIUS type (string).

--Jari

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

Delivery-date: Thu, 15 Dec 2005 10:45:48 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Treatment of null Identity Response
Date: Thu, 15 Dec 2005 11:45:13 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi David,=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: 13. joulukuuta 2005 21:07
> To: [email-masked]
> Subject: RE: Issue: Treatment of null Identity Response
>=20
> Barney Wolff writes...
>=20
> > I believe the CUI was to be a single byte of 0-bits, thus NUL rather
> > than NULL and not a violation.
>=20
> I don't believe so.  The intent of the "hint" flavor of CUI was not to
> change the underlying base type from printable-string to=20
> binary-string.
> Sending a single byte of value zero would only be permissible for a
> binary-string and not a UTF-8 printable-string.

The text in the CUI draft indicates that the NUL CUI includes a single
'NUL' character.

"...
 For the initial authentication, the CUI attribute will include a
 single NUL character (referred to as a nul CUI).  And, during re-
 authentication, the CUI attribute will include a previously received
 ..."

> The CUI type is defined as: "The string identifies the CUI of the
> end-user and is of type UTF8String."  Of course, type=20
> UTF8String is not
> a recognized data type in RFC 2865.  Can anyone point me to a formal
> definition of this, within a RADIUS RFC?=20

I recall that representation originates from Diameter specs. As at some
early phases of the CUI there was direct linkage to Diameter CC
Subscription-Id-data, which is defined as UTF8String. A definition for
UTF8String is in RFC3588 (using UTF-8 transformation format as described
in RFC2279) -- not in RADIUS RFCs though.

Cheers,
	Jouni

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

Delivery-date: Thu, 15 Dec 2005 06:04:31 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: Another review of draft-ietf-radext-digest-auth06.txt (fwd)
Date: Wed, 14 Dec 2005 22:02:48 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C600FA.1EFBF2D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

---------- Forwarded message ----------
Date: Wed, 14 Dec 2005 14:04:20 -0800
From: Kurt D. Zeilenga <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],
    [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [secdir]Re: Review request:
draft-ietf-radext-digest-auth06.txt

Sam, the following is my SecDir review of this draft. -- Kurt

Overall, I believe the document with some changes is generally
suitable for publication on the Standards Track.   I believe
some changes are necessary to clarify handling of digest-uri
and fixing the first example in section 7.  In this example,
the "Proxy Server" modifies the URI.  This would cause a different
and incorrect A2 to be produced by the RADIUS server, and hence
cause the authentication to fail.  I suspect a typo in the example.
I do note that RFC 2617 does allow proxies to provide a different
URI than the HTTP client's request URI, but the assumption here
is that its modifying the HTTP request URI and not the value of
the digest-uri parameter.   Aside from fixing the example, I
suggest the document be more clear as to which Digest values,
including but not limited to digest-uri, can be modified by
the proxy and which must be preserved as presented by the
client/server.

Aside from this, I found a number of editorial and other relatively
minor issues, such as inconsistent use of the term "protection
space",  which should be address prior to the document's
progression.  Attached are my raw review notes.

------=_NextPart_000_000A_01C600FA.1EFBF2D0
Content-Type: TEXT/PLAIN;
	name="draft-ietf-radext-digest-auth-06.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-ietf-radext-digest-auth-06.txt"

There is no digest-uri discussion.  RFC 2617 allows proxies
to modify the digest-uri.  Is the RADIUS client allowed
to modify the digest-uri?  I would assume not as the
digest-uri is used in computing A2.  However, in the
first example, the RADIUS client changes the URI.

>Network Working Group                                         B. Sterman
>Internet-Draft                                           Kayote Networks
>Expires: April 17, 2006                                    D. Sadolevsky
>                                                          SecureOL, Inc.
>                                                             D. Schwartz
>                                                         Kayote Networks
>                                                             D. Williams
>                                                           Cisco Systems
>                                                                 W. Beck
>                                                     Deutsche Telekom AG
>                                                        October 14, 2005
>
>
>               RADIUS Extension for Digest Authentication
>                  draft-ietf-radext-digest-auth-06.txt
>
>
>Abstract
>
>   This document defines an extension to the RADIUS protocol to enable
>   support of Digest Authentication, for use with HTTP-style protocols
>   like SIP and HTTP.

Acronyms, especially RADIUS and SIP, should be spelled out on
first use in the abstract.

>1.  Introduction
>
>1.1.  Terminology
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in [RFC2119].
>
>   The use of normative requirement key words in this document shall
>   apply only to RADIUS Client and RADIUS Server implementations that
>   include the features described in this document.  This document
>   creates no normative requirements for existing implementations.
>
>   HTTP-style protocol
>         The term 'HTTP-style' denotes any protocol that uses HTTP-like
>         headers and uses HTTP digest authentication as described in
>         [RFC2617].  Examples are HTTP and SIP.
>   NAS
>         Network Access Server, the RADIUS client.
>   nonce
>         An unpredictable value used to prevent replay attacks.  The
>         nonce generator may use cryptographic mechanisms to produce
>         nonces it can recognize without maintaining state.
>   protection space
>         The combination of realm and digest URI, the use of which is
>         authorized by the RADIUS server.

This definition seems only consistent with RFC2617 if the digest
URI holds a canonical root URL.  See Section 1.1 of RFC 2617.

>   SIP UA
>         SIP User Agent, an Internet endpoint that uses the Session
>         Initiation Protocol.
>   SIP UAS
>         SIP User Agent Server, a logical entity that generates a
>         response to a SIP (Session Initiation Protocol) request.

Note that while SIP is spelled out in the last use above, this
is not the first use in the body.  Other acyronyms should also be
spelled out on first use in body.

>1.2.  Motivation
>
>   The HTTP Digest Authentication mechanism, defined in [RFC2617], was
>   subsequently adapted to use with SIP in [RFC2543] (obsoleted by
>   [RFC3261]).  Due to the limitations and weaknesses of Digest
>   Authentication (see [RFC2617], section 4), additional authentication
>   and encryption mechanisms are defined in SIP [RFC3261], including TLS
>   [RFC2246] and S/MIME [RFC2633].  However, Digest Authentication has
>   been widely implemented within SIP clients and to support those
>   clients there is a need for support of Digest Authentication within
>   AAA protocols such as RADIUS [RFC2865] and Diameter [RFC3588].
>
>   This document defines an extension to the RADIUS protocol to enable
>   support of Digest Authentication, for use with SIP, HTTP, and other
>   HTTP-style protocols using this authentication method.  Support for
>   Digest mechanisms such as AKA [RFC3310] is also supported.  A
>   companion document [I-D.ietf-aaa-diameter-sip-app] defines support
>   for Digest Authentication within Diameter.
>
>1.3.  Overview
>
>   HTTP digest is a challenge-response protocol used to authenticate a
>   client's request to access some resource on a server.  Figure 1 shows
>   a single HTTP digest transaction.
>
>
>
>                        HTTP/SIP..
>         +------------+  (1)     +------------+
>         |            |--------->|            |
>         | HTTP-style |  (2)     | HTTP-style |
>         | Client     |<---------| server     |
>         |            |  (3)     |            |
>         |            |--------->|            |
>         |            |  (4)     |            |
>         |            |<---------|            |
>         +------------+          +------------+
>
>
>
>
>   Figure 1: digest operation without RADIUS
>
>   If the client sends a request without any credentials (1), the server
>   will reply with an error response (2) containing a nonce.  The client
>   creates a cryptographic digest from parts of the request, from the
>   nonce it received from the server, and a shared secret.  The client
>   re-transmits the request (3) to the server, but now includes the
>   digest within the packet.  The server does the same digest
>   calculation as the client and compares the result with the digest it
>   received in (3).  If the digest values are identical, the server
>   grants access to the resource and sends a positive response to the
>   client (4).  If the digest values differ, the server sends a negative
>   response to the client (4).
>
>   Instead of maintaining a local user database, the server could use
>   RADIUS to access a centralized user database.  However, RADIUS
>   [RFC2865] does not include support for HTTP digest authentication.
>   The RADIUS client can not use the User-Password attribute, since it
>   does not receive a password from the HTTP-style client.  The CHAP-
>   Challenge and CHAP-Password attributes are also not suitable since
>   the CHAP algorithm is not compatible with HTTP digest.

Informative reference for CHAP?

>   This document defines new attributes that enable the RADIUS server to
>   perform the digest calculation defined in [RFC2617], providing
>   support for Digest Authentication as a native authentication
>   mechanism within RADIUS.
>
>   This document defines new attributes that enable the RADIUS server to
>   perform the digest calculation defined in [RFC2617].
>
>   The nonces required by the digest algorithm are either generated by
>   the RADIUS client or by the RADIUS server.  A mix of nonce generation
>   modes is not supported.  This specification assumes that both the
>   RADIUS client and server are appropriately configured to generate the
>   nonces in either the RADIUS client or the RADIUS server, but not in
>   both at the same time.  Implementations, though, do not have the
>   means to verify this behavior.
>
>1.3.1.  Scenario 1, RADIUS client chooses nonces
>
>
>                        HTTP/SIP           RADIUS
>
>               +-----+    (1)    +-----+           +-----+
>               |     |==========>|     |           |     |
>               |     |    (2)    |     |           |     |
>               |     |<==========|     |           |     |
>               |     |    (3)    |     |           |     |
>               |     |==========>|     |           |     |
>               |  A  |           |  B  |    (4)    |  C  |
>               |     |           |     |---------->|     |
>               |     |           |     |    (5)    |     |
>               |     |           |     |<----------|     |
>               |     |    (6)    |     |           |     |
>               |     |<==========|     |           |     |
>               +-----+           +-----+           +-----+
>
>               ====> HTTP/SIP
>               ----> RADIUS
>
>
>
>   Figure 2: RADIUS client chooses nonces
>
>   The roles played by the entities in this scenario are as follows:
>
>   A: HTTP client / SIP UA
>
>   B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS}
>   acting also as a RADIUS NAS (RADIUS client)
>
>   C: RADIUS server
>
>   The relevant order of messages sent in this scenario is as follows:
>
>   A sends B an HTTP/SIP request without authorization header (step 1).
>   B challenges A sending an HTTP/SIP "407 / 401 (Proxy) Authorization
>   required" response containing a locally generated nonce (step 2).  A
>   sends B an HTTP/SIP request with authorization header (step 3).  B
>   sends C a RADIUS Access-Request with attributes described in this
>   document (step 4).  C responds to B with a RADIUS Access-Accept/
>   Access-Reject response (step 5).  If credentials were accepted, B
>   receives an Access-Accept response and the message sent from A is
>   considered authentic.  If B receives an Access-Reject response,
>   however, B then responds to A with a "407 / 401 (Proxy) Authorization
>   required" response (step 6).
>
>1.3.2.  Scenario 2, RADIUS server chooses nonces
>
>   While the usage scenario described in Section 1.3.1 minimizes the
>   load on the RADIUS server, alternatives are required in some
>   situations.  When using AKA [RFC3310] the nonce is partially derived
>   from a precomputed authentication vector, which is often stored
>   centrally.
>
>   Figure 3 depicts a scenario in which the RADIUS server chooses
>   nonces.  In this case entities A and B communicate using HTTP or SIP,
>   while entities B and C communicate using RADIUS."

Extraneous " ?
>
>
>                        HTTP/SIP           RADIUS
>
>               +-----+    (1)    +-----+           +-----+
>               |     |==========>|     |    (2)    |     |
>               |     |           |     |---------->|     |
>               |     |           |     |    (3)    |     |
>               |     |    (4)    |     |<----------|     |
>               |     |<==========|     |           |     |
>               |     |    (5)    |     |           |     |
>               |     |==========>|     |           |     |
>               |  A  |           |  B  |    (6)    |  C  |
>               |     |           |     |---------->|     |
>               |     |           |     |    (7)    |     |
>               |     |           |     |<----------|     |
>               |     |    (8)    |     |           |     |
>               |     |<==========|     |           |     |
>               +-----+           +-----+           +-----+
>
>               ====> HTTP/SIP
>               ----> RADIUS
>
>
>
>   Figure 3: RADIUS server chooses nonces
>
>   The roles played by the entities in this scenario are as follows:
>
>   A: HTTP client / SIP UA
>
>   B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS}
>   acting also as a RADIUS NAS
>
>   C: RADIUS server
>
>   The following messages are sent in this scenario:
>
>   A sends B an HTTP/SIP request without an authorization header (step
>   1).  B sends an Access-Request packet with the newly defined Digest-
>   Method and Digest-URI attributes but without a Digest-Nonce attribute
>   to the RADIUS server, C (step 2).  C chooses a nonce and responds
>   with an Access-Challenge (step 3).  This Access-Challenge contains
>   Digest attributes, from which B takes values to construct an HTTP/SIP
>   "(Proxy) Authorization required" response.  The remaining steps are
>   identical with scenario 1 (Section 1.3.1): B sends this response to A
>   (step 4).  A resends its request with its credentials (step 5).  B
>   sends an Access-Request to C (step 6).  C checks the credentials and
>   replies with Access-Accept or Access-Reject (step 7).  Dependent on
>   the C's result, B processes A's request or rejects it with a "(Proxy)
>   Authorization required" response (step 8).
>
>
>2.  Interoperability
>
>   An implementation supporting this extension MUST include a Digest-
>   Response attribute within an Access-Request packet where Digest
>   Authentication is desired.  An Access-Request MUST NOT contain both a
>   Digest-Response attribute and another authentication attribute, such
>   as User-Password, CHAP-Password, or EAP-Message.
>
>   RADIUS clients and servers MUST support both nonce generation modes.
>   As there is no automatic capability exchange, the operator MUST make
>   sure that the RADIUS client software uses the correct nonce
>   generation mode when accessing a specific RADIUS server:

The above MUST does not apply to an implementation, but to a user,
which seems counter to proper RFC 2119 usage.

>   o  If the RADIUS server generates nonces, its RADIUS clients MUST NOT
>      try to generate nonces.
>   o  If the RADIUS server does not generate nonces, its RADIUS clients
>      MUST generate nonces locally.
>   o  If at least one HTTP-style client requires AKA authentication
>      [RFC3310], the RADIUS server MUST generate nonces and its RADIUS
>      clients MUST NOT generate nonces locally.
>   RADIUS implementations MUST offer respective configuration options.
>
>
>3.  Detailed Description
>
>3.1.  RADIUS Client Behavior
>
>   The attributes described in this document are sent in cleartext.
>   Therefore were a RADIUS client to accept secured connections (https
>   or sips) from HTTP-style clients, this could result in information
>   intentionally protected by HTTP-style clients being sent in the clear
>   during the RADIUS exchange.
>
>   On reception of an HTTP-style request message, the RADIUS client
>   checks whether it is authorized to authenticate the request.  Where
>   an HTTP-style request traverses several proxies and each of the
>   proxies requests to authenticate the HTTP-style client, the request
>   at the HTTP-style server may contain multiple credential sets.
>
>   The RADIUS client can use the 'realm' directive in HTTP to determine
>   which credentials are applicable.  Where none of the realms are of
>   interest, the RADIUS client MUST behave as though no relevant
>   credentials were sent.  In all situations the RADIUS client MUST send
>   zero or exactly one credential to the RADIUS server.  The RADIUS
>   client MUST choose the credential of the (Proxy-)Authorization header
>   if the realm directive matches its locally configured realm.
>
>   If such a (Proxy-)Authorization header is present and contains HTTP
>   digest information, the RADIUS client checks the 'nonce' parameter.
>   If the RADIUS client generates nonces but did not issue the received
>   nonce, it responds with a 401 (Unauthorized) or 407 (Proxy
>   Authentication Required) to the HTTP-style client.  In this error
>   response, the RADIUS client sends a new nonce.
>
>   If the RADIUS client recognizes the nonce or does not generate
>   nonces, it takes the header directives and puts them into a RADIUS
>   Access-Request packet.  It puts the 'response' directive into a
>   Digest-Response attribute and the realm / nonce / digest-uri / qop /
>   algorithm / cnonce / nc / username / opaque directives into the

What is '/' above used to signify?  In ABNF, / character separates choices.
I assume each of these directives are actually required, seems using
a comma as a separator would be more appropriate for this prose. 
Likewise below.

>   respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop /
>   Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest-
>   Username / Digest-Opaque attributes.  The request method is put into
>   the Digest-Method attribute.  The RADIUS client adds a Message-
>   Authenticator attribute, defined in [RFC3579] and sends the Access-
>   Request packet to the RADIUS server.
>
>   The RADIUS server processes the packet and responds with an Access-
>   Accept or an Access-Reject.
>
>   The RADIUS client constructs an Authentication-Info header:
>   o  If the Access-Accept packet contains a Digest-Response-Auth
>      attribute, the RADIUS client checks the Digest-Qop attribute:
>      *  If the Digest-Qop attribute's value is 'auth' or not specified,
>         the RADIUS client puts the Digest-Response-Auth attribute's
>         content into the Authentication-Info header's 'rspauth'
>         directive of the HTTP-style response.
>      *  If the Digest-Qop attribute's value is 'auth-int', the RADIUS
>         client ignores the Access-Accept packet and behaves like it had
>         received an Access-Reject packet (Digest-Response-Auth can't be
>         correct as the RADIUS server does not know the contents of the
>         HTTP-style response's body).
>   o  If the Access-Accept packet contains a Digest-HA1 attribute, the
>      RADIUS client checks the 'qop' and 'algorithm' directives in the
>      Authorization header of the HTTP-style request it wants to
>      authorize:
>      *  If the 'qop' directive is missing or its value is 'auth', the
>         RADIUS client ignores the Digest-HA1 attribute.  It does not
>         include an Authentication-Info header into its HTTP-style
>         response.
>      *  If the 'qop' directive's value is 'auth-int' and at least one
>         of the following conditions is true, the RADIUS client
>         calculates the contents of the HTTP-style response's 'rspauth'
>         directive:
>         +  The algorithm directive's value is 'MD5-sess' or 'AKAv1-MD5-
>            sess'.
>         +  The packets between RADIUS client and RADIUS server are
>            protected with IPsec (see Section 9).
>         It creates the HTTP-style response message and calculates the
>         hash of this message's body.  It uses the result and the
>         Digest-URI attribute's value of the corresponding Access-
>         Request packet to perform the H(A2) calculation.  It takes the
>         Digest-Nonce, Digest-Nonce-Count, Digest-CNonce and Digest-Qop
>         values of the corresponding Access-Request and the Digest-HA1
>         attribute's value to finish the computation of the 'rspauth'
>         value.
>   o  If the Access-Accept packet contains neither a Digest-Response-
>      Auth nor a Digest-HA1 attribute, the RADIUS client will not create
>      an Authentication-Info header for its HTTP-style response.
>
>   The RADIUS server MAY have added a Digest-Nextnonce attribute into an
>   Access-Accept packet.  If the RADIUS client discovers this, it puts
>   the contents of this attribute into a 'nextnonce' directive.  Now it
>   can send an HTTP-style response.

The use of MAY here seems odd.  The actual OPTIONAL behavior of
the RADIUS server is discussed elsewhere.  This could more simply be
worded:
	When the RADIUS server provides a Digest-Nextnonce attribute
	in the Access-Accept packet, the RADIUS client puts the
	contexts of this attributes into a 'nextnonce' directive.
	Now it can send an HTTP-style response.

>   If the RADIUS client did receive an HTTP-style request without a
>   (Proxy-)Authorization header matching its locally configured realm
>   value, it obtains a new nonce and sends an error response (401 or
>   407) containing a (Proxy-)Authenticate header.
>
>   If the RADIUS client receives an Access-Reject from the RADIUS
>   server, it sends an error response to the HTTP-style request it has
>   received.  If the RADIUS client does not receive a response, it
>   retransmits or fails over to another RADIUS server as described in
>   [RFC2865].
>
>   The RADIUS client has three ways to obtain nonces: it generates them
>   locally, it has received one in a Digest-Nextnonce attribute of a
>   previously received Access-Accept packet, or it asks the RADIUS
>   server for one.  To do the latter, it sends an Access-Request
>   containing a Digest-Method and a Digest-URI attribute but without a
>   Digest-Nonce attribute.  It adds a Message-Authenticator (see
>   [RFC3579]) attribute to the Access-Request packet.  The RADIUS server
>   chooses a nonce and responds with an Access-Challenge containing a
>   Digest-Nonce attribute.
>
>   The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest-
>   Realm, Digest-Domain and Digest-Opaque attributes in the Access-
>   Challenge carrying the nonce.  If these attributes are present, the
>   client MUST use them.
>
>   If the RADIUS client receives an Access-Challenge packet in response
>   to an Access-Request containing a Digest-Nonce attribute, the RADIUS
>   server did not accept the nonce.  If a Digest-Stale attribute is
>   present in the Access-Challenge and has a value of 'true' (without
>   quotes), the RADIUS client sends an error (401 or 407) response
>   containing WWW-/Proxy-Authenticate header with the directive 'stale'
>   and the digest directives derived from the Digest-* attributes.
>
>3.2.  RADIUS Server Behavior
>
>   If the RADIUS server receives an Access-Request packet with a Digest-
>   Method and a Digest-URI attribute but without a Digest-Nonce
>   attribute, it chooses a nonce.  It puts the nonce into a Digest-Nonce
>   attribute and sends it in an Access-Challenge packet to the RADIUS
>   client.  The RADIUS server MUST add Digest-Realm, Message-
>   Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm, one or
>   more Digest-Qop and MAY add Digest-Domain, Digest-Opaque attributes
>   to the Access-Challenge packet.  If the server cannot choose a nonce,
>   it replies with an Access-Reject packet.
>
>   If the RADIUS server receives an Access-Request packet containing a
>   Digest-Response attribute, it looks for the following attributes:
>   Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop,
>   Digest-Algorithm, Digest-Username.  Depending on the content of
>   Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body-
>   Hash, Digest-CNonce and Digest-AKA-Auts, too.  See [RFC2617] and
>   [RFC3310] for details.  If the Digest-Algorithm attribute is missing,
>   'MD5' is assumed.  If the RADIUS server has issued a Digest-Opaque
>   attribute along with the nonce, the Access-Request MUST have a
>   matching Digest-Opaque attribute.
>
>   If mandatory attributes are missing, it MUST respond with an Access-
>   Reject packet.  If the attributes are present, the RADIUS server
>   calculates the digest response as described in [RFC2617].  To look up
>   the password, the RADIUS server uses the RADIUS User-Name attribute.
>   The RADIUS server MUST check if the user identified by the User-Name
>   attribute
>   o  is authorized to access the protection space defined by the
>      Digest-URI and Digest-Realm attributes,
>   o  is authorized to use the URI included in the SIP-AOR attribute, if
>      this attribute is present.
>   If any of those checks fails, the RADIUS server MUST send an Access-
>   Reject.
>
>   Correlation between User-Name and SIP-AOR AVP values is required just
>   to avoid that any user can register or misuse a SIP-AOR allocated to
>   another user.
>
>   A RADIUS server MUST check if the RADIUS client is authorized to
>   serve users of the realm mentioned in the Digest-Realm attribute.  If
>   the RADIUS client is not authorized, the RADIUS server MUST send an
>   Access-Reject.  The RADIUS server SHOULD log the event so as to
>   notify the operator, and MAY take additional action such as sending
>   an Access-Reject in response to all future requests from this client,
>   until this behavior is reset by management action.
>
>   All values required for the digest calculation are taken from the
>   Digest attributes described in this document.  If the calculated
>   digest response equals the value received in the Digest-Response
>   attribute, the authentication was successful.  If not, the RADIUS
>   server responds with an Access-Reject.
>
>   If the authentication was successful, the RADIUS server adds an
>   attribute to the Access-Accept packet which can be used by the RADIUS
>   client to construct an Authentication-Info header:
>   o  If the Digest-Qop attribute's value is 'auth' or unspecified, the
>      RADIUS server SHOULD put a Digest-Response-Auth attribute into the
>      Access-Accept packet
>   o  If the Digest-Qop attribute's value is 'auth-int' and at least one
>      of the following conditions is true, the RADIUS server SHOULD put
>      a Digest-HA1 attribute into the Access-Accept packet:
>      *  The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1-
>         MD5-sess'.
>      *  The packets between RADIUS client and RADIUS server are
>         protected with IPsec (see Section 9).
>   In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be
>   sent.
>
>   RADIUS servers issuing nonces MAY construct a Digest-Nextnonce
>   attribute and add it to the Access-Accept packet.  This is useful to
>   limit the lifetime of a nonce and to save a round-trip in future
>   requests (see nextnonce discussion in [RFC2617], section 3.2.3).  The
>   RADIUS server adds a Message-Authenticator attribute (see [RFC3579])
>   and sends the Access-Accept packet to the RADIUS client.
>
>   If the RADIUS server does not accept the nonce received in an Access-
>   Request packet but authentication was successful, the RADIUS server
>   MUST send an Access-Challenge packet containing a Digest-Stale
>   attribute set to 'true' (without quotes).  The RADIUS server MUST add
>   Message-Authenticator (see [RFC3579]), Digest-Nonce, Digest-Realm,
>   SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add
>   Digest-Domain, Digest-Opaque attributes to the Access-Challenge
>   packet.
>
>
>4.  New RADIUS attributes
>
>   If not stated otherwise, the attributes have the following format:
>
>
>   0                   1                   2
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |     Type      |  Length       | Text ...
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>4.1.  Digest-Response attribute
>
>   Description
>         If this attribute is present in an Access-Request message, a
>         RADIUS server implementing this specification MUST treat the
>         Access-Request as a request for Digest Authentication.  When a
>         RADIUS client receives a (Proxy-)Authorization header, it puts
>         the request-digest value into a Digest-Response attribute.
>         This attribute (which enables the user to prove possession of
>         the password) MUST only be used in Access-Requests.
>   Type
>         [IANA: use 102 if possible] for Digest-Response.
>   Length
>         >= 3
>   Text
>         When using HTTP digest, the text field is 32 octets long and
>         contains a hexadecimal representation of 16 octet digest value
>         as it was calculated by the authenticated client.  Other digest
>         algorithms MAY define different digest lengths.  The text field
>         MUST be copied from request-digest of digest-response
>         ([RFC2617]) without quotes.
>
>4.2.  Digest-Realm attribute
>
>   Description
>         This attribute describes a protection space of the RADIUS
>         server.  See [RFC2617] 1.2 for details.  It MUST only be used
>         in Access-Request and Access-Challenge packets.

Per the definion in section 1,
	The combination of realm and digest URI, the use of which is
	authorized by the RADIUS server.

But this says this attribute, just a Realm, describes a protection
space.

>   Type
>         [IANA: use 103 if possible] for Digest-Realm
>   Length
>         >=3
>   Text
>         In Access-Requests, the RADIUS client takes the value of the
>         realm directive (realm-value according to [RFC2617]) without
>         quotes from the HTTP-style request it wants to authenticate.
>         In Access-Challenge packets, the RADIUS server puts the
>         expected realm value into this attribute.
>
>4.3.  Digest-Nonce attribute
>
>   Description
>         This attribute holds a nonce to be used in the HTTP Digest
>         calculation.  If the Access-Request had a Digest-Method and a
>         Digest-URI but no Digest-Nonce attribute and the RADIUS server
>         is configured to choose nonces, it MUST put a Digest-Nonce
>         attribute into its Access-Challenge packet.  This attribute
>         MUST only be used in Access-Request and Access-Challenge
>         packets.
>   Type
>         [IANA: use 104 if possible] for Digest-Nonce
>   Length
>         >=3
>   Text
>         In Access-Requests, the RADIUS client takes the value of the
>         nonce directive (nonce-value in [RFC2617]) without quotes from
>         the HTTP-style request it wants to authenticate.  In Access-
>         Challenge packets, the attribute contains the nonce selected by
>         the RADIUS server.
>
>4.4.  Digest-Response-Auth attribute
>
>   Description
>         This attribute enables the RADIUS server to prove possession of
>         the password.  If the previously received Digest-Qop attribute
>         was 'auth-int' (without quotes), the RADIUS server MUST send a
>         Digest-HA1 attribute instead of a Digest-Response-Auth
>         attribute.  The Digest-Response-Auth attribute MUST only be
>         used in Access-Accept packets.  The RADIUS client puts the
>         attribute value without quotes into the rspauth directive of
>         the Authentication-Info header.
>   Type
>         [IANA: use 105 if possible] for Digest-Response-Auth.
>   Length
>         >= 3
>   Text
>         The RADIUS server calculates a digest according to section
>         3.2.3 of [RFC2617] and copies the result into this attribute.
>         Other digest algorithms than the one defined in [RFC2617] MAY
>         define digest lengths other than 32.
>
>4.5.  Digest-Nextnonce attribute
>
>   This attribute holds a nonce to be used in the HTTP Digest
>   calculation.
>
>   Description
>         If the RADIUS server is configured to choose nonces it MAY put
>         a Digest-Nextnonce attribute into an Access-Accept packet.  If
>         this attribute is present, the RADIUS client MUST put the
>         contents of this attribute into the nextnonce directive of an
>         Authentication-Info header in its HTTP-style response.  This
>         attribute MUST only be used in Access-Accept packets.
>   Type
>         [IANA: use 106 if possible] for Digest-Nextnonce
>   Length
>         >=3
>   Text
>         It is recommended that this text be base64 or hexadecimal data.
>
>4.6.  Digest-Method attribute
>
>   Description
>         This attribute holds the method value to be used in the HTTP
>         Digest calculation.  This attribute MUST only be used in
>         Access-Request packets.
>   Type
>         [IANA: use 107 if possible] for Digest-Method
>   Length
>         >=3
>   Text
>         In Access-Requests, the RADIUS client takes the value of the
>         request method from the HTTP-style request it wants to
>         authenticate.
>
>4.7.  Digest-URI attribute
>
>   Description
>         This attribute is used to transport the contents of the digest-
>         uri directive or the URI of the HTTP-style request.  It MUST
>         only be used in Access-Request packets.
>   Type
>         [IANA: use 108 if possible] for Digest-URI
>   Length
>         >=3
>   Text
>         If the HTTP-style request has an Authorization header, the
>         RADIUS client puts the value of the "uri" directive in the
>         (known as "digest-uri-value" in section 3.2.2 of [RFC2617])
>         without quotes into this attribute.

This text implies the client is to remove any quote characters
appearing in the URI.  Suggest:
	s/without quotes/without quoting/

>                                                   If there is no
>         Authorization header, the RADIUS client takes the value of the
>         request URI from the HTTP-style request it wants to
>         authenticate.
>
>4.8.  Digest-Qop attribute
>
>   Description
>         This attribute holds the Quality of Protection parameter that
>         influences the HTTP Digest calculation.  This attribute MUST
>         only be used in Access-Request and Access-Challenge packets.  A
>         RADIUS client SHOULD insert one of the Digest-Qop attributes it
>         has received in a previous Access-Challenge packet.  RADIUS
>         servers SHOULD insert at least one Digest-Qop attribute in an
>         Access-Challenge packet.  Digest-Qop is optional in order to
>         preserve backward compatibility with a minimal implementation
>         of [RFC2069].
>   Type
>         [IANA: use 109 if possible] for Digest-Qop
>   Length
>         >=3
>   Text
>         In Access-Requests, the RADIUS client takes the value of the
>         qop directive (qop-value as described in [RFC2617]) without the
>         quotes from the HTTP-style request it wants to authenticate.
>         In Access-Challenge packets, the RADIUS server puts a desired
>         qop-value into this attribute.  If the RADIUS server supports
>         more than one "quality of protection" value, it puts each qop-
>         value into a separate Digest-Qop attribute.
>
>4.9.  Digest-Algorithm attribute
>
>   Type

s/Type/Description/
>         This attribute holds the algorithm parameter that influences
>         the HTTP Digest calculation.  It MUST only be used in Access-
>         Request and Access-Challenge packets.  If this attribute is
>         missing, "MD5" is assumed.
>
>   Type
>         [IANA: use 110 if possible] for Digest-Algorithm
>   Length
>         >=3
>   Text
>         In Access-Requests, the RADIUS client takes the value of the
>         algorithm directive (as described in [RFC2617], section 3.2.1)
>         without the quotes from the HTTP-style request it wants to
>         authenticate.  In Access-Challenge packets, the RADIUS server
>         SHOULD put the desired algorithm into this attribute.
>
>4.10.  Digest-Entity-Body-Hash attribute
>
>   Description
>         When using the qop level 'auth-int', a hash of the HTTP-style
>         message body's contents is required for digest calculation.
>         Instead of sending the complete body of the message, only its
>         hash value is sent.  This hash value can be used directly in
>         the digest calculation.
>         The clarifications described in section 22.4 of [RFC2617] about
>         the hash of empty entity bodies apply to the Digest-Entity-
>         Body-Hash attribute.  This attribute MUST only be sent in
>         Access-Request packets.
>   Type
>         [IANA: use 111 if possible] for Digest-Entity-Body-Hash
>   Length
>         >=3
>   Text
>         The attribute holds the hexadecimal representation of H(entity-
>         body).  This hash is required by certain authentication
>         mechanisms, such as HTTP Digest with quality of protection set
>         to "auth-int".  RADIUS clients MUST use this attribute to
>         transport the hash of the entity body when HTTP Digest is the
>         authentication mechanism and the RADIUS server requires to
>         verify the integrity of the entity body (e.g., qop parameter
>         set to "auth-int").  Extensions to this document may define
>         support for authentication mechanisms other than HTTP Digest.
>
>4.11.  Digest-CNonce attribute
>
>   Description
>         This attribute holds the client nonce parameter that is used in
>         the HTTP Digest calculation.  It MUST only be used in Access-
>         Request packets.
>   Type
>         [IANA: use 112 if possible] for Digest-CNonce
>   Length
>         >=3
>   Text
>         This attribute includes the value of the cnonce-value [RFC2617]
>         without quotes, taken from the HTTP-style request.
>
>4.12.  Digest-Nonce-Count attribute
>
>   Description
>         This attribute includes the nonce count parameter that is used
>         to detect replay attacks.  The attribute MUST only be used in
>         Access-Request packets.
>   Type
>         [IANA: use 113 if possible] for Digest-Nonce-Count
>   Length
>         10
>   Text
>         In Access-Requests, the RADIUS client takes the value of the nc
>         directive (nc-value according to [RFC2617]) without quotes from
>         the HTTP-style request it wants to authenticate.
>
>4.13.  Digest-Username attribute
>
>   Description
>         This attribute holds the user name used in the HTTP digest
>         calculation.  The RADIUS server MUST use this attribute only
>         for the purposes of calculating the digest.  In order to
>         determine the appropriate user credentials, the RADIUS server
>         MUST use the User-Name (1) attribute, and MUST NOT use the
>         Digest-Username attribute.  This attribute MUST only be used in
>         Access-Request packets.
>   Type
>         [IANA: use 114 if possible] for Digest-Username
>   Length
>         >= 3
>   Text
>         In Access-Requests, the RADIUS client takes the value of the
>         username directive (username-value according to [RFC2617])
>         without quotes from the HTTP-style request it wants to
>         authenticate.
>
>4.14.  Digest-Opaque attribute
>
>   Description
>         This attribute holds the opaque parameter that is passed to the
>         HTTP-style client.  The HTTP-style client will pass this value
>         back to the server (i.e. the RADIUS client) without
>         modification.  This attribute is only used when the RADIUS
>         server chooses nonces and MUST only be used in Access-Request
>         and Access-Challenge packets.
>   Type
>         [IANA: use 115 if possible] for Digest-Opaque
>   Length
>         >=3
>   Text
>         In Access-Requests, the RADIUS client takes the value of the
>         opaque directive (opaque-value according to [RFC2617]) without
>         quotes from the HTTP-style request it wants to authenticate and
>         puts it into this attribute.  In Access-Challenge packets, the
>         RADIUS server MAY include this attribute.
>
>4.15.  Digest-Auth-Param attribute
>
>   Description
>         This attribute is a placeholder for future extensions and
>         corresponds to the "auth-param" parameter defined in section
>         3.2.1 of [RFC2617].  The Digest-Auth-Param is the mechanism
>         whereby the RADIUS client and RADIUS server can exchange auth-
>         param extension parameters contained within Digest headers that
>         are not understood by the RADIUS client and for which there are
>         no corresponding stand-alone attributes.
>         Unlike the previously listed Digest-* attributes, the Digest-
>         Auth-Param contains not only the value, but also the parameter
>         name, since the parameter name is unknown to the RADIUS client.
>         If the Digest header contains several unknown parameters, then
>         the RADIUS implementation MUST repeat this attribute and each
>         instance MUST contain one different unknown Digest parameter/
>         value combination.  This attribute MUST ONLY be used in Access-
>         Request, Access-Challenge, or Access-Accept packets.
>   Type
>         [IANA: use 116 if possible] for Digest-Auth-Param
>   Length
>         >=3
>   Text
>         The text consists of the whole parameter, including its name
>         and the equal ('=') sign and quotes.
>
>4.16.  Digest-AKA-Auts attribute
>
>   Description
>         This attribute holds the auts parameter that is used in the
>         Digest AKA ([RFC3310]) calculation.  It is only used if the
>         algorithm of the digest-response denotes a version of AKA
>         digest [RFC3310].  This attribute MUST only be used in Access-
>         Request packets.
>   Type
>         [IANA: use 117 if possible] for Digest-AKA-Auts
>   Length
>         >=3
>   Text
>         In Access-Requests, the RADIUS client takes the value of the
>         auts directive (auts-param according to section 3.4 of
>         [RFC3310]) without quotes from the HTTP-style request it wants
>         to authenticate.
>
>4.17.  Digest-Domain attribute
>
>   Description
>         When a RADIUS client has asked for a nonce, the RADIUS server
>         MAY send one or more Digest-Domain attributes in its Access-
>         Challenge packet.  The RADIUS client puts them into the quoted,
>         space-separated list of URIs of the 'domain' directive of a
>         WWW-Authenticate header.  The URIs in the list define the
>         protection space (see [RFC2617], section 3.2.1).  RADIUS
>         servers MAY send one or more attributes of this type in Access-
>         Challenge packets.  This attribute MUST only be used in Access-
>         Challenge packets.
>   Type
>         [IANA: use 118 if possible] for Digest-Domain
>   Length
>         3
>   Text
>         This attribute consists of a single URI, that defines a
>         protection space.
>
>4.18.  Digest-Stale attribute
>
>   Description
>         This attribute is sent by a RADIUS server in order to notify
>         the RADIUS client whether it has accepted a nonce.  If the
>         nonce presented by the RADIUS client was stale, the value is
>         'true' and is 'false' otherwise.  The RADIUS client puts the
>         content of this attribute into a 'stale' directive of the WWW-
>         Authenticate header in the HTTP-style response to the request
>         it wants to authenticate.  The attribute MUST only be used in
>         Access-Challenge packets and only if the RADIUS server chooses
>         nonces.
>   Type
>         [IANA: use 119 if possible] for Digest-Stale
>   Length
>         3
>   Text
>         The attribute has either the value 'true' or 'false' (both
>         values without quotes).
>
>4.19.  Digest-HA1 attribute
>
>   Description
>         This attribute is used to allow the generation of an
>         Authentication-Info header, even if the HTTP-style response's
>         body is required for the calculation of the rspauth value.  It
>         SHOULD be used in Access-Accept packets if the required quality
>         of protection ('qop') is 'auth-int'.
>         This attribute MUST NOT be sent if the qop parameter was not
>         specified or has a value of 'auth' (in this case, use Digest-
>         Response-Auth instead).
>         The Digest-HA1 attribute MUST only be sent by the RADIUS server
>         or processed by the RADIUS client if at least one of the
>         following conditions is true:
>         +  The Digest-Algorithm attribute's value is 'MD5-sess' or
>            'AKAv1-MD5-sess'.
>         +  The packets between RADIUS client and RADIUS server are
>            protected with IPsec (see Section 9).
>         This attribute MUST only be used in Access-Accept packets.
>   Type
>         [IANA: use 120 if possible] for Digest-HA1
>   Length
>         >= 3
>   Text
>         This attribute contains the hexadecimal representation of H(A1)
>         as described in [RFC2617], section 3.1.3, 3.2.1 and 3.2.2.2.
>
>4.20.  SIP-AOR
>
>   Type

s/Type/Description/

>         This attribute is used for the authorization of SIP messages.
>         The SIP-AOR attribute identifies the URI the use of which must
>         be authenticated and authorized.  The RADIUS server uses this
>         attribute to authorize the processing of the SIP request.  The
>         SIP-AOR can be derived from, e.g., the To header field in a SIP
>         REGISTER request (user under registration), or the From header
>         field in other SIP requests.  However, the exact mapping of
>         this attribute to SIP can change due to new developments in the
>         protocol.  This attribute MUST only be used when the RADIUS
>         client wants to authorize SIP users and MUST only be used in
>         Access-Request packets.
>   Type
>         [IANA:use 121 if possible] for SIP-AOR
>   Length
>         >=3
>   Text
>         The syntax of this attribute corresponds either to a SIP URI
>         (with the format defined in [RFC3261] or a TEL URI (with the
>         format defined in [RFC3966]).
>         The SIP-AOR attribute holds the complete URI, including
>         parameters and other parts.  It is up to the RADIUS server what
>         components of the URI are regarded in the authorization
>         decision.
>
>
>5.  Diameter Compatibility
>
>   This document defines support for Digest Authentication in RADIUS.  A
>   companion document "Diameter Session Initiation Protocol (SIP)
>   Application" [I-D.ietf-aaa-diameter-sip-app] defines support for
>   Digest Authentication in Diameter, and addresses compatibility issues
>   between RADIUS and Diameter.
>
>
>6.  Table of Attributes
>
>   The following table provides a guide to which attributes may be found
>   in which kinds of packets, and in what quantity.
>
>     Req   Accept   Reject   Challenge   #     Attribute                
>     1     0        0        0           1     User-Name                
>     1     1        1        1           80    Message-Authenticator    
>     0-1   0        0        0           TBD   Digest-Response          
>     0-1   0        0        1           TBD   Digest-Realm             
>     0-1   0        0        1           TBD   Digest-Nonce             
>     0     0-1      0        0           TBD   Digest-Response-Auth     
>                                               (see Note 1, 2)          
>     0     0-1      0        0           TBD   Digest-Nextnonce         
>     0-1   0        0        0           TBD   Digest-Method            
>     0-1   0        0        0           TBD   Digest-URI               
>     0-1   0        0        1+          TBD   Digest-Qop               
>     0-1   0        0        0-1         TBD   Digest-Algorithm (see    
>                                               Note 3)                  
>     0-1   0        0        0           TBD   Digest-Entity-Body-Hash  
>     0-1   0        0        0           TBD   Digest-CNonce            
>     0-1   0        0        0           TBD   Digest-Nonce-Count       
>     0-1   0        0        0           TBD   Digest-Username          
>     0-1   0        0        0-1         TBD   Digest-Opaque            
>     0+    0+       0        0+          TBD   Digest-Auth-Param        
>     0-1   0        0        0           TBD   Digest-AKA-Auts          
>     0     0        0        0+          TBD   Digest-Domain            
>     0     0        0        0-1         TBD   Digest-Stale             
>     0     0-1      0        0           TBD   Digest-HA1 (see Note 1,  
>                                               2)                       
>     0-1   0        0        0           TBD   SIP-AOR                  
>
>                                  Table 1
>
>   [Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if
>      Digest-Qop is 'auth-int'.
>   [Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if
>      Digest-Qop is 'auth'.
>   [Note 3] If Digest-Algorithm is missing, 'MD5' is assumed
>
>
>7.  Example

s/Example/Examples/

>   This is an example sniffed from the traffic between a softphone (A),
>   a Proxy Server (B) and example.com RADIUS server (C).  The
>   communication between the Proxy Server and a SIP PSTN gateway is
>   omitted for brevity.  The SIP messages are not shown completely.
>
>
>   A->B
>
>      INVITE sip:[email-masked] SIP/2.0
>      From: <sip:[email-masked]>
>      To: <sip:[email-masked]>
>
>
>   B->A
>
>      SIP/2.0 100 Trying
>
>
>   B->A
>
>      SIP/2.0 407 Proxy Authentication Required
>      Proxy-Authenticate: Digest realm="example.com"
>           ,nonce="3bada1a0", algorithm="md5"
>      Content-Length: 0
>
>
>   A->B
>
>      ACK sip:[email-masked] SIP/2.0
>
>
>   A->B
>
>      INVITE sip:[email-masked] SIP/2.0
>      Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0"
>           ,opaque="",realm="example.com"
>           ,response="f3ce87e6984557cd0fecc26f3c5e97a4"
>           ,uri="sip:[email-masked]",username="12345678"
>      From: <sip:[email-masked]>
>      To: <sip:[email-masked]>
>
>
>   B->C
>
>      Code = 1 (Access-Request)
>      Attributes:
>      NAS-IP-Address = a 0 45 26 (10.0.69.38)
>      NAS-Port-Type = 5 (Virtual)
>      User-Name = "12345678"
>      Digest-Response = "f3ce87e6984557cd0fecc26f3c5e97a4"
>      Digest-Realm = "example.com"
>      Digest-Nonce = "3bada1a0"
>      Digest-Method = "INVITE"
>      Digest-URI = "sip:[email-masked]"

Why is the value of Digest-URI not the same URI provided by A?

>      Digest-Algorithm = "md5"
>      Digest-Username =  "12345678"
>      SIP-AOR =  "sip:[email-masked]"
>
>
>   C->B
>
>      Code = 2 (Access-Accept)
>      Attributes:
>      Digest-Response-Auth =
>                      "6303c41b0e2c3e524e413cafe8cce954"
>
>
>   B->A
>
>      SIP/2.0 180 Ringing
>
>
>   B->A
>
>      SIP/2.0 200 OK
>
>
>   A->B
>
>      ACK sip:[email-masked] SIP/2.0
>
>
>
>   A second example shows the traffic between a web browser (A), web
>   server (B) and a RADIUS server (C).
>
>
>
>   A->B
>
>      GET /index.html HTTP/1.1
>
>
>   B->A
>
>      HTTP/1.1 407 Authentication Required
>      WWW-Authenticate: Digest realm="example.com",
>          domain="/index.html",
>          nonce="a3086ac8", algorithm="md5"
>      Content-Length: 0
>
>
>   A->B
>
>      GET /index.html HTTP/1.1
>      Authorization: Digest algorithm="md5",nonce="a3086ac8"
>           ,opaque="",realm="example.com"
>           ,response="f052b68058b2987aba493857ae1ab002"
>           ,uri="/index.html",username="12345678"
>
>
>   B->C
>
>      Code = 1 (Access-Request)
>      Attributes:
>      NAS-IP-Address = a 0 45 26 (10.0.69.38)
>      NAS-Port-Type = 5 (Virtual)
>      User-Name = "12345678"
>      Digest-Response = "f052b68058b2987aba493857ae1ab002"
>      Digest-Realm = "example.com"
>      Digest-Nonce = "a3086ac8"
>      Digest-Method = "GET"
>      Digest-URI = "/index.html""
>      Digest-Algorithm = "md5"
>      Digest-Username =  "12345678"
>
>
>   C->B
>
>      Code = 2 (Access-Accept)
>      Attributes:
>      Digest-Response-Auth =
>          "e644aa513effbfe1caff67103ff6433c"
>
>
>   B->A
>
>      HTTP/1.1 200 OK
>      ...
>
>      <html>
>      ...
>
>
>
>
>8.  IANA Considerations
>
>   This document serves as IANA registration request for a number of
>   values from the RADIUS attribute type number space:
>
>           +-------------------------+------------------------+
>           | placeholder             | value assigned by IANA |
>           +-------------------------+------------------------+
>           | Digest-Response         | TBD                    |
>           | Digest-Realm            | TBD                    |
>           | Digest-Nonce            | TBD                    |
>           | Digest-Nextnonce        | TBD                    |
>           | Digest-Response-Auth    | TBD                    |
>           | Digest-Method           | TBD                    |
>           | Digest-URI              | TBD                    |
>           | Digest-Qop              | TBD                    |
>           | Digest-Algorithm        | TBD                    |
>           | Digest-Entity-Body-Hash | TBD                    |
>           | Digest-CNonce           | TBD                    |
>           | Digest-Nonce-Count      | TBD                    |
>           | Digest-Username         | TBD                    |
>           | Digest-Opaque           | TBD                    |
>           | Digest-Auth-Param       | TBD                    |
>           | Digest-AKA-Auts         | TBD                    |
>           | Digest-Domain           | TBD                    |
>           | Digest-Stale            | TBD                    |
>           | Digest-HA1              | TBD                    |
>           | SIP-AOR                 | TBD                    |
>           +-------------------------+------------------------+
>
>                                  Table 2
>
>
>9.  Security Considerations
>
>   The RADIUS extensions described in this document enable RADIUS to
>   transport the data that required to perform a digest calculation.  As
>   a result, RADIUS inherits the vulnerabilities of HTTP Digest (see
>   [RFC2617], section 4) in addition to RADIUS security vulnerabilities
>   described in [RFC2865] Section 8 and [RFC3579] Section 4.
>
>   An attacker compromising a RADIUS client or proxy can carry out man-
>   in-the-middle attacks even if the paths between A, B and B, C
>   (Figure 2) have been secured with TLS or IPsec.
>
>   The RADIUS server MUST check the Digest-Realm attribute it has
>   received from a client.  If the RADIUS client is not authorized to
>   serve HTTP-style clients of that realm, it might be compromised.
>
>   RADIUS clients implementing the extension described in this document
>   may authenticate HTTP-style requests received over the Internet.  As
>   compared with use of RADIUS to authenticate link layer network
>   access, an attacker may find it easier to cover their tracks in such
>   a scenario.
>
>   An attacker can attempt a denial of service attack on one or more
>   RADIUS servers by sending a large number of HTTP-style requests.  To
>   make simple denial of service attacks more difficult, the nonce
>   issuer (RADIUS client or server) MUST check if it has generated the
>   nonce received from an HTTP-style client.  This SHOULD be done
>   statelessly.  For example, a nonce could consist of a
>   cryptographically random part and some kind of signature provided by
>   the RADIUS client, as described in [RFC2617], section 3.2.1.
>
>   RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm
>   attributes in Access-Challenge messages.  A man in the middle can
>   modify or remove those attributes in a bidding down attack, causing
>   the RADIUS client to use a weaker authentication scheme than
>   intended.
>
>   The Message-Authenticator attribute, described in [RFC3579] section
>   3.2 MUST be included in Access-Request, Access-Challenge, Access-
>   Reject and Access-Accept messages that contain attributes described
>   in this specification.
>
>   The Digest-HA1 attribute contains no random components if the
>   algorithm is 'MD5' or 'AKAv1-MD5'.  This makes offline dictionary
>   attacks easier and enables replay attacks.
>
>   HTTP-style clients can use TLS with server side certificates together
>   with HTTP-Digest Authentication.  Instead of TLS, IPsec can be used,
>   too.  TLS or IPsec secure the connection while Digest Authentication
>   authenticates the user.  The RADIUS transaction can be regarded as
>   one leg on the path between the HTTP-style client and the HTTP-style
>   server.  To prevent RADIUS from representing the weak link, a RADIUS
>   client receiving an HTTP-style request via TLS or IPsec could use an
>   equally secure connection to the RADIUS server.  There are several
>   ways to achieve this, for example:
>   o  the RADIUS client may reject HTTP-style requests received over TLS
>      or IPsec
>   o  the RADIUS client require that traffic be sent and received over
>      IPsec.
>   RADIUS over IPsec, if used, MUST conform to the requirements
>   described in [RFC3579] section 4.2.
>
>
>10.  Acknowledgments
>
>   We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or
>   providing comments and experimental implementation.
>
>   Many thanks to all reviewers, especially to Miguel Garcia, Jari
>   Arkko, Avi Lior and Jun Wang.
>
>
>11.  References
>
>11.1.  Normative References
>
>   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>              Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
>              Leach, P., Luotonen, A., and L. Stewart, "HTTP
>              Authentication: Basic and Digest Access Authentication",
>              RFC 2617, June 1999.
>
>   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
>              "Remote Authentication Dial In User Service (RADIUS)",
>              RFC 2865, June 2000.
>
>   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
>              A., Peterson, J., Sparks, R., Handley, M., and E.
>              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
>              June 2002.
>
>   [RFC3310]  Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
>              Protocol (HTTP) Digest Authentication Using Authentication
>              and Key Agreement (AKA)", RFC 3310, September 2002.
>
>   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
>              Dial In User Service) Support For Extensible
>              Authentication Protocol (EAP)", RFC 3579, September 2003.
>
>   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
>              RFC 3966, December 2004.
>
>11.2.  Informative References
>
>   [I-D.ietf-aaa-diameter-sip-app]
>              Garcia-Martin, M., "Diameter Session Initiation Protocol
>              (SIP) Application", draft-ietf-aaa-diameter-sip-app-09
>              (work in progress), September 2005.
>
>   [RFC2069]  Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
>              Luotonen, A., Sink, E., and L. Stewart, "An Extension to
>              HTTP : Digest Access Authentication", RFC 2069,
>              January 1997.
>
>   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
>              RFC 2246, January 1999.
>
>   [RFC2543]  Handley, M., Schulzrinne, H., Schooler, E., and J.
>              Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
>              March 1999.
>
>   [RFC2633]  Ramsdell, B., "S/MIME Version 3 Message Specification",
>              RFC 2633, June 1999.
>
>   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
>              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
>

------=_NextPart_000_000A_01C600FA.1EFBF2D0--

--
to unsubscribe send a message 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 Dec 2005 22:29:50 +0000
Date: Wed, 14 Dec 2005 14:25:23 -0800
To: "Nelson, David" <[email-masked]>
From: Ignacio Goyret <[email-masked]>
Subject: RE: Issue: Treatment of null Identity Response
Cc: <[email-masked]>

At 11:30 12/13/2005 -0500, Nelson, David wrote:
>Well, yes, but...  RFC 2865 defines the value field of attributes as
>follows:
>
><quote>
>
>      The format of the value field is one of five data types.  Note
>      that type "text" is a subset of type "string".
>
>      text      1-253 octets containing ...
>      string    1-253 octets containing ...

Long ago, in the previous instance of a RADIUS WG, a similar question was
posted and the WG decision was that attributes with empty value fields
must not be sent (hence, the 1-253 octets limit for text and string).

Back then, some people tried (unsuccessfully) to argue that the presence
of a null valued attribute is different from the absence of such attribute.
In my mind (and apparently, in a few others as well), an absent attribute
should mean "I don't know anything about that attribute" whereas an empty
attribute should mean "the attribute is known and its value is empty"
but that's not what the RFC says.

Appended are some related messages from the old WG mailing list that may
help shed some light on this issue. I don't know if the old mailing list
is archived somewhere (livingston.com went offline a long time ago) but
if there is, google doesn't seem to know about it.

HTH,
-Ignacio

>Date: Wed, 24 Feb 1999 13:26:59 -0800 (PST)
>From: Carl Rigney <[email-masked]>
>Message-Id: <[email-masked]>
>To: [email-masked]
>Subject: (radius) Zero-length strings
>
>Right now there are no zero-length strings in RADIUS, because all the
>definitions require at least an octet of data.  People's use of zero
>length attributes disturbs me, because I suspect they're implying
>semantics in such usage that are not documented and therefore non
>interoperable.  So I want to pin this discrepancy down by either
>updating the language from "0-253 octets of data" to "1-253 octets" or
>by explicitly describing what to do with a zero length attribute.
>
>The reference implementation (RADIUS 1.13 from Livingston) didn't allow
>zero length attributes; if the protocol is going to be changed to allow
>zero length attributes I want to see really strong justification for
>their usefulness IN AN INTEROPERABLE MANNER.  Post fast, the next
>draft's only a couple of days away.
>
>(Its fine to email me directly, or to the list, as you prefer.)
>
>--
>Carl Rigney
>[email-masked]

=======================================

>Date: Wed, 24 Feb 1999 13:36:09 -0800
>From: "Dale E. Reed Jr." <[email-masked]>
>To: Carl Rigney <[email-masked]>
>CC: [email-masked]
>Subject: Re: (radius) Zero-length strings
>References: <[email-masked]>
>
>I'm an advocate of "if there isn't any data, don't include the
>attribute".  Therefore, I'd like to see a requirement on all
>attributes of 1-253 octets.

=======================================

>To: "Dale E. Reed Jr." <[email-masked]>
>cc: Carl Rigney <[email-masked]>, [email-masked],
>        [email-masked]
>Subject: Re: (radius) Zero-length strings 
>In-reply-to: Your message of "Wed, 24 Feb 1999 13:36:09 PST."
>             <[email-masked]> 
>Date: Wed, 24 Feb 1999 17:01:01 -0500
>From: "Richard S. Conto" <[email-masked]>
>
>
>I don't like zero length strings (I call them empty strings,
>because people I've worked will have been confused between
>NULL and 0 and ""), but that doesn't mean that an empty string
>isn't valid. It's like the difference between reporting 0 or
>not reporting anything at all (0 vs. missing data.)
>
>At least one vendor uses zero length strings, (in the STATE
>attribute) and as one of the contributors to a well known
>RADIUS implementation, I have to cope with it.
>
>I also have to anticipate RADIUS clients that accept whatever
>a user provides, and that includes empty strings and garbage
>filled strings.
>
>I think that zero-length (empty) strings MUST be allowed,
>especially where the value may be provided by a human being,
>or where the use of the value is left to the vendor (USER-NAME
>and STATE come to mind.) I think so for the pragmatic
>reason that there are implementations using it, and for the
>architectural reason that an empty value is different from a
>missing value.

=======================================

>Date: Wed, 24 Feb 1999 21:56:47 -0800
>From: "Dale E. Reed Jr." <[email-masked]>
>To: "Richard S. Conto" <[email-masked]>
>CC: Carl Rigney <[email-masked]>, [email-masked]
>Subject: Re: (radius) Zero-length strings
>References: <[email-masked]>
>
>"Richard S. Conto" wrote:
>> 
>> I don't like zero length strings (I call them empty strings,
>> because people I've worked will have been confused between
>> NULL and 0 and ""), but that doesn't mean that an empty string
>> isn't valid. It's like the difference between reporting 0 or
>> not reporting anything at all (0 vs. missing data.)
>> 
>> At least one vendor uses zero length strings, (in the STATE
>> attribute) and as one of the contributors to a well known
>> RADIUS implementation, I have to cope with it.
>> 
>> I also have to anticipate RADIUS clients that accept whatever
>> a user provides, and that includes empty strings and garbage
>> filled strings.
>
>I can't agree with this.  What possible usefullness can state
>with an empty contents (AVP length of two) contribute to anything
>and what makes it different than not including it at all?  The
>same thing really goes for username.  A NAS should reject a 
>request immediately is a user hits enter for the username, and
>not even bother with sending the request.  Althought the RADIUS
>client is supposed to be simple, its not supposed to be stupid. :(
>
>Because there are broken or current implementations that send
>a AVP length of two, doesn't mean that the RFC has to accept
>or allow it.    The purpose of this update that Carl is working
>on is to clarify the implementation rules and clean up problems.
>This is one I brought up over a year ago and am excited about 
>getting cleaned up.
>
>> I think that zero-length (empty) strings MUST be allowed,
>> especially where the value may be provided by a human being,
>> or where the use of the value is left to the vendor (USER-NAME
>> and STATE come to mind.) I think so for the pragmatic
>> reason that there are implementations using it, and for the
>> architectural reason that an empty value is different from a
>> missing value.
>
>Whats different from the server making interpreting a missing
>attribute the same as it would interpret an AVP length of two?
>I really don't like (although I can live with it) an AVP 
>length of 3 with the single data of 0.  I interpret this as
>a blank NULL terminated string (and we all know strings are not
>NULL terminated in RADIUS).
>
>-- 
>
>Dale E. Reed Jr.      Emerald and RadiusNT
>__________________________________________
>IEA Software, Inc.    www.iea-software.com

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

Envelope-to: [email-masked]
Delivery-date: Wed, 14 Dec 2005 20:19:22 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Issue: Treatment of null Identity Response 
Date: Wed, 14 Dec 2005 15:23:59 -0500
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> Asked another way, is there any actual authentication or
> authorization decision that a RADIUS server makes based on the
> content of the User-Name in this specific scenario?

  Yes, but I don't think it's related to the NULL identity response
problem.  A follow-up question is:

  Q1: If a server receives Calling-Station-Id, and sees that the value
of the identity is the same as the Calling-Station-Id, what does it
do?

  A1: I don't recall any currently mandated behavior.  It's up to local policy.

  Q2: How does a server distinguish this situation (which may occur
      today) from the proposed mandated behavior for NULL identity
      response?

  A2: I have no idea.  I don't know that it can distinguish them.

  If the situations can be distinguished, then we can mandate server
behavior here.  If the situations can't be distinguished, then
mandating server behavior will change existing deployments and
practices.

  Alan DeKok.

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

Delivery-date: Wed, 14 Dec 2005 19:59:40 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Treatment of null Identity Response 
Date: Wed, 14 Dec 2005 14:59:36 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Alan DeKok writes...

> >  Is there an explicit signal or hint to the RADIUS Server that the
> > user name is the MAC address, or does it figure that out by
> > inspection (parsing)?  Or doesn't it matter?
>=20
>   It's up to local policy.  So it doesn't matter.

Uh, yes, but...  If the behavior of the RADIUS server is a matter of
local policy, doesn't that raise interoperability issues?  Asked another
way, is there any actual authentication or authorization decision that a
RADIUS server makes based on the content of the User-Name in this
specific scenario?  As I recall, RADIUS Clients and Servers had to
implement specific code paths to deal with the "anonymous" user cases.=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/>

Envelope-to: [email-masked]
Delivery-date: Wed, 14 Dec 2005 19:27:23 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Issue: Treatment of null Identity Response 
Date: Wed, 14 Dec 2005 14:32:09 -0500
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> To clarify, we use the value of Calling-Station-ID in the User-Name
> attribute, and the Service-Type is Framed (or whatever).  Do we
> additionally include an instance of the Calling-Station-ID in the
> Access-Request? 

  Yes.  The Calling-Station-Id should still be the value of the
calling station id.

>  Is there an explicit signal or hint to the RADIUS Server that the
> user name is the MAC address, or does it figure that out by
> inspection (parsing)?  Or doesn't it matter?

  It's up to local policy.  So it doesn't matter.

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Wed, 14 Dec 2005 19:26:44 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Issue: Treatment of null Identity Response 
Date: Wed, 14 Dec 2005 14:30:56 -0500
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:
> Here is where I think we are:
> 
> 1.  In RFC 2486bis a null NAI is not legal.  So no data in the 
...
> 2.  Since there is no identity in the EAP-Response/Identity field, the 

  I concur.

  Alan DeKok.

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

Delivery-date: Wed, 14 Dec 2005 18:03:34 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Treatment of null Identity Response
Date: Wed, 14 Dec 2005 13:03:14 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...
=20
> 2.  Since there is no identity in the EAP-Response/Identity field, the
> RADIUS client should include the Calling-Station-ID (MAC Address) in
the
> User-Name field, as it would for Service Type =3D Call Check.  =
However,
the
> Service-Type should not actually be set to Call-Check since the call
has
> already been accepted.

To clarify, we use the value of Calling-Station-ID in the User-Name
attribute, and the Service-Type is Framed (or whatever).  Do we
additionally include an instance of the Calling-Station-ID in the
Access-Request?  Is there an explicit signal or hint to the RADIUS
Server that the user name is the MAC address, or does it figure that out
by inspection (parsing)?  Or doesn't it matter?

--
to unsubscribe send a message 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 Dec 2005 17:22:57 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Issue: Treatment of null Identity Response
Date: Wed, 14 Dec 2005 09:22:44 -0800

Here is where I think we are:

1.  In RFC 2486bis a null NAI is not legal.  So no data in the 
EAP-Response/Identity should not be treated as a request for privacy (e.g. 
the anonymous user within the local realm).  If the desire is to indicate 
"the anonymous user in the local realm" then the NAI "@localrealm" should be 
used instead.

2.  Since there is no identity in the EAP-Response/Identity field, the 
RADIUS client should include the Calling-Station-ID (MAC Address) in the 
User-Name field, as it would for Service Type = Call Check.  However, the 
Service-Type should not actually be set to Call-Check since the call has 
already been accepted.

>From: Jari Arkko <[email-masked]>
>To: Bernard Aboba <[email-masked]>
>CC: [email-masked],  [email-masked]
>Subject: Re: Issue: Treatment of null Identity Response
>Date: Wed, 14 Dec 2005 13:10:19 +0200
>
>I think we should (1) discourage use of empty string in the client for
>privacy purposes and (2) document the different current usage in the
>NAS side and recommend X for new implementations. I'm leaning on
>X being no User-Name but use of CSID instead.
>
>--Jari

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

Delivery-date: Wed, 14 Dec 2005 16:56:02 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Treatment of null Identity Response
Date: Wed, 14 Dec 2005 11:55:21 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Jari Arkko writes...

> I think we should (1) discourage use of empty string in the client for
> privacy purposes and (2) document the different current usage in the
> NAS side and recommend X for new implementations. I'm leaning on
> X being no User-Name but use of CSID instead.

I agree.

--
to unsubscribe send a message 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 Dec 2005 11:10:51 +0000
Date: Wed, 14 Dec 2005 13:10:19 +0200
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Issue: Treatment of null Identity Response

I think we should (1) discourage use of empty string in the client for
privacy purposes and (2) document the different current usage in the
NAS side and recommend X for new implementations. I'm leaning on
X being no User-Name but use of CSID instead.

--Jari

Bernard Aboba wrote:

> It certainly makes sense to discourage use of a null 
> EAP-Response/Identity.  If anonymity is desired, then a response of 
> "@localrealm" can be sent instead.  But what should the RADIUS client 
> do if it gets an EAP-Response/Identity with no data?  Should it insert 
> "@localrealm" in the User-Name attribute?  Send no User-Name attribute 
> and include the Called-Station-ID instead?
>
>
>> From: Jari Arkko <[email-masked]>
>> To: Bernard Aboba <[email-masked]>
>> CC: [email-masked],  [email-masked]
>> Subject: Re: Issue: Treatment of null Identity Response
>> Date: Tue, 13 Dec 2005 16:25:12 +0200
>>
>> Bernard Aboba wrote:
>>
>>> RFC 4282 allows use of a userid without a realm ("fred").  It also 
>>> allows use of a realm without a userid ("@example.com").   So as far 
>>> as I can tell, an NAI without either a userid or realm is allowed as 
>>> well.
>>
>>
>> I think not -- here's the ABNF:
>>
>>   nai         =  username
>>   nai         =/ "@" realm
>>   nai         =/ username "@" realm
>>
>> which seems to imply that its either username, realm, or both. And 
>> neither
>> the "username" or "realm" can be an empty string.
>>
>>> One interpretation is that it represents the anonymous NAI of the 
>>> local realm, and so is equivalent to "@localrealm".  Since RFC 4282 
>>> discourages use of pseudonyms such as "anonymous" it is not clear 
>>> what the preferred representation is for "the anonymous user of the 
>>> local realm".  Under this line of thought, the null userid might not 
>>> only be legal, it might actually be the *preferred* representation!
>>
>>
>> Anyway, even if such a NAI would be legal, I think we should 
>> discourage it
>> at the client side for obvious roaming problems -- of course the NAS 
>> side could
>> still use that.
>>
>> But if I can read (or write) ABNF, then its not a legal NAI...
>>
>> --Jari
>>
>>
>> -- 
>> to unsubscribe send a message to [email-masked] with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://psg.com/lists/radiusext/>
>
>
>
>
>

--
to unsubscribe send a message 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 Dec 2005 11:08:35 +0000
Content-class: urn:content-classes:message
Subject: review of draft-ietf-radext-digest-auth-06.txt:
Date: Wed, 14 Dec 2005 13:07:49 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

I was selected as General Area Review Team reviewer for this
specification (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Summary: This document is ready for publication - however, I did notice
that in many sections text like:

        [IANA: use 102 if possible] for Digest-Response.

I am sure IANA will raise this issue, but it would be best if this was
covered in the IANA Considerations section.

thanks,
John
=09

--
to unsubscribe send a message 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 Dec 2005 06:52:44 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Issue: Treatment of null Identity Response
Date: Tue, 13 Dec 2005 22:52:10 -0800

It certainly makes sense to discourage use of a null EAP-Response/Identity.  
If anonymity is desired, then a response of "@localrealm" can be sent 
instead.  But what should the RADIUS client do if it gets an 
EAP-Response/Identity with no data?  Should it insert "@localrealm" in the 
User-Name attribute?  Send no User-Name attribute and include the 
Called-Station-ID instead?

>From: Jari Arkko <[email-masked]>
>To: Bernard Aboba <[email-masked]>
>CC: [email-masked],  [email-masked]
>Subject: Re: Issue: Treatment of null Identity Response
>Date: Tue, 13 Dec 2005 16:25:12 +0200
>
>Bernard Aboba wrote:
>
>>RFC 4282 allows use of a userid without a realm ("fred").  It also allows 
>>use of a realm without a userid ("@example.com").   So as far as I can 
>>tell, an NAI without either a userid or realm is allowed as well.
>
>I think not -- here's the ABNF:
>
>   nai         =  username
>   nai         =/ "@" realm
>   nai         =/ username "@" realm
>
>which seems to imply that its either username, realm, or both. And neither
>the "username" or "realm" can be an empty string.
>
>>One interpretation is that it represents the anonymous NAI of the local 
>>realm, and so is equivalent to "@localrealm".  Since RFC 4282 discourages 
>>use of pseudonyms such as "anonymous" it is not clear what the preferred 
>>representation is for "the anonymous user of the local realm".  Under this 
>>line of thought, the null userid might not only be legal, it might 
>>actually be the *preferred* representation!
>
>Anyway, even if such a NAI would be legal, I think we should discourage it
>at the client side for obvious roaming problems -- of course the NAS side 
>could
>still use that.
>
>But if I can read (or write) ABNF, then its not a legal NAI...
>
>--Jari
>
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message 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 Dec 2005 04:09:39 +0000
Date: Wed, 14 Dec 2005 01:09:10 -0300
From: Claudio Lapidus <[email-masked]>
To: Alan DeKok <[email-masked]>
Subject: Re: RADEXT Issue 148 Item 6
Cc: "Romascanu, Dan (Dan)" <[email-masked]>, [email-masked]

Hello all,

In addition to this most interesting discussion between "design" and
"implementation" points of view, let me state a simple fact from the
"user" perspective:

>  Another disconnect, I think, is the differences between design and
> implementation.  The MIB's define counters, which is well and good,
> but implementations have to make *some* decision for topics on which
> the MIBs are silent.  Since we can't describe all possible scenarios
> in the MIB specification, some level of vagueness is built-in to it.

True. Every user of the same "standard" MIB objects as implemented by
different SNMP agents knows the hard way that it is necessary first to
test thoroughly what is exactly the way a particular piece of software
implements a certain object. Anything can happen, from very subtle
differences that go undetected for several months to flagrant
discrepancies and whole portions of the MIB unimplemented, and indeed
it happens all the time, from all vendors.

Fortunately, all these seldom results in "interoperability" problems,
at least in the classical sense of the word. The work of implementing
network management systems is overall one of integration, and while
two implementations may differ in a certain detail, they usually do it
in a consistent way, i.e. they always differ in the same manner, so it
is relatively easy to define correlation and aggregation rules at the
NMS level to iron out those differences.

>  These issues hold true not only for RADIUS, but for any MIB
> implementation which have relationships between multiple counters.

Ditto.

best regards
cl.

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

Envelope-to: [email-masked]
Delivery-date: Tue, 13 Dec 2005 21:01:06 +0000
From: "Alan DeKok" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Subject: Re: RADEXT Issue 148 Item 6 
Cc: [email-masked]
Date: Tue, 13 Dec 2005 16:05:31 -0500
Message-Id: <[email-masked]>

"Romascanu, Dan (Dan)" <[email-masked]> wrote:
> There is some confusion in what you are describing between the
> definition of objects, and measurement methodology.

  I understand.  My reason for the confusion, though, is that for many
reasons I see those issues as overlapping.

  Another disconnect, I think, is the differences between design and
implementation.  The MIB's define counters, which is well and good,
but implementations have to make *some* decision for topics on which
the MIBs are silent.  Since we can't describe all possible scenarios
in the MIB specification, some level of vagueness is built-in to it.

> A clear definition of what you are counting MUST be provided. It is
> missing now.

  I agree.  The definition for "malformed" is generally agreed on:
doesn't match the packet format as defined in RFC 2865.  The rest of
the arguments are over the details.

> You seem to believe that MIB objects, or it's only counters maybe,
> have a level of vagueness by design.

  No, I'm saying that the *measurement* of those counters is
imprecise.  Each implementation defines exactly which counter it
increments, and when.  But that information may not be visible to the
management application that queries the counters.  As a result, the
management application may have to assume that the counters are close
to being consistent, but may not be perfect.

  e.g. If you query the counters, the equation relating them may *not*
hold true, but it should be *close*.

> What is the admissible variation due to implementation timing? Is it
> possible that one implementation never counts anything because of timing
> issues? Probably not.

  Or, an implementation simply doesn't increment a particular counter.

  These issues hold true not only for RADIUS, but for any MIB
implementation which have relationships between multiple counters.
The only way those relationships can hold true is if the SNMP queries
are against a transactional versioned database.

  Such MIB implementations are not common.  Rather, the common
implementation is that the MIB data is a "snapshot" of the current
counter, at the time it was queried.

  In any case, I think we've wandered far afield from the original
topic.  My background here is from implementation, where imperfect
specs lead to implementation-defined behavior.  We try to get
implementations inter-operable, but they will never be identical.

  As for this issue, I think the consensus is that the definition of
"malformed" is "does not match the packet format as defined in RFC
2865".  If you're OK with that, I think we can move forward.

  That's what implementations have deployed today, and that appears to
be the consensus so far here.

  Alan DeKok.

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

Delivery-date: Tue, 13 Dec 2005 20:26:39 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT Issue 148 Item 6 
Date: Tue, 13 Dec 2005 22:26:04 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>

Alan,

See in-line.

Regards,

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Tuesday, December 13, 2005 9:48 PM
> To: [email-masked]
> Subject: Re: RADEXT Issue 148 Item 6=20
>=20
> "Romascanu, Dan (Dan)" <[email-masked]> wrote:
> > Can you clarify what you mean by 'test vector with time-dependent=20
> > specifications of input packets and output counts'?
>=20
>   If we want to specify in *detail* how the implementations=20
> increment the counters, we need:
>=20
>   a) set of test packets which should increment various counters
>   b) for each packet, a list of counter(s) it increments
>   c) time ordering for packets: send packet 1, 2, 3, 4...
>   d) time ordering for querying the counters: after packet 1,
>      the counters should have the following values: a, b, c, d...
>=20
>   Without that level of detail, *no* management application=20
> can guarantee that the same input to multiple implementations=20
> results in the same MIB values over time.

There is some confusion in what you are describing between the
definition of objects, and measurement methodology.=20

My comment in the initial review was triggered by the usage of the term
malformed in the RFC 2618bis-2621bis documents. The term is not defined
in RFC 2865, and the later discussions on the list showed up that there
is no agreement between the subject experts about what this is.=20

A clear definition of what you are counting MUST be provided. It is
missing now.=20

Typically people writing MIB modules are able to provide definitions of
counters without detailing the measurement methodology. But I may be
wrong, I am not a expert in RADIUS, I leave this to the experts.=20

>=20
>   And even that level of detail isn't enough, because there=20
> may be any packet ordering, any number of simultaneous=20
> packets, and any combination of the two.
>=20
>   The suggested equations in the MIB documents *cannot* hold=20
> true, except as approximations over long periods of time. =20
> This is because the SNMP queries are generally not against a=20
> "snapshot" of the system, but rather a sert of independent=20
> queries spread over time.
>=20
>   At best, the counters are the MIB implementation's idea of=20
> what the values should be, at a particular time.  We=20
> shouldn't pretend that the MIB's offer a rigorously defined=20
> view of a transactional and versioned database.

So, define what kind of objects you are putting in, that's all that I am
asking.=20

>=20
> > >   I'm not sure what you mean by that.  There is no mandated=3D20=20
> > > behavior for interpretation of the counters by a management=3D20=20
> > > application.  There is no "interoperability" requirement=3D20 =
among=20
> > > management applications.
> >=20
> > I am sorry, no offense intended, but are you serious? Of=20
> course there=20
> > is, as with any standard. Why are we defining MIB objects at all?
>=20
>   Because having some information is better than having no=20
> information.

Maybe this is true sometimes, certainly not always. You seem to believe
that MIB objects, or it's only counters maybe, have a level of vagueness
by design. This is simply not true in general. If this is the case of
the RADIUS MIBs objects, or maybe for the 'malformed' objects, you need
to define this in the MIB specification.=20

>=20
>   The only way I can interpret your requirement on "interoperability"
> of management applications is that for a given set of input,=20
> all RADIUS servers must yield exactly the same values for all=20
> counters over time.  This means that the management=20
> application can then know that the counters have consistent=20
> meaning across all implementations.
>=20
>   I don't see how this is *ever* possible in practice. =20
> Implementation timing issues result in different counters=20
> being incremented at different points in time.  Unless we are=20
> to forbid this behavior, our only option is to agree that the=20
> counters have some level of implementation-dependent behavior.

What is the admissible variation due to implementation timing? Is it
possible that one implementation never counts anything because of timing
issues? Probably not.=20

>=20
> > >   Can you give concrete examples of problems caused by=3D20=20
> different=20
> > > implementations of the MIB counters?
> >=20
> > What MIB counters? People are using MIB counters in a=20
> zillion of ways,=20
> > from disconnecting backbone networks when networkErrors counters=20
> > thresholds are exceeded to sending congratulation messages=20
> each time=20
> > the counter of years in ageOfPerson objects advance? In=20
> both cases and=20
> > in many other fuzzy definitions leading to inconsistent=20
> > implementations may cause problems.
>=20
>   Sorry, I was asking about *RADIUS* counters, and concrete=20
> examples of problems when implementations differ slightly in=20
> their incrementing of the counters.

If you believe that a certain level of aproximation for this counteres
is tolerable, you need to define it.=20

>=20
> > Of course implementations may be different, but definitions=20
> of objects=20
> > must be clear enough exactly so that the results obtained by=20
> > implementing differently are consistent.
>=20
>   Consistent, I can agree with.  My concern is that you=20
> appeared to be advocating *identical* results, which I=20
> believe to be impossible.
>=20

If this is the case, it needs to be documented.=20

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

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

Envelope-to: [email-masked]
Delivery-date: Tue, 13 Dec 2005 19:43:25 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: RADEXT Issue 148 Item 6 
Date: Tue, 13 Dec 2005 14:48:03 -0500
Message-Id: <[email-masked]>

"Romascanu, Dan (Dan)" <[email-masked]> wrote:
> Can you clarify what you mean by 'test vector with time-dependent
> specifications of input packets and output counts'?

  If we want to specify in *detail* how the implementations increment
the counters, we need:

  a) set of test packets which should increment various counters
  b) for each packet, a list of counter(s) it increments
  c) time ordering for packets: send packet 1, 2, 3, 4...
  d) time ordering for querying the counters: after packet 1,
     the counters should have the following values: a, b, c, d...

  Without that level of detail, *no* management application can
guarantee that the same input to multiple implementations results in
the same MIB values over time.

  And even that level of detail isn't enough, because there may be any
packet ordering, any number of simultaneous packets, and any
combination of the two.

  The suggested equations in the MIB documents *cannot* hold true,
except as approximations over long periods of time.  This is because
the SNMP queries are generally not against a "snapshot" of the system,
but rather a sert of independent queries spread over time.

  At best, the counters are the MIB implementation's idea of what the
values should be, at a particular time.  We shouldn't pretend that the
MIB's offer a rigorously defined view of a transactional and versioned
database.

> >   I'm not sure what you mean by that.  There is no mandated=20
> > behavior for interpretation of the counters by a management=20
> > application.  There is no "interoperability" requirement=20
> > among management applications.
> 
> I am sorry, no offense intended, but are you serious? Of course there
> is, as with any standard. Why are we defining MIB objects at all?

  Because having some information is better than having no information.

  The only way I can interpret your requirement on "interoperability"
of management applications is that for a given set of input, all
RADIUS servers must yield exactly the same values for all counters
over time.  This means that the management application can then know
that the counters have consistent meaning across all implementations.

  I don't see how this is *ever* possible in practice.  Implementation
timing issues result in different counters being incremented at
different points in time.  Unless we are to forbid this behavior, our
only option is to agree that the counters have some level of
implementation-dependent behavior.

> >   Can you give concrete examples of problems caused by=20
> > different implementations of the MIB counters?
> 
> What MIB counters? People are using MIB counters in a zillion of ways,
> from disconnecting backbone networks when networkErrors counters
> thresholds are exceeded to sending congratulation messages each time the
> counter of years in ageOfPerson objects advance? In both cases and in
> many other fuzzy definitions leading to inconsistent implementations may
> cause problems.

  Sorry, I was asking about *RADIUS* counters, and concrete examples
of problems when implementations differ slightly in their incrementing
of the counters.

> Of course implementations may be different, but definitions of objects
> must be clear enough exactly so that the results obtained by
> implementing differently are consistent.

  Consistent, I can agree with.  My concern is that you appeared to be
advocating *identical* results, which I believe to be impossible.

  Alan DeKok.

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

Delivery-date: Tue, 13 Dec 2005 19:35:51 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Issue 148 Item 6
Date: Tue, 13 Dec 2005 14:35:46 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Dan Romascanu writes...

> As a MIB reviewer I cannot let this fly. Sorry.

On a procedural note, I would observe that if Dan and/or other MIB
Doctors feel this way about the current drafts it is likely that these
comments will generate a blocking DISCUSS in IESG review of these
drafts.

--
to unsubscribe send a message 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 Dec 2005 19:15:39 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT Issue 148 Item 6 
Date: Tue, 13 Dec 2005 21:15:22 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

Alan,

See in-line.=20

Regards,

Dan

=20
=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf=20
> Of Alan DeKok
> Sent: Tuesday, December 13, 2005 8:53 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: RADEXT Issue 148 Item 6=20
>=20
> "Romascanu, Dan (Dan)" <[email-masked]> wrote:
> > What do you mean by counters being 'implementation-dependent'? Two=20
> > different implementations will count the same thing? If so fine=20
> > otherwise we have a problem.
>=20
>   The specs do not include test vectors with time-dependent=20
> specifications of input packets and output counts.  As a=20
> result, for the same input packets, the values of the=20
> counters will vary across multiple implementations.

Can you clarify what you mean by 'test vector with time-dependent
specifications of input packets and output counts'?

>=20
>   This issue is *not* limited to "malformed" packets.
>=20
> > Consistent definition of the MIB objects leading to interoperable=20
> > management applications is not a recommendation, but a mandatory=20
> > requirement.
>=20
>   I'm not sure what you mean by that.  There is no mandated=20
> behavior for interpretation of the counters by a management=20
> application.  There is no "interoperability" requirement=20
> among management applications.

I am sorry, no offense intended, but are you serious? Of course there
is, as with any standard. Why are we defining MIB objects at all? =20

>=20
>   Can you give concrete examples of problems caused by=20
> different implementations of the MIB counters?

What MIB counters? People are using MIB counters in a zillion of ways,
from disconnecting backbone networks when networkErrors counters
thresholds are exceeded to sending congratulation messages each time the
counter of years in ageOfPerson objects advance? In both cases and in
many other fuzzy definitions leading to inconsistent implementations may
cause problems.=20

>=20
>   I ask because all implementations in use today have=20
> slightly different implementations of the MIB counters, and I=20
> haven't heard of any problem resulting from this.

Of course implementations may be different, but definitions of objects
must be clear enough exactly so that the results obtained by
implementing differently are consistent.=20

>=20

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

Delivery-date: Tue, 13 Dec 2005 19:07:25 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Treatment of null Identity Response
Date: Tue, 13 Dec 2005 14:07:21 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Barney Wolff writes...

> I believe the CUI was to be a single byte of 0-bits, thus NUL rather
> than NULL and not a violation.

I don't believe so.  The intent of the "hint" flavor of CUI was not to
change the underlying base type from printable-string to binary-string.
Sending a single byte of value zero would only be permissible for a
binary-string and not a UTF-8 printable-string.

The CUI type is defined as: "The string identifies the CUI of the
end-user and is of type UTF8String."  Of course, type UTF8String is not
a recognized data type in RFC 2865.  Can anyone point me to a formal
definition of this, within a RADIUS RFC?=20

This leads me to believe that the CUI attribute value field ought to
have been defined as a text type, rather than a string type.  See the
RFC 2865 definitions of the basic types:=20

	text      1-253 octets containing UTF-8 encoded 10646 [7]
                characters.  Text of length zero (0) MUST NOT be sent;
                omit the entire attribute instead.

      string    1-253 octets containing binary data (values 0 through
                255 decimal, inclusive).  Strings of length zero (0)
                MUST NOT be sent; omit the entire attribute instead.

Having noted that types discrepancy (a bit too late, alas), I don't
think there has ever been a substantive difference between the NULL
string and the NUL string.  Both are a string containing a binary-zero
as the first element of the array.  NUL is the abbreviation you'll find
in the US-ASCII character set definition for the character with hex
value zero.  The three character abbreviations for ASCII characters are
a historical artifact.  AFAIK, NULL means the same thing.=20

RADIUS specifically indicates that strings (text and binary) are not
NULL-terminated strings, but are counted strings.  In converting a
C-language NULL (or NUL) string to a RADIUS attribute, it would become a
RADIUS string type of zero length.

See the relevant text from RFC 2865:

      Note that none of the types in RADIUS terminate with a NUL (hex
      00). In particular, types "text" and "string" in RADIUS do not
      terminate with a NUL (hex 00).  The Attribute has a length field
      and does not use a terminator.  Text contains UTF-8 encoded 10646
      [7] characters and String contains 8-bit binary data.  Servers and
      servers and clients MUST be able to deal with embedded nulls.
      RADIUS implementers using C are cautioned not to use strcpy() when
      handling strings.

> I must say, in passing, that I never understood why zero-length
strings
> were forbidden.  Can anyone point to a logical, or historical, reason?

I believe that the historical reason was that zero-length attributes
contained no data, and were presumed to have no semantics, and for
reasons of bits-on-the-wire efficiency and protocol clarity it was
deemed preferable to omit the attribute rather than send an "empty
container".

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

Envelope-to: [email-masked]
Delivery-date: Tue, 13 Dec 2005 18:51:33 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: RADEXT Issue 148 Item 6 
Date: Tue, 13 Dec 2005 13:56:13 -0500
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> (1) Should the existing RADIUS MIB objects that count malformed packets
> be deprecated, a normative definition of malformed created, and new
> counter objects be added to count malformed packets according to the new
> definition?  {YES|NO}

  No.

> (2) Should the normative definition of malformed packets, created as
> described in Question (1), include packets that do not conform to the
> suggested VSA syntax of RFC 2865? {YES|NO}

  No.

  We should recommend, however, that future implementations do NOT
count non-conforming VSA's in the "malformed" count.

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Tue, 13 Dec 2005 18:48:53 +0000
From: "Alan DeKok" <[email-masked]>
To: Barney Wolff <[email-masked]>
Subject: Re: RADEXT Issue 148 Item 6 
Cc: [email-masked]
Date: Tue, 13 Dec 2005 13:53:33 -0500
Message-Id: <[email-masked]>

Barney Wolff <[email-masked]> wrote:
> Seems to me that the only important criterion for counting malformed
> packets is that the count MUST reflect how many packets were handled
> as malformed.

  I agree.

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Tue, 13 Dec 2005 18:48:13 +0000
From: "Alan DeKok" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Subject: Re: RADEXT Issue 148 Item 6 
Cc: [email-masked]
Date: Tue, 13 Dec 2005 13:52:49 -0500
Message-Id: <[email-masked]>

"Romascanu, Dan (Dan)" <[email-masked]> wrote:
> What do you mean by counters being 'implementation-dependent'? Two
> different implementations will count the same thing? If so fine
> otherwise we have a problem.

  The specs do not include test vectors with time-dependent
specifications of input packets and output counts.  As a result, for
the same input packets, the values of the counters will vary across
multiple implementations.

  This issue is *not* limited to "malformed" packets.

> Consistent definition of the MIB objects leading to interoperable
> management applications is not a recommendation, but a mandatory
> requirement.

  I'm not sure what you mean by that.  There is no mandated behavior
for interpretation of the counters by a management application.  There
is no "interoperability" requirement among management applications.

  Can you give concrete examples of problems caused by different
implementations of the MIB counters?

  I ask because all implementations in use today have slightly
different implementations of the MIB counters, and I haven't heard of
any problem resulting from this.

  Alan DeKok.

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

Delivery-date: Tue, 13 Dec 2005 18:46:57 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT Issue 148 Item 6
Date: Tue, 13 Dec 2005 20:46:43 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Please use this version of the mail.

See in-line.=20

Regards,

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Barney Wolff
> Sent: Tuesday, December 13, 2005 8:32 PM
> Cc: [email-masked]
> Subject: Re: RADEXT Issue 148 Item 6
>=20
> On Tue, Dec 13, 2005 at 06:39:26PM +0200, Romascanu, Dan (Dan) wrote:
> >=20
> > Interoperability means that the document is clear enough so=20
> that two=20
> > different implementers can create two distinct implementations that=20
> > result in the same counter values for any given mix of=20
> well-formed and=20
> > malformed packets. Different implementations following the=20
> text in the=20
> > documents MUST NOT result in different counter values.
>=20
> Why?  What harm would result, to users or providers, if two=20
> implementations produced somewhat different counts?  For that=20
> matter, what harm would result, to users or providers, if two=20
> implementations differed somewhat in how strict their=20
> interpretations of "well-formed" on receipt were?

One cannot and should not make assumptions about how objects are used.=20

Let me ask you the other way? What is the usage of defining MIB objects
in a way that applications cannot build on these objects having
consistent and repeatable values even if coming from different code
basis.=20

> Is every implementation required to be a conformance test suite?
>=20
> I imagine we would all agree that a conformant implementation MUST NOT
> *send* malformed packets, and MUST NOT crash or loop on=20
> receipt of any packet.
>=20
> Seems to me that the only important criterion for counting=20
> malformed packets is that the count MUST reflect how many=20
> packets were handled as malformed.

If this is what the applications need, then deprecate the current
'malformed' objects, and define 'handled as malformed' objects. The
problem is that today you have 'malformed' objects that not only are not
defined, but you guys do not seem to agree what they mean, and candidly
admit that different implementations will return different values for
these objects. As a MIB reviewer I cannot let this fly. Sorry.=20
=20
>=20
> Regards,
> Barney
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Tue, 13 Dec 2005 18:44:28 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT Issue 148 Item 6
Date: Tue, 13 Dec 2005 20:44:15 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

See in-line.=20

Regards,

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Barney Wolff
> Sent: Tuesday, December 13, 2005 8:32 PM
> Cc: [email-masked]
> Subject: Re: RADEXT Issue 148 Item 6
>=20
> On Tue, Dec 13, 2005 at 06:39:26PM +0200, Romascanu, Dan (Dan) wrote:
> >=20
> > Interoperability means that the document is clear enough so=20
> that two=20
> > different implementers can create two distinct implementations that=20
> > result in the same counter values for any given mix of=20
> well-formed and=20
> > malformed packets. Different implementations following the=20
> text in the=20
> > documents MUST NOT result in different counter values.
>=20
> Why?  What harm would result, to users or providers, if two=20
> implementations produced somewhat different counts?  For that=20
> matter, what harm would result, to users or providers, if two=20
> implementations differed somewhat in how strict their=20
> interpretations of "well-formed" on receipt were?

One cannot and should not make assumptions about how objects are used.=20

Let me ask you the other way? What is the usage of defining MIB objects
in a way that applications can build on these objects having consistent
and repeatable values even if coming from different code basis.=20

> Is every implementation required to be a conformance test suite?
>=20
> I imagine we would all agree that a conformant implementation MUST NOT
> *send* malformed packets, and MUST NOT crash or loop on=20
> receipt of any packet.
>=20
> Seems to me that the only important criterion for counting=20
> malformed packets is that the count MUST reflect how many=20
> packets were handled as malformed.

If this is what the applications need, then deprecate the current
'malformed' objects, and define 'handled as malformed' objects. The
problem is that today you have 'malformed' objects that not only are not
defined, but you guys do not seem to agree what they mean, and candidly
admit that different implementations will return different values for
these objects. As a MIB reviewer I cannot let this fly. Sorry.=20
=20
>=20
> Regards,
> Barney
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Tue, 13 Dec 2005 18:38:53 +0000
Date: Tue, 13 Dec 2005 13:38:39 -0500
From: Barney Wolff <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue: Treatment of null Identity Response

On Tue, Dec 13, 2005 at 11:42:11AM -0500, Nelson, David wrote:
> 
> > For text and string types, RFC 2865 indicates that zero-length binary
> or
> > text strings MUST NOT be sent in attributes.  So it would seem to be a
> > conflict with RFC 2865 to require NULL strings.
> 
> To follow up on my thoughts, it seems we've already [additionally]
> violated this RFC 2865 requirement in the CUI document, wherein we
> suggest a NULL value of CUI as a hint to the RADIUS Server.  :-(  So I
> suppose, this is an "issue" to be resolved.

I believe the CUI was to be a single byte of 0-bits, thus NUL rather
than NULL and not a violation.  I must say, in passing, that I never
understood why zero-length strings were forbidden.  Can anyone point
to a logical, or historical, reason?

Regards,
Barney

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I never met a computer I didn't like.

--
to unsubscribe send a message 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 Dec 2005 18:32:12 +0000
Date: Tue, 13 Dec 2005 13:32:01 -0500
From: Barney Wolff <[email-masked]>
Cc: [email-masked]
Subject: Re: RADEXT Issue 148 Item 6

On Tue, Dec 13, 2005 at 06:39:26PM +0200, Romascanu, Dan (Dan) wrote:
> 
> Interoperability means that the document is clear enough so that two
> different implementers can create two distinct implementations that
> result in the same counter values for any given mix of well-formed and
> malformed packets. Different implementations following the text in the
> documents MUST NOT result in different counter values. 

Why?  What harm would result, to users or providers, if two implementations
produced somewhat different counts?  For that matter, what harm would
result, to users or providers, if two implementations differed somewhat
in how strict their interpretations of "well-formed" on receipt were?
Is every implementation required to be a conformance test suite?

I imagine we would all agree that a conformant implementation MUST NOT
*send* malformed packets, and MUST NOT crash or loop on receipt of any
packet.

Seems to me that the only important criterion for counting malformed
packets is that the count MUST reflect how many packets were handled
as malformed.

Regards,
Barney

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

Delivery-date: Tue, 13 Dec 2005 18:15:29 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT Issue 148 Item 6 
Date: Tue, 13 Dec 2005 20:15:08 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>

>   Recognizing that the counters are implementation-dependent=20
> is a good idea.  Recommending behavior is a good idea.
>=20

Alan,

What do you mean by counters being 'implementation-dependent'? Two
different implementations will count the same thing? If so fine,
otherwise we have a problem.=20

Consistent definition of the MIB objects leading to interoperable
management applications is not a recommendation, but a mandatory
requirement.=20

Regards,

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Tuesday, December 13, 2005 7:59 PM
> To: [email-masked]
> Subject: Re: RADEXT Issue 148 Item 6=20
>=20
> "Nelson, David" <[email-masked]> wrote:
> > And the inference is that the recommended or suggested VSA=20
> format in=20
> > RFC
> > 2865 is not sufficient to establish syntax rules for VSAs, is that=20
> > right?  I think that Alan DeKok's position is that some=20
> > implementations chose to interpret the VSA suggestions as syntax=20
> > rules, and enforce them as such.
>=20
>   Yes.  Without a clear definition of "malformed", those=20
> implementations are compatible with the specs.  Unless we=20
> choose to define "malformed" in the MIB documents, we cannot=20
> label those implementations as non-compliant.
>=20
> > I think Alan's suggestion was (a).
>=20
>   Yes.  The counting method used for "malformed" is=20
> implementation-dependent.  As is the counting method for all=20
> other counters, too (barring standardized test vectors).
>=20
> > (b) is to be desired, but it will likely draw criticism from those=20
> > whose implementations don't match the new normative definition of=20
> > "malformed".  While the "legislative intent" information from the=20
> > RADIUS WG deliberations is enlightening and instructive, at=20
> the end of=20
> > the day we are left with the text that was actually incorporated in=20
> > the RFCs.
>=20
>   Recognizing that the counters are implementation-dependent=20
> is a good idea.  Recommending behavior is a good idea.
>=20
>   We can recognize that there is no definition of=20
> "malformed", that the counters are implementation-dependent,=20
> and then recommend that the contents of VSA's are out of=20
> scope of the counter.
>=20
>   Alan DeKok.
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Envelope-to: [email-masked]
Delivery-date: Tue, 13 Dec 2005 17:54:45 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: RADEXT Issue 148 Item 6 
Date: Tue, 13 Dec 2005 12:59:17 -0500
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> And the inference is that the recommended or suggested VSA format in RFC
> 2865 is not sufficient to establish syntax rules for VSAs, is that
> right?  I think that Alan DeKok's position is that some implementations
> chose to interpret the VSA suggestions as syntax rules, and enforce them
> as such.

  Yes.  Without a clear definition of "malformed", those
implementations are compatible with the specs.  Unless we choose to
define "malformed" in the MIB documents, we cannot label those
implementations as non-compliant.

> I think Alan's suggestion was (a).

  Yes.  The counting method used for "malformed" is
implementation-dependent.  As is the counting method for all other
counters, too (barring standardized test vectors).

> (b) is to be desired, but it will likely draw criticism from those
> whose implementations don't match the new normative definition of
> "malformed".  While the "legislative intent" information from the
> RADIUS WG deliberations is enlightening and instructive, at the end
> of the day we are left with the text that was actually incorporated
> in the RFCs.

  Recognizing that the counters are implementation-dependent is a good
idea.  Recommending behavior is a good idea.

  We can recognize that there is no definition of "malformed", that
the counters are implementation-dependent, and then recommend that the
contents of VSA's are out of scope of the counter.

  Alan DeKok.

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

Delivery-date: Tue, 13 Dec 2005 17:46:41 +0000
Date: Tue, 13 Dec 2005 18:46:42 +0100
From: Emile van Bergen <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked], "Romascanu, Dan (Dan)" <[email-masked]>
Subject: Re: RADEXT Issue 148 Item 6
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked], "Romascanu, Dan (Dan)" <[email-masked]>

Hi,

On Tue, Dec 13, 2005 at 11:14:18AM -0500, Nelson, David wrote:

> Dan Romascanu writes...
> 
> > I believe that (a) is not an acceptable solution from an
> > interoperability point of view. The currently used term of 'malformed'
> > is not defined properly. If left to the implementation to interpret
> > 'malformed', interoperability cannot be ensured. Rather than
> documenting
> > this situation, I would by now rather deprecate the current objects
> > counting 'malformed', define the term properly, and create new
> objects,
> > now or later.
> 
> That seems like a reasonable suggestion.  Let me solicit an informal
> poll of the WG Mailing list to see if we have a consensus solution to
> this issue.
> 
> Please reply to the list answering these two poll questions:
> 
> (1) Should the existing RADIUS MIB objects that count malformed packets
> be deprecated, a normative definition of malformed created, and new
> counter objects be added to count malformed packets according to the new
> definition?  {YES|NO}

YES, provided the normative definition is conservative and does not
impose requirements not set forth in RFC 2865. 

Optionally, the definition for malformed packets may include packets
containing VSAs whose internal structure do not conform to the rules
defined by the vendor as associated with the PEC or even the exact
attribute in question, if the implementation knows about them. Those
rules may be the ones suggested by RFC 2865 or different ones.

Regardless of whether that is included, I do think that the counter
should only cover the SYNTAX level, not the semantic level. If packets
containing attributes containing semantic errors (eg. out of bounds
values, unroutable IP addresses, and so on) should be counted, then I
think that should be done using an unrelated MIB value.

> (2) Should the normative definition of malformed packets, created as
> described in Question (1), include packets that do not conform to the
> suggested VSA syntax of RFC 2865? {YES|NO}

NO (resoundingly).

Cheers,

Emile.

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

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

Delivery-date: Tue, 13 Dec 2005 16:42:11 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Treatment of null Identity Response
Date: Tue, 13 Dec 2005 11:42:11 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> For text and string types, RFC 2865 indicates that zero-length binary
or
> text strings MUST NOT be sent in attributes.  So it would seem to be a
> conflict with RFC 2865 to require NULL strings.

To follow up on my thoughts, it seems we've already [additionally]
violated this RFC 2865 requirement in the CUI document, wherein we
suggest a NULL value of CUI as a hint to the RADIUS Server.  :-(  So I
suppose, this is an "issue" to be resolved.

--
to unsubscribe send a message 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 Dec 2005 16:39:35 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT Issue 148 Item 6
Date: Tue, 13 Dec 2005 18:39:26 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

The counter objects are for malformed packets. So a definition is
necessary, even if the definition is just saying something like 'a
malformed packet is any packet that is not well-formed, according to
[reference]'.

Interoperability means that the document is clear enough so that two
different implementers can create two distinct implementations that
result in the same counter values for any given mix of well-formed and
malformed packets. Different implementations following the text in the
documents MUST NOT result in different counter values.=20

Regards,

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Barney Wolff
> NO.  Surely the question for interoperability is what the=20
> receiver is going to do with the packet, not how it counts it.
> We already have definition of what a well-formed packet is,=20
> so defining malformed separately risks conflict.  The notion=20
> that an implementation should have separate code to check=20
> malformation, apart from the code that actually processes the=20
> content, does not strike me as good advice.
>=20

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

Delivery-date: Tue, 13 Dec 2005 16:31:18 +0000
Date: Tue, 13 Dec 2005 11:31:13 -0500
From: Barney Wolff <[email-masked]>
Cc: [email-masked]
Subject: Re: RADEXT Issue 148 Item 6

On Tue, Dec 13, 2005 at 11:14:18AM -0500, Nelson, David wrote:
> 
> (1) Should the existing RADIUS MIB objects that count malformed packets
> be deprecated, a normative definition of malformed created, and new
> counter objects be added to count malformed packets according to the new
> definition?  {YES|NO}

NO.  Surely the question for interoperability is
what the receiver is going to do with the packet, not how it counts it.
We already have definition of what a well-formed packet is, so defining
malformed separately risks conflict.  The notion that an implementation
should have separate code to check malformation, apart from the code
that actually processes the content, does not strike me as good advice.

> (2) Should the normative definition of malformed packets, created as
> described in Question (1), include packets that do not conform to the
> suggested VSA syntax of RFC 2865? {YES|NO}

NO.  An implementation that does anything with the contents of a VSA
that it does not understand is broken.

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I never met a computer I didn't like.

--
to unsubscribe send a message 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 Dec 2005 16:30:42 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Treatment of null Identity Response
Date: Tue, 13 Dec 2005 11:30:33 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> Since RFC 4282 discourages use of pseudonyms such as "anonymous"
> it is not clear what the preferred representation is for "the=20
> anonymous user of the local realm".  Under this line of thought,
> the null userid might not only be legal, it might actually
> be the *preferred* representation!

Well, yes, but...  RFC 2865 defines the value field of attributes as
follows:

<quote>

      The format of the value field is one of five data types.  Note
      that type "text" is a subset of type "string".

      text      1-253 octets containing UTF-8 encoded 10646 [7]
                characters.  Text of length zero (0) MUST NOT be sent;
                omit the entire attribute instead.

      string    1-253 octets containing binary data (values 0 through
                255 decimal, inclusive).  Strings of length zero (0)
                MUST NOT be sent; omit the entire attribute instead.

      address   32 bit value, most significant octet first.

      integer   32 bit unsigned value, most significant octet first.

      time      32 bit unsigned value, most significant octet first --
                seconds since 00:00:00 UTC, January 1, 1970.  The
                standard Attributes do not use this data type but it is
                presented here for possible use in future attributes.

</quote>

For text and string types, RFC 2865 indicates that zero-length binary or
text strings MUST NOT be sent in attributes.  So it would seem to be a
conflict with RFC 2865 to require NULL strings.

--
to unsubscribe send a message 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 Dec 2005 16:14:21 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Issue 148 Item 6
Date: Tue, 13 Dec 2005 11:14:18 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Romascanu, Dan \(Dan\)" <[email-masked]>

Dan Romascanu writes...

> I believe that (a) is not an acceptable solution from an
> interoperability point of view. The currently used term of 'malformed'
> is not defined properly. If left to the implementation to interpret
> 'malformed', interoperability cannot be ensured. Rather than
documenting
> this situation, I would by now rather deprecate the current objects
> counting 'malformed', define the term properly, and create new
objects,
> now or later.

That seems like a reasonable suggestion.  Let me solicit an informal
poll of the WG Mailing list to see if we have a consensus solution to
this issue.

Please reply to the list answering these two poll questions:

(1) Should the existing RADIUS MIB objects that count malformed packets
be deprecated, a normative definition of malformed created, and new
counter objects be added to count malformed packets according to the new
definition?  {YES|NO}

(2) Should the normative definition of malformed packets, created as
described in Question (1), include packets that do not conform to the
suggested VSA syntax of RFC 2865? {YES|NO}

Thanks, in advance, for your assistance!

-- Dave

--
to unsubscribe send a message 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 Dec 2005 16:05:10 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT Issue 148 Item 6
Date: Tue, 13 Dec 2005 18:04:50 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

I believe that (a) is not an acceptable solution from an
interoperability point of view. The currently used term of 'malformed'
is not defined properly. If left to the implementation to interpret
'malformed', interoperability cannot be ensured. Rather than documenting
this situation, I would by now rather deprecate the current objects
counting 'malformed', define the term properly, and create new objects,
now or later.=20

Regards,

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Tuesday, December 13, 2005 5:49 PM
> To: [email-masked]
> Subject: RE: RADEXT Issue 148 Item 6
>=20
>=20
> Bernard Aboba writes...
> =20
> > I agree with Emile on this.  During the discussion of "malformed"=20
> > in the original RADEXT WG, the intent was to catch syntax=20
> errors, not=20
> > unknown attributes.
>=20
> And the inference is that the recommended or suggested VSA=20
> format in RFC
> 2865 is not sufficient to establish syntax rules for VSAs, is=20
> that right?  I think that Alan DeKok's position is that some=20
> implementations chose to interpret the VSA suggestions as=20
> syntax rules, and enforce them as such.
>=20
> <snip>
>=20
> > To fix the issue, you've got to choose one interpretation or the=20
> > other.  This may require some implementations to change=20
> their code --=20
> > but shying away from this will only sacrifice=20
> interoperability, which=20
> > isn't a good tradeoff.
>=20
> Is your recommendation to (a) document the current state of=20
> affairs, that "malformed" is defined by the implementation,=20
> or to (b) normatively define "malformed" someplace,=20
> potentially causing some implementations to be non-compliant?
>=20
> I think Alan's suggestion was (a).  From an interoperability=20
> perspective, (b) is to be desired, but it will likely draw=20
> criticism from those whose implementations don't match the=20
> new normative definition of "malformed".  While the=20
> "legislative intent" information from the RADIUS WG=20
> deliberations is enlightening and instructive, at the end of=20
> the day we are left with the text that was actually=20
> incorporated in the RFCs.
>=20
> I'm just looking for consensus on some text to include in the=20
> MIB drafts to close this issue.  :-)
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Tue, 13 Dec 2005 15:50:03 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Issue 148 Item 6
Date: Tue, 13 Dec 2005 10:49:10 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...
=20
> I agree with Emile on this.  During the discussion of "malformed"=20
> in the original RADEXT WG, the intent was to catch syntax errors,=20
> not unknown attributes.

And the inference is that the recommended or suggested VSA format in RFC
2865 is not sufficient to establish syntax rules for VSAs, is that
right?  I think that Alan DeKok's position is that some implementations
chose to interpret the VSA suggestions as syntax rules, and enforce them
as such.

<snip>

> To fix the issue, you've got to choose one interpretation or=20
> the other.  This may require some implementations to change their
> code -- but shying away from this will only sacrifice=20
> interoperability, which isn't a good tradeoff.

Is your recommendation to (a) document the current state of affairs,
that "malformed" is defined by the implementation, or to (b) normatively
define "malformed" someplace, potentially causing some implementations
to be non-compliant?

I think Alan's suggestion was (a).  From an interoperability
perspective, (b) is to be desired, but it will likely draw criticism
from those whose implementations don't match the new normative
definition of "malformed".  While the "legislative intent" information
from the RADIUS WG deliberations is enlightening and instructive, at the
end of the day we are left with the text that was actually incorporated
in the RFCs.

I'm just looking for consensus on some text to include in the MIB drafts
to close this issue.  :-)

--
to unsubscribe send a message 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 Dec 2005 15:12:46 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IESG Review of draft-ietf-radext-digest-auth06.txt (fwd)
Date: Tue, 13 Dec 2005 16:03:33 +0100

Alexey Melnikov wrote:

> General comments on the document:
> 1). sections 3.1 and 3.2 are too complex to follow, because 
> they allow for so many different modes of operations: nonce 
> generated on the RADIUS client or the RADIUS server, hash is 
> calculated on the RADIUS client or the RADIUS server, etc. I 
> understand why the document is trying to be so flexible, but 
> the text suffers as the result. I would suggest to separately 
> talk about scenarios described in sections 1.3.1 and 1.3.2.
This would introduce some redundancy. A developer implementing
the draft for both modes would have to join those sections anyway.

> 
> 2). everywhere in section 4: all references to "without 
> quotes" has to be replaced with "unquoted" or similar. 
> "Without quotes" can be interpreted as just blindly removing 
> the surrounding quote characters, however many attribute 
> values are allowed to contain quoted (escaped) "\" and <">, 
> so just removing the quotes will not produce proper result.
> 
Blindly removing the surrounding quotes is exactly
what was meant. quoted-string is used to allow characters
that would break the HTTP syntax. This is not relevant for RADIUS,
as we have TLV. (Un-)Escaping the actual value would not save very
much space (I'd guess that escapes are rare) but complicate the
implementation. 

> 3). It would be nice to see examples of both scenario 1 and 2 
> in the document. I think it will clean up a lot of confusion.
> 
What's wrong with message flow given in 1.3.1 figure 2?

> 
> Specific comments on the document (please let me know if I 
> got anything
> wrong):
> 
>  >3.1.  RADIUS Client Behavior
>  >
>  >   The attributes described in this document are sent in cleartext.
>  >   Therefore were a RADIUS client to accept secured connections (https
>  >   or sips) from HTTP-style clients, this could result in information
>  >   intentionally protected by HTTP-style clients being sent in the clear
>  >   during the RADIUS exchange.
> 
> This paragraph is an important security consideration, so I 
> think it should be moved to section 9 (Security Considerations section),
> otherwise it is too easy to overlook.
> 
This paragraph used to include a RADIUS client protocol action, so
I put it here. I agree that it is better to move it to the SC section now.

> [...]
> 
>  >   If the RADIUS client recognizes the nonce or does not generate
>  >   nonces,
> 
> Regarding "does not generate nonces" case - does this 
> paragraph talk about scenario 2 step 2, or scenario 2 step 6? 
> I think the latter, but the text is no clear.
>
The paragraph talks about the handling of an HTTP-style request
containing an Authorization header. Scenario 2 Step 2 follows an
HTTP-style request without an Authorization header. Is this really
that unclear?

>  >   it takes the header directives and puts them into a RADIUS
>  >   Access-Request packet.  It puts the 'response' directive into a
>  >   Digest-Response attribute and the realm / nonce / digest-uri / qop /
>  >   algorithm / cnonce / nc / username / opaque directives into the
>  >   respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop /
>  >   Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest-
>  >   Username / Digest-Opaque attributes.  The request method is put into
>  >   the Digest-Method attribute.  The RADIUS client adds a Message-
>  >   Authenticator attribute, defined in [RFC3579] and sends the Access-
>  >   Request packet to the RADIUS server.
> 
> [...]
> 
>  >   If the RADIUS client did receive an HTTP-style request without a
>  >   (Proxy-)Authorization header matching its locally configured realm
>  >   value, it obtains a new nonce and sends an error response (401 or
>  >   407) containing a (Proxy-)Authenticate header.
>  >
>  >   If the RADIUS client receives an Access-Reject from the RADIUS
>  >   server, it sends an error response to the HTTP-style request it has
>  >   received.  If the RADIUS client does not receive a response, it
>  >   retransmits or fails over to another RADIUS server as described in
>  >   [RFC2865].
>  >
>  >   The RADIUS client has three ways to obtain nonces: it generates them
>  >   locally, it has received one in a Digest-Nextnonce attribute of a
>  >   previously received Access-Accept packet, or it asks the RADIUS
>  >   server for one.  To do the latter, it sends an Access-Request
>  >   containing a Digest-Method and a Digest-URI attribute but without a
>  >   Digest-Nonce attribute.  It adds a Message-Authenticator (see
>  >   [RFC3579]) attribute to the Access-Request packet.  The RADIUS server
>  >   chooses a nonce and responds with an Access-Challenge containing a
>  >   Digest-Nonce attribute.
> 
> I suggest to move the second quoted above paragraph before 
> the first, so that the two paragraphs talking about nonces 
> are sequential.
OK

>  >   The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest-
>  >   Realm, Digest-Domain and Digest-Opaque attributes in the Access-
>  >   Challenge carrying the nonce.  If these attributes are present, the
>  >   client MUST use them.
> 
> The Digest-Realm attribute is required as per section 3.2. 
> The use of "can" is confusing in this case, as all other 
> attributes are optional.
OK

>  >3.2.  RADIUS Server Behavior
> [...]
>  >   A RADIUS server MUST check if the RADIUS client is authorized to
>  >   serve users of the realm mentioned in the Digest-Realm attribute.  If
>  >   the RADIUS client is not authorized, the RADIUS server MUST send an
>  >   Access-Reject.  The RADIUS server SHOULD log the event so as to
>  >   notify the operator, and MAY take additional action such as sending
>  >   an Access-Reject in response to all future requests from this client,
>  >   until this behavior is reset by management action.
> 
> If the server follow the last MAY, this can be used by DOS 
> attacks, so I think this should be pointed out.
> 
In this paragraph or in the Security Considerations section?

>  >   If the RADIUS server does not accept the nonce received in an Access-
>  >   Request packet but authentication was successful,
> 
> Does the server always have to check that the authentication 
> was successful before reporting nonce mismatch? Are there any 
> security implications?
> 
This is defined in RfC 2617. If the HTTP-style client receives
a 'stale' directive, it does not need to prompt the user for the
password again.

>  > the RADIUS server
>  >   MUST send an Access-Challenge packet containing a Digest-Stale
>  >   attribute set to 'true' (without quotes).  The RADIUS server MUST add
>  >   Message-Authenticator (see [RFC3579]), Digest-Nonce, Digest-Realm,
>  >   SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add
>  >   Digest-Domain, Digest-Opaque attributes to the Access-Challenge
>  >   packet.
> 
>  >4.4.  Digest-Response-Auth attribute
>  >
>  >   Description
>  >         This attribute enables the RADIUS server to prove possession of
>  >         the password.  If the previously received Digest-Qop attribute
>  >         was 'auth-int' (without quotes), the RADIUS server MUST send a
>  >         Digest-HA1 attribute instead of a Digest-Response-Auth
>  >         attribute.
> 
> This MUST is confusing, as other sections say that both 
> Digest-Response-Auth and Digest-HA1 are optional.
This is a conditional MUST. Digest-HA1 is mandatory, if Digest-Qop was
auth-int.

> 
>  >  The Digest-Response-Auth attribute MUST only be
>  >         used in Access-Accept packets.  The RADIUS client puts the
>  >         attribute value without quotes into the rspauth directive of
>  >         the Authentication-Info header.
> 
>  >4.8.  Digest-Qop attribute
>  >
>  >   Description
>  >         This attribute holds the Quality of Protection parameter that
>  >         influences the HTTP Digest calculation.  This attribute MUST
>  >         only be used in Access-Request and Access-Challenge packets.  A
>  >         RADIUS client SHOULD insert one of the Digest-Qop attributes it
>  >         has received in a previous Access-Challenge packet.
> 
> I was under impression that the HTTP[-like] client is the one 
> choosing Qop from the list of Qops specified by the RADIUS server.
I don't understand the problem.

> 
>  >RADIUS
>  >         servers SHOULD insert at least one Digest-Qop attribute in an
>  >         Access-Challenge packet.  Digest-Qop is optional in order to
>  >         preserve backward compatibility with a minimal implementation
>  >         of [RFC2069].
>  >   Type
>  >         [IANA: use 109 if possible] for Digest-Qop
>  >   Length
>  >         >=3
>  >   Text
>  >         In Access-Requests, the RADIUS client takes the value of the
>  >         qop directive (qop-value as described in [RFC2617]) without the
>  >         quotes from the HTTP-style request it wants to authenticate.
>  >         In Access-Challenge packets, the RADIUS server puts a desired
>  >         qop-value into this attribute.  If the RADIUS server supports
>  >         more than one "quality of protection" value, it puts each qop-
>  >         value into a separate Digest-Qop attribute.
> 
> As per my comment above - if multiple Qop values were 
> specified by the RADIUS server, the RADIUS client needs to 
> put them into a single "qop" directive containing comma 
> separated list of Qop values.
This is one possibility. I've chosen a different one: "If the RADIUS server
supports more than one "quality of protection" value, it puts each qop-value into
a separate Digest-Qop attribute."
Do you object to splitting up the qop directive into various TLVs?

> 
>  >4.13.  Digest-Username attribute
>  >
>  >   Description
>  >         This attribute holds the user name used in the HTTP digest
>  >         calculation.  The RADIUS server MUST use this attribute only
>  >         for the purposes of calculating the digest.  In order to
>  >         determine the appropriate user credentials, the RADIUS server
>  >         MUST use the User-Name (1) attribute, and MUST NOT use the
>  >         Digest-Username attribute.  This attribute MUST only be used in
>  >         Access-Request packets.
> 
> I am still not convinced that the Digest-Username is ever 
> different from the User-Name attribute. I would like to see 
> an example when they would be different.
>
What if your current policy was to assign HTTP user names containing '@'
signs? A RADIUS infrastructure would interpret those User-Names as NAIs
which may lead to undesired effects.

>  >4.17.  Digest-Domain attribute
>  >
>  >   Description
>  >         When a RADIUS client has asked for a nonce, the RADIUS server
>  >         MAY send one or more Digest-Domain attributes in its Access-
>  >         Challenge packet.  The RADIUS client puts them into the quoted,
>  >         space-separated list of URIs of the 'domain' directive of a
>  >         WWW-Authenticate header.  The URIs in the list define the
>  >         protection space (see [RFC2617], section 3.2.1).  RADIUS
>  >         servers MAY send one or more attributes of this type in Access-
>  >         Challenge packets.
> 
> The last sentence is just repeating the first sentence in the 
> same paragraph.
OK. 

>  >  This attribute MUST only be used in Access-
>  >         Challenge packets.
> 
>  >9.  Security Considerations
> [...]
>  >   The Message-Authenticator attribute, described in [RFC3579] section
>  >   3.2 MUST be included in Access-Request, Access-Challenge, Access-
>  >   Reject and Access-Accept messages that contain attributes described
>  >   in this specification.
> 
> I couldn't see this required attribute in the examples.
> 
OK

Regards,

Wolfgang

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

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

Delivery-date: Tue, 13 Dec 2005 14:50:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 102: NAS/QoS Filter Rule
Date: Tue, 13 Dec 2005 06:49:46 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>, "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>, <[email-masked]>

The following additional text to the Appendix is proposed to satisfy
Pasi's issue around tunneling clarity.  This text inserts nicely into
the existing Appendix A.  In less we hear otherwise, the following text
will be inserted as is.

Paul

A.1.4 Tunnel Redirection Examples

The following examples illustrate how traffic flows when subjected to a
NAS-Filter-Rule using tunnel redirection.  In these scenarios, the
following notation is used to represent traffic flows:

------>  Flow in one direction
<----->  Flow in two directions
=3D=3D=3D=3D=3D=3D>  Flow in a tunnel in one direction <=3D=3D=3D=3D=3D> =
 and in both
directions

A RADIUS server that wishes all traffic to flow between the client and a
selected redirection destination will issue an Access-Accept that
contains the specification for the tunnel using the attributes defined
by RFC 2868 and an NAS-Filter-Rule attribute using the tunnel action and
arguments.

An example NAS-Filter-Rule will look like:

tunnel "t1" in from assigned to any

This will cause all traffic that flows from the client to any
destination to be tunneled over the named tunnel "t1" to the tunnel
endpoint (TEP).

   +-------+            +------+         +------+       +------+
   |       |            |      |         |Tunnel|       |      |
   |client +<---------->+ NAS  +<=3D=3Dt1=3D=3D=3D>+ End  +<----->+ Dest =
|
   |       |            |      |         |Point |       |      |
   +-------+            +------+         +------+       +------+

The direction argument takes the values of "in", "out" or "inout" and is
important because it controls how information is routed. The following
diagram demonstrates how traffic is routed. In all these diagrams time
is increasing as we proceed down the page.

When rule direction is "in":

   client       NAS       TEP    DESTINATION
     |           |         |          |
     |---------->|=3D=3D=3Dt1=3D=3D=3D>|--------->|
     |           |         |          |
     |<----------|<-------------------|  (flows directly to NAS)
     |           |         |          |
    =20
The inbound traffic from the client matches the specified filter rule
and the IP packet is placed in the tunnel to the TEP. The TEP forwards
the packet to the Destination using the destination IP address in the
packet header. Note that the source address of the packet is the address
assigned at the NAS. Therefore if the destination were to reply to the
packet it would use the NAS source address and the packet would flow
directly to the NAS and to the client bypassing the TEP.  The Home
network would use this capability if it was only interested in metering
or seeing the inbound traffic from the client.

However, if the home network wanted to see the traffic in both
directions it could deploy a NAT function at the TEP.

Here is the flow when the TEP is acting like a NAT:=20

   client       NAS       TEP/NAT DESTINATION
     |           |         |          |
     |---------->|=3D=3D=3Dt1=3D=3D=3D>|--------->|
     |           |         |          |
     |<----------|<=3D=3Dt1=3D=3D=3D=3D|<---------|

The client establishes a connection to the Destination, but the TEP
acting as NAT, changes the source address of the IP packet(as NATs do)
to that of the TEP/NAT.  Now any replies from the Destination are sent
to the TEP/NAT.  The TEP/NAT then forwards these packets to the client
through the NAS.

When the TEP is acting as a NAT, using the direction argument "in" is
important.
The direction argument set to "out" will have no effect on traffic
coming from the tunnel since all traffic to the client should come from
the TEP/NAT inside the tunnel.  The direction argument set to "inout"
will have the same effect as if it were set to "in".

The TEP/NAT forwards all traffic for the client into the tunnel to the
NAS.
The NAS always forwards any egressing traffic from the tunnel to the
client.
It does not apply any redirection rules on traffic egressing a tunnel.
The NAS does not care whether the TEP is transparent or is acting as a
NAT.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of=20
> [email-masked]
> Sent: Tuesday, November 22, 2005 12:24 AM
> To: Sanchez, Mauricio (PNB Roseville); [email-masked]
> Subject: RE: Issue 102: NAS/QoS Filter Rule
>=20
> Mauricio Sanchez wrote:
> >=20
> > Can you describe which were the primary points you found useful in=20
> > reading Avi's document? Moreover, how would you suggest the=20
> RFC draft=20
> > incorporate those points you found useful?  Should we add=20
> yet another=20
> > Appendix?  A new section?  Something else?
>=20
> The most useful part of Avi's document to me was the section=20
> titled "Directing flows to a single tunnel". Perhaps adding=20
> an appendix containing roughly that material would be sufficient?
>=20
> Best regards,
> Pasi
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Tue, 13 Dec 2005 14:26:15 +0000
Date: Tue, 13 Dec 2005 16:25:12 +0200
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Issue: Treatment of null Identity Response

Bernard Aboba wrote:

> RFC 4282 allows use of a userid without a realm ("fred").  It also 
> allows use of a realm without a userid ("@example.com").   So as far 
> as I can tell, an NAI without either a userid or realm is allowed as 
> well.  

I think not -- here's the ABNF:

   nai         =  username
   nai         =/ "@" realm
   nai         =/ username "@" realm

which seems to imply that its either username, realm, or both. And neither
the "username" or "realm" can be an empty string.

> One interpretation is that it represents the anonymous NAI of the 
> local realm, and so is equivalent to "@localrealm".  Since RFC 4282 
> discourages use of pseudonyms such as "anonymous" it is not clear what 
> the preferred representation is for "the anonymous user of the local 
> realm".  Under this line of thought, the null userid might not only be 
> legal, it might actually be the *preferred* representation!

Anyway, even if such a NAI would be legal, I think we should discourage it
at the client side for obvious roaming problems -- of course the NAS 
side could
still use that.

But if I can read (or write) ABNF, then its not a legal NAI...

--Jari

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

Delivery-date: Tue, 13 Dec 2005 14:19:47 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Issue: Treatment of null Identity Response
Date: Tue, 13 Dec 2005 06:18:53 -0800

>>What we are seeing in implementations in the field is a mix of a) and c), 
>>with the behavior in case c) ranging all over the map.  In particular, 
>>some implementations are treating a null EAP-Response/Identity as a 
>>privacy NAI (no userid or realm).
>
>Oh boy. Hmm... lets think about this some further. RFC 4282 has
>another approach to privacy NAI, and one which works better with
>roaming and other AAA routing arrangements. So I think we should
>discourage that the use of empty EAP-Response/Identity for
>privacy purposes.

RFC 4282 allows use of a userid without a realm ("fred").  It also allows 
use of a realm without a userid ("@example.com").   So as far as I can tell, 
an NAI without either a userid or realm is allowed as well.  One 
interpretation is that it represents the anonymous NAI of the local realm, 
and so is equivalent to "@localrealm".  Since RFC 4282 discourages use of 
pseudonyms such as "anonymous" it is not clear what the preferred 
representation is for "the anonymous user of the local realm".  Under this 
line of thought, the null userid might not only be legal, it might actually 
be the *preferred* representation!

--
to unsubscribe send a message 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 Dec 2005 13:32:27 +0000
Date: Tue, 13 Dec 2005 15:31:40 +0200
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Issue: Treatment of null Identity Response

> What we are seeing in implementations in the field is a mix of a) and 
> c), with the behavior in case c) ranging all over the map.  In 
> particular, some implementations are treating a null 
> EAP-Response/Identity as a privacy NAI (no userid or realm).

Oh boy. Hmm... lets think about this some further. RFC 4282 has
another approach to privacy NAI, and one which works better with
roaming and other AAA routing arrangements. So I think we should
discourage that the use of empty EAP-Response/Identity for
privacy purposes.

What I think remains is two real cases. The first case is simply
failure, and all we are debating is whether the failure occurs
in the client who never responds, the NAS who dislikes the
response, or in AAA that can't route or authenticate the
user. Here my preference would be to fail as late as possible.
That is, have clients respond with empty identity, have
NASes forward the request to AAA etc. I think it is clear
that empty User-Name should not be used, but here we
still have the question of whether to omit it altogether or
or to use Calling-Station-Id as User-Name. I'd be in favor
of the latter, given the RFC 3579 text.

The second case is a legitimate attempt to use provide
no User-Name, complemented with, e.g., some MAC-address
based directory of users. This appears to not work in
roaming, which to me says that we should discourage
such behaviour. But we can still allow it... the proposed
approach would be same as for the above case, i.e., use
Calling-Station-Id as the User-Name and let the AAA handle
it.

Documenting this: this seems mostly a RFC 3579/4005 problem.
Unless we are developing a bis for them, we could talk about
the issue in the issues & fixes draft. The text should indicate
rules for EAP client and NAS behaviour, and explain the
implications of particular usage (e.g. limitations in roaming).

--Jari

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

Delivery-date: Tue, 13 Dec 2005 13:02:41 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: RADEXT Issue 148 Item 6
Date: Tue, 13 Dec 2005 05:02:30 -0800

I agree with Emile on this.  During the discussion of "malformed" in the 
original RADEXT WG, the intent was to catch syntax errors, not unknown 
attributes.  RFC 2865 does not require a particular VSA format, and in AAA 
WG, we've had an extensive discussion about the problems that can occur when 
it is assumed that all VSAs obey the suggested format.  Going down this road 
could therefore set a precedent that could affect the interoperability of 
RADIUS in other contexts as well.

In cases where there are interoperability problems, it is not possible to 
establish precedent based on the existing behavior, since by definition the 
text has been interpretted differently by different implementers.  So the 
logic behind the proposed text is flawed.  To fix the issue, you've got to 
choose one interpretation or the other.  This may require some 
implementations to change their code -- but shying away from this will only 
sacrifice interoperability, which isn't a good tradeoff.

>I disagree with the issue.
>
>I would say that "malformed" means that the packet and the rules
>governing its format cannot be reconciled. A "syntax error", so to
>speak.
>
>If the rules governing the internal contents of the VSA are not known by
>the server (eg. by it not knowing about the vendor in question), it
>cannot flag the packet as malformed. It has rules governing the outer
>structure of the VSA, and those are the only ones it should apply.
>
>If, on the other hand, a server knows eg. that all USR VSAs use
>16-bit attribute numbers plus a length field that only covers the value
>subfield, and it sees an Ascend VSA that does not follow this format
>(eg. the 'internal length' exceeding the 'outer length' of the VSA), the
>server can flag a malformed packet.
>
>This keeps the counter meaningful. Otherwise, 'malformed' and thus
>ignored attributes from the vendor's point of view would cause the
>packet to be counted as well formed, while the inclusion of well formed
>attributes from the vendor's point of view, would cause the packet to be
>counted as malformed.
>
>If you run an USR NAS, that would make the counter meaningless.
>
>Cheers,
>
>
>Emile.
>
>--
>E-Advies - Emile van Bergen           [email-masked]
>tel. +31 (0)78 6136282           http://www.e-advies.nl
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message 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 Dec 2005 12:52:43 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Issue: Treatment of null Identity Response
Date: Tue, 13 Dec 2005 04:52:22 -0800

>I like what you suggest above. But admittedly the specs
>could be clearer about this. We also have RFC 3579, which
>says
>
>   ... the NAS MUST copy the
>   contents of the Type-Data field of the EAP-Response/Identity received
>   from the peer into the User-Name attribute...
>
>Which we can perhaps interpret so that if the contents is missing then
>we omit the attribute. But its not very clear. RFC 3579 also says
>
>   ... If the NAS initially sends an EAP-Request for an
>   authentication method, and the peer identity cannot be determined
>   from the EAP-Response, then the User-Name attribute SHOULD be
>   determined by another means.  As noted in [RFC2865] Section 5.6, it
>   is recommended that Access-Requests use the value of the
>   Calling-Station-Id as the value of the User-Name attribute.
>
>which talks about a similar but not exactly the same case. And
>recommends something different from what you were saying above.
>Anyway, it seems like we have the options of (a) failing the connection,
>(b) omitting User-Name, and (c) filling it with Called-Station-Id or some
>predetermined value.
>
>The other issue is what, if anything, we should clarify in the specs
>about this.

What we are seeing in implementations in the field is a mix of a) and c), 
with the behavior in case c) ranging all over the map.  In particular, some 
implementations are treating a null EAP-Response/Identity as a privacy NAI 
(no userid or realm).

--
to unsubscribe send a message 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 Dec 2005 11:20:42 +0000
Date: Tue, 13 Dec 2005 13:19:39 +0200
From: Jari Arkko <[email-masked]>
To:  [email-masked]
CC:  [email-masked],  [email-masked]
Subject: Re: Issue:  Treatment of null Identity Response

Pasi,

>I don't think there's any contradiction here...
>
>Both specs say that there are valid cases where no user name is
>available or known. In EAP, the whole EAP-Response/Identity packet
>cannot be omitted, so the client sends one with an empty data
>field. In RADIUS, an unavailable/unknown username is indicated by
>omitting the User-Name attribute from the Access-Request ("It MUST 
>be sent in Access-Request packets _if_available_.").
>
>So it seems the issue is only whether NAS implementations have really
>remembered to handle this special case correctly.
>
I like what you suggest above. But admittedly the specs
could be clearer about this. We also have RFC 3579, which
says

   ... the NAS MUST copy the
   contents of the Type-Data field of the EAP-Response/Identity received
   from the peer into the User-Name attribute...

Which we can perhaps interpret so that if the contents is missing then
we omit the attribute. But its not very clear. RFC 3579 also says

   ... If the NAS initially sends an EAP-Request for an
   authentication method, and the peer identity cannot be determined
   from the EAP-Response, then the User-Name attribute SHOULD be
   determined by another means.  As noted in [RFC2865] Section 5.6, it
   is recommended that Access-Requests use the value of the
   Calling-Station-Id as the value of the User-Name attribute.

which talks about a similar but not exactly the same case. And
recommends something different from what you were saying above.
Anyway, it seems like we have the options of (a) failing the connection,
(b) omitting User-Name, and (c) filling it with Called-Station-Id or some
predetermined value.

The other issue is what, if anything, we should clarify in the specs
about this.

--Jari

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

Delivery-date: Tue, 13 Dec 2005 07:14:14 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue:  Treatment of null Identity Response
Date: Tue, 13 Dec 2005 09:13:54 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

=20
I don't think there's any contradiction here...

Both specs say that there are valid cases where no user name is
available or known. In EAP, the whole EAP-Response/Identity packet
cannot be omitted, so the client sends one with an empty data
field. In RADIUS, an unavailable/unknown username is indicated by
omitting the User-Name attribute from the Access-Request ("It MUST=20
be sent in Access-Request packets _if_available_.").

So it seems the issue is only whether NAS implementations have really
remembered to handle this special case correctly. I'd guess there are
probably some implementations that send an empty User-Name attribute
instead (thus violating RFC2865), but this is just a hunch and not
based on actual experiences...

Best regards,
Pasi

> -----Original Message-----
> From: Bernard Aboba
> Sent: 12 December, 2005 22:24
> To: [email-masked]
> Subject: Issue: Treatment of null Identity Response
>=20
> RFC 3748 and RFC 2865 appear to disagree on the subject of whether=20
> a response to an EAP-Request/Identity can be an=20
> EAP-Response/Identity packet with no data.
>=20
> RFC 3748 Section 5.1 says:
>=20
>    Type
>=20
>       1
>=20
>    Type-Data
>=20
>       This field MAY contain a displayable message in the Request,
>       containing UTF-8 encoded ISO 10646 characters [RFC2279].  Where
>       the Request contains a null, only the portion of the field prior
>       to the null is displayed.  If the Identity is unknown, the
>       Identity Response field should be zero bytes in length.  The
>       Identity Response field MUST NOT be null terminated.  In all
>       cases, the length of the Type-Data field is derived from the
>       Length field of the Request/Response packet.
>=20
> So according to RFC 3748, it is possible to have an Identity=20
> Response field that is zero bytes in length, if the identity is=20
> not known.
>=20
> However, RFC 2865 Section 5.1 says:
>=20
> 5.1.  User-Name
>=20
>    Description
>=20
>       This Attribute indicates the name of the user to be=20
>       authenticated. It MUST be sent in Access-Request packets if=20
>       available.
>=20
>       It MAY be sent in an Access-Accept packet, in which case the
>       client SHOULD use the name returned in the Access-Accept packet=20
>       in all Accounting-Request packets for this session.  If the=20
>       Access-Accept includes Service-Type =3D Rlogin and the User-Name =

>       attribute, a NAS MAY use the returned User-Name when performing=20
>       the Rlogin function.
>=20
>    A summary of the User-Name Attribute format is shown below.  The
>    fields are transmitted from left to right.
>=20
>     0                   1                   2
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>    |     Type      |    Length     |  String ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>=20
>    Type
>=20
>       1 for User-Name.
>=20
>    Length
>=20
>       >=3D 3
>=20
>    String
>=20
>       The String field is one or more octets.  The NAS may limit the
>       maximum length of the User-Name but the ability to=20
>       handle at least 63 octets is recommended.
>=20
>       The format of the username MAY be one of several forms:
>       text      Consisting only of UTF-8 encoded 10646 [7] characters.
>       network access identifier
>=20
> Since the User-Name must be at least 3 bytes in length, a=20
> zero-length String  field is not acceptable.
>=20
> Question:  What does a RADIUS client do if it receives an=20
> EAP-Identity/Response with no data?

--
to unsubscribe send a message 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 Dec 2005 06:21:11 +0000
Date: Tue, 13 Dec 2005 08:20:06 +0200
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Issue:  Treatment of null Identity Response

Interesting question. One possible answer is that the
NAS should fail the login attempt. This seems reasonable,
because without a NAI it will be hard to route the authentication
request anyway. But is there use of EAP where the user
identity is not known but some other identity (e.g. calling
line identification) is used on the NAS side to decide which
customer this is?

--Jari

Bernard Aboba wrote:

> RFC 3748 and RFC 2865 appear to disagree on the subject of whether a 
> response to an EAP-Request/Identity can be an EAP-Response/Identity 
> packet with no data.
>
> RFC 3748 Section 5.1 says:
>
>   Type
>
>      1
>
>   Type-Data
>
>      This field MAY contain a displayable message in the Request,
>      containing UTF-8 encoded ISO 10646 characters [RFC2279].  Where
>      the Request contains a null, only the portion of the field prior
>      to the null is displayed.  If the Identity is unknown, the
>      Identity Response field should be zero bytes in length.  The
>      Identity Response field MUST NOT be null terminated.  In all
>      cases, the length of the Type-Data field is derived from the
>      Length field of the Request/Response packet.
>
> So according to RFC 3748, it is possible to have an Identity Response 
> field that is zero bytes in length, if the identity is not known.
>
> However, RFC 2865 Section 5.1 says:
>
> 5.1.  User-Name
>
>   Description
>
>      This Attribute indicates the name of the user to be authenticated.
>      It MUST be sent in Access-Request packets if available.
>
>      It MAY be sent in an Access-Accept packet, in which case the
>      client SHOULD use the name returned in the Access-Accept packet in
>      all Accounting-Request packets for this session.  If the Access-
>      Accept includes Service-Type = Rlogin and the User-Name attribute,
>      a NAS MAY use the returned User-Name when performing the Rlogin
>      function.
>
>   A summary of the User-Name Attribute format is shown below.  The
>   fields are transmitted from left to right.
>
>    0                   1                   2
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>   |     Type      |    Length     |  String ...
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>
>   Type
>
>      1 for User-Name.
>
>   Length
>
>      >= 3
>
>   String
>
>      The String field is one or more octets.  The NAS may limit the
>      maximum length of the User-Name but the ability to handle at least
>      63 octets is recommended.
>
>      The format of the username MAY be one of several forms:
>      text      Consisting only of UTF-8 encoded 10646 [7] characters.
>      network access identifier
>
> Since the User-Name must be at least 3 bytes in length, a zero-length 
> String field is not acceptable.
>
> Question:  What does a RADIUS client do if it receives an 
> EAP-Identity/Response with no data?
>
>
>
> -- 
> to unsubscribe send 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, 12 Dec 2005 20:24:17 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Issue:  Treatment of null Identity Response
Date: Mon, 12 Dec 2005 12:23:53 -0800

RFC 3748 and RFC 2865 appear to disagree on the subject of whether a 
response to an EAP-Request/Identity can be an EAP-Response/Identity packet 
with no data.

RFC 3748 Section 5.1 says:

   Type

      1

   Type-Data

      This field MAY contain a displayable message in the Request,
      containing UTF-8 encoded ISO 10646 characters [RFC2279].  Where
      the Request contains a null, only the portion of the field prior
      to the null is displayed.  If the Identity is unknown, the
      Identity Response field should be zero bytes in length.  The
      Identity Response field MUST NOT be null terminated.  In all
      cases, the length of the Type-Data field is derived from the
      Length field of the Request/Response packet.

So according to RFC 3748, it is possible to have an Identity Response field 
that is zero bytes in length, if the identity is not known.

However, RFC 2865 Section 5.1 says:

5.1.  User-Name

   Description

      This Attribute indicates the name of the user to be authenticated.
      It MUST be sent in Access-Request packets if available.

      It MAY be sent in an Access-Accept packet, in which case the
      client SHOULD use the name returned in the Access-Accept packet in
      all Accounting-Request packets for this session.  If the Access-
      Accept includes Service-Type = Rlogin and the User-Name attribute,
      a NAS MAY use the returned User-Name when performing the Rlogin
      function.

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

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

      1 for User-Name.

   Length

      >= 3

   String

      The String field is one or more octets.  The NAS may limit the
      maximum length of the User-Name but the ability to handle at least
      63 octets is recommended.

      The format of the username MAY be one of several forms:
      text      Consisting only of UTF-8 encoded 10646 [7] characters.
      network access identifier

Since the User-Name must be at least 3 bytes in length, a zero-length String 
field is not acceptable.

Question:  What does a RADIUS client do if it receives an 
EAP-Identity/Response with no data?

--
to unsubscribe send a message 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, 12 Dec 2005 20:05:53 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: IESG Review of draft-ietf-radext-digest-auth06.txt (fwd)
Date: Mon, 12 Dec 2005 12:05:42 -0800

>---------- Forwarded message ----------
>Date: Mon, 12 Dec 2005 13:38:59 -0500
>From: Sam Hartman <[email-masked]>
>To: [email-masked], [email-masked]
>Cc: [email-masked], [email-masked]
>Subject: [Alexey Melnikov] Re: Review request:
>     draft-ietf-radext-digest-auth06.txt
>
>I'd appreciate it if you could engage Alexey on these comments.  I
>think at least some of these might be blocking; I won't get around to
>evaluating whether I want to hold a discuss until Wednesday evening.
>
>I also expect another review tomorrow.

Date: Mon, 12 Dec 2005 15:28:43 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Cc: Sam Hartman <[email-masked]>, Kurt D. Zeilenga 
<[email-masked]>, [email-masked]
Subject: Re: Review request: draft-ietf-radext-digest-auth06.txt

Hi everyone,
Sam has asked me to review draft-ietf-radext-digest-auth-06.txt. I think
for the most part the document is ready, but I would recommend at least
one more revision to address some issues outlined below.

General comments on the document:
1). sections 3.1 and 3.2 are too complex to follow, because they allow
for so many different modes of operations: nonce generated on the RADIUS
client or the RADIUS server, hash is calculated on the RADIUS client or
the RADIUS server, etc. I understand why the document is trying to be so
flexible, but the text suffers as the result. I would suggest to
separately talk about scenarios described in sections 1.3.1 and 1.3.2.

2). everywhere in section 4: all references to "without quotes" has to
be replaced with "unquoted" or similar. "Without quotes" can be
interpreted as just blindly removing the surrounding quote characters,
however many attribute values are allowed to contain quoted (escaped)
"\" and <">, so just removing the quotes will not produce proper result.

3). It would be nice to see examples of both scenario 1 and 2 in the
document. I think it will clean up a lot of confusion.

Specific comments on the document (please let me know if I got anything
wrong):

 >3.1.  RADIUS Client Behavior
 >
 >   The attributes described in this document are sent in cleartext.
 >   Therefore were a RADIUS client to accept secured connections (https
 >   or sips) from HTTP-style clients, this could result in information
 >   intentionally protected by HTTP-style clients being sent in the clear
 >   during the RADIUS exchange.

This paragraph is an important security consideration, so I think it
should be moved to section 9 (Security Considerations section),
otherwise it is too easy to overlook.

[...]

 >   If the RADIUS client recognizes the nonce or does not generate
 >   nonces,

Regarding "does not generate nonces" case - does this paragraph talk
about scenario 2 step 2, or scenario 2 step 6?
I think the latter, but the text is no clear.

 > it takes the header directives and puts them into a RADIUS
 >   Access-Request packet.  It puts the 'response' directive into a
 >   Digest-Response attribute and the realm / nonce / digest-uri / qop /
 >   algorithm / cnonce / nc / username / opaque directives into the
 >   respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop /
 >   Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest-
 >   Username / Digest-Opaque attributes.  The request method is put into
 >   the Digest-Method attribute.  The RADIUS client adds a Message-
 >   Authenticator attribute, defined in [RFC3579] and sends the Access-
 >   Request packet to the RADIUS server.

[...]

 >   If the RADIUS client did receive an HTTP-style request without a
 >   (Proxy-)Authorization header matching its locally configured realm
 >   value, it obtains a new nonce and sends an error response (401 or
 >   407) containing a (Proxy-)Authenticate header.
 >
 >   If the RADIUS client receives an Access-Reject from the RADIUS
 >   server, it sends an error response to the HTTP-style request it has
 >   received.  If the RADIUS client does not receive a response, it
 >   retransmits or fails over to another RADIUS server as described in
 >   [RFC2865].
 >
 >   The RADIUS client has three ways to obtain nonces: it generates them
 >   locally, it has received one in a Digest-Nextnonce attribute of a
 >   previously received Access-Accept packet, or it asks the RADIUS
 >   server for one.  To do the latter, it sends an Access-Request
 >   containing a Digest-Method and a Digest-URI attribute but without a
 >   Digest-Nonce attribute.  It adds a Message-Authenticator (see
 >   [RFC3579]) attribute to the Access-Request packet.  The RADIUS server
 >   chooses a nonce and responds with an Access-Challenge containing a
 >   Digest-Nonce attribute.

I suggest to move the second quoted above paragraph before the first, so
that the two paragraphs talking about nonces are sequential.

 >   The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest-
 >   Realm, Digest-Domain and Digest-Opaque attributes in the Access-
 >   Challenge carrying the nonce.  If these attributes are present, the
 >   client MUST use them.

The Digest-Realm attribute is required as per section 3.2. The use of
"can" is confusing in this case, as all other attributes are optional.

 >3.2.  RADIUS Server Behavior
[...]
 >   A RADIUS server MUST check if the RADIUS client is authorized to
 >   serve users of the realm mentioned in the Digest-Realm attribute.  If
 >   the RADIUS client is not authorized, the RADIUS server MUST send an
 >   Access-Reject.  The RADIUS server SHOULD log the event so as to
 >   notify the operator, and MAY take additional action such as sending
 >   an Access-Reject in response to all future requests from this client,
 >   until this behavior is reset by management action.

If the server follow the last MAY, this can be used by DOS attacks, so I
think this should be pointed out.

 >   If the RADIUS server does not accept the nonce received in an Access-
 >   Request packet but authentication was successful,

Does the server always have to check that the authentication was
successful before reporting nonce mismatch?
Are there any security implications?

 > the RADIUS server
 >   MUST send an Access-Challenge packet containing a Digest-Stale
 >   attribute set to 'true' (without quotes).  The RADIUS server MUST add
 >   Message-Authenticator (see [RFC3579]), Digest-Nonce, Digest-Realm,
 >   SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add
 >   Digest-Domain, Digest-Opaque attributes to the Access-Challenge
 >   packet.

 >4.4.  Digest-Response-Auth attribute
 >
 >   Description
 >         This attribute enables the RADIUS server to prove possession of
 >         the password.  If the previously received Digest-Qop attribute
 >         was 'auth-int' (without quotes), the RADIUS server MUST send a
 >         Digest-HA1 attribute instead of a Digest-Response-Auth
 >         attribute.

This MUST is confusing, as other sections say that both
Digest-Response-Auth and Digest-HA1 are optional.

 >  The Digest-Response-Auth attribute MUST only be
 >         used in Access-Accept packets.  The RADIUS client puts the
 >         attribute value without quotes into the rspauth directive of
 >         the Authentication-Info header.

 >4.8.  Digest-Qop attribute
 >
 >   Description
 >         This attribute holds the Quality of Protection parameter that
 >         influences the HTTP Digest calculation.  This attribute MUST
 >         only be used in Access-Request and Access-Challenge packets.  A
 >         RADIUS client SHOULD insert one of the Digest-Qop attributes it
 >         has received in a previous Access-Challenge packet.

I was under impression that the HTTP[-like] client is the one choosing
Qop from the list of Qops specified by the RADIUS server.

 >RADIUS
 >         servers SHOULD insert at least one Digest-Qop attribute in an
 >         Access-Challenge packet.  Digest-Qop is optional in order to
 >         preserve backward compatibility with a minimal implementation
 >         of [RFC2069].
 >   Type
 >         [IANA: use 109 if possible] for Digest-Qop
 >   Length
 >         >=3
 >   Text
 >         In Access-Requests, the RADIUS client takes the value of the
 >         qop directive (qop-value as described in [RFC2617]) without the
 >         quotes from the HTTP-style request it wants to authenticate.
 >         In Access-Challenge packets, the RADIUS server puts a desired
 >         qop-value into this attribute.  If the RADIUS server supports
 >         more than one "quality of protection" value, it puts each qop-
 >         value into a separate Digest-Qop attribute.

As per my comment above - if multiple Qop values were specified by the
RADIUS server, the RADIUS client needs to put them into a single "qop"
directive containing comma separated list of Qop values.

 >4.13.  Digest-Username attribute
 >
 >   Description
 >         This attribute holds the user name used in the HTTP digest
 >         calculation.  The RADIUS server MUST use this attribute only
 >         for the purposes of calculating the digest.  In order to
 >         determine the appropriate user credentials, the RADIUS server
 >         MUST use the User-Name (1) attribute, and MUST NOT use the
 >         Digest-Username attribute.  This attribute MUST only be used in
 >         Access-Request packets.

I am still not convinced that the Digest-Username is ever different from
the User-Name attribute. I would like to see an example when they would
be different.

 >4.17.  Digest-Domain attribute
 >
 >   Description
 >         When a RADIUS client has asked for a nonce, the RADIUS server
 >         MAY send one or more Digest-Domain attributes in its Access-
 >         Challenge packet.  The RADIUS client puts them into the quoted,
 >         space-separated list of URIs of the 'domain' directive of a
 >         WWW-Authenticate header.  The URIs in the list define the
 >         protection space (see [RFC2617], section 3.2.1).  RADIUS
 >         servers MAY send one or more attributes of this type in Access-
 >         Challenge packets.

The last sentence is just repeating the first sentence in the same
paragraph.

 >  This attribute MUST only be used in Access-
 >         Challenge packets.

 >9.  Security Considerations
[...]
 >   The Message-Authenticator attribute, described in [RFC3579] section
 >   3.2 MUST be included in Access-Request, Access-Challenge, Access-
 >   Reject and Access-Accept messages that contain attributes described
 >   in this specification.

I couldn't see this required attribute in the examples.

Regards,
Alexey

--
to unsubscribe send a message 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, 12 Dec 2005 19:26:36 +0000
To: [email-masked]
Subject: RFC 4282 on The Network Access Identifier
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Mon, 12 Dec 2005 11:23:56 -0800

--NextPart

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

        RFC 4282

        Title:      The Network Access Identifier
        Author(s):  B. Aboba, M. Beadles, J. Arkko, P. Eronen
        Status:     Standards Track
        Date:       December 2005
        Mailbox:    [email-masked], [email-masked],
                    [email-masked], [email-masked]
        Pages:      16
        Characters: 34421
        Obsoletes:  2486

        I-D Tag:    draft-ietf-radext-rfc2486bis-06.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4282.txt

In order to provide roaming services, it is necessary to have a
standardized method for identifying users.  This document defines the
syntax for the Network Access Identifier (NAI), the user identity
submitted by the client during network authentication.  "Roaming" may
be loosely defined as the ability to use any one of multiple Internet
Service Providers (ISPs), while maintaining a formal,
\%customer-vendor
relationship with only one.  Examples of where roaming capabilities
might be required include ISP "confederations" and \%ISP-provided
corporate network access support.  This document is a revised version
of RFC 2486, which originally defined NAIs.  Enhancements include
international character set and privacy support, as well as a number
of corrections to the original RFC.

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

This is now a Proposed Standard Protocol.

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

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

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

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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

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

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

RETRIEVE: rfc
DOC-ID: rfc4282

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc4282.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

Envelope-to: [email-masked]
Delivery-date: Mon, 12 Dec 2005 16:20:32 +0000
From: "Alan DeKok" <[email-masked]>
To: Emile van Bergen <[email-masked]>
Subject: Re: RADEXT Issue 148 Item 6 
Cc: "Nelson, David" <[email-masked]>, [email-masked], [email-masked]
Date: Mon, 12 Dec 2005 11:24:49 -0500
Message-Id: <[email-masked]>

Emile van Bergen <[email-masked]> wrote:
> If the rules governing the internal contents of the VSA are not known by
> the server (eg. by it not knowing about the vendor in question), it
> cannot flag the packet as malformed. It has rules governing the outer
> structure of the VSA, and those are the only ones it should apply.

  That's all and good, but where in the RADIUS specifications does it
define which rules should be applied to define this term?

  The suggested definition of "malformed" was due to two reasons:

  1) there is no definition of "malformed" in the RFC's
  2) existing implementations count "malformed" packets in
     implementation-dependent ways (as a result of (1))

> If, on the other hand, a server knows eg. that all USR VSAs use
> 16-bit attribute numbers plus a length field that only covers the value
> subfield, and it sees an Ascend VSA that does not follow this format
> (eg. the 'internal length' exceeding the 'outer length' of the VSA), the
> server can flag a malformed packet.

  The decision as to what is good, or bad, syntax in your examples is
up to the implementation.  The proposed text is intended to say that
the definition of "malformed" is implementation-dependent.

  The text is *not* intended to define that all new implementations
must behave in the way described.  Rather, it is intended to define
that there is no clear definition for the counter, and that the
meaning of the counter is implementation dependent.

> This keeps the counter meaningful. Otherwise, 'malformed' and thus
> ignored attributes from the vendor's point of view would cause the
> packet to be counted as well formed, while the inclusion of well formed
> attributes from the vendor's point of view, would cause the packet to be
> counted as malformed.

  Yes.  It's inconsistent, precisely because the definition of
"malformed" is non-existent.

> If you run an USR NAS, that would make the counter meaningless.

  No, it makes the counters implementation dependent.  If you want to
know what the counters mean, ask your RADIUS server vendor.  As was
noted previously, implementations may not implement all of the
counters.

  Implementations may (or may not) implement portions of RADIUS.  If
an implementation does not completely support the protocol, that does
not make it useless, or meaningless.

  Can you suggest text that would address these issues to your
satisfaction?

  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, 12 Dec 2005 14:16:43 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT Issue 148 Items 2 and 3
Date: Mon, 12 Dec 2005 16:16:24 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Just to make sure - the text mentioned in comment 3 of the review, which
appears in all four documents in the Deprecated Objects sections is to
be replaced by the suggested text.=20

Regards,

Dan

=20
=20

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]]=20
> Sent: Friday, December 09, 2005 5:26 PM
> To: [email-masked]
> Cc: Romascanu, Dan (Dan)
> Subject: RADEXT Issue 148 Items 2 and 3
>=20
> The following text is proposed as a resolution to RADEXT=20
> Issue 148, Items 2 and 3:
>=20
> <quote>
>=20
> Managed entities SHOULD NOT instantiate row entries in the=20
> deprecated table, containing IPv4-only address objects, when=20
> the RADIUS server address represented in such a table row is=20
> not an IPv4 address.  Managed entities SHOULD NOT return=20
> inaccurate values of IP address or SNMP object access errors=20
> for IPv4-only address objects in otherwise populated tables. =20
> When row entries exist in both the deprecated IPv4-only table=20
> and the new IP version neutral table, that describe the same=20
> RADIUS server, the row indexes SHOULD be the same for the=20
> corresponding rows in each table, to facilitate correlation=20
> of these related rows by management applications.
>=20
> </quote>
>=20
> This text appears in Section 6. Deprecated Objects.
>=20
>=20

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

Delivery-date: Mon, 12 Dec 2005 13:48:39 +0000
Date: Mon, 12 Dec 2005 14:48:01 +0100
From: Emile van Bergen <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: RADEXT Issue 148 Item 6
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked], [email-masked]

Hi,

On Fri, Dec 09, 2005 at 03:21:12PM -0500, Nelson, David wrote:

> The following text is proposed to be added to Section 1. Terminology, to
> resolve RADEXT Issue 148, Item 6 (under General comments):
> 
> <quote>
> 
> This document uses the word "malformed" with respect to RADIUS packets,
> particularly in the context of counters of "malformed packets".  While
> RFC 2865 does not provide an explicit definition of "malformed",
> malformed generally means that the implementation has determined the
> packet does 
> not match the format defined in RFC 2865.  Some implementations may
> determine that packets are malformed when the Vendor Specific Attribute
> (VSA) format does not follow the RFC 2865 recommendations for VSAs.
> Those implementations are used in deployments today, and thus set the
> de-facto definition of "malformed".
> 
> </quote>

I disagree with the issue. 

I would say that "malformed" means that the packet and the rules
governing its format cannot be reconciled. A "syntax error", so to
speak.

If the rules governing the internal contents of the VSA are not known by
the server (eg. by it not knowing about the vendor in question), it
cannot flag the packet as malformed. It has rules governing the outer
structure of the VSA, and those are the only ones it should apply.

If, on the other hand, a server knows eg. that all USR VSAs use
16-bit attribute numbers plus a length field that only covers the value
subfield, and it sees an Ascend VSA that does not follow this format
(eg. the 'internal length' exceeding the 'outer length' of the VSA), the
server can flag a malformed packet.

This keeps the counter meaningful. Otherwise, 'malformed' and thus
ignored attributes from the vendor's point of view would cause the
packet to be counted as well formed, while the inclusion of well formed
attributes from the vendor's point of view, would cause the packet to be
counted as malformed.

If you run an USR NAS, that would make the counter meaningless.

Cheers,

Emile.

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

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

Delivery-date: Fri, 09 Dec 2005 20:22:04 +0000
Content-class: urn:content-classes:message
Subject: RADEXT Issue 148 Item 6
Date: Fri, 9 Dec 2005 15:21:12 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

The following text is proposed to be added to Section 1. Terminology, to
resolve RADEXT Issue 148, Item 6 (under General comments):

<quote>

This document uses the word "malformed" with respect to RADIUS packets,
particularly in the context of counters of "malformed packets".  While
RFC 2865 does not provide an explicit definition of "malformed",
malformed generally means that the implementation has determined the
packet does=20
not match the format defined in RFC 2865.  Some implementations may
determine that packets are malformed when the Vendor Specific Attribute
(VSA) format does not follow the RFC 2865 recommendations for VSAs.
Those implementations are used in deployments today, and thus set the
de-facto definition of "malformed".

</quote>

--
to unsubscribe send a message 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 Dec 2005 15:27:08 +0000
Content-class: urn:content-classes:message
Subject: RADEXT Issue 148 Items 2 and 3
Date: Fri, 9 Dec 2005 10:25:52 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

The following text is proposed as a resolution to RADEXT Issue 148,
Items 2 and 3:

<quote>

Managed entities SHOULD NOT instantiate row entries in the deprecated
table, containing IPv4-only address objects, when the RADIUS server
address represented in such a table row is not an IPv4 address.  Managed
entities SHOULD NOT return inaccurate values of IP address or SNMP
object access errors for IPv4-only address objects in otherwise
populated tables.  When row entries exist in both the deprecated
IPv4-only table and the new IP version neutral table, that describe the
same RADIUS server, the row indexes SHOULD be the same for the
corresponding rows in each table, to facilitate correlation of these
related rows by management applications.

</quote>

This text appears in Section 6. Deprecated Objects.

--
to unsubscribe send a message 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, 08 Dec 2005 17:25:24 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Review of draft-salowey-radext-delegated-prefix-01.txt
Date: Thu, 08 Dec 2005 09:25:12 -0800

Some comments on draft-salowey-radext-delegated-prefix-01, based my 
(possibly imperfect) understanding of the scenario.  Overall, I think the 
document is ok, but it may need some tweaking with respect to its 
description of the functionality of the existing Framed-IPv6-Prefix 
attribute.

  This is different from the usage of Framed-IPv6-
   Prefix attribute in which the prefix remains in control of the
   Network Access Server (NAS).  The prefix in the Framed-IPv6-Prefix
   attribute can be assigned to a link to which the NAS is attached, and
   may subsequently be advertised through Router Advertisement messages
   [3].

At the time RFC 3162 was written, I believe that intent was for the prefix 
described in Framed-IPv6-Prefix to be advertised by the NAS in Router 
Advertisement messages.   However, I am not clear that this necessarily 
implies that the prefix is solely for use on the link to which the NAS is 
attached.  For example, if a /48 is assigned, wouldn't it be possible for 
the NAS to advertise the /48 via Router Advertisement and for the CPE to 
parcel out /64s to its interfaces?  Given that interpretation, I don't think 
it is necessarily true that "the prefix remains in control of the NAS".

       Prefix-Length

            The length of the prefix, in bits.  At least 0 and no larger  
than 128.

This sentence, echoing RFC 3162 may introduce some of the same issues. Is it 
really the intent to enable prefixes more granular than a /64?   What is the 
inplication for prefix delegation if a /128 is assigned?

--
to unsubscribe send a message 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, 08 Dec 2005 17:14:07 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Prefix Delegation Discussion
Date: Thu, 08 Dec 2005 09:13:55 -0800

To kick off the review of draft-salowey-radext-delegated-prefix-01.txt, I 
thought I would post my (admittedly imperfect) understanding of what the 
problem is, why this document is necessary, and what (if anything) is wrong 
with RFC 3162.

RFC 3633 describes the basic scenario for use of prefix delegation:

   The model of operation for prefix delegation is as follows.  A
   delegating router is provided IPv6 prefixes to be delegated to
   requesting routers.  Examples of ways in which the delegating router
   may be provided these prefixes are given in Section 12.2.  A
   requesting router requests prefix(es) from the delegating router, as
   described in Section 12.1.  The delegating router chooses prefix(es)
   for delegation, and responds with prefix(es) to the requesting
   router.  The requesting router is then responsible for the delegated
   prefix(es).  For example, the requesting router might assign a subnet
   from a delegated prefix to one of its interfaces, and begin sending
   router advertisements for the prefix on that link.

   Each prefix has an associated valid and preferred lifetime, which
   constitutes an agreement about the length of time over which the
   requesting router is allowed to use the prefix.  A requesting router
   can request an extension of the lifetimes on a delegated prefix and
   is required to terminate the use of a delegated prefix if the valid
   lifetime of the prefix expires.

   This prefix delegation mechanism would be appropriate for use by an
   ISP to delegate a prefix to a subscriber, where the delegated prefix
   would possibly be subnetted and assigned to the links within the
   subscriber's network.

The use of RADIUS is described in Section 11.2:

   The  mechanism through which the delegating router selects prefix(es) for
   delegation is not specified in this document.  Examples of ways in
   which the delegating router might select prefix(es) for a requesting
   router include: static assignment based on subscription to an ISP;
   dynamic assignment from a pool of available prefixes; selection based
   on an external authority such as a RADIUS server using the Framed-
   IPv6-Prefix option as described in RFC 3162 [5].

Ralph's presentation from IETF 64 is located here:
http://www.drizzle.com/~aboba/IETF64/radext/ietf64_radext_Delegation.pdf

As I understand it, the issue occurs when an ISP desires to support Prefix 
Delegation at the same time that it would like to assign a prefix for the 
link between the NAS and CPE.  In this situation, the sematics of 
Framed-IPv6-Prefix are unclear:  what prefixes are to be used for 
delegation, and which one is to be used for the link?

Here is what RFC 3162 says about Framed-IPv6-Prefix:

      This Attribute indicates an IPv6 prefix (and corresponding route)
      to be configured for the user.  It MAY be used in Access-Accept
      packets, and can appear multiple times.  It MAY be used in an
      Access-Request packet as a hint by the NAS to the server that it
      would prefer these prefix(es), but the server is not required to
      honor the hint.  Since it is assumed that the NAS will plumb a
      route corresponding to the prefix, it is not necessary for the
      server to also send a Framed-IPv6-Route attribute for the same
      prefix.

In this case the user is the CPE.  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.  RFC 2865 Section 
5.10 describes the purpose of Framed-Routing:

      This Attribute indicates the routing method for the user, when the
      user is a router to a network.  It is only used in Access-Accept
      packets.

      The Value field is four octets.

       0      None
       1      Send routing packets
       2      Listen for routing packets
       3      Send and Listen

The description of the Prefix-Length field in RFC 3162 indicates 
(excessively?) wide latitude:

      The length of the prefix, in bits.  At least 0 and no larger than 128.

In my opinion, this is somewhat too broad, because it is not  clear to me 
what a NAS should do with a prefix of greater granularity than /64.  For 
example, what if Framed-IPv6-Prefix contains a /128? Does this imply that 
the NAS should be assigning an IPv6 address to the CPE?  I think the answer 
to that is no, because RFC 3162 already defines a Framed-IPv6-Identifier 
attribute to handle the Identifier portion.

In any case, it appears to me that the statement that "Framed-IPv6-Prefix is 
intended for assignment to the link between NAS and CPE" is only true if a 
/64 prefix is assigned.  When a larger prefix is sent, the intent was to 
provide the entire prefix to the CPE, enabling the CPE to assign 
sub-prefixes if it wished to do so.

--
to unsubscribe send a message 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, 08 Dec 2005 16:38:11 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Request for review of draft-salowey-radext-delegated-prefix-01.txt
Date: Thu, 08 Dec 2005 08:37:29 -0800

At IETF 64, Ralph Droms, co-chair of DHC WG, gave a presentation describing 
operational problems that have been found when RFC 3162 is deployed along 
with DHCPv6 prefix delegation (RFC  3633). These issues have been affecting 
on-going deployments of IPv6, so that there is an urgent need to address 
them.

To fix the problem, Ralph has worked with Joe Salowey:
http://www.ietf.org/internet-drafts/draft-salowey-radext-delegated-prefix-01.txt

The RADEXT WG is requested to review this document, as well as RFC 3162.  
Questions to ask include:

* Is this document a suitable basis for deployment of IPv6 prefix 
delegation?
* Is it compatible with RFC 3162?
* Do the operational problems that have arisen required any changes to RFC 
3162, or is this document sufficient?

--
to unsubscribe send a message 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, 04 Dec 2005 07:45:53 +0000
content-class: urn:content-classes:message
Subject: RE: Discussion of RADEXT Issue 148 (MIB review)
Date: Sun, 4 Dec 2005 09:45:07 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

=20
=20

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]]=20
> Sent: Saturday, December 03, 2005 12:59 AM
> To: [email-masked]
> Cc: Romascanu, Dan (Dan)
> Subject: Discussion of RADEXT Issue 148 (MIB review)
>=20
>=20
> It would indeed be helpful to add UNITS clauses to the=20
> Counter32 objects.  I can take a stab at doing this, but=20
> review will be required to ensure that objects are not being=20
> effectively redefined by these additions.
>=20
> It would also be useful to add REFERENCE clauses to objects=20
> that are specifically tied to sections of the base RFCs.  I=20
> can also take a stab at that.
>=20

I believe that adding UNITS and REFERENCE clauses does not change the
SYNTAX of the objects, and does not create any interoperability
problems, thus it may be considered as editorial changes for the purpose
of clarification. Actually in many cases this information is already
present in the DESCRIPTION clauses.=20

Regards,

Dan

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

Envelope-to: [email-masked]
Delivery-date: Sat, 03 Dec 2005 00:02:58 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Discussion of RADEXT Issue 148 (MIB review) 
Cc: [email-masked]
Date: Fri, 02 Dec 2005 19:06:50 -0500
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> While having a formal definition of "malformed" packets might be useful,
> since one has not heretofore existed I am concerned that creating such a
> definition at this point in time might in effect change the definition
> of existing objects.  If there is WG consensus on a definition of
> "malformed", and agreement that this consensus definition matches with
> existing implementations, then it may be desirable to add a definition
> of "malformed".  Comments are solicited.

  Malformed means that the implementation has determined the packet
does not match the format defined in RFC 2865.

  Some implementations may say packets are malformed when the VSA
format does not follow the RFC 2865 suggestion.  Those implementations
are used in deployments today, and thus set the de-facto definition of
"malformed".

  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, 02 Dec 2005 22:59:51 +0000
Content-class: urn:content-classes:message
Subject: Discussion of RADEXT Issue 148 (MIB review)
Date: Fri, 2 Dec 2005 17:59:09 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Most of the comments and suggestions in RAREXT Issue 148 ( =
http://www.drizzle.com/~aboba/RADEXT/#Issue%20148 ) are editorial and/or =
straightforward, and I propose to accept those for inclusion in the next =
version of the drafts.  I would like to generate some discussion on the =
list of a few of the comment items.

The consensus of the WG (and of the MIB Doctors) was that the new =
objects should be rooted under the existing IANA OID assignments, using =
the next available OID.  The comments in Issue 148 suggest, however, =
that the top RADIUS MIB OID assignment (radiusMIB) be included in only =
one of the four documents and imported into the other three.  This =
changes the document organization, but would not change the resulting =
OID tree.  I have no strong opinion on this option, one way or the =
other.  Comments are solicited.

The text in Section 6, Deprecated Objects, intends to indicate that =
managed entities should only instantiate rows in the deprecated tables =
when the address objects in those rows can accurately be represented as =
IPv4 format addresses.  If the managed entity contains a mixture of IPv4 =
addresses and IPv6 addresses, then the new tables may contain row =
entries for both sets of addresses, while the deprecated tables may =
contain only row entries for the IPv4 addresses.  The question of =
whether there is a required relationship in the indexing of rows within =
the deprecated and new tables was not addressed, but it may be =
reasonable to do so.  I would solicit suggestions on whether this is a =
good idea, and if it is, then some suggested text regarding the =
synchronization of row indexes.

It would indeed be helpful to add UNITS clauses to the Counter32 =
objects.  I can take a stab at doing this, but review will be required =
to ensure that objects are not being effectively redefined by these =
additions.

It would also be useful to add REFERENCE clauses to objects that are =
specifically tied to sections of the base RFCs.  I can also take a stab =
at that.

While having a formal definition of "malformed" packets might be useful, =
since one has not heretofore existed I am concerned that creating such a =
definition at this point in time might in effect change the definition =
of existing objects.  If there is WG consensus on a definition of =
"malformed", and agreement that this consensus definition matches with =
existing implementations, then it may be desirable to add a definition =
of "malformed".  Comments are solicited.

Regards,
=A0
Dave Nelson

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

Delivery-date: Fri, 02 Dec 2005 18:54:22 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 102: NAS/QoS Filter Rule - sub-issue 7 
Date: Fri, 2 Dec 2005 10:53:37 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Congdon, Paul T (ProCurve)" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5F771.B452A783
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Paul responded...

> -----Original Message-----
> Sent: Friday, September 23, 2005 3:04 PM [pc] Comments on Pasi's issue

> 102...

<...unneeded discussion cut...>

> 7) The document does not seem to describe what HTTP filter rules are=20
> or how they work (HTTP redirect rules are explained, but not HTTP=20
> filter rules).
>=20
> [pc] There really aren't specific HTTP filter rules per-se. =20
> We don't filter based upon HTTP content, but it is possible to filter=20
> all HTTP traffic using normal IP filter rules.  The text is a little=20
> unclear at the end of the section that indicates there are 'redirect'=20
> and 'filter'
> rules.  Seems like we need to discuss redirect rules separately from=20
> filter rules.  There are really two types of redirect rules; tunnel=20
> and http, and two filter rules; L2 and IP.

Discussion on this sub-issue 102-7 never was satisfactorily completed as
it stopped here.  Here's a new stab at for the beginning portion of the
'description' sub-section for nas-filter-rule attribute that I hope is a
bit better to understand.  I await comments.=20

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

The NAS-Filter-Rule attribute is derived from the Diameter IPFilterRule
and enables provisioning of base encapsulation (Layer 2) rules, Internet
Protocol (Layer 3-4) rules, and HTTP (Layer 5+) rules on the NAS by the
RADIUS server.  For each rule and depending on the rule type, the NAS
can be instructed to take a single action as follows:=20
=09
	Rule Type 	 		Allowable rule action=20
      -------------------    	---------------------
      Base Encapsultation     filter
      Internet Protocol       filter, tunnel
	HTTP 				filter, redirect

When specifying a base encapsulation rule, NAS-Filter-Rule processes
packets based on the following information that is associated with it:=20
         =20
      Direction                          (in and/or out)=20
      Base encapsulation type                     =20
      Source and destination MAC address (possibly masked)=20

For a base encapsulation rule, the filter action entails having the NAS
permit (i.e. forward) or deny (i.e. block) a user's traffic. =20
         =20
When specifying an Internet Protocol rule, NAS-Filter-Rule processes
packets based on the following information that is associated with it:=20
         =20
      Direction                          (in and/or out)=20
      Source and destination IP address  (possibly masked)=20
      Protocol=20
      Source and destination port        (lists or ranges)=20
      TCP flags=20
      IP fragment flag=20
      IP options=20
      ICMP types=20

For an Internet Protocol rule, the filter action entails having the NAS
permit (i.e. forward) or deny (i.e. block) a user's traffic.  The tunnel
action entails having the NAS forward user traffic to or from a named
tunnel that has been established per [RFC2868].=20
         =20
When specifying an HTTP rule, NAS-Filter-Rule process packets based on
the following information that is associated with it:=20
            =20
      HTTP URL =20
      Source and destination IP address   (possibly masked)=20

For an HTTP rule, the filter action entails having the NAS permit (i.e.
forward) or deny (i.e. block) a user's [RFC2616] request message.  For a
deny action, the NAS MAY respond to the request message with a code 403
(Forbidden) response in accordance with [RFC2616]. For a redirect action
the NAS SHOULD respond to the user's request with a code 302 (Found)
response in accordance with [RFC2616].=20
         =20
It should be noted that an HTTP filter...<description text continues
same as in current draft>

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

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

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

------_=_NextPart_001_01C5F771.B452A783
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7232.46">
<TITLE>RE: Issue 102: NAS/QoS Filter Rule - sub-issue 7 </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Paul responded...</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt; -----Original =
Message-----</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; Sent: Friday, September 23, =
2005 3:04 PM [pc] Comments on Pasi's issue </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; 102...</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&lt;...unneeded discussion =
cut...&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt; 7) The document does not =
seem to describe what HTTP filter rules are </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; or how they work (HTTP =
redirect rules are explained, but not HTTP </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; filter rules).</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; [pc] There really aren't =
specific HTTP filter rules per-se.&nbsp; </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; We don't filter based upon =
HTTP content, but it is possible to filter </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; all HTTP traffic using =
normal IP filter rules.&nbsp; The text is a little </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; unclear at the end of the =
section that indicates there are 'redirect' </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; and 'filter'</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; rules.&nbsp; Seems like we =
need to discuss redirect rules separately from </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; filter rules.&nbsp; There =
are really two types of redirect rules; tunnel </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; and http, and two filter =
rules; L2 and IP.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Discussion on this sub-issue =
102-7 never was satisfactorily completed as it stopped here.&nbsp; =
Here's a new stab at for the beginning portion of the 'description' =
sub-section for nas-filter-rule attribute that I hope is a bit better to =
understand.&nbsp; I await comments. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier =
New">------------------------------------------------------</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">The NAS-Filter-Rule attribute is =
derived from the Diameter IPFilterRule and enables provisioning of base =
encapsulation (Layer 2) rules, Internet Protocol (Layer 3-4) rules, and =
HTTP (Layer 5+) rules on the NAS by the RADIUS server.&nbsp; For each =
rule and depending on the rule type, the NAS can be instructed to take a =
single action as follows: </FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">Rule Type &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Allowable rule action </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-------------------&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; =
---------------------</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Base Encapsultation&nbsp;&nbsp;&nbsp;&nbsp; filter</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Internet Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; filter, =
tunnel</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">HTTP &nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; filter, redirect</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">When specifying a base =
encapsulation rule, NAS-Filter-Rule processes packets based on the =
following information that is associated with it: </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Direction&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; (in and/or out) </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Base encapsulation =
type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Source and destination MAC address (possibly masked) </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">For a base encapsulation rule, =
the filter action entails having the NAS permit (i.e. forward) or deny =
(i.e. block) a user's traffic.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">When specifying an Internet =
Protocol rule, NAS-Filter-Rule processes packets based on the following =
information that is associated with it: </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Direction&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; (in and/or out) </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Source and destination IP address&nbsp; (possibly masked) </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Protocol </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Source and destination port&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
(lists or ranges) </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
TCP flags </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
IP fragment flag </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
IP options </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ICMP types </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">For an Internet Protocol rule, =
the filter action entails having the NAS permit (i.e. forward) or deny =
(i.e. block) a user's traffic.&nbsp; The tunnel action entails having =
the NAS forward user traffic to or from a named tunnel that has been =
established per [RFC2868]. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">When specifying an HTTP rule, =
NAS-Filter-Rule process packets based on the following information that =
is associated with it: </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
HTTP URL&nbsp; </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Source and destination IP address&nbsp;&nbsp; (possibly masked) </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">For an HTTP rule, the filter =
action entails having the NAS permit (i.e. forward) or deny (i.e. block) =
a user's [RFC2616] request message.&nbsp; For a deny action, the NAS MAY =
respond to the request message with a code 403 (Forbidden) response in =
accordance with [RFC2616]. For a redirect action the NAS SHOULD respond =
to the user's request with a code 302 (Found) response in accordance =
with [RFC2616]. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">It should be noted that an HTTP =
filter...&lt;description text continues same as in current =
draft&gt;</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
-----------------------------------------------------------------</FONT><=
/P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">--------------------------------------------</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Mauricio Sanchez</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">, CISSP</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Network Security Architect</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Procurve Networking Business</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Hewlett Packard</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">8000 Foothills Boulevard, ms =
5555</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Roseville CA, 95747-5557</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">916.785.1910 Tel</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">916.785.1815 Fax</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">[email-masked]</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">--------------------------------------------&nbsp;&nbsp; =
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C5F771.B452A783--

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