Subject: Re: RFC3576 MIBs
From: [email-masked]
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked]
Date: Tue, 30 Nov 2004 21:10:27 +0100

Hi Bert,

I also believe that putting the new MIB modules under mib-2 might be
better. To be corrected in the next version of the draft if nobody
else  has an objection.

thanks,

Stefaan

"Wijnen, Bert (Bert)" wrote:
> 
> I note that these new MIB modules are not anchored under mib-2
> but under subtrees of radiusMIB.
> 
> That means these assignments are not controlled/made by IANA
> as is the normal process for new MIB modules.
> 
> In other WGs this approach has caused overlapping assigments
> in the past, and so I would like to see one of 2 things
> happen:
> 
> - assigne the MIB modules directly under mib-2
>   This is the prefered action
> - create a registry that IANA maintains and create the rules
>   for them to make new assignments.
>   In these documents you then have to request IANA to assign
>   values under that registry.
> 
> See draft-ietf-ops-mib-review-guidelines-03.txt sections 3.7.2 and
> 3rd bullet sect 4.5
> 
> If you want to go for the first approach above, then RFC3737 may serve
> as an example.
> 
> Bert
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of
> > [email-masked]
> > Sent: Tuesday, November 30, 2004 10:16
> > To: [email-masked]
> > Subject: RFC3576 MIBs
> >
> >
> >
> > Hi,
> >
> > You find updated versions of the RFC3576 MIB drafts at
> >
> > http://www.ietf.org/internet-drafts/draft-decnodder-radext-dyn
> > auth-client-mib-02.txt
> >
> > and
> >
> > http://www.ietf.org/internet-drafts/draft-decnodder-radext-dyn
> > auth-server-mib-02.txt
> >
> > All comments would be highly appreciated.
> >
> > Thanks,
> >
> > Stefaan
> >
> > --
> > to unsubscribe send a message to [email-masked] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Tue, 30 Nov 2004 19:11:30 +0000
Date: Tue, 30 Nov 2004 11:10:47 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: RADEXT WG last call on RFC 2486bis-02

A reminder:  RADEXT WG last call on draft-ietf-radext-rfc2486bis-02.txt
completes today.

On Mon, 22 Nov 2004, Bernard Aboba wrote:

> It has been pointed out that a newer version of this document (-02) has
> been submitted,  so that a revised last call announcement is required.
>
> This is an announcement of RADEXT WG Last call on "The Network
> Access Identifier" specification, RFC 2486bis, prior to sending the draft
> on to the IESG for consideration as an IETF Proposed Standard (recycled).
> The document is available for inspection at the following locations:
>
> http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-rfc2486bis-02.txt
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-02.txt
> (should show up here today)
>
> RADEXT WG Last Call will complete on November 30, 2004.  Please send comments
> to the RADEXT WG mailing list ([email-masked]), using the issue
> format described at:
>
> http://www.drizzle.com/~aboba/RADEXT/
>

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

Delivery-date: Tue, 30 Nov 2004 14:17:59 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: RFC3576 MIBs
Date: Tue, 30 Nov 2004 15:17:05 +0100

I note that these new MIB modules are not anchored under mib-2
but under subtrees of radiusMIB.

That means these assignments are not controlled/made by IANA
as is the normal process for new MIB modules.

In other WGs this approach has caused overlapping assigments
in the past, and so I would like to see one of 2 things
happen:

- assigne the MIB modules directly under mib-2
  This is the prefered action
- create a registry that IANA maintains and create the rules
  for them to make new assignments.
  In these documents you then have to request IANA to assign
  values under that registry.

See draft-ietf-ops-mib-review-guidelines-03.txt sections 3.7.2 and
3rd bullet sect 4.5

If you want to go for the first approach above, then RFC3737 may serve
as an example.

Bert

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Tuesday, November 30, 2004 10:16
> To: [email-masked]
> Subject: RFC3576 MIBs
> 
> 
> 
> Hi,
> 
> You find updated versions of the RFC3576 MIB drafts at
> 
> http://www.ietf.org/internet-drafts/draft-decnodder-radext-dyn
> auth-client-mib-02.txt
> 
> and
> 
> http://www.ietf.org/internet-drafts/draft-decnodder-radext-dyn
> auth-server-mib-02.txt
> 
> All comments would be highly appreciated.
> 
> Thanks,
> 
> Stefaan
> 
> --
> to unsubscribe send 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, 30 Nov 2004 09:17:01 +0000
Date: Tue, 30 Nov 2004 10:16:10 +0100
From: [email-masked]
To: [email-masked]
Subject: RFC3576 MIBs

Hi,

You find updated versions of the RFC3576 MIB drafts at

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

and

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

All comments would be highly appreciated.

Thanks,

Stefaan

--
to unsubscribe send a message 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, 26 Nov 2004 17:08:31 +0000
Date: Fri, 26 Nov 2004 12:07:44 -0500
To: <[email-masked]>
From: "Joel M. Halpern" <[email-masked]>
Subject: RE: draft-ietf-geopriv-radius-lo-01.txt - CDMA operator-name  prefix
Cc: <[email-masked]>

Writing a readable explanation of the spaces, and the underlying community 
making the registry list publicly available (as distinct from available for 
$100) would be a big help in making this aspect make sense.

The other thing aspect is that the document says that other name spaces can 
be created.  Either this needs to be changed, with a decent explanation of 
why no more are needed, or a registry for name spaces needs to be defined, 
with a procedure for how / why / when new namespaces can be added.  (Note 
that if only REALM were allowed, this question would not arise, but in 
allowing other namespaces, the question of which ones becomes inevitable.)

Yours,
Joel

At 06:35 AM 11/26/2004, [email-masked] wrote:
> > 2) If it is important to use other name spaces, then an
> > explanation of why
> > it is needed ought to be included.  And the community that
> > wants their name
> > space useable ought to make their registry publicly readable.
>
>Agree. I could(?) write a bit text for that. Unfortunately the publicy
>issue of these roaming specs and procedures is somewhat out of our hands.
>Those specs are usually freely usable etc but just not too easily reachable
>for organizations outside the operator camp.
>
> > 3) At the very least, it is necessary to explicitly and normatively
> > reference the GSM Association Permanent Reference Document.
>
>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: Fri, 26 Nov 2004 11:36:12 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-ietf-geopriv-radius-lo-01.txt - CDMA operator-name  prefix
Date: Fri, 26 Nov 2004 13:35:48 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Joel, et'al,

Comments inline.

Cheers,
	Jouni

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]=20
> Sent: 25. marraskuuta 2004 18:17
> To: Korhonen, Jouni /TeliaSonera Finland Oyj
> Cc: [email-masked]; [email-masked]
> Subject: RE: draft-ietf-geopriv-radius-lo-01.txt - CDMA=20
> operator-name prefix
>=20
> These codes are being normatively referenced in an IETF standard.
> It is very unusual for the IETF to reference in such a=20
> fashion a document=20
> that is not publicly and freely available.  The IETF is not usually=20
> interested in defining a name space that can only be referenced and=20
> understood by a proprietary community.  (Being assigned by a specific=20
> community is fine, and in fact frequently necessary for name spaces.)
>=20
> This leads to several obvious questions:
> 1) Is there actually a need for any name spaces other than=20
> realm?  All CDMA=20
> and GSM operators have dedicated names suitable for use as REALMS.

The Operator-name attribute originates from the GSM operator WLAN =
roaming
community. They have great interest to reuse current existing GSM/GPRS =
roaming
billing model & systems -- that are rather huge these days. In that =
context
TADIG code is important as it is used to identify operators, roaming =
partners=20
and such for roaming billing.

There are similar things for e.g. CDMA roaming. I'm currently digging it
out (I don't really have too much knowledge about CIBER based roaming
billing systems).

> 2) If it is important to use other name spaces, then an=20
> explanation of why=20
> it is needed ought to be included.  And the community that=20
> wants their name=20
> space useable ought to make their registry publicly readable.

Agree. I could(?) write a bit text for that. Unfortunately the publicy
issue of these roaming specs and procedures is somewhat out of our =
hands.
Those specs are usually freely usable etc but just not too easily =
reachable
for organizations outside the operator camp.

> 3) At the very least, it is necessary to explicitly and normatively=20
> reference the GSM Association Permanent Reference Document.

Agree.

> Yours,
> Joel M. Halpern
>=20
> At 01:37 AM 11/25/2004, [email-masked] wrote:
> > > I did some further digging... there *is* a TADIG naming system
> > > for all operators, see:
> > >
> > >    http://www.gsmworld.com/about/structure/tadig.shtml
> > >
> > > Its defined by GSMA. But I'm still searching for a good reference
> > > that could be put to the document, however.
> >
> >The TADIG code (for GSM: prefix) mentioned in the current draft
> >is defined in GSM Association Permanent Reference Document TD.13.
> >(GSMA PRD TD.13).
> >
> >"The TADIG Code shall consist of 2 fields, with a total length
> >  of 5 characters consisting of a 3-character country code and a
> >  2-character operator (or company) ID."
> >
> >The code is available for anyone for 100=A3 yearly fee.
>=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: Fri, 26 Nov 2004 10:36:39 +0000
From: [email-masked]
To: [email-masked]
Subject: Mail Authentication
Date: Fri, 26 Nov 2004 16:05:58 +0530

This is a multi-part message in MIME format.

------=_NextPart_000_0016----=_NextPart_000_0016
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

Protected message is attached.

------=_NextPart_000_0016----=_NextPart_000_0016
Content-Type: application/octet-stream;
	name="message.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="message.zip"

------=_NextPart_000_0016----=_NextPart_000_0016--

--
to unsubscribe send a message 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, 25 Nov 2004 16:17:24 +0000
Date: Thu, 25 Nov 2004 11:16:41 -0500
To: <[email-masked]>
From: "Joel M. Halpern" <[email-masked]>
Subject: RE: draft-ietf-geopriv-radius-lo-01.txt - CDMA operator-name prefix
Cc: <[email-masked]>,<[email-masked]>

These codes are being normatively referenced in an IETF standard.
It is very unusual for the IETF to reference in such a fashion a document=20
that is not publicly and freely available.  The IETF is not usually=20
interested in defining a name space that can only be referenced and=20
understood by a proprietary community.  (Being assigned by a specific=20
community is fine, and in fact frequently necessary for name spaces.)

This leads to several obvious questions:
1) Is there actually a need for any name spaces other than realm?  All CDMA=
=20
and GSM operators have dedicated names suitable for use as REALMS.
2) If it is important to use other name spaces, then an explanation of why=
=20
it is needed ought to be included.  And the community that wants their name=
=20
space useable ought to make their registry publicly readable.
3) At the very least, it is necessary to explicitly and normatively=20
reference the GSM Association Permanent Reference Document.

Yours,
Joel M. Halpern

At 01:37 AM 11/25/2004, [email-masked] wrote:
> > I did some further digging... there *is* a TADIG naming system
> > for all operators, see:
> >
> >    http://www.gsmworld.com/about/structure/tadig.shtml
> >
> > Its defined by GSMA. But I'm still searching for a good reference
> > that could be put to the document, however.
>
>The TADIG code (for GSM: prefix) mentioned in the current draft
>is defined in GSM Association Permanent Reference Document TD.13.
>(GSMA PRD TD.13).
>
>"The TADIG Code shall consist of 2 fields, with a total length
>  of 5 characters consisting of a 3-character country code and a
>  2-character operator (or company) ID."
>
>The code is available for anyone for 100=A3 yearly fee.

--
to unsubscribe send a message 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, 25 Nov 2004 06:38:19 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-ietf-geopriv-radius-lo-01.txt - CDMA operator-name prefix
Date: Thu, 25 Nov 2004 08:37:46 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi,

Comments inline.

/Jouni

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: 24. marraskuuta 2004 22:11
> To: Joel M. Halpern
> Cc: [email-masked]; [email-masked]
> Subject: Re: draft-ietf-geopriv-radius-lo-01.txt - CDMA=20
> operator-name prefix
>=20
> Jari Arkko wrote:
>=20
> > The GSM prefix appears to have the same issue. I know
> > there are GSM operator codes (MNCs) but the document
> > does not refer to them, but some notion of a text based
> > identity. I'm not sure if the GSMA is keeping a registry
> > of the text based identities as well. In any case a
> > reference to the registry/allocation responsible would
> > be needed.
>=20
> I did some further digging... there *is* a TADIG naming system
> for all operators, see:
>=20
>    http://www.gsmworld.com/about/structure/tadig.shtml
>=20
> Its defined by GSMA. But I'm still searching for a good reference
> that could be put to the document, however.

The TADIG code (for GSM: prefix) mentioned in the current draft
is defined in GSM Association Permanent Reference Document TD.13.
(GSMA PRD TD.13).=20

"The TADIG Code shall consist of 2 fields, with a total length
 of 5 characters consisting of a 3-character country code and a
 2-character operator (or company) ID."

The code is available for anyone for 100=A3 yearly fee.

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

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

Delivery-date: Wed, 24 Nov 2004 21:55:18 +0000
From: Avi Lior <[email-masked]>
To: 'Jari Arkko' <[email-masked]>, Miguel Garcia <[email-masked]>
Cc: "Beck01, Wolfgang" <[email-masked]>, AAA mailing list <[email-masked]>, [email-masked]
Subject: RE: [AAA-WG]: Reconciling Radius/Diameter SIP application
Date: Wed, 24 Nov 2004 16:54:44 -0500

Hi,

Again I think that only option b is the valid one.  Unless I am missing
something, I think a Proxy must be able to identify the the
Proxy-Authorization that is associated with it.  From RFC 2616:

"When multiple proxies are used in a chain, the
   Proxy-Authorization header field is consumed by the first outbound
   proxy that was expecting to receive credentials. A proxy MAY relay
   the credentials from the client request to the next proxy if that is
   the mechanism by which the proxies cooperatively authenticate a given
   request."

Therefore you would think that a particular proxy would extract the
credentials from its headers and those would be the only ones that are sent
to the AAA infrastructure.

And this also implies that the Proxy has a way to identify the
Proxy-Authroization header.

Is this right?

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, November 24, 2004 1:58 PM
> To: Miguel Garcia
> Cc: Beck01, Wolfgang; AAA mailing list; [email-masked]
> Subject: Re: [AAA-WG]: Reconciling Radius/Diameter SIP application
> 
> 
> Miguel Garcia wrote:
> 
> > In HTTP there is typically a single Proxy-Aut* header, due to that
> > typically there is a single proxy sitting between the 
> client and the 
> > server.
> > 
> > In SIP things get a bit more complicated, since it is common that a 
> > SIP
> > request traverses several proxies, where theoretically each 
> proxy could 
> > demand credentials. It is also valid that each SIP proxy requests 
> > credentials for the same or different realms than other SIP proxies.
> > 
> > In other words, a SIP proxy can receive a SIP request that contain
> > several Proxy-Authorization header fieldss. Each header field will 
> > contain the credentials for a particular realm.
> > 
> > So let's assume that one of this proxies receives a request that
> > contains several Proxy-Authorization headers. Which one 
> should the SIP 
> > proxy put into the Radius/Diameter message and send it to the 
> > Radius/Diameter server?
> 
> Thanks for the explanation. The situation is clearer to me
> now.
> 
> > a) Put blindly everything, I mean, all the Proxy-Authorization 
> > headers.
> > Repeat attributes (Radius will give us a problem since 
> attributes are 
> > not grouped).
> 
> I see the problem.
> 
> > b) Extract the credentials that are of interested (according to the
> > realm) of the SIP server and RADIUS/Diameter server. This 
> requires to 
> > configure the SIP server with the realm it is serving, but 
> it has some 
> > benefits: first the Radius/Diameter message contains one set of 
> > credentials (no poblems with Radius); second, it allows the 
> > Radius/Diameter server to be authenticating several realms, 
> so there is 
> > no uncertainity because there is only one set of credentials in the 
> > message.
> > 
> > Therefore, we proposed to clarify all this issue and 
> describe the need
> > to configure the SIP server with the realm it is serving. 
> This allows 
> > the server to select the appropriate credentials.
> 
> This sounds reasonable, and my original worry turned out
> to be a non-issue. (I worried that this might somehow
> limit what the user's realm might be. But the client's
> header includes both the username, which might of the
> form jari@domain, and the challenging proxy's realm.
> Only the latter is used in matching what gets sent to
> the AAA server. In conclusion I could be jari@domain1
> when traversing through three proxies that challenge
> me using realms domain2, domain3, and domain4, and
> a single AAA server could handle all of 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: Wed, 24 Nov 2004 20:12:38 +0000
Date: Wed, 24 Nov 2004 22:10:30 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Joel M. Halpern" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: draft-ietf-geopriv-radius-lo-01.txt - CDMA operator-name prefix

Jari Arkko wrote:

> The GSM prefix appears to have the same issue. I know
> there are GSM operator codes (MNCs) but the document
> does not refer to them, but some notion of a text based
> identity. I'm not sure if the GSMA is keeping a registry
> of the text based identities as well. In any case a
> reference to the registry/allocation responsible would
> be needed.

I did some further digging... there *is* a TADIG naming system
for all operators, see:

   http://www.gsmworld.com/about/structure/tadig.shtml

Its defined by GSMA. But I'm still searching for a good reference
that could be put to the document, however.

--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, 24 Nov 2004 19:37:25 +0000
Date: Wed, 24 Nov 2004 21:35:22 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Joel M. Halpern" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: draft-ietf-geopriv-radius-lo-01.txt - registry of operator  name prefixes?

Joel M. Halpern wrote:
> Description of issue: operator name prefix space must be properly defined
> Submitter name: Joel M. Halpern
> Submitter email address: [email-masked]
> Date first submitted: 18-November-2004
> Reference:
> Document: draft-ietf-geopriv-radius-lo-01.txt
> Comment type: T
> Priority: 1
> Section: 5.1 & 11
> Rationale/Explanation of issue:  Operator-prefixes are defined.  
> Creation rules and a registry must be defined
> Length description of problem:
>     Section 5.1 states that only the listed operator name prefixes may 
> be used. It then states that other operator name prefixes may come into 
> existence.  Thus, it is creating a registry, presumably with some 
> expectation on rules for how prefixes get into that registry.
>     However, the IANA considerations section (11) does not even mention 
> the three allocated values.  No section describes how new values may be 
> created, or what rules such new values must abide by.
> 
> Requested change:
>     The document should properly define the registry it is creating.

Agreed.

--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, 24 Nov 2004 19:36:55 +0000
Date: Wed, 24 Nov 2004 21:34:37 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Joel M. Halpern" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: draft-ietf-geopriv-radius-lo-01.txt - CDMA operator-name prefix

Joel M. Halpern wrote:
> Description of issue: Operator-Name prefix defined without usage
> Submitter name: Joel M. Halpern
> Submitter email address: [email-masked]
> Date first submitted: 18-November-2004
> Reference:
> Document: draft-ietf-geopriv-radius-lo-01.txt
> Comment type: T
> Priority: 2
> Section: 5.1
> Rationale/Explanation of issue:  The operator prefix CDMA is defined, 
> but never user
> Length description of problem:
>     The CDMA operator-name prefix is listed as a valid prefix in section 
> 5.1.  However, no definition is included as to what names may use such a 
> prefix or how they should use it.
> 
> Requested change:
>     Either describe who allocates "CDMA" operator names, and how such 
> names are allocated, ore remove the name

The GSM prefix appears to have the same issue. I know
there are GSM operator codes (MNCs) but the document
does not refer to them, but some notion of a text based
identity. I'm not sure if the GSMA is keeping a registry
of the text based identities as well. In any case a
reference to the registry/allocation responsible would
be needed.

The REALM prefix is the only one that does not have an
issue, although I'm not sure the text for that is
100% accurate either. How about

   REALM can be used by any domain name acquired from IANA.

=>

   The right to use of REALM with a specific name is
   obtained coincident with acquiring the rights to use the
   particular Fully Qualified Domain Name (FQDN). Using
   a REALM name without ownership of the supplied FQDN
   creates the possibility of conflict and is therefore
   discouraged.

--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, 24 Nov 2004 18:30:32 +0000
Date: Wed, 24 Nov 2004 10:09:45 -0800
To: [email-masked]
From: Jun Wang <[email-masked]>
Subject: Sterman Issue#8 and Some Other Issues
Cc: ac Mahendran <[email-masked]>

Hi folks,

The following comments and questions are related to issue #8 and some other 
new issues.

1) The title of Issue #8 indicates that "Rspauth generation not possible if 
RADIUS server chooses nonces and qop=auth-int"

This issue exists regardless of whether the RADIUS Server or Client chooses 
the nonces. We think the current approach proposed by Wolfgang can apply 
for both cases.

2) Section 2.19 (Digest-HA1 attribute) first paragraph states:

"If this attribute is present, the RADIUS server did not accept the nonce 
value."

This statement seems incorrect. It should be replaced with: "This attribute 
holds H(A1) as described in RFC2617 to be used for constructing the 
Authentication-Info header by the RADIUS client."

3) There several places (like sections 2.19, 3.1, and 3.2) which state 
something like: ".... MUST NOT...., unless....".   We think it will be 
better to reword the sentences along the lines provided in the examples below.

a) Section 2.19 under string definition, states the following:

"If the 'algorithm' directive's value is 'MD5' or 'AKAv1-MD5', the 
Digest-HA1 attribute MUST NOT be sent by the RADIUS server or processed by 
the RADIUS client, unless the authenticity and integrity of the 
Access-Accept message was secured by cryptographic or equivalently secure 
means."

We can replace the above text to:

If the 'algorithm' directive's value is 'MD5' or 'AKAv1-MD5', and the 
authenticity and integrity of the Access-Accept message was not secured by 
cryptographic or equivalent secure means, the Digest-HA1 attribute MUST NOT 
be sent by the RADIUS server or processed by the RADIUS client.

b) Text in Sections 3.1 and 3.2 states:

"If the Digest-Qop attribute's value is 'auth-int' and the Digest-Algorithm 
attribute's value is 'MD5' or 'AKAv1-MD5', the RADIUS client MUST NOT use 
the Digest-HA1 attribute, unless it knows for sure that the Access-Accept 
message was encrypted or otherwise protected against eavesdropping".

We can replace the above text to:

The RADIUS client MUST NOT use the Digest-HA1 attribute if all of the 
following conditions are true:
- The Digest-Qop attribute's value is 'auth-int';
- The Digest-Algorithm attribute's value is 'MD5' or 'AKAv1-MD5'; and
- The authenticity and integrity of the Access-Accept message was not 
secured by cryptographic or other equivalent secure means.

4) Section  2.4 (Digest-Response-Auth attribute) states:

"This attribute is only used in Access-Accept messages if the RADIUS server 
is configured to choose nonces."

Why is this attribute not applicable when RADIUS client chooses nonces? It 
seems that this attribute is needed as long as the mutual authentication is 
performed (see section 3.2.3 of RFC 2617.)

5) This comment is applicable to all attributes in Section 2. All attribute 
definitions should clearly specify in which RADIUS messages (Access 
Request, Access Accept, Access-Challenge, Access-Reject) these are valid.

For example, section 2.9 only mentions Access Accept message. However, the 
Digest-Algorithm attribute can also be present in Access-Challenge message.

6) The definition of Digest-Stale attribute in Section 2.18 is not clear. 
It should be clarified as follows:

2.18  Digest-Stale attribute

This attribute indicates whether the RADIUS server accepted the nonce value 
received from the RADIUS client.

Type
          DIG-STALE

Length
          3

String
          The string consists of a single character.  If the nonce 
presented by the RADIUS client was stale, the character is '1' and is '0' 
otherwise.  If the RADIUS sever does not accept the nonce received in 
Access Request message but authentication was successful, the RADIUS server 
MUST include this attribute in Access Accept message and set it to '1'; the 
RADIUS server MUST also set the 'next-nonce' attribute in the Access-Accept 
message to the valid nonce-value.

7) In Section 3.1, the text on Digest-Stale attribute is not clear. It 
should be clarified as follows:

If the RADIUS client receives an Access-Accept message from the RADIUS 
Server with the Digest-Stale attribute set to '1', the RADIUS client sends 
an error (401 or 407) response to the HTTP-style client containing 
WWW-/Proxy-Authenticate header with the stale flag set to "TRUE and the 
nonce value set to the 'next-nonce' value received in the Access-Accept 
message.

8) The following RADIUS Server procedure should be added to section 3.2:

If the RADIUS sever does not accept the nonce received in Access Request 
message but authentication was successful, the RADIUS server MUST include 
this attribute in Access Accept message and set it to '1'; the RADIUS 
server MUST also set the 'next-nonce' attribute in the Access-Accept 
message to the valid nonce-value.

9) More general question related to comments 6), 7) & 8) above. 
The  current text assumes that if the nonce is stale and authentication is 
successful, the RADIUS server will indicate it to the RADIUS client using 
Access-Accept message. Shouldn't this be indicated in Access-Challenge 
message? So, Access-Accept messages should be sent only when nonce is valid 
and authentication is successful. For any other purpose, Access-Challenge 
or Access-Reject should be used.

Thanks,
Jun

--
to unsubscribe send a message 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, 24 Nov 2004 16:23:41 +0000
From: Avi Lior <[email-masked]>
To: 'Jari Arkko' <[email-masked]>, [email-masked],  "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [AAA-WG]: Reconciling Radius/Diameter SIP application
Date: Wed, 24 Nov 2004 11:23:32 -0500

Miguel, Wolfgang and Jari,

I am trying to get a deeper understanding here. But it seems to me that in
Scenario 1 where the RADIUS Client is generating the nonces, the client
really needs to be the one that determines the staleness of the nonces and
not the AAA.  Therefore, the client will not even invoke the AAA server when
the nonce is stale; and the AAA will just assume that all nonces are valid.

> > 8- In the Radius document, scenario 1, we have a question. 
> We suspect 
> > that this scenario does not work if the Radius client generates a 
> > nextnonce. The reason is that in the following authentication, when 
> > the nextnonce becomes a nonce, the Radius server will not recognize 
> > the nonce as locally generated (it was generated by the Radius 
> > client), and will reject the request with a "state=true". RFC 2617 
> > seems to describe the case:
> > 
> >    If the
> >    nextnonce field is present the client SHOULD use it when 
> constructing
> >    the Authorization header for its next request. Failure 
> of the client
> >    to do so may result in a request to re-authenticate from 
> the server
> >    with the "stale=TRUE".
> > 
> > Does anyone have any comment? Can anyone confirm that the 
> operation in
> > Digest is as we indicate? We will add some text indicating the 
> > limitations of Scenario 1.
> 
> In looking at this, I have the same question as you. So no
> help from me, sorry.
> 
> > 9- The Radius draft, in section 2.15, indicates:
> > 
> >          RADIUS
> >          servers that do not implement a parameter contained in a
> >          Digest-Auth-Param attribute MUST respond with an 
> Access-Reject
> >          message.  RADIUS clients that do not implement a parameter
> >          contained in a Digest-Auth-Param attribute MUST reject the
> >          original HTTP-style request.
> > 
> > The problem is that the text seems to go against RFC 2617 that says:
> > 
> >    auth-param
> >      This directive allows for future extensions. Any unrecognized
> >      directive MUST be ignored.
> > 
> > The proposal is to remove the above text from the RADIUS draft.
> 
> Yes, this is correct.
> 
> > 10- Similar contradictory text was found in Section 2.16 of 
> the RADIUS
> > draft, that says:
> > 
> >   RADIUS servers that do
> >   not implement AKA Digest MUST response with an Access Reject
> >   message.
> > 
> > We propose to remove the above text. The motivation is that the
> > algorithm already conveys the AKA (AKA extends the algorithm to be 
> > AKAv1-MD5 and AKAv1-MD5-sess). The server chooses the 
> algorithm, so the 
> > situation currently described, where the client may include an auts 
> > attribute, is just an error case, where the client made a 
> mistake and 
> > included AUTS when not doing AKA. In case the Radius server 
> does not 
> > implement AKA authentication, it will safely ignore this AVP.
> 
> Right.
> 
> > 11- We noticed that most of the HTTP Digest directives 
> contain just a
> > single token. However, the "qop" directive may contain a 
> comma-separated 
> > collection of tokens. For instance, qop="auth,auth-int". 
> The question is 
> > how do encode these tokens in the Digest-Qop attribute. The 
> options are:
> > 
> > a) Treat the whole thing as one token and put it into the attribute 
> > value.
> > b) Each token is an attribute, thus, there might be 
> multiple Digest-Qop 
> > attributes in a particular Radius/Diameter message.
> > 
> > We think that option b) is cleaner. Particularly it will be 
> easier for
> > the Diameter/Radius client to encode different values in different 
> > attributes.
> 
> I think option a) is cleaner, although I don't care enough to 
> think it should be a showstopper. But here's my reasoning: 
> avoid unnecessary mapping work that the client needs to do; 
> handle everything as much as possible by taking all text from 
> the SIP syntax and putting it blindly into an AVP...
> 
> --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, 24 Nov 2004 16:15:38 +0000
From: Avi Lior <[email-masked]>
To: 'Miguel Garcia' <[email-masked]>, Jari Arkko <[email-masked]>
Cc: "Beck01, Wolfgang" <[email-masked]>, AAA mailing list <[email-masked]>, [email-masked]
Subject: RE: [AAA-WG]: Reconciling Radius/Diameter SIP application
Date: Wed, 24 Nov 2004 11:15:15 -0500

Option b) is cleaner because it requires less parsing work by AAA server.

Regarding the following comment:

> handle everything 
> as much as 
> > possible by taking all text from the SIP syntax and putting 
> it blindly 
> > into an AVP...

Wolfgang's original document did that for all the attributes (using
subtypes) which could have been handled by both RADIUS and Diameter. Lets
not go there again.

> > 
> >> 11- We noticed that most of the HTTP Digest directives 
> contain just a
> >> single token. However, the "qop" directive may contain a 
> >> comma-separated collection of tokens. For instance, 
> >> qop="auth,auth-int". The question is how do encode these 
> tokens in the 
> >> Digest-Qop attribute. The options are:
> >>
> >> a) Treat the whole thing as one token and put it into the attribute
> >> value.
> >> b) Each token is an attribute, thus, there might be multiple 
> >> Digest-Qop attributes in a particular Radius/Diameter message.
> >>
> >> We think that option b) is cleaner. Particularly it will be easier 
> >> for
> >> the Diameter/Radius client to encode different values in different 
> >> attributes.
> > 
> > 
> > I think option a) is cleaner, although I don't care enough 
> to think it 
> > should be a showstopper. But here's my reasoning: avoid unnecessary 
> > mapping work that the client needs to do; handle everything 
> as much as 
> > possible by taking all text from the SIP syntax and putting 
> it blindly 
> > into an AVP...
> > 
> 
> I don't care either. I just thought we shouldn't put too much work to 
> the Diameter/Radius server about how to encode Digest directives. 
> Approach a requires the Diameter/Radius server to be able to encode 
> "auth", "aut-int", "auth,auth-int", and use it appropriately. If the 
> number of tokens is just two, then any approach is feasible.
> 
> - Miguel
> 
> 
> > --Jari
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland
> 

--
to unsubscribe send a message 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, 24 Nov 2004 15:26:20 +0000
From: Avi Lior <[email-masked]>
To: 'Jari Arkko' <[email-masked]>, Miguel Garcia <[email-masked]>, "Beck01, Wolfgang" <[email-masked]>
Cc: AAA mailing list <[email-masked]>, [email-masked]
Subject: RE: [AAA-WG]: Reconciling Radius/Diameter SIP application
Date: Wed, 24 Nov 2004 10:26:01 -0500

Hi Miquel, Jarri,

> > 3- Radius does not define UTF8String data types, so all these 
> > attributes
> > will remain as String, but the Radius draft will indicate 
> that contain a
> > UTF8String verbally (this is required by HTTP and SIP).

Just one point now.  RADIUS "Text" type attributes are UTF-8 compliant.  I
just want to make sure that the definition of Text and UTF8String are the
same. And they appear to be.

>From RFC 2865:

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.

[7]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
         2279, January 1998.

>From RFC 3588:

This is a human readable string represented using the
      ISO/IEC IS 10646-1 character set, encoded as an OctetString using
      the UTF-8 [UFT8] transformation format described in RFC 2279.

So where applicable the attributes in Sterman should be set to Text.

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

Delivery-date: Wed, 24 Nov 2004 14:13:14 +0000
Date: Wed, 24 Nov 2004 16:11:09 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Beck01, Wolfgang" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, Miguel Garcia <[email-masked]>
Subject: Re: issues in 11 and 12 in the sterman draft

There's one more additional thing. Is Section 4 the final result
or will it be modified based on your agreement with Miguel? The
table below still has some mapping for the translation agent.
I think we should be able to do it completely without any
AVP mapping. But I don't dig into this deeper if you say Section
4 is still being worked on.

>  +-------------------------+-----------------------------------------+
>  | RADIUS                  | Diameter                                |
>  +-------------------------+-----------------------------------------+
>  | Digest-Realm            | Digest-Realm                            |
>  |                         |                                         |
>  | Digest-Nonce            | Digest-Nonce                            |
>  |                         |                                         |
>  | Digest-URI              | Digest-URI                              |
>  |                         |                                         |
>  | Digest-Domain           | Digest-Domain                           |
>  |                         |                                         |
>  | Digest-QoP              | Digest-Qop                              |
>  |                         |                                         |
>  | Digest-Algorithm        | Digest-Algorithm                        |
>  |                         |                                         |
>  | Digest-CNonce           | Digest-Cnonce                           |
>  |                         |                                         |
>  | Digest-Nonce-Count      | Digest-Nonce-Count                      |
>  |                         |                                         |
>  | Digest-Method           | SIP-Method AVP                          |
>  |                         |                                         |
>  | Digest-Username         | Digest-Username AVP                     |
>  |                         |                                         |
>  | Digest-Entity-Body-Hash | SIP-Entity-Body-Hash AVP                |
>  |                         |                                         |
>  | Digest-Response         | SIP-Authorization Digest-Response       |
>  |                         |                                         |
>  | Digest-Response-Auth    | SIP-Authentication-Info Digest-Response |
>  |                         |                                         |
>  | Digest-Opaque           | Digest-Opaque AVP                       |
>  |                         |                                         |
>  | Digest-Auth-Param       | Digest-Auth-Param                       |
>  |                         |                                         |
>  | Digest-AKA-Auts         | Digest-AKA-Auts                         |
>  |                         |                                         |
>  | Digest-Stale            | Digest-Stale AVP                        |
>  +-------------------------+-----------------------------------------+

--
to unsubscribe send a message 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, 24 Nov 2004 14:10:55 +0000
Date: Wed, 24 Nov 2004 16:08:49 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Beck01, Wolfgang" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: radius-sip nits

radius-sip nits
Submitter name: Jari Arkko
Submitter email address: [email-masked]
Date first submitted: Nov 24th, 2004
Reference:
Document: radius-sip
Comment type: E
Priority: 2
Section: Multiple
Rationale/Explanation of issue:

>    proprietary (ie costly) extensions.  Operators are therefore

s/(ie costly)//

> 2.16  Digest-AKA-Auts attribute
> 
>    This attribute holds the auts parameter that is used in the AKA
>    Digest ([RFC3310]) calculation.
> 
>    ...
> 
> 11.2  Informative References
> 
>    ... 
> 
>    [RFC3310]  Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer
>               Protocol (HTTP) Digest Authentication Using Authentication
>               and Key Agreement (AKA)", RFC 3310, September 2002.

This looks more like a normative reference to me.

>       Digest-Realm (DIG-REALM) = "examplecom"

Is the realm style in digest this, or is there a dot
missing?

--
to unsubscribe send a message 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, 24 Nov 2004 14:08:35 +0000
Date: Wed, 24 Nov 2004 16:06:26 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Beck01, Wolfgang" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: issues in 11 and 12 in the sterman draft

I am happy with the resolutions of everything in
these issues, except for two parts:

(1) My understanding is that there's still
one version of at least of the AAA draft and maybe
of both drafts coming due to the attribute merge.
This was part of issue 11, so I'd like to check
the results when the final text is available.

(2) I think we didn't end the discussion on:

     Jari wrote:

     > The choice between the server and client generated
     > nonces: is there some guidance on how the client knows
     > which one to do? if it believes it may have a user that
     > does Digest AKA then it should do use the server generated
     > scheme? But how would it know this in a roaming case?

     Wolfgang wrote:

     > If you are expecting AKA users, you have to use server
     > generated nonces.

     Jari wrote:

     > I guess my question was how do you know you are expecting
     > AKA users. Is there a fallback in case we were NOT expecting
     > them but one showed up because our roaming partner started
     > supporting AKA yesterday?

     (Or am I missing an e-mail?) I also looked through the draft
     but did not spot text that deals with this. Can we provide
     a server-generated error that says "please try again without
     generating your own nonce"? Or is it too late if some message
     has already been sent to the user at this point?

--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, 24 Nov 2004 13:39:52 +0000
Date: Wed, 24 Nov 2004 15:37:22 +0200
From: Jari Arkko <[email-masked]>
Organization: None
To: [email-masked]
Subject: Re: [AAA-WG]: Reconciling Radius/Diameter SIP application

Miguel Garcia wrote:

> I am deliberately cross posting to AAA and Radius-ext because I believe 
> this topic is of interest for both lists.
> 
> Yesterday Wolfgang and me met for a few hours and set the goal of 
> reconcile the Diameter SIP application and the RADIUS HTTP/SIP Digest 
> drafts. These are the drafts:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-04.txt
> 
> http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt
> 
> These are the main points we discuss. If you have any comments, speak up 
> now, otherwise we will do the proposed changes in the relevant drafts:
> 
> 1- We agreed to modify the Diameter SIP application so that it imports 
> the Digest-* AVP from the corresponding RADIUS attributes address space.
> This came out of a comment from Jari Arkko, and I think it is important 
> to avoid duplication of AVP/attributes.
> 
> As a side effect of the above, the SIP-Authentication-Context will 
> disappear in Diameter SIP app. This was a grouped AVP that only 
> contained a Digest-Entity-Body-Hash AVP. The latter will remain (in the 
> RADIUS draft).

Great!

> 2- We noticed a divergence in the Digest-Expected-Response AVP in 
> Diameter, which does not exist in RADIUS. RADIUS defines a Digest-HA1 
> attribute. The difference: Digest-HA1 contains H(A1), which is computed 
> at the Radius server and sent to the Radius client, and it is used to 
> compute the expected response. In Diameter, the expected response is 
> computed at the Diameter server and sent to the client. This assumes a 
> secure connection to avoid eavesdropping, which is not a problem for 
> Diameter that mandates IPsec or TLS. I think Diameter can go for the 
> Radius approach for compatibility reasons.
> 
> Proposal: Diameter will remove Digest-Expected-Response AVP and will 
> import Digest-HA1 from Radius.

Ok.

> 3- Radius does not define UTF8String data types, so all these attributes 
> will remain as String, but the Radius draft will indicate that contain a
> UTF8String verbally (this is required by HTTP and SIP).

Hm, I guess this is OK.

> 4- Currently here is a divergence on the definition of Digest-Stale 
> attribute: Diameter uses "true" and "false" (as per RFC2617), Radius 
> uses 1 and 0. We agreed to use "true" and "false" to avoid stupid 
> transcodings.

This is much better. Good.

> 5- Diameter indicates that the Digest-* AVPs contain the quotes from/to 
> the Digest directive, Radius assumes (although does not indicate) no 
> quotes. We agreed that the Digest-* attributes do not need to include 
> the quotes from HTTP Digest parameters. So, there will be an explicit 
> indication that quotes are not part of the attribute value.

This is better too.

> 6- We run into a problem when multiple SIP proxies are authenticating
> the user, because at some point in time the SIP request may contain
> several Proxy-Authorization headers. The key here is the realm, it
> will be always different. If different Diameter/Radius servers are 
> serving different realms, there is not problem. But, if a common 
> Diameter/Radius server is serving different realms, then the server is 
> not able to determine which credentials should be evaluated.
> 
> We propose that the Diameter/Radius client MUST send only one set of 
> credentials at a time, those belonging to the served realm. This 
> requires to configure the Diameter/Radius client with the realm it is 
> serving. We will include some text indicating this case.

I fail to see the problem, most likely due to the insufficient
understanding of the protocol details on my part. But will
your solution lead to some problem if there's roaming
involved?

> 7- Some of the attributes (e.g, Digest-Response and
> Digest-Response-Auth) had an artificial limit of 32 octets in the
> value. While this value is correct for MD5 hashes, if in the future
> other hashes are added to HTTP Digest, will run into
> trouble. Proposal: don't restrict the length of a value.

Right.

> 8- In the Radius document, scenario 1, we have a question. We suspect
> that this scenario does not work if the Radius client generates a
> nextnonce. The reason is that in the following authentication, when the
> nextnonce becomes a nonce, the Radius server will not recognize the
> nonce as locally generated (it was generated by the Radius client), and 
> will reject the request with a "state=true". RFC 2617 seems to describe 
> the case:
> 
>    If the
>    nextnonce field is present the client SHOULD use it when constructing
>    the Authorization header for its next request. Failure of the client
>    to do so may result in a request to re-authenticate from the server
>    with the "stale=TRUE".
> 
> Does anyone have any comment? Can anyone confirm that the operation in 
> Digest is as we indicate? We will add some text indicating the 
> limitations of Scenario 1.

In looking at this, I have the same question as you. So no
help from me, sorry.

> 9- The Radius draft, in section 2.15, indicates:
> 
>          RADIUS
>          servers that do not implement a parameter contained in a
>          Digest-Auth-Param attribute MUST respond with an Access-Reject
>          message.  RADIUS clients that do not implement a parameter
>          contained in a Digest-Auth-Param attribute MUST reject the
>          original HTTP-style request.
> 
> The problem is that the text seems to go against RFC 2617 that says:
> 
>    auth-param
>      This directive allows for future extensions. Any unrecognized
>      directive MUST be ignored.
> 
> The proposal is to remove the above text from the RADIUS draft.

Yes, this is correct.

> 10- Similar contradictory text was found in Section 2.16 of the RADIUS 
> draft, that says:
> 
>   RADIUS servers that do
>   not implement AKA Digest MUST response with an Access Reject
>   message.
> 
> We propose to remove the above text. The motivation is that the 
> algorithm already conveys the AKA (AKA extends the algorithm to be 
> AKAv1-MD5 and AKAv1-MD5-sess). The server chooses the algorithm, so the 
> situation currently described, where the client may include an auts 
> attribute, is just an error case, where the client made a mistake and 
> included AUTS when not doing AKA. In case the Radius server does not 
> implement AKA authentication, it will safely ignore this AVP.

Right.

> 11- We noticed that most of the HTTP Digest directives contain just a 
> single token. However, the "qop" directive may contain a comma-separated 
> collection of tokens. For instance, qop="auth,auth-int". The question is 
> how do encode these tokens in the Digest-Qop attribute. The options are:
> 
> a) Treat the whole thing as one token and put it into the attribute value.
> b) Each token is an attribute, thus, there might be multiple Digest-Qop 
> attributes in a particular Radius/Diameter message.
> 
> We think that option b) is cleaner. Particularly it will be easier for 
> the Diameter/Radius client to encode different values in different 
> attributes.

I think option a) is cleaner, although I don't care enough to
think it should be a showstopper. But here's my reasoning:
avoid unnecessary mapping work that the client needs to do;
handle everything as much as possible by taking all text
from the SIP syntax and putting it blindly into an AVP...

--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, 22 Nov 2004 22:51:16 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: [Sterman Issue 7] Message Authenticator:  Options
Date: Mon, 22 Nov 2004 17:50:45 -0500

Glen,

I hope the answer is no. That is, when there are security issues we should
fix tehm - charter or not charter.

So far however, Message-Authenticator has not been shown to be compromized.

And apparently there is still some question on whether or not the ease of
generating MD5 collisions is a parctical RADIUS attack.

--
to unsubscribe send a message 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, 22 Nov 2004 22:43:39 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [Sterman Issue 7] Message Authenticator:  Options
Date: Mon, 22 Nov 2004 14:43:27 -0800

Avi Lior <> wrote:

...

>> Also, should RADIUS Digest go through unmodified, standard RADIUS
>> proxies? If so, how would they be aware of a new AVP that they
need
>> to process?
> 
> Yes that would be a problem.  They wouldn't be aware of it. So
there
> is that issue as well. 

So, does this mean that as far as the IETF is concerned RADIUS
security is good enough, forever (I assume that this reasoning was
at least in part behind the injunction against 'new security
methods' in the charter)?

~gwz

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

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

Delivery-date: Mon, 22 Nov 2004 22:32:07 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>, "'Avi Lior'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Progress on RADIUS Extension for Digest Authentication
Date: Mon, 22 Nov 2004 14:31:45 -0800

Jari Arkko <> wrote:
> Avi Lior wrote:
> 
>> Also, if Message-Authenticator is busted or close to being busted
it
>> is busted for EAP as well as Sterman.  So Key Wrap document can
>> basically indicated that Message-Authenticator should be
deprecated
>> and replaced with Key-Wrap. What is wrong with this strartegy?
> 
> Nothing as far as I can see.

It's a fine strategy, as long as it is executed _outside_ this WG
(since it would appear to violate the charter in at least two ways).

> 
> --Jari

Hope this helps,

~gwz

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

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

Delivery-date: Mon, 22 Nov 2004 22:15:30 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: RE: [Sterman Issue 7] Message Authenticator:  Options
Date: Mon, 22 Nov 2004 17:14:56 -0500

Hi Jarri,

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Monday, November 22, 2004 4:44 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: [Sterman Issue 7] Message Authenticator: Options
> 
> 
> Hi Avi,
> 
> I may be missing some background here. [Ok, I confess I have 
> not read all the e-mails in my Inbox :-) ]
> 
> Why is this problem specific to RADIUS Digest draft? I 
> realize that it will have to reference the use of 
> Message-Authenticator. But so do other RADIUS specs. If the 
> use of MD5 is an issue, it would seem to be simpler that the 
> IETF would just do it once and for all in all of RADIUS. 
> Alternatively, start mandating IPsec.

This is a problem for RADIUS in general. The discussion started around the
use of message authenticator for the digest draft.

Mandating Ipsec. Hmmmmm Ipsec could be mandated but I don't see that it will
be used in RADIUS.   
 
> Also, should RADIUS Digest go through unmodified,
> standard RADIUS proxies? If so, how would they be aware of
> a new AVP that they need to process?

Yes that would be a problem.  They wouldn't be aware of it. So there is that
issue as well.

> Finally, if MD5 is bad, wouldn't that be a problem for
> most Digest usage, RADIUS or not, given that the only 
> algorithms supported now are MD5 and AKA? I guess I'm asking 
> what makes the Message-Authenticator usage of MD5 different 
> from other RADIUS usage of MD5 or Digest usage of MD5, both 
> of which have to be relied upon anyway? Or is the issue that 
> the MD5 usage in Message-Authenticator is particularly vulnerable?

It seems that everyone thinks MD5 is bad.

But note that in fact Message-Authenticator (is HMAC-MD5 based) and is *not*
vunerable  (as I understand it).

MD5 is vunerable in that we can easily create collisions.  But as Chiba
pointed out, 

"From what I understand, having an easy way to generate collisions does 
not mean that it will be easy to create valid RADIUS packets that result 
in the collision hash."

Not being a security expert, I would be interested to see analysis if it is
feasable to apply the MD5 attacks to RADIUS messages.

--
to unsubscribe send a message 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, 22 Nov 2004 21:54:57 +0000
Date: Mon, 22 Nov 2004 23:52:42 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: Re: Progress on RADIUS Extension for Digest Authentication

Avi Lior wrote:

> Also, if Message-Authenticator is busted or close to being busted it is
> busted for EAP as well as Sterman.  So Key Wrap document can basically
> indicated that Message-Authenticator should be deprecated and replaced with
> Key-Wrap. What is wrong with this strartegy?

Nothing as far as I can see.

--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, 22 Nov 2004 21:48:28 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: [Sterman Issue 7] Message Authenticator:  Options
Date: Mon, 22 Nov 2004 16:48:11 -0500

Hi David,

Thanx for the quick repsonse.  I didn't even consider the charter issue.
That will take some time.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Monday, November 22, 2004 4:39 PM
> To: [email-masked]
> Subject: RE: [Sterman Issue 7] Message Authenticator: Options
> 
> 
> Avi Lior writes...
> 
> > -Will keywrap be ready in time?
> > This is important but the authors feel that it is ready to go.
> 
> Keywrap may well be important, to the extent that it 
> successfully addresses NIST certification requirements, but 
> it includes more than just an improved MAC, and would likely 
> require a charter change to be in scope (new RADIUS security 
> methods are currently out of scope).
> 
> I think that Message-Authenticator is probably the way to go 
> for the Sterman draft.  More extensive security enhancements 
> to RADIUS could be optionally applied to digest 
> authentication, as well as any other RADIUS application, when 
> and if they are standardized.
> 
> -- 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/>
> 

--
to unsubscribe send a message 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, 22 Nov 2004 21:46:08 +0000
Date: Mon, 22 Nov 2004 23:44:05 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sterman Issue 7] Message Authenticator:  Options

Hi Avi,

I may be missing some background here. [Ok, I confess I have
not read all the e-mails in my Inbox :-) ]

Why is this problem specific to RADIUS Digest draft? I realize
that it will have to reference the use of Message-Authenticator.
But so do other RADIUS specs. If the use of MD5 is an issue,
it would seem to be simpler that the IETF would just do it once
and for all in all of RADIUS. Alternatively, start mandating
IPsec.

Also, should RADIUS Digest go through unmodified,
standard RADIUS proxies? If so, how would they be aware of
a new AVP that they need to process?

Finally, if MD5 is bad, wouldn't that be a problem for
most Digest usage, RADIUS or not, given that the only
algorithms supported now are MD5 and AKA? I guess I'm
asking what makes the Message-Authenticator usage of
MD5 different from other RADIUS usage of MD5 or Digest
usage of MD5, both of which have to be relied upon anyway?
Or is the issue that the MD5 usage in Message-Authenticator
is particularly vulnerable?

--Jari

Avi Lior wrote:
> Hi folks,
> We would like to get closure on the issue of the use of Message
> Authenticator for draft-sterman-aaa-sip-04.
> 
> Everyone seems to agree that we need to use some sort of RADIUS Message
> Authenticator.
> 
> There was a discussion on the strength of HMAC-MD5.  Some suggested that we
> should stregthen the RADIUS Message-Authenticator to HMAC-SHA1.
> 
> -HMAC-MD5 is not busted (yet).
> -draft-sterman-aaa-sip-04 carries HTTP digest which are based on MD5.
> -draft-sterman-aaa-sip-04 seems to be addressing legacy deployements.
> Recommending that greenfield implementation use Diameter.
> -There is a push to get draft-sterman-aaa-sip-04 out quickly.
> -keywrap proposes a new message authenticator Message-Authentication-Code
> which supports either HMAC-MD5 or MHAC-SHA1 methods.
> 
> Options:
> ========
> 1) Allow draft-sterman-aaa-sip to use Message-Authenticator(80). And when
> keywrap is ready we can state in keywrap that RADIUS implmentation should
> upgrade to Message-Authentication-Code.
> 
> 2) Require draft-sterman-aaa-sip to use Message-Authentication-Code.
> 
> 
> Questions:
> ==========
> 
> -Will IESG accept a new RFC based on HMAC-MD5?
> If not then we don't really have a choice.
> 
> -Will keywrap be ready in time?
> This is important but the authors feel that it is ready to go.  However,
> note that Keywrap allows Message-Authentication-Code to be HMAC-MD5 isn't
> this a problem?
> 
> Your comments and opinion would be appreciated.

--
to unsubscribe send a message 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, 22 Nov 2004 21:45:10 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: [Sterman Issue 7] Message Authenticator:  Options
Date: Mon, 22 Nov 2004 16:44:56 -0500

Hi Glen,

If you allow HMAC-MD5 people will keep using it.  If HMAC-MD5 is an issue,
then in my opinion don't provide that option.

Besides folks already have Message-Authenticator that they can use. 

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]] 
> Sent: Monday, November 22, 2004 4:37 PM
> To: 'Avi Lior'; [email-masked]
> Subject: RE: [Sterman Issue 7] Message Authenticator: Options
> 
> 
> Avi Lior <> wrote:
> 
> > -Will keywrap be ready in time?
> > This is important but the authors feel that it is ready to go.
> > However, note that Keywrap allows Message-Authentication-Code to
> be
> > HMAC-MD5 isn't this a problem?
> 
> The use of HMAC-MD5 is optional and included just for ease of 
> transition.  It is _not_ required by the draft; if you like, 
> we can add text to the Security Considerations section 
> deprecating its use (or even remove it altogether -- I have 
> no problem with that).
> 
> > 
> > Your comments and opinion would be appreciated.
> > 
> > Avi
> 
> Hope this helps,
> 
> ~gwz
> 
> Why is it that most of the world's problems can't be solved by simply
>   listening to John Coltrane? -- Henry Gabriel
> 

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

Delivery-date: Mon, 22 Nov 2004 21:39:03 +0000
Content-class: urn:content-classes:message
Subject: RE: [Sterman Issue 7] Message Authenticator:  Options
Date: Mon, 22 Nov 2004 16:38:46 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> -Will keywrap be ready in time?
> This is important but the authors feel that it is ready to go.=20

Keywrap may well be important, to the extent that it successfully
addresses NIST certification requirements, but it includes more than
just an improved MAC, and would likely require a charter change to be in
scope (new RADIUS security methods are currently out of scope).

I think that Message-Authenticator is probably the way to go for the
Sterman draft.  More extensive security enhancements to RADIUS could be
optionally applied to digest authentication, as well as any other RADIUS
application, when and if they are standardized.

-- 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: Mon, 22 Nov 2004 21:37:31 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, <[email-masked]>
Subject: RE: [Sterman Issue 7] Message Authenticator:  Options
Date: Mon, 22 Nov 2004 13:37:19 -0800

Avi Lior <> wrote:

> -Will keywrap be ready in time?
> This is important but the authors feel that it is ready to go. 
> However, note that Keywrap allows Message-Authentication-Code to
be
> HMAC-MD5 isn't this a problem? 

The use of HMAC-MD5 is optional and included just for ease of
transition.  It is _not_ required by the draft; if you like, we can
add text to the Security Considerations section deprecating its use
(or even remove it altogether -- I have no problem with that).

> 
> Your comments and opinion would be appreciated.
> 
> Avi

Hope this helps,

~gwz

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

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

Delivery-date: Mon, 22 Nov 2004 21:17:10 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Subject: [Sterman Issue 7] Message Authenticator:  Options
Date: Mon, 22 Nov 2004 16:16:33 -0500

Hi folks,
We would like to get closure on the issue of the use of Message
Authenticator for draft-sterman-aaa-sip-04.

Everyone seems to agree that we need to use some sort of RADIUS Message
Authenticator.

There was a discussion on the strength of HMAC-MD5.  Some suggested that we
should stregthen the RADIUS Message-Authenticator to HMAC-SHA1.

-HMAC-MD5 is not busted (yet).
-draft-sterman-aaa-sip-04 carries HTTP digest which are based on MD5.
-draft-sterman-aaa-sip-04 seems to be addressing legacy deployements.
Recommending that greenfield implementation use Diameter.
-There is a push to get draft-sterman-aaa-sip-04 out quickly.
-keywrap proposes a new message authenticator Message-Authentication-Code
which supports either HMAC-MD5 or MHAC-SHA1 methods.

Options:
========
1) Allow draft-sterman-aaa-sip to use Message-Authenticator(80). And when
keywrap is ready we can state in keywrap that RADIUS implmentation should
upgrade to Message-Authentication-Code.

2) Require draft-sterman-aaa-sip to use Message-Authentication-Code.

Questions:
==========

-Will IESG accept a new RFC based on HMAC-MD5?
If not then we don't really have a choice.

-Will keywrap be ready in time?
This is important but the authors feel that it is ready to go.  However,
note that Keywrap allows Message-Authentication-Code to be HMAC-MD5 isn't
this a problem?

Your comments and opinion would be appreciated.

Avi

--
to unsubscribe send a message 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, 22 Nov 2004 16:10:35 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>,  'Bernard Aboba' <[email-masked]>
Cc: [email-masked], 'AC Mahendran' <[email-masked]>
Subject: RE: Progress on RADIUS Extension for Digest Authentication
Date: Mon, 22 Nov 2004 11:10:13 -0500

Glen and all,

I agree, if the keywrap doc is ready we should ask for it to be: a) a
working group item; and b) put it in to working last call ASAP.

As for its use for sterman draft, ideally we should use keywrap for this
document. I am all for that with the caveat that we should not delay
sterman. I don't want to see sterman delayed.  Especially since
Message-Authenticator is not busted. 

Also, if Message-Authenticator is busted or close to being busted it is
busted for EAP as well as Sterman.  So Key Wrap document can basically
indicated that Message-Authenticator should be deprecated and replaced with
Key-Wrap. What is wrong with this strartegy?

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]] 
> Sent: Friday, November 19, 2004 4:07 PM
> To: 'Nelson, David'; 'Avi Lior'; 'Bernard Aboba'
> Cc: [email-masked]; 'AC Mahendran'
> Subject: RE: Progress on RADIUS Extension for Digest Authentication
> 
> 
> Nelson, David <> wrote:
> >> Okay. So lets get this draft into last call right away.
> > 
> > Which draft?  The keywrap draft?  We haven't reached consensus
> that
> > it should be a WG work item yet,
> 
> Has anybody called for consensus from the WG?  It's 
> incredibly difficult to reach something without moving your hand...
> 
> > although Bernard has suggested that
> > it should be, and it seems to address a valid issue (NIST/FIPS
> > approved algorithms).   
> > 
> > Perhaps we ought to follow your earlier suggestion and use the 
> > existing Message-Authenticator Attribute in the Digest
> Authentication
> > draft (as it is a short-term dependency for 3GPP2).  We 
> could then let 
> > the keywrap draft take its course, hopefully eliciting more 
> review and 
> > comment on the list than heretofore.
> 
> I like this plan!  Let's 1) rubberstamp a flawed document, insuring
> 2) either massive upgrades or (more likely) non-action later because
> 3) we can't make a decision on anything of substance in less 
> than 2 years.
>   
> > 
> > -- Dave
> 
> Hope this helps,
> 
> ~gwz
> 
> Why is it that most of the world's problems can't be solved by simply
>   listening to John Coltrane? -- Henry Gabriel
> 

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

Delivery-date: Mon, 22 Nov 2004 15:41:49 +0000
Date: Mon, 22 Nov 2004 07:41:19 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Adoption of CUI as a RADEXT WG Work Item

There appears to be a substantial community of people interested in the
CUI work, so that we have consensus that it should become a RADEXT WG Work
Item.

My suggestion is that the open issues be addressed and that a new
draft-ietf-radext-cui-00.txt be submitted to the archive.

--
to unsubscribe send a message 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, 22 Nov 2004 14:37:16 +0000
Date: Mon, 22 Nov 2004 06:36:44 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Issue: RFC 2486bis - obsoletes or updates?

> Hmm... RFC 2284bis at least had a line in the header that said
> something about obsoleting 2284. Checking for the XML command
> to do this... found from Henrik's 2284 draft... Ok, I'll add it.

Yes.

--
to unsubscribe send a message 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, 22 Nov 2004 12:22:18 +0000
Date: Mon, 22 Nov 2004 14:19:56 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: [email-masked]
Subject: Re: Issue: RFC 2486bis  - PPTP

[email-masked] wrote:

> PPTP is used in the document, but never expanded.
> Expand first instance of PPTP

Done. Thanks. Also added a few informational references
to the terms, and expanded ABNF, EAP and RADIUS where they
first appeared, just in case...

--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, 22 Nov 2004 09:20:47 +0000
Date: Mon, 22 Nov 2004 11:18:27 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: [email-masked]
Subject: Re: Issue: RFC 2486bis - obsoletes or updates?

[email-masked] wrote:

> Abstract says: 
>    This document is a revised version
>    of RFC 2486 which originally defined NAIs. 
> 
> Don't know if 2486 is still valid after this document is published
> 
> Requested change:
> 
> Somewhere it should say if this draft updates or obsoletes RFC2486.

I think it obsoletes RFC 2486. But its unclear to me whether
this needs to be put into a text within the document itself,
or whether its something that the RFC editor adds. I haven't
personally edited a bis draft before, so I have no experience.

Hmm... RFC 2284bis at least had a line in the header that said
something about obsoleting 2284. Checking for the XML command
to do this... found from Henrik's 2284 draft... Ok, I'll add it.

Here's the current revised version:

   http://www.arkko.com/publications/nai/naibis.txt
   http://www.arkko.com/publications/nai/naibisdiff.html

Thanks for reporting this John.

--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, 22 Nov 2004 08:44:50 +0000
content-class: urn:content-classes:message
Subject: Issue: RFC 2486bis  - PPTP
Date: Mon, 22 Nov 2004 10:31:19 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Description of issue
Submitter name: John Loughney
Submitter email address: [email-masked]
Date first submitted: 11/22/2004
Document: RFC2284bis
Comment type: E
Priority: 1=20
Section: Abstract
Rationale/Explanation of issue: no expansion of PPTP
Length description of problem

PPTP is used in the document, but never expanded.

Don't know if 2486 is still valid after this document is published

Requested change:

Expand first instance of PPTP

--
to unsubscribe send a message 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, 22 Nov 2004 08:44:42 +0000
content-class: urn:content-classes:message
Subject: Issue: RFC 2486bis - obsoletes or updates?
Date: Mon, 22 Nov 2004 10:30:17 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Description of issue
Submitter name: John Loughney
Submitter email address: [email-masked]
Date first submitted: 11/22/2004
Document: RFC2284bis
Comment type: E
Priority: 1=20
Section: Abstract
Rationale/Explanation of issue:
Length description of problem

Abstract says:=20
   This document is a revised version
   of RFC 2486 which originally defined NAIs.=20

Don't know if 2486 is still valid after this document is published

Requested change:

Somewhere it should say if this draft updates or obsoletes RFC2486.

--
to unsubscribe send a message 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, 22 Nov 2004 08:44:36 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT WG last call on RFC 2486bis-02
Date: Mon, 22 Nov 2004 10:37:56 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Bernard,

> It has been pointed out that a newer version of this document (-02) =
has
> been submitted,  so that a revised last call announcement is required.

I did a re-review of the draft, found two points to be clarified (the =
2nd point -=20
expanding PPTP might be better solved by having a terminolgy section, =
where
most acronyms are expanded), but no show-stoppers.  If there are no =
significant
other issues, I'd be fine with having my issues addressed during next =
revision,
if there are any AD or IESG comments.

thanks,
John

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

Delivery-date: Mon, 22 Nov 2004 08:06:56 +0000
Date: Mon, 22 Nov 2004 00:05:58 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG last call on RFC 2486bis-02

It has been pointed out that a newer version of this document (-02) has
been submitted,  so that a revised last call announcement is required.

This is an announcement of RADEXT WG Last call on "The Network
Access Identifier" specification, RFC 2486bis, prior to sending the draft
on to the IESG for consideration as an IETF Proposed Standard (recycled).
The document is available for inspection at the following locations:

http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-rfc2486bis-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-02.txt
(should show up here today)

RADEXT WG Last Call will complete on November 30, 2004.  Please send comments
to the RADEXT WG mailing list ([email-masked]), using the issue
format described at:

http://www.drizzle.com/~aboba/RADEXT/

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

Delivery-date: Sat, 20 Nov 2004 06:18:00 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT WG last call on RFC 2486bis
Date: Sat, 20 Nov 2004 08:17:01 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi all,

> 2) Like Pasi, I'm a bit puzzled why we need another LC
> on this document. We already had a last call and all
> issues were resolved, the issue tracker does not show
> anything remaining.

I agree.

John

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

Delivery-date: Fri, 19 Nov 2004 22:09:26 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Nelson, David'" <[email-masked]>
Cc: <[email-masked]>, "'AC Mahendran'" <[email-masked]>
Subject: RE: Progress on RADIUS Extension for Digest Authentication
Date: Fri, 19 Nov 2004 14:09:11 -0800

Nelson, David <> wrote:
> Glen Zorn writes (regarding the keywrap draft)...
> 
>> Has anybody called for consensus from the WG?
> 
> No.  Not so far.
> 
>> I like this plan!  Let's 1) rubberstamp a flawed document,
insuring
>> 2) either massive upgrades or (more likely) non-action later
because
>> 3) we can't make a decision on anything of substance in less than
2
>> years.
> 
> Well, since RADEXT has been in existence for about 4 months, the
> comment about 2 years is probably an exaggeration.  :-) 

I call it wild hyperbole, myself, if I hadn't been referring to the
IETF in general...

> 
> If 3GPP2 can wait for us to do the right thing, I'd prefer that
> approach as well. 

I see no reason to assume that waiting would be necessary: the
document in question has been widely reviewed already, both within
and outside the co-authors' respective companies; the reviewers have
included at least one IESG member.  There can't be _that_ much wrong
with it!  So, if I may be so bold as to suggest a plan of action:

1) Issue a call for consensus on accepting the document as a WG item
today.
2) If consensus is positive, ask the authors to submit a renamed
version of the doc.
3) Upon submission of the revised document, immediately issue WG
Last Call on it (as many people have observed, Last Call is the best
(if not only) way to get people to read a draft anyway) :-(
4) If the key-wrap draft bogs down in any way during LC, just
advance the Digest Auth draft as is; otherwise make the minor
modifications necessary and advance it.

> 
> -- Dave

Hope this helps,

~gwz

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

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

Delivery-date: Fri, 19 Nov 2004 21:39:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Progress on RADIUS Extension for Digest Authentication
Date: Fri, 19 Nov 2004 16:38:46 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "AC Mahendran" <[email-masked]>

Glen Zorn writes (regarding the keywrap draft)...

> Has anybody called for consensus from the WG?

No.  Not so far.

> I like this plan!  Let's 1) rubberstamp a flawed document, insuring
> 2) either massive upgrades or (more likely) non-action later because
> 3) we can't make a decision on anything of substance in less than 2
> years.

Well, since RADEXT has been in existence for about 4 months, the comment
about 2 years is probably an exaggeration.  :-)

If 3GPP2 can wait for us to do the right thing, I'd prefer that approach
as well.

-- 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: Fri, 19 Nov 2004 21:07:02 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, "'Avi Lior'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>, "'AC Mahendran'" <[email-masked]>
Subject: RE: Progress on RADIUS Extension for Digest Authentication
Date: Fri, 19 Nov 2004 13:06:47 -0800

Nelson, David <> wrote:
>> Okay. So lets get this draft into last call right away.
> 
> Which draft?  The keywrap draft?  We haven't reached consensus
that
> it should be a WG work item yet, 

Has anybody called for consensus from the WG?  It's incredibly
difficult to reach something without moving your hand...

> although Bernard has suggested that
> it should be, and it seems to address a valid issue (NIST/FIPS
> approved algorithms).   
> 
> Perhaps we ought to follow your earlier suggestion and use the
> existing Message-Authenticator Attribute in the Digest
Authentication
> draft (as it is a short-term dependency for 3GPP2).  We could then
> let the keywrap draft take its course, hopefully eliciting more
> review and comment on the list than heretofore. 

I like this plan!  Let's 1) rubberstamp a flawed document, insuring
2) either massive upgrades or (more likely) non-action later because
3) we can't make a decision on anything of substance in less than 2
years.
  
> 
> -- Dave

Hope this helps,

~gwz

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

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

Delivery-date: Fri, 19 Nov 2004 20:49:24 +0000
Date: Fri, 19 Nov 2004 21:53:12 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Nelson, David" <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: RADEXT WG last call on RFC 2486bis

Nelson, David wrote:

> I thought we were looking for affirmative acknowledgement from the
> previous commenters that all the issues had been appropriately addressed
> in the revised draft.

As I recall, the three changes in -02 were all minor and
editorial. So far we've used the positive acknowledgment
approach in cases where there's been problems, suspicion
of inadequate review, or something else abnormal. If we
don't suspect these problems it might be more efficient
to just move forward; the issue submitters either responded
positively already or at least they've had quite some time
to look at our proposed text... How about at least making
the period shorter, say a week? I think we have some other
work which has bigger issues, lets get this thing out of
the way so that we can concentrate on the other stuff.

--Jari

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

Delivery-date: Fri, 19 Nov 2004 20:33:27 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>, Bernard Aboba <[email-masked]>,  "Glen Zorn (gwz)" <[email-masked]>
Cc: [email-masked], AC Mahendran <[email-masked]>
Subject: RE: Progress on RADIUS Extension for Digest Authentication
Date: Fri, 19 Nov 2004 15:17:07 -0500

Yes it would be the keywrap. 

So I would prefer to do it right but as time constraints have it.... 

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Friday, November 19, 2004 2:28 PM
> To: Avi Lior; Bernard Aboba; Glen Zorn (gwz)
> Cc: [email-masked]; AC Mahendran
> Subject: RE: Progress on RADIUS Extension for Digest Authentication
> 
> 
> > Okay. So lets get this draft into last call right away.
> 
> Which draft?  The keywrap draft?  We haven't reached 
> consensus that it should be a WG work item yet, although 
> Bernard has suggested that it should be, and it seems to 
> address a valid issue (NIST/FIPS approved algorithms).
> 
> Perhaps we ought to follow your earlier suggestion and use 
> the existing Message-Authenticator Attribute in the Digest 
> Authentication draft (as it is a short-term dependency for 
> 3GPP2).  We could then let the keywrap draft take its course, 
> hopefully eliciting more review and comment on the list than 
> heretofore.
> 
> -- 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: Fri, 19 Nov 2004 20:24:44 +0000
From: "Kuntal Chowdhury" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: CUI: WG Work Item
Date: Fri, 19 Nov 2004 14:55:58 -0500

--
to unsubscribe send a message 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, 19 Nov 2004 19:47:34 +0000
Reply-To: <[email-masked]>
From: "Ed Van Horne \(evh\)" <[email-masked]>
To: <[email-masked]>
Subject: CUI: WG Work Item
Date: Fri, 19 Nov 2004 11:47:20 -0800

--
to unsubscribe send a message 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, 19 Nov 2004 19:31:32 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG last call on RFC 2486bis
Date: Fri, 19 Nov 2004 14:30:29 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

> 2) Like Pasi, I'm a bit puzzled why we need another LC
> on this document. We already had a last call and all
> issues were resolved, the issue tracker does not show
> anything remaining.

I thought we were looking for affirmative acknowledgement from the
previous commenters that all the issues had been appropriately addressed
in the revised draft.

-- 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: Fri, 19 Nov 2004 19:28:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Progress on RADIUS Extension for Digest Authentication
Date: Fri, 19 Nov 2004 14:27:48 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Bernard Aboba" <[email-masked]>, "Glen Zorn \(gwz\)" <[email-masked]>
Cc: <[email-masked]>, "AC Mahendran" <[email-masked]>

> Okay. So lets get this draft into last call right away.

Which draft?  The keywrap draft?  We haven't reached consensus that it
should be a WG work item yet, although Bernard has suggested that it
should be, and it seems to address a valid issue (NIST/FIPS approved
algorithms).

Perhaps we ought to follow your earlier suggestion and use the existing
Message-Authenticator Attribute in the Digest Authentication draft (as
it is a short-term dependency for 3GPP2).  We could then let the keywrap
draft take its course, hopefully eliciting more review and comment on
the list than heretofore.

-- 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: Fri, 19 Nov 2004 19:26:46 +0000
Date: Fri, 19 Nov 2004 21:24:34 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: RADEXT WG last call on RFC 2486bis

1) The correct draft version is -02, not -01. I posted
the pointer to the new version earlier to the list but did not
submit until today. Here are the pointers until it appears:

   http://www.arkko.com/publications/nai/draft-ietf-radext-rfc2486bis-02.txt
   http://www.arkko.com/publications/nai/draft-ietf-radext-rfc2486bis-02diff.html

2) Like Pasi, I'm a bit puzzled why we need another LC
on this document. We already had a last call and all
issues were resolved, the issue tracker does not show
anything remaining.

--Jari

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

Delivery-date: Fri, 19 Nov 2004 18:18:48 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: CUI: WG Work Item
Date: Fri, 19 Nov 2004 19:18:16 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4CE64.23D3F4A2
Content-Type: text/plain

------_=_NextPart_001_01C4CE64.23D3F4A2
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.2">
<TITLE>CUI: WG Work Item</TITLE>
</HEAD>
<BODY>

</BODY>
</HTML>
------_=_NextPart_001_01C4CE64.23D3F4A2--

--
to unsubscribe send a message 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, 19 Nov 2004 16:18:35 +0000
content-class: urn:content-classes:message
Subject: CUI: WG Work Item
Date: Fri, 19 Nov 2004 18:16:46 +0200
From: <[email-masked]>
To: <[email-masked]>

(Oops, my previous message was actually about 2486bis,
but ended up having the wrong subject line. Sorry about that!)

But I also support making CUI a WG work item (the contents
of the document still need work, though).

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: Fri, 19 Nov 2004 16:16:04 +0000
content-class: urn:content-classes:message
Subject: CUI: WG Work Item
Date: Fri, 19 Nov 2004 18:14:57 +0200
From: <[email-masked]>
To: <[email-masked]>

We already had one WGLC for 2486bis; given that the issues
raised back then were very minor, I'm not quite sure why=20
we need another one...

But anyway, the issues I brought up back then have been
resolved, so I'm OK with the document.

Best regards,
Pasi

> -----Original Message-----
> From: Bernard Aboba
> Sent: Thursday, November 18, 2004 7:54 PM
> To: [email-masked]
> Subject: RADEXT WG last call on RFC 2486bis
>=20
>=20
> This is an announcement of RADEXT WG Last call on "The Network
> Access Identifier" specification, RFC 2486bis, prior to=20
> sending the draft on to the IESG for consideration as an IETF=20
> Proposed Standard (recycled). The draft is available for=20
> inspection at:
>=20
> http://www.ietf.org/internet-drafts/draft-ietf-radext-
> rfc2486bis-01.txt

> RADEXT WG Last Call will complete on December 8, 2004.  Please send=20
> comments to the RADEXT WG mailing list ([email-masked]),=20
> using the issue format described at:
>=20
> http://www.drizzle.com/~aboba/RADEXT/

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

Delivery-date: Fri, 19 Nov 2004 15:12:19 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, "Glen Zorn (gwz)" <[email-masked]>
Cc: Avi Lior <[email-masked]>, [email-masked],  AC Mahendran <[email-masked]>
Subject: RE: Progress on RADIUS Extension for Digest Authentication
Date: Fri, 19 Nov 2004 10:11:28 -0500

Okay. So lets get this draft into last call right away.

Bernard, remember that 3GPP2 is looking for the sterman draft ASAP.  There
is a document that is ready to publish that must have an RFC number for
sterman.  So if this achievable then I am all for doing it right.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, November 18, 2004 11:56 PM
> To: Glen Zorn (gwz)
> Cc: 'Avi Lior'; [email-masked]
> Subject: RE: Progress on RADIUS Extension for Digest Authentication
> 
> 
> > Doesn't this draft 
> > http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt
> > solve your problem?
> 
> I believe that Section 3.2 of this document does provide for the
> following:
> 
> a. Integrity protection and authentication of messages.
> b. Multiple algorithm support (HMAC-MD5 & HMAC-SHA1 for starters)
> 
> My reason for suggesting that the WG consider this is that 
> the Security ADs have expressed concern about MD5 usage in 
> new documents.  In addition, NIST is likely to require a 
> FIPS-approved MAC such as HMAC-SHA1 for FIPS certification.  
> So I think that RADEXT WG will eventually need something 
> along these lines.  So why not bite the bullet now?
> 

--
to unsubscribe send a message 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, 19 Nov 2004 07:42:37 +0000
content-class: urn:content-classes:message
Subject: CUI: WG Work Item
Date: Fri, 19 Nov 2004 09:42:23 +0200
From: <[email-masked]>
To: <[email-masked]>, <[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: Fri, 19 Nov 2004 06:44:23 +0000
content-class: urn:content-classes:message
Subject: RE: Request for Review: Chargeable User Identity (CUI)
Date: Fri, 19 Nov 2004 08:41:53 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Farid,

> As per our IETF discussion, John has volunteered to write up an
> applicability section for the CUI draft - the idea is to make the
> rationale for the CUI more clear.  So, John's suggestion is a good =
idea
> *IF* most folks are not still convinced about the rationale=20
> for the CUI.

I agree.  If the WG thinks that this should be a WG item, then we can
submit the update as draft-radext- ...

John

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

Delivery-date: Fri, 19 Nov 2004 04:56:40 +0000
Date: Thu, 18 Nov 2004 20:56:15 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
cc: "'Avi Lior'" <[email-masked]>, [email-masked]
Subject: RE: Progress on RADIUS Extension for Digest Authentication

> Doesn't this draft
> http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt
> solve your problem?

I believe that Section 3.2 of this document does provide for the
following:

a. Integrity protection and authentication of messages.
b. Multiple algorithm support (HMAC-MD5 & HMAC-SHA1 for starters)

My reason for suggesting that the WG consider this is that the Security
ADs have expressed concern about MD5 usage in new documents.  In addition,
NIST is likely to require a FIPS-approved MAC such as HMAC-SHA1 for FIPS
certification.  So I think that RADEXT WG will eventually need something
along these lines.  So why not bite the bullet now?

--
to unsubscribe send a message 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, 19 Nov 2004 03:57:10 +0000
content-class: urn:content-classes:message
Subject: CUI: WG Work Item
Date: Fri, 19 Nov 2004 05:56:04 +0200
From: <[email-masked]>
To: <[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: Thu, 18 Nov 2004 23:38:44 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: Progress on RADIUS Extension for Digest Authentication
Date: Thu, 18 Nov 2004 15:38:31 -0800

Avi Lior <> wrote:
> Hi Bernard,
> 
> Regarding Issue[7] The need to use Message Authenticator.
> 
> I think we all agreed that a message authenticator is needed here.
> I think the debate was whether the Message-Autheticator will
suffice
> here. 
> 
> You suggested that maybe we introduce a new attribute.  But as you
> pointed out that while MD5 was found to be vunerable HMAC-MD5 was
> not. There was lots of debate on this issue.  
> 
> I don't think we would solve this issue in the near future.  This
is
> because, judging from the emails I don't think we would get
consensus
> even if we created a new message authenticator based on HMAC-SHA1.

Doesn't this draft
(http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.tx
t) solve your problem?

> 
> So my suggestion is to use Message-Authenticator(80) which is
based
> on(HMAC-MD5). Which is not broken and proceed with the work.  Not
> having anything is clearly bad.  
> 
> 
>> -----Original Message-----
>> From: Bernard Aboba [mailto:[email-masked]]
>> Sent: Thursday, November 18, 2004 1:16 PM
>> To: [email-masked]
>> Subject: Progress on RADIUS Extension for Digest Authentication
>> 
>> 
>> The specification "RADIUS Extension for Digest Authentication"
has
>> completed RADEXT WG Last call.  Issues filed against the
>> specification are available here: 
>> 
>> http://www.drizzle.com/~aboba/RADEXT/
>> 
>> The latest version of the specification is available here:
>> http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt
>> 
>> Further progress on this document requires that we verify that
>> changes made in the -04 document represent RADEXT WG consensus.
>> Since detailed text changes were not posted to the RADEXT WG
mailing
>> list prior to the submission of the -04 document, it is not
possible
>> to determine whether RADEXT WG consensus exists on the changes
based
>> on examination of the mailing list discussion.  It is therefore
not
>> possible to move forward on this document until this issue is
>> cleared up. 
>> 
>> In order to make progress, we have made a request that Issue
>> submitters and other WG participants examine the changes in
>> -04 and send email to the WG list, stating whether the changes
are
>> acceptable.  So far, the mail received indicates the following:
>> 
>> Issue 4: No mail received. WG consensus not verified.
>> Issue 5: No mail received, Diameter draft needs to be updated
before
>>          determining whether the resolutions can work. WG
consensus 
>> not verified. Issue 6: No mail received. WG consensus not
verified.
>> Issue 7: Mail received, indicates WG consensus *against* the
proposed
>>          resolution. No consensus verified.
>> Issue 8: No mail received, security issues raised at IETF 60. No

>> consensus verified. Issue 11: No mail received. No consensus
>> verified. 
>> Issue 12: No mail received. No censensus verified.
>> 
>> Given the lack of confirming email, we are at present unable to
>> confirm whether the changes made in -04 represent WG consensus,
and
>> in one case (Issue 7) it appears that the proposed resolution has
>> been rejected by the RADEXT WG. 
>> 
>> In order to enable the WG to demonstrate sufficient interest, we
are
>> going to extend the Request for Comment on the proposed
resolutions
>> until December 6, 2004.   If you have submitted an Issue on the
>> document, and
>> believe it has been resolved, please send mail with "Issue X:
>> Resolved" in the subject line, where X is the Issue number of
your
>> issue. 
>> 
>> If you have additional comments on the specification, or wish to
>> contest the resolution of an issue, please send email to the
RADEXT
>> WG mailing list ([email-masked]) in the format described
on
>> the RADEXT WG mailing list: 
>> 
>> http://www.drizzle.com/~aboba/RADEXT/
>> 
>> --
>> to unsubscribe send a message to
>> [email-masked] with the word 'unsubscribe' in a
>> single line as the message text body.
>> archive: <http://psg.com/lists/radiusext/>

Hope this helps,

~gwz

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

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

Delivery-date: Thu, 18 Nov 2004 23:33:33 +0000
Content-class: urn:content-classes:message
Subject: CUI: WG Work Item
Date: Thu, 18 Nov 2004 15:23:15 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[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: Thu, 18 Nov 2004 23:21:28 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: CUI:  WG Work Item
Date: Thu, 18 Nov 2004 18:21:22 -0500

--
to unsubscribe send a message 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, 18 Nov 2004 23:18:50 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, [email-masked]
Subject: RE: Progress on RADIUS Extension for Digest Authentication
Date: Thu, 18 Nov 2004 18:18:34 -0500

Hi Bernard,

Regarding Issue[7] The need to use Message Authenticator.

I think we all agreed that a message authenticator is needed here.  
I think the debate was whether the Message-Autheticator will suffice here.

You suggested that maybe we introduce a new attribute.  But as you pointed
out that while MD5 was found to be vunerable HMAC-MD5 was not. There was
lots of debate on this issue.

I don't think we would solve this issue in the near future.  This is
because, judging from the emails I don't think we would get consensus even
if we created a new message authenticator based on HMAC-SHA1.

So my suggestion is to use Message-Authenticator(80) which is based
on(HMAC-MD5). Which is not broken and proceed with the work.  Not having
anything is clearly bad.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, November 18, 2004 1:16 PM
> To: [email-masked]
> Subject: Progress on RADIUS Extension for Digest Authentication
> 
> 
> The specification "RADIUS Extension for Digest 
> Authentication" has completed RADEXT WG Last call.  Issues 
> filed against the specification are available here:
> 
> http://www.drizzle.com/~aboba/RADEXT/
> 
> The latest version of the specification is available here: 
> http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt
> 
> Further progress on this document requires that we verify 
> that changes made in the -04 document represent RADEXT WG 
> consensus. Since detailed text changes were not posted to the 
> RADEXT WG mailing list prior to the submission of the -04 
> document, it is not possible to determine whether RADEXT WG 
> consensus exists on the changes based on examination of the 
> mailing list discussion.  It is therefore not possible to 
> move forward on this document until this issue is cleared up.
> 
> In order to make progress, we have made a request that Issue 
> submitters and other WG participants examine the changes in 
> -04 and send email to the WG list, stating whether the 
> changes are acceptable.  So far, the mail received indicates 
> the following:
> 
> Issue 4: No mail received. WG consensus not verified.
> Issue 5: No mail received, Diameter draft needs to be updated before
>          determining whether the resolutions can work. WG consensus
>          not verified.
> Issue 6: No mail received. WG consensus not verified.
> Issue 7: Mail received, indicates WG consensus *against* the proposed
>          resolution. No consensus verified.
> Issue 8: No mail received, security issues raised at IETF 60. No
>          consensus verified.
> Issue 11: No mail received. No consensus verified.
> Issue 12: No mail received. No censensus verified.
> 
> Given the lack of confirming email, we are at present unable 
> to confirm whether the changes made in -04 represent WG 
> consensus, and in one case (Issue 7) it appears that the 
> proposed resolution has been rejected by the RADEXT WG.
> 
> In order to enable the WG to demonstrate sufficient interest, 
> we are going to extend the Request for Comment on the 
> proposed resolutions until
> December 6, 2004.   If you have submitted an Issue on the 
> document, and
> believe it has been resolved, please send mail with "Issue X: 
> Resolved" in the subject line, where X is the Issue number of 
> your issue.
> 
> If you have additional comments on the specification, or wish 
> to contest the resolution of an issue, please send email to 
> the RADEXT WG mailing list ([email-masked]) in the 
> format described on the RADEXT WG mailing list:
> 
> http://www.drizzle.com/~aboba/RADEXT/
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message 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, 18 Nov 2004 23:06:35 +0000
content-class: urn:content-classes:message
Subject: CUI: WG Work Item
Date: Thu, 18 Nov 2004 15:05:28 -0800
From: "Bari, Farooq" <[email-masked]>
To: <[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: Thu, 18 Nov 2004 22:00:40 +0000
Date: Thu, 18 Nov 2004 16:57:11 -0500
To: [email-masked],[email-masked]
From: "Joel M. Halpern" <[email-masked]>
Subject: draft-ietf-geopriv-radius-lo-01.txt - registry of operator name prefixes?

Description of issue: operator name prefix space must be properly defined
Submitter name: Joel M. Halpern
Submitter email address: [email-masked]
Date first submitted: 18-November-2004
Reference:
Document: draft-ietf-geopriv-radius-lo-01.txt
Comment type: T
Priority: 1
Section: 5.1 & 11
Rationale/Explanation of issue:  Operator-prefixes are defined.  Creation 
rules and a registry must be defined
Length description of problem:
     Section 5.1 states that only the listed operator name prefixes may be 
used. It then states that other operator name prefixes may come into 
existence.  Thus, it is creating a registry, presumably with some 
expectation on rules for how prefixes get into that registry.
     However, the IANA considerations section (11) does not even mention 
the three allocated values.  No section describes how new values may be 
created, or what rules such new values must abide by.

Requested change:
     The document should properly define the registry it is creating.

--
to unsubscribe send a message 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, 18 Nov 2004 22:00:34 +0000
Date: Thu, 18 Nov 2004 16:59:48 -0500
To: [email-masked],[email-masked]
From: "Joel M. Halpern" <[email-masked]>
Subject: draft-ietf-geopriv-radius-lo-01.txt - whose location?

Description of issue: Document mixes location of user and location of access
Submitter name: Joel M. Halpern
Submitter email address: [email-masked]
Date first submitted: 18-November-2004
Reference:
Document: draft-ietf-geopriv-radius-lo-01.txt
Comment type: T
Priority: 1
Section: Multiple
Rationale/Explanation of issue:  The location of a user is very different 
from the location of an access device.
Length description of problem:
     The document states that it provides the location of the access device 
providing network service.  The document then goes on to describe this as 
"the users location".  The document even describes this location as being 
useful for services other than charging (cf section 4.2).  However, what is 
needed for accounting is very different from the location for service 
delivery.  The correlation between the two depends many factors outside of 
the scope of this draft.  Mixing the two is not helpful.
     The information format in fact seems designed to provide not the 
access device location, but the location of the subscriber.
     It is also likely that if access identification is desired, geographic 
location will often not be the correct mechanism.

Requested change:
     Decide whether this document is intended to provide subscriber 
location (which is rarely directly useful for AAA), or access device / 
network location information.  In either case, remove the inappropriate 
material.
     If access device identification is desired, please indicate why 
operator defined tokens are not sufficient.  And reference where such 
tokens are when they are needed.

--
to unsubscribe send a message 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, 18 Nov 2004 21:47:25 +0000
Date: Thu, 18 Nov 2004 16:46:41 -0500
To: [email-masked],[email-masked]
From: "Joel M. Halpern" <[email-masked]>
Subject: draft-ietf-geopriv-radius-lo-01.txt - CDMA operator-name prefix

Description of issue: Operator-Name prefix defined without usage
Submitter name: Joel M. Halpern
Submitter email address: [email-masked]
Date first submitted: 18-November-2004
Reference:
Document: draft-ietf-geopriv-radius-lo-01.txt
Comment type: T
Priority: 2
Section: 5.1
Rationale/Explanation of issue:  The operator prefix CDMA is defined, but 
never user
Length description of problem:
     The CDMA operator-name prefix is listed as a valid prefix in section 
5.1.  However, no definition is included as to what names may use such a 
prefix or how they should use it.

Requested change:
     Either describe who allocates "CDMA" operator names, and how such 
names are allocated, ore remove the name

--
to unsubscribe send a message 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, 18 Nov 2004 21:34:58 +0000
Content-class: urn:content-classes:message
Subject: RE: Request for Review: Chargeable User Identity (CUI)
Date: Thu, 18 Nov 2004 13:34:28 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

As per our IETF discussion, John has volunteered to write up an
applicability section for the CUI draft - the idea is to make the
rationale for the CUI more clear.  So, John's suggestion is a good idea
*IF* most folks are not still convinced about the rationale for the CUI.

Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of=20
> [email-masked]
> Sent: Thursday, November 18, 2004 1:12 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Request for Review: Chargeable User Identity (CUI)
>=20
>=20
> Bernard,
>=20
> I am working on some revised text. I should have this ready=20
> tomorrow, and perhaps
> resubmit it next week.  Would it be more useful to do the=20
> consensus call
> on the updated draft?
>=20
> John
>=20
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of ext Bernard Aboba
> > Sent: 18 November, 2004 20:36
> > To: [email-masked]
> > Subject: Request for Review: Chargeable User Identity (CUI)
> >=20
> >=20
> > This is a request for RADEXT WG review of the document=20
> > "Chargeable User
> > Identity", for the purpose of determining whether this document is
> > suitable for becoming a RADEXT WG work item.  So far, the RADEXT WG
> > response to the call for interest has been insufficient to=20
> > move forward
> > on it. The document is available for inspection here:
> >=20
> > http://www.ietf.org/internet-drafts/draft-adrangi-radius-charg
> > eable-user-identity-02.txt
> >=20
> > The Request for Review will last until December 6, 2004.  If you
> > believe this document is suitable as a RADEXT WG work item, please
> > send email with "CUI: WG Work Item" in the subject.  If you=20
> > believe this
> > document is unsuitable, please post email with "CUI: Reject" in the
> > subject.  If you  have an Issue, please post it to the RADEXT=20
> > WG mailing list
> > ([email-masked]), using the format described in the=20
> > RADEXT Issues list:
> >=20
> > http://www.drizzle.com/~aboba/RADEXT/
> >=20
> > --
> > to unsubscribe send a message to [email-masked] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Thu, 18 Nov 2004 21:13:57 +0000
content-class: urn:content-classes:message
Subject: RE: Request for Review: Chargeable User Identity (CUI)
Date: Thu, 18 Nov 2004 23:12:03 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Bernard,

I am working on some revised text. I should have this ready tomorrow, =
and perhaps
resubmit it next week.  Would it be more useful to do the consensus call
on the updated draft?

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Bernard Aboba
> Sent: 18 November, 2004 20:36
> To: [email-masked]
> Subject: Request for Review: Chargeable User Identity (CUI)
>=20
>=20
> This is a request for RADEXT WG review of the document=20
> "Chargeable User
> Identity", for the purpose of determining whether this document is
> suitable for becoming a RADEXT WG work item.  So far, the RADEXT WG
> response to the call for interest has been insufficient to=20
> move forward
> on it. The document is available for inspection here:
>=20
> http://www.ietf.org/internet-drafts/draft-adrangi-radius-charg
> eable-user-identity-02.txt
>=20
> The Request for Review will last until December 6, 2004.  If you
> believe this document is suitable as a RADEXT WG work item, please
> send email with "CUI: WG Work Item" in the subject.  If you=20
> believe this
> document is unsuitable, please post email with "CUI: Reject" in the
> subject.  If you  have an Issue, please post it to the RADEXT=20
> WG mailing list
> ([email-masked]), using the format described in the=20
> RADEXT Issues list:
>=20
> http://www.drizzle.com/~aboba/RADEXT/
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Thu, 18 Nov 2004 18:48:17 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>
Subject: CUI: WG Work Item
Date: Thu, 18 Nov 2004 10:48:02 -0800

--
to unsubscribe send a message 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, 18 Nov 2004 18:36:15 +0000
Date: Thu, 18 Nov 2004 10:36:05 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Request for Review: Chargeable User Identity (CUI)

This is a request for RADEXT WG review of the document "Chargeable User
Identity", for the purpose of determining whether this document is
suitable for becoming a RADEXT WG work item.  So far, the RADEXT WG
response to the call for interest has been insufficient to move forward
on it. The document is available for inspection here:

http://www.ietf.org/internet-drafts/draft-adrangi-radius-chargeable-user-identity-02.txt

The Request for Review will last until December 6, 2004.  If you
believe this document is suitable as a RADEXT WG work item, please
send email with "CUI: WG Work Item" in the subject.  If you believe this
document is unsuitable, please post email with "CUI: Reject" in the
subject.  If you  have an Issue, please post it to the RADEXT WG mailing list
([email-masked]), using the format described in the RADEXT Issues list:

http://www.drizzle.com/~aboba/RADEXT/

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

Delivery-date: Thu, 18 Nov 2004 18:25:39 +0000
Date: Thu, 18 Nov 2004 10:25:24 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Request for Review: Carrying Location Objects in RADIUS

This is a request for RADEXT WG review of the document "Carrying Location
Objects in RADIUS".  The document is available for inspection here:

http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-01.txt

The Request for Review will last until December 6, 2004.  Please post your
issues to both the RADEXT WG mailing list ([email-masked]), and
the GEOPRIV WG mailing list ([email-masked]) using the format described
in the RADEXT Issues list:

http://www.drizzle.com/~aboba/RADEXT/

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

Delivery-date: Thu, 18 Nov 2004 18:16:10 +0000
Date: Thu, 18 Nov 2004 10:15:41 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Progress on RADIUS Extension for Digest Authentication

The specification "RADIUS Extension for Digest Authentication" has
completed RADEXT WG Last call.  Issues filed against the specification are
available here:

http://www.drizzle.com/~aboba/RADEXT/

The latest version of the specification is available here:
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt

Further progress on this document requires that we verify that changes
made in the -04 document represent RADEXT WG consensus.
Since detailed text changes were not posted to the RADEXT WG mailing
list prior to the submission of the -04 document, it is not possible to
determine whether RADEXT WG consensus exists on the changes based on
examination of the mailing list discussion.  It is therefore not possible
to move forward on this document until this issue is cleared up.

In order to make progress, we have made a request that Issue submitters
and other WG participants examine the changes in -04 and send email to
the WG list, stating whether the changes are acceptable.  So far, the
mail received indicates the following:

Issue 4: No mail received. WG consensus not verified.
Issue 5: No mail received, Diameter draft needs to be updated before
         determining whether the resolutions can work. WG consensus
         not verified.
Issue 6: No mail received. WG consensus not verified.
Issue 7: Mail received, indicates WG consensus *against* the proposed
         resolution. No consensus verified.
Issue 8: No mail received, security issues raised at IETF 60. No
         consensus verified.
Issue 11: No mail received. No consensus verified.
Issue 12: No mail received. No censensus verified.

Given the lack of confirming email, we are at present unable to confirm
whether the changes made in -04 represent WG consensus, and in one case
(Issue 7) it appears that the proposed resolution has been rejected by the
RADEXT WG.

In order to enable the WG to demonstrate sufficient interest, we are going
to extend the Request for Comment on the proposed resolutions until
December 6, 2004.   If you have submitted an Issue on the document, and
believe it has been resolved, please send mail with "Issue X: Resolved" in
the subject line, where X is the Issue number of your issue.

If you have additional comments on the specification, or wish to contest
the resolution of an issue, please send email to the RADEXT WG mailing
list ([email-masked]) in the format described on the RADEXT WG
mailing list:

http://www.drizzle.com/~aboba/RADEXT/

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

Delivery-date: Thu, 18 Nov 2004 17:54:23 +0000
Date: Thu, 18 Nov 2004 09:53:35 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG last call on RFC 2486bis

This is an announcement of RADEXT WG Last call on "The Network
Access Identifier" specification, RFC 2486bis, prior to sending the draft
on to the IESG for consideration as an IETF Proposed Standard (recycled).
The draft is available for inspection at:

http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-01.txt

RADEXT WG Last Call will complete on December 8, 2004.  Please send
comments to the RADEXT WG mailing list ([email-masked]), using the
issue format described at:

http://www.drizzle.com/~aboba/RADEXT/

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

Delivery-date: Wed, 17 Nov 2004 22:13:25 +0000
Content-class: urn:content-classes:message
Subject: RE: [Geopriv]: Another review of the geopriv radius location attributes draft
Date: Wed, 17 Nov 2004 14:12:28 -0800
From: "Blair T. Bullock" <[email-masked]>
To: "MORAND Lionel RD-CORE-ISS" <[email-masked]>, "Hannes Tschofenig" <[email-masked]>, [email-masked], "Adrangi, Farid" <[email-masked]>
cc: [email-masked], "BOURDON Gilles RD-CORE-ISS" <[email-masked]>, "FOUQUART Philippe RD-CORE-ISS" <[email-masked]>

It is very common practice to introduce Location resolutions from the
back-end systems through a RADIUS server and/or policy proxy.  That is
where the data and intelligence lies and attribute "stuffing" is more
and more prevalent in these systems, particularly when the location
information requirements (generality/granularity) are variable depending
on the consuming entity and multiple policy-based correlations are used
to determine such designations (NAS-IP + Framed-Address subnet + proxy
target)

However, from a standards standpoint, it does not preclude someone from
developing proprietary policy and location logic and leverage attribute
manipulation to achieve your goals.  NAS-level location data features
and formal AVP definitions for basic service information exchange is a
really good thing whether or not a company decides to preclude them by
some other proprietary manipulation.  It sure does make first-mile
RADIUS diagnosis much easier.  At least there is a solid value
definition and sound standards-based industry assessment to which we can
all use as a baseline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of MORAND Lionel RD-CORE-ISS
Sent: Tuesday, November 09, 2004 1:50 PM
To: Hannes Tschofenig; [email-masked]; Adrangi, Farid
Cc: [email-masked]; BOURDON Gilles RD-CORE-ISS; FOUQUART
Philippe RD-CORE-ISS
Subject: [Geopriv]: Another review of the geopriv radius location
attributes draft

Hi,

Here are "some" comments and questions on the location attributes draft.

As general comments:

- User location, network location, etc. should be clearly defined or
clarifed each time they are used.
- It seems that it is assumed that only the NAS can insert the location
information. However, it is likely that this information will be also
introduced by a local RADIUS server acting as a proxy (e.g. when the
exact location information is not available at the NAS).=20
- It is not described whether this location information will be included
in every access-request or only when some criteria are met e.g. based on
a given realm. It'd be intersting to spell out these criteria.=20
- If the use of location info in access-request could be optional, a COA
explicitly requesting this info (when not received in the initial
access-request) could be used by the Home RADIUS server.

*************
1.  Introduction

   Wireless LAN (WLAN) Access Networks (AN) are being deployed in public
   places such as airports, hotels, shopping malls, and coffee shops by
   a diverse set of incumbent operators such as cellular carriers (GSM
   and CDMA), Wireless Internet Service Providers (WISP), and fixed
   broadband operators.[skip]
  =20
   [skip] Although the proposed attributes in this draft are intended
for
   wireless LAN deployments, they can also be used in other wireless and
   wired networks where location-aware services are required.

=3D=3D> the need goes beyond location-based services for these networks. =
The
location information may be needed in any roaming situation, to enable
the home network to authorize/deny access based on the user's location
(network and/or geographical location), whatever the access network
technology.
Proposal: replace "where location-aware services are required" by
"whenever location information is necessary"

****************
3.2  Mid-session Delivery

   Mid-session delivery method uses the Change of Authorization (COA)
   message as defined in [RFC3576].  In accordance to [RFC3576], at
   anytime during the session the AAA server may send the access network
   a COA message containing session identification attributes (see
   [RFC3576] for the possible options).  The COA message may instruct
   the access network to generate an Authorize-Only Access-Request
   (Access-Request with Service-Type set to "Authorize-Only") in which
   case it is instructing the access network to send the location
   information attributes.

=3D=3D> How does the AAA server instruct the access network to send =
location
information attributes within the new Access-Request? Is there any
specific attribute in the COA indicating that the location information
is requested? Or do you assume that any Access-Request sent by the NAS
will contain the location information attribute and so case 1 and 2 are
the same?

*****************
4.1  Use Case 1 - Use of Location Information in AAA

   An Operator requires Location Informaion for Authorization and
   Billing purposes.  The operator may deny service if Location
   Information is not available.  Or it may offer limited service.  The
   NAS delivers Location Information to the Home AAA server.

=3D=3D> Is there a way for the AAA server to indicate to the access =
network
that the request failed because the location information is missing?

   The RADIUS server authenticates and authroizes the session.  If the
   user's location policies are available to the RADIUS server, the
   RADIUS server may deliver those policies in an Access Accept.  This
   information may be needed if intermediaries or other elements want to
   act as Location Servers (see Section 4.2).  In the absence of
   receiving the policies intermediaries MUST NOT divulge the location
   information.

=3D=3D> (1) the attributes that convey the policies in the Access-Accept =
are
not described.=20
=3D=3D> (2) As stated in the section 6 (Policy-Information attribute),
policies can also be put by the access network and propagated with
Access-Request or Accounting-request.

   Location Information may also be reported in accouning messages.
> edit "accounting"
   Accounting messages are generated when the session starts, stops and
   periodically.  Accounting messages may also be generated when the
   user roams during handoff.  This information may be needed by the
   billing system to calculate the users bill.  For example, there may
   be different tarrif rates applied based on the location and their
   maybe different tax rates applied based on the location.  Unless
   otherwise specified, location information in the accounting stream
   may not be transmitted to third parties.

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

=3D=3D> Do the user's location policies received in the Access-Accept =
(in
the authorization phase) also apply to Accounting messages?

*******************
4.2  Scenario 2 - Use of Location Information for other Services

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

   Unless otherwise specified, excluding the proxy chain from the NAS to
   the Home RADIUS, the Location Server may not transmit the location
   information to other parties.

=3D=3D> I think you mean: "Unless otherwise specified, the location =
servers
MUST NOT transmit the location information to other parties outside the
proxy chain between the NAS and the Home RADIUS server".=20

   Upon authentication and authorization, the Home RADIUS may transmit
   the Rule set in an Access-Accept to the other Location Server
   allowing them to transmit location information.  Then and only then
   they are allowed to share the information.

=3D=3D> Is it possible to discriminate parties allowed to distribute the
location information to third parties e.g. only the local access network
is allowed and not intermediary networks (e.g. brokers)?

   Note since the NAS is the source of all Location information that is
   disimenated by RADIUS, the NAS could tag the location information
   with the location rules or a reference for the location rules
   received in an Access-Accept.  All location information in the
   Accounting Stream will now be tagged.

=3D=3D> Is it so sure that NAS is always the source of location =
information?
Couldn't we have scenarios where the location information is added by
the RADIUS proxy in the visited network, because the NAS is not able to
retrieve the user's location for instance?

***********************
5.1  Operator-Name Attribute

   This attribute contains an operator name which uniquely identifies
   the ownership of an access network.  The Attribute value is a
   non-NULL terminated string whose Length MUST NOT exceed 253 bytes.
   The attribute value is comprised of the prefix and the identity,
   separated by a colon.  The prefix identifies the operator type;
   example: GSM, CDMA, and REALM.  The identity uniquely identifies the
   operator name within the scope of the operator type.

=3D=3D> What is the exact meaning of "operator type"? The operator name =
is
supposed to identify the owner of the access network. Therefore, instead
of GSM, CDMA and REALM, would it be better to define something more
generic describing the type of access network connected to the NAS?

   This document defines three operator type prefixes which are: GSM,
   CDMA, and REALM.  The GSM prefix can be used to indicate operator
   names based on GSMA TADIG codes.  REALM can be used by any domain
   name acquired from IANA.  Possible forthcoming operator types MUST be
   associated with an ogranization responsible for assigning/managing
   operator names.

=3D=3D> Is it really needed to have IANA assigned numbers for prefix (as
currently defined)? Prefix and name are just text information. It should
be up to the RADIUS end-points to use a common language. Ones could
decide to have something based on pref+ID, others something else (e.g.
country code+operator/network code).

**************************
5.2  Location-Information Attribute

   This document describes two formats for conveying location
   information: civil and geospatial location information.  Section
   5.2.1 defines the civil location information format.  Section 5.2.2
   defines the geospatial location information format.

   Additionally, the Precision field provides further information about
   the location information provided via Radius.  For large networks
   information about the location of the user can be provided in
   different degrees of accuracy.  This field gives a hint.  Ideally the
   location of the user is returned to the home network but in some
   cases it might not be available.  It has to be noted that the user
   does not provide the location information itself.

=3D=3D> (1) I don't understand the end of this paragraph! What kind of =
user
location are you referring to here? Whatever the precision and the
nature of the location information, the location of the user could
always be returned to the home network. Maybe you are talking about the
location of the user's end point (which could be far away from the NAS)?

=3D=3D> (2) only two formats of location information are defined at this
stage: civil and geospatial. What about some "location ID" that could be
sent to the AAA server to retrieve location info? I mean that the
location info attribute may convey either explicit ("self-explicit")
location information or any identifier if there is a mean for the
receiver to extract explicit information from this ID, such as the
CellID in GSM.

*****************************
6.  Policy-Information Attribute

   In some environments it is possible for the user to attach
   information about its privacy preferences.  These preferences allow
   the visited network, intermediate RADIUS proxies and the home network
   to authorize the distribution of the user's location information.

=3D=3D> How do these privacy preferences distributed by the
Policy-Information attribute in the Access-Request interact with the
policies being delivered by the Home RADIUS server in the Access-Accept?

*****************************
9.1  Operator-Name Attribute

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

   A summary of the Operator-Name Attribute is shown below.

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

     Type:
       To Be Assigned by IANA - Operator-Name

     Length:
       >=3D 3

     Operator-Name:
       The text field contains an Access Network Operator Name in
       prefix-based format as describe above.
       Example: REALM:anyisp.com

=3D=3D> If the prefix is put in the "Operator-Name" field in text format =
and
if it keeps the current signification, there is no reason IMHO to have
IANA-assigned numbers. Otherwise, we could have a separate field
describing the operator type (whaterver the meaning of this parameter)
as defined below:

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

*************************************
9.2  Location-Information Attribute

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

   The Location-Information Attribute has two variations depending on
   civil or geospatial location information.  The format is shown below.

       0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type        |  Length       | Code          |  Precision    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               Location-Info                                  ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type (8 bits):
       To Be Assigned by IANA  - Location-Information

     Length (8 bits):
       >=3D 3

     Code (8 bits):
       Describes which location format is carried in this attribute:
       (0) describes civil location information
       (1) describes geospatial location information
       All other bites of the Code field is reserved
       and required for alignment.

=3D=3D> it is proposed to add a value (2) for location ID

     Precision (8 bits):
       Describes which location this attribute refers to:
       (0) describes the location of the NAS
       (1) describes the location of the AAA server
       (2) describes the location of the end host (user)
       (3) describes the location of the network

=3D=3D> What is the meaning of the fourth value? How could it be =
possible to
have less than the NAS or the visited RADIUS location information?

BR,

Lionel

--
to unsubscribe send 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, 11 Nov 2004 18:00:58 +0000
From: Avi Lior <[email-masked]>
To: 'Miguel Garcia' <[email-masked]>, "Beck01, Wolfgang" <[email-masked]>, Mari Carmen belinchon <[email-masked]>, Miguel-Angel Pallares <[email-masked]>, "ext Carolina Canales (ML/EEM)" <[email-masked]>, Pete McCann <[email-masked]>,  Rajaniemi Jaakko Matti <[email-masked]>, Tammi Kalle Tapani <[email-masked]>
Cc: AAA mailing list <[email-masked]>, [email-masked]
Subject: RE: [AAA-WG]: Reconciling Radius/Diameter SIP application
Date: Thu, 11 Nov 2004 12:59:31 -0500

Hi,

Wrt to UTF8String in diameter and lack of support in RADIUS. Well would the
RADIUS type TEXT work for you?

Text is defined in 2865 as  "Text contains UTF-8 encoded 10646
      [7] characters"

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]] 
> Sent: Thursday, November 11, 2004 8:55 AM
> To: Beck01, Wolfgang; Mari Carmen belinchon; Miguel-Angel 
> Pallares; ext Carolina Canales (ML/EEM); Pete McCann; 
> Rajaniemi Jaakko Matti; Tammi Kalle Tapani
> Cc: AAA mailing list; [email-masked]
> Subject: [AAA-WG]: Reconciling Radius/Diameter SIP application
> 
> 
> Hi:
> 
> I am deliberately cross posting to AAA and Radius-ext because 
> I believe 
> this topic is of interest for both lists.
> 
> Yesterday Wolfgang and me met for a few hours and set the goal of 
> reconcile the Diameter SIP application and the RADIUS HTTP/SIP Digest 
> drafts. These are the drafts:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-si
> p-app-04.txt
> 
> http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt
> 
> These are the main points we discuss. If you have any 
> comments, speak up 
> now, otherwise we will do the proposed changes in the relevant drafts:
> 
> 1- We agreed to modify the Diameter SIP application so that 
> it imports 
> the Digest-* AVP from the corresponding RADIUS attributes 
> address space. This came out of a comment from Jari Arkko, 
> and I think it is important 
> to avoid duplication of AVP/attributes.
> 
> As a side effect of the above, the SIP-Authentication-Context will 
> disappear in Diameter SIP app. This was a grouped AVP that only 
> contained a Digest-Entity-Body-Hash AVP. The latter will 
> remain (in the 
> RADIUS draft).
> 
> 2- We noticed a divergence in the Digest-Expected-Response AVP in 
> Diameter, which does not exist in RADIUS. RADIUS defines a Digest-HA1 
> attribute. The difference: Digest-HA1 contains H(A1), which 
> is computed 
> at the Radius server and sent to the Radius client, and it is used to 
> compute the expected response. In Diameter, the expected response is 
> computed at the Diameter server and sent to the client. This 
> assumes a 
> secure connection to avoid eavesdropping, which is not a problem for 
> Diameter that mandates IPsec or TLS. I think Diameter can go for the 
> Radius approach for compatibility reasons.
> 
> Proposal: Diameter will remove Digest-Expected-Response AVP and will 
> import Digest-HA1 from Radius.
> 
> 3- Radius does not define UTF8String data types, so all these 
> attributes 
> will remain as String, but the Radius draft will indicate 
> that contain a UTF8String verbally (this is required by HTTP and SIP).
> 
> 4- Currently here is a divergence on the definition of Digest-Stale 
> attribute: Diameter uses "true" and "false" (as per RFC2617), Radius 
> uses 1 and 0. We agreed to use "true" and "false" to avoid stupid 
> transcodings.
> 
> 5- Diameter indicates that the Digest-* AVPs contain the 
> quotes from/to 
> the Digest directive, Radius assumes (although does not indicate) no 
> quotes. We agreed that the Digest-* attributes do not need to include 
> the quotes from HTTP Digest parameters. So, there will be an explicit 
> indication that quotes are not part of the attribute value.
> 
> 6- We run into a problem when multiple SIP proxies are 
> authenticating the user, because at some point in time the 
> SIP request may contain several Proxy-Authorization headers. 
> The key here is the realm, it will be always different. If 
> different Diameter/Radius servers are 
> serving different realms, there is not problem. But, if a common 
> Diameter/Radius server is serving different realms, then the 
> server is 
> not able to determine which credentials should be evaluated.
> 
> We propose that the Diameter/Radius client MUST send only one set of 
> credentials at a time, those belonging to the served realm. This 
> requires to configure the Diameter/Radius client with the realm it is 
> serving. We will include some text indicating this case.
> 
> 7- Some of the attributes (e.g, Digest-Response and
> Digest-Response-Auth) had an artificial limit of 32 octets in 
> the value. While this value is correct for MD5 hashes, if in 
> the future other hashes are added to HTTP Digest, will run 
> into trouble. Proposal: don't restrict the length of a value.
> 
> 8- In the Radius document, scenario 1, we have a question. We 
> suspect that this scenario does not work if the Radius client 
> generates a nextnonce. The reason is that in the following 
> authentication, when the nextnonce becomes a nonce, the 
> Radius server will not recognize the nonce as locally 
> generated (it was generated by the Radius client), and 
> will reject the request with a "state=true". RFC 2617 seems 
> to describe 
> the case:
> 
>     If the
>     nextnonce field is present the client SHOULD use it when 
> constructing
>     the Authorization header for its next request. Failure of 
> the client
>     to do so may result in a request to re-authenticate from 
> the server
>     with the "stale=TRUE".
> 
> Does anyone have any comment? Can anyone confirm that the 
> operation in 
> Digest is as we indicate? We will add some text indicating the 
> limitations of Scenario 1.
> 
> 9- The Radius draft, in section 2.15, indicates:
> 
>           RADIUS
>           servers that do not implement a parameter contained in a
>           Digest-Auth-Param attribute MUST respond with an 
> Access-Reject
>           message.  RADIUS clients that do not implement a parameter
>           contained in a Digest-Auth-Param attribute MUST reject the
>           original HTTP-style request.
> 
> The problem is that the text seems to go against RFC 2617 that says:
> 
>     auth-param
>       This directive allows for future extensions. Any unrecognized
>       directive MUST be ignored.
> 
> The proposal is to remove the above text from the RADIUS draft.
> 
> 
> 10- Similar contradictory text was found in Section 2.16 of 
> the RADIUS 
> draft, that says:
> 
>    RADIUS servers that do
>    not implement AKA Digest MUST response with an Access Reject
>    message.
> 
> We propose to remove the above text. The motivation is that the 
> algorithm already conveys the AKA (AKA extends the algorithm to be 
> AKAv1-MD5 and AKAv1-MD5-sess). The server chooses the 
> algorithm, so the 
> situation currently described, where the client may include an auts 
> attribute, is just an error case, where the client made a mistake and 
> included AUTS when not doing AKA. In case the Radius server does not 
> implement AKA authentication, it will safely ignore this AVP.
> 
> 11- We noticed that most of the HTTP Digest directives contain just a 
> single token. However, the "qop" directive may contain a 
> comma-separated 
> collection of tokens. For instance, qop="auth,auth-int". The 
> question is 
> how do encode these tokens in the Digest-Qop attribute. The 
> options are:
> 
> a) Treat the whole thing as one token and put it into the 
> attribute value.
> b) Each token is an attribute, thus, there might be multiple 
> Digest-Qop 
> attributes in a particular Radius/Diameter message.
> 
> We think that option b) is cleaner. Particularly it will be 
> easier for 
> the Diameter/Radius client to encode different values in different 
> attributes.
> 
> Any comments to any of the above?
> 
> Regards,
> 
>            Miguel
> 
> 
> 
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland
> 

--
to unsubscribe send a message 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, 10 Nov 2004 19:12:47 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, MORAND Lionel RD-CORE-ISS <[email-masked]>
Cc: [email-masked], [email-masked], Hannes Tschofenig <[email-masked]>, BOURDON Gilles RD-CORE-ISS <[email-masked]>, FOUQUART Philippe RD-CORE-ISS <[email-masked]>
Subject: RE: [Geopriv]: Another review of the geopriv radius location attr ibutes draft
Date: Wed, 10 Nov 2004 14:12:14 -0500

Hi Bernard and Lionel,

> > ==> How does the AAA server instruct the access network to send 
> > location information attributes within the new Access-Request? Is 
> > there any specific attribute in the COA indicating that the 
> location 
> > information is requested? Or do you assume that any Access-Request 
> > sent by the NAS will contain the location information 
> attribute and so 
> > case 1 and 2 are the same?
> 
> RFC 3576 does not use attributes in the CoA-Request in order 
> to request attributes in a subsequent Access-Request.  Nor 
> does it make sense to include location attributes in a 
> CoA-Request.  The session to which the CoA applies is not 
> selected using location attributes, nor is the request that 
> the NAS change its location -- "Please move NAS17483 to 
> Cleveland, Ohio."

I agree with Bernard, and we don't send location attributes to the NAS in
COA Request.

I think that the text is confusing:

   "The COA message may instruct the access
   network to generate an Authorize-Only Access-Request (Access-Request
   with Service-Type set to "Authorize-Only") in which case it is
   instructing the access network to send the location information
   attributes."

May be we should say:

   "The COA message may instruct the access
   network to generate an Authorize-Only Access-Request (Access-Request
   with Service-Type set to "Authorize-Only") in which case the NAS 
   MUST include the location infromation in this Access-Request."
 
> > ==> Is there a way for the AAA server to indicate to the access 
> > network that the request failed because the location information is 
> > missing?
> 
> See RFC 3576 Error-Cause attribute, value 402 (Missing Attribute)

I don't think that we can use the Error-Cause attribute.  It is only
available in COA ACK/NAK messages. So the AAA has no way to tell the NAS
that it is missing the location attribute. I don't think that this attribute
can be placed in an Access-Reject message.
What do you think Bernard? 

--
to unsubscribe send a message 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, 09 Nov 2004 23:30:09 +0000
Date: Tue, 9 Nov 2004 15:29:45 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: MORAND Lionel RD-CORE-ISS <[email-masked]>
cc: Hannes Tschofenig <[email-masked]>, [email-masked], "Adrangi, Farid" <[email-masked]>, [email-masked], BOURDON Gilles RD-CORE-ISS <[email-masked]>, FOUQUART Philippe RD-CORE-ISS <[email-masked]>
Subject: Re: [Geopriv]: Another review of the geopriv radius location attributes draft

> ==> How does the AAA server instruct the access network to send location
> information attributes within the new Access-Request? Is there any
> specific attribute in the COA indicating that the location information
> is requested? Or do you assume that any Access-Request sent by the NAS
> will contain the location information attribute and so case 1 and 2 are
> the same?

RFC 3576 does not use attributes in the CoA-Request in order to request
attributes in a subsequent Access-Request.  Nor does it make sense to
include location attributes in a CoA-Request.  The session to which the
CoA applies is not selected using location attributes, nor is the request
that the NAS change its location -- "Please move NAS17483 to Cleveland,
Ohio."

> ==> Is there a way for the AAA server to indicate to the access network
> that the request failed because the location information is missing?

See RFC 3576 Error-Cause attribute, value 402 (Missing Attribute)

> ==> Is it so sure that NAS is always the source of location information?
> Couldn't we have scenarios where the location information is added by
> the RADIUS proxy in the visited network, because the NAS is not able to
> retrieve the user's location for instance?

This seems quite likely, in fact.

> ==> (1) I don't understand the end of this paragraph! What kind of user
> location are you referring to here? Whatever the precision and the
> nature of the location information, the location of the user could
> always be returned to the home network. Maybe you are talking about the
> location of the user's end point (which could be far away from the NAS)?

I was confused about this as well.

> ==> What is the meaning of the fourth value? How could it be possible to
> have less than the NAS or the visited RADIUS location information?

I don't understand this either.

--
to unsubscribe send a message 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, 09 Nov 2004 21:51:49 +0000
Content-class: urn:content-classes:message
Subject: [Geopriv]: Another review of the geopriv radius location attributes draft
Date: Tue, 9 Nov 2004 22:50:06 +0100
From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>, <[email-masked]>, "Adrangi, Farid" <[email-masked]>
Cc: <[email-masked]>, "BOURDON Gilles RD-CORE-ISS" <[email-masked]>, "FOUQUART Philippe RD-CORE-ISS" <[email-masked]>

Hi,

Here are "some" comments and questions on the location attributes draft.

As general comments:

- User location, network location, etc. should be clearly defined or
clarifed each time they are used.
- It seems that it is assumed that only the NAS can insert the location
information. However, it is likely that this information will be also
introduced by a local RADIUS server acting as a proxy (e.g. when the
exact location information is not available at the NAS).=20
- It is not described whether this location information will be included
in every access-request or only when some criteria are met e.g. based on
a given realm. It'd be intersting to spell out these criteria.=20
- If the use of location info in access-request could be optional, a COA
explicitly requesting this info (when not received in the initial
access-request) could be used by the Home RADIUS server.

*************
1.  Introduction

   Wireless LAN (WLAN) Access Networks (AN) are being deployed in public
   places such as airports, hotels, shopping malls, and coffee shops by
   a diverse set of incumbent operators such as cellular carriers (GSM
   and CDMA), Wireless Internet Service Providers (WISP), and fixed
   broadband operators.[skip]
  =20
   [skip] Although the proposed attributes in this draft are intended
for
   wireless LAN deployments, they can also be used in other wireless and
   wired networks where location-aware services are required.

=3D=3D> the need goes beyond location-based services for these networks. =
The
location information may be needed in any roaming situation, to enable
the home network to authorize/deny access based on the user's location
(network and/or geographical location), whatever the access network
technology.
Proposal: replace "where location-aware services are required" by
"whenever location information is necessary"

****************
3.2  Mid-session Delivery

   Mid-session delivery method uses the Change of Authorization (COA)
   message as defined in [RFC3576].  In accordance to [RFC3576], at
   anytime during the session the AAA server may send the access network
   a COA message containing session identification attributes (see
   [RFC3576] for the possible options).  The COA message may instruct
   the access network to generate an Authorize-Only Access-Request
   (Access-Request with Service-Type set to "Authorize-Only") in which
   case it is instructing the access network to send the location
   information attributes.

=3D=3D> How does the AAA server instruct the access network to send =
location
information attributes within the new Access-Request? Is there any
specific attribute in the COA indicating that the location information
is requested? Or do you assume that any Access-Request sent by the NAS
will contain the location information attribute and so case 1 and 2 are
the same?

*****************
4.1  Use Case 1 - Use of Location Information in AAA

   An Operator requires Location Informaion for Authorization and
   Billing purposes.  The operator may deny service if Location
   Information is not available.  Or it may offer limited service.  The
   NAS delivers Location Information to the Home AAA server.

=3D=3D> Is there a way for the AAA server to indicate to the access =
network
that the request failed because the location information is missing?

   The RADIUS server authenticates and authroizes the session.  If the
   user's location policies are available to the RADIUS server, the
   RADIUS server may deliver those policies in an Access Accept.  This
   information may be needed if intermediaries or other elements want to
   act as Location Servers (see Section 4.2).  In the absence of
   receiving the policies intermediaries MUST NOT divulge the location
   information.

=3D=3D> (1) the attributes that convey the policies in the Access-Accept =
are
not described.=20
=3D=3D> (2) As stated in the section 6 (Policy-Information attribute),
policies can also be put by the access network and propagated with
Access-Request or Accounting-request.

   Location Information may also be reported in accouning messages.
> edit "accounting"
   Accounting messages are generated when the session starts, stops and
   periodically.  Accounting messages may also be generated when the
   user roams during handoff.  This information may be needed by the
   billing system to calculate the users bill.  For example, there may
   be different tarrif rates applied based on the location and their
   maybe different tax rates applied based on the location.  Unless
   otherwise specified, location information in the accounting stream
   may not be transmitted to third parties.

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

=3D=3D> Do the user's location policies received in the Access-Accept =
(in
the authorization phase) also apply to Accounting messages?

*******************
4.2  Scenario 2 - Use of Location Information for other Services

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

   Unless otherwise specified, excluding the proxy chain from the NAS to
   the Home RADIUS, the Location Server may not transmit the location
   information to other parties.

=3D=3D> I think you mean: "Unless otherwise specified, the location =
servers
MUST NOT transmit the location information to other parties outside the
proxy chain between the NAS and the Home RADIUS server".=20

   Upon authentication and authorization, the Home RADIUS may transmit
   the Rule set in an Access-Accept to the other Location Server
   allowing them to transmit location information.  Then and only then
   they are allowed to share the information.

=3D=3D> Is it possible to discriminate parties allowed to distribute the
location information to third parties e.g. only the local access network
is allowed and not intermediary networks (e.g. brokers)?

   Note since the NAS is the source of all Location information that is
   disimenated by RADIUS, the NAS could tag the location information
   with the location rules or a reference for the location rules
   received in an Access-Accept.  All location information in the
   Accounting Stream will now be tagged.

=3D=3D> Is it so sure that NAS is always the source of location =
information?
Couldn't we have scenarios where the location information is added by
the RADIUS proxy in the visited network, because the NAS is not able to
retrieve the user's location for instance?

***********************
5.1  Operator-Name Attribute

   This attribute contains an operator name which uniquely identifies
   the ownership of an access network.  The Attribute value is a
   non-NULL terminated string whose Length MUST NOT exceed 253 bytes.
   The attribute value is comprised of the prefix and the identity,
   separated by a colon.  The prefix identifies the operator type;
   example: GSM, CDMA, and REALM.  The identity uniquely identifies the
   operator name within the scope of the operator type.

=3D=3D> What is the exact meaning of "operator type"? The operator name =
is
supposed to identify the owner of the access network. Therefore, instead
of GSM, CDMA and REALM, would it be better to define something more
generic describing the type of access network connected to the NAS?

   This document defines three operator type prefixes which are: GSM,
   CDMA, and REALM.  The GSM prefix can be used to indicate operator
   names based on GSMA TADIG codes.  REALM can be used by any domain
   name acquired from IANA.  Possible forthcoming operator types MUST be
   associated with an ogranization responsible for assigning/managing
   operator names.

=3D=3D> Is it really needed to have IANA assigned numbers for prefix (as
currently defined)? Prefix and name are just text information. It should
be up to the RADIUS end-points to use a common language. Ones could
decide to have something based on pref+ID, others something else (e.g.
country code+operator/network code).

**************************
5.2  Location-Information Attribute

   This document describes two formats for conveying location
   information: civil and geospatial location information.  Section
   5.2.1 defines the civil location information format.  Section 5.2.2
   defines the geospatial location information format.

   Additionally, the Precision field provides further information about
   the location information provided via Radius.  For large networks
   information about the location of the user can be provided in
   different degrees of accuracy.  This field gives a hint.  Ideally the
   location of the user is returned to the home network but in some
   cases it might not be available.  It has to be noted that the user
   does not provide the location information itself.

=3D=3D> (1) I don't understand the end of this paragraph! What kind of =
user
location are you referring to here? Whatever the precision and the
nature of the location information, the location of the user could
always be returned to the home network. Maybe you are talking about the
location of the user's end point (which could be far away from the NAS)?

=3D=3D> (2) only two formats of location information are defined at this
stage: civil and geospatial. What about some "location ID" that could be
sent to the AAA server to retrieve location info? I mean that the
location info attribute may convey either explicit ("self-explicit")
location information or any identifier if there is a mean for the
receiver to extract explicit information from this ID, such as the
CellID in GSM.

*****************************
6.  Policy-Information Attribute

   In some environments it is possible for the user to attach
   information about its privacy preferences.  These preferences allow
   the visited network, intermediate RADIUS proxies and the home network
   to authorize the distribution of the user's location information.

=3D=3D> How do these privacy preferences distributed by the
Policy-Information attribute in the Access-Request interact with the
policies being delivered by the Home RADIUS server in the Access-Accept?

*****************************
9.1  Operator-Name Attribute

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

   A summary of the Operator-Name Attribute is shown below.

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

     Type:
       To Be Assigned by IANA - Operator-Name

     Length:
       >=3D 3

     Operator-Name:
       The text field contains an Access Network Operator Name in
       prefix-based format as describe above.
       Example: REALM:anyisp.com

=3D=3D> If the prefix is put in the "Operator-Name" field in text format =
and
if it keeps the current signification, there is no reason IMHO to have
IANA-assigned numbers. Otherwise, we could have a separate field
describing the operator type (whaterver the meaning of this parameter)
as defined below:

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

*************************************
9.2  Location-Information Attribute

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

   The Location-Information Attribute has two variations depending on
   civil or geospatial location information.  The format is shown below.

       0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type        |  Length       | Code          |  Precision    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               Location-Info                                  ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type (8 bits):
       To Be Assigned by IANA  - Location-Information

     Length (8 bits):
       >=3D 3

     Code (8 bits):
       Describes which location format is carried in this attribute:
       (0) describes civil location information
       (1) describes geospatial location information
       All other bites of the Code field is reserved
       and required for alignment.

=3D=3D> it is proposed to add a value (2) for location ID

     Precision (8 bits):
       Describes which location this attribute refers to:
       (0) describes the location of the NAS
       (1) describes the location of the AAA server
       (2) describes the location of the end host (user)
       (3) describes the location of the network

=3D=3D> What is the meaning of the fourth value? How could it be =
possible to
have less than the NAS or the visited RADIUS location information?

BR,

Lionel

--
to unsubscribe send a message 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, 08 Nov 2004 16:09:45 +0000
Date: Mon, 8 Nov 2004 08:09:16 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Slides from IETF61 Presentations available

Here is the link:

http://www.drizzle.com/~aboba/RADEXT/IETF61/

--
to unsubscribe send a message 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, 08 Nov 2004 14:35:57 +0000
Date: Mon, 08 Nov 2004 16:33:34 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Nelson, David" <[email-masked]>
Cc: [email-masked], "David Mariblanca (EE/EEM)" <[email-masked]>
Subject: Re: alternatives for carrying eap lower layer information

Nelson, David wrote:
> Jari writes ...
> 
> 
>>Yes, that was my question. I can certainly see this happening,
>>but I'm uncertain if RFC 2868 is able to cope with it.
> 
> 
> I don't think it would.  Since service provisioning in RADIUS is a
> result of authentication (and authorization) I'm unsure how RADIUS would
> address the set-up of a tunnel that is pre-requisite to the
> authentication process.  That's what the incoming tunnel in this "two
> tunnel" scenario would be, right?

Well, RADIUS *is* helping to create the incoming tunnel too --
just think of IKEv2 EAP authentication in a situation where the
IKEv2 GW doesn't have the user database internally. Now, if
the GW is also doing some sort of mandatory tunneling for the
traffic, then we are in essence doing both at the same time.

Note: I do not have a good example why both tunnels would be
needed at the same time, but I'm sure the innovative service
providers or SDOs will come up with some network scenario where
they need 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: Mon, 08 Nov 2004 14:21:33 +0000
Content-class: urn:content-classes:message
Subject: RE: alternatives for carrying eap lower layer information
Date: Mon, 8 Nov 2004 06:20:47 -0800
From: "Blair T. Bullock" <[email-masked]>
To: [email-masked]
cc: [email-masked]

Sorry if this comment is not very salient to this thread....

I like that level of clarification of virtual transport since it seems
to be a trend to make everything a VIRTUAL N-P-T simply because it is
not of a single distinct interface type and may also encompass
non-physical transport which is not explicitly defined.

Such as an Access Gateway that feeds both ENET and 802.11 Access Points,
but uses L2TP for transport.... What N-P-T is it?!  Aw, heck let's just
call it Virtual.   =3D^(  =20

What I don't get is why include Auth Methods such as PANA and PEAP? The
Nas-Port-Type should describe the consumed (inbound) service as stated
in this thread.  Today it is commonly used to differentiate and bill
consumed services at different rates based on Media used by the STA, but
unfortunately we have cases where dial, Wi-Fi and Ethernet NAS set all
N-P-T to Virtual; regardless.   PEAP can be used over Ethernet and
Wi-Fi, so to claim a N-P-T of PEAP is just as ambiguous as to the
consumed service is it not?  Could these virtual transport and multi-use
protocol extensions allow this to break-down into an ambiguous mess?

Thanks for your time,=20

Blair

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jari Arkko
Sent: Monday, November 08, 2004 5:06 AM
To: Bernard Aboba
Cc: [email-masked]'; David Mariblanca (EE/EEM)
Subject: Re: alternatives for carrying eap lower layer information

Bernard Aboba wrote:
> There are multiple problems being discussed here:=20
>=20
> a. Ability to differentiate tunneled EAP methods (PEAP, EAP-IKEv2,
etc.) from non-tunneled EAP methods.=20
>=20
> b. Ability to differentiate EAP lower layers from one another
(EAP-IKEv2).
>=20
> In terms of problem a), the EAP peer and server know what EAP method
is being negotiated (and whether it is tunneled), but the NAS is
presumed to be a pass-through.  Therefore, I am not clear how the NAS
would obtain information on the EAP method to put into an attribute,
unless it gets this from the RADIUS server. =20

Yes, it seems you are right. The endpoints of the two methods should
always be the same, so there is no need to tell the distinction to
anyone.

> In terms of problem b), it seems that the problem arises in part from
the allocation of a single NAS-Port-Type (Virtual) to all tunnels.  In
contrast, in RFC 2868 the combination of Tunnel-Type and
Tunnel-Medium-Type attributes enables description of virtually any
tunnel type over any medium.  I'd suggest that this approach is more
sound than trying to allocate a NAS-Port-Type value for every
conceivable combination.=20

I think you are right on this one also. But are you suggesting that
these attributes be used, or just that the same idea of separating
this into two steps makes sense?

I think you must mean the latter, because it seems that
RFC 2868 is targeted towards mandatory tunneling, i.e.,
something that happens after the traffic leaves the NAS.
What we are talking about here is a service provided
as a tunnel, something that happens before the traffic
enters the NAS. This might lead to a confusion if the
same attributes were used, or am I missing something?
Presumably you could have both a virtual service coming
in and a mandatory tunnel going out...

If I am right we should do the following:

1. Use the NAS-Port-Type as the primary differentiator
    between different kinds of incoming connections to NAS.
    If its 802.11, use value 19. If its IKEv2 or any
    other sort of non-physical interface, use 5 (Virtual).
    Allocate a new value for PANA.

2. Then, if 5 (Virtual) was used above, define a new attribute
    that indicates the type of the virtual device.

    NAS-Virtual-Port-Type
      1 (IKEv2)
      2 ...

3. Optionally, define another attribute that also defines the
    type of protocol that this virtual service run on top of
    (e.g., IPv4 or IPv6).

This would work for me, I think.

The crucial question is whether the RFC 2868 attributes can
be used for this purpose or if new ones are needed because
the mandatory tunneling vs. incoming usage collides. Opinions?

--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: Mon, 08 Nov 2004 13:47:11 +0000
Content-class: urn:content-classes:message
Subject: RE: alternatives for carrying eap lower layer information
Date: Mon, 8 Nov 2004 08:44:51 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "David Mariblanca \(EE/EEM\)" <[email-masked]>

Jari writes ...

> Yes, that was my question. I can certainly see this happening,
> but I'm uncertain if RFC 2868 is able to cope with it.

I don't think it would.  Since service provisioning in RADIUS is a
result of authentication (and authorization) I'm unsure how RADIUS would
address the set-up of a tunnel that is pre-requisite to the
authentication process.  That's what the incoming tunnel in this "two
tunnel" scenario would be, right?

-- 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: Mon, 08 Nov 2004 13:36:13 +0000
Date: Mon, 08 Nov 2004 15:34:10 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Nelson, David" <[email-masked]>
Cc: [email-masked], "David Mariblanca (EE/EEM)" <[email-masked]>
Subject: Re: alternatives for carrying eap lower layer information

Nelson, David wrote:

> Is the potential for confusion because one might have *both* an incoming
> tunnel service (potentially terminating at the NAS) and an outgoing
> tunnel service for the same connection? 

Yes, that was my question. I can certainly see this happening,
but I'm uncertain if RFC 2868 is able to cope with it.

--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, 08 Nov 2004 13:24:10 +0000
Content-class: urn:content-classes:message
Subject: RE: alternatives for carrying eap lower layer information
Date: Mon, 8 Nov 2004 08:23:18 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "David Mariblanca \(EE/EEM\)" <[email-masked]>

Jari Writes...

> The crucial question is whether the RFC 2868 attributes can
> be used for this purpose or if new ones are needed because
> the mandatory tunneling vs. incoming usage collides. Opinions?

Is the potential for confusion because one might have *both* an incoming
tunnel service (potentially terminating at the NAS) and an outgoing
tunnel service for the same connection?  Re-use of attributes seems OK
to me as long as the semantics are the same (or at least analogous) and
the context of interpretation is unambiguous.  If there is the potential
for confusion, it would be preferable to have a distinct attribute.

-- 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: Mon, 08 Nov 2004 13:08:30 +0000
Date: Mon, 08 Nov 2004 15:06:17 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "David Mariblanca (EE/EEM)" <[email-masked]>
Subject: Re: alternatives for carrying eap lower layer information

Bernard Aboba wrote:
> There are multiple problems being discussed here: 
> 
> a. Ability to differentiate tunneled EAP methods (PEAP, EAP-IKEv2, etc.) from non-tunneled EAP methods. 
> 
> b. Ability to differentiate EAP lower layers from one another (EAP-IKEv2).
> 
> In terms of problem a), the EAP peer and server know what EAP method is being negotiated (and whether it is tunneled), but the NAS is presumed to be a pass-through.  Therefore, I am not clear how the NAS would obtain information on the EAP method to put into an attribute, unless it gets this from the RADIUS server.  

Yes, it seems you are right. The endpoints of the two methods should
always be the same, so there is no need to tell the distinction to
anyone.

> In terms of problem b), it seems that the problem arises in part from the allocation of a single NAS-Port-Type (Virtual) to all tunnels.  In contrast, in RFC 2868 the combination of Tunnel-Type and Tunnel-Medium-Type attributes enables description of virtually any tunnel type over any medium.  I'd suggest that this approach is more sound than trying to allocate a NAS-Port-Type value for every conceivable combination. 

I think you are right on this one also. But are you suggesting that
these attributes be used, or just that the same idea of separating
this into two steps makes sense?

I think you must mean the latter, because it seems that
RFC 2868 is targeted towards mandatory tunneling, i.e.,
something that happens after the traffic leaves the NAS.
What we are talking about here is a service provided
as a tunnel, something that happens before the traffic
enters the NAS. This might lead to a confusion if the
same attributes were used, or am I missing something?
Presumably you could have both a virtual service coming
in and a mandatory tunnel going out...

If I am right we should do the following:

1. Use the NAS-Port-Type as the primary differentiator
    between different kinds of incoming connections to NAS.
    If its 802.11, use value 19. If its IKEv2 or any
    other sort of non-physical interface, use 5 (Virtual).
    Allocate a new value for PANA.

2. Then, if 5 (Virtual) was used above, define a new attribute
    that indicates the type of the virtual device.

    NAS-Virtual-Port-Type
      1 (IKEv2)
      2 ...

3. Optionally, define another attribute that also defines the
    type of protocol that this virtual service run on top of
    (e.g., IPv4 or IPv6).

This would work for me, I think.

The crucial question is whether the RFC 2868 attributes can
be used for this purpose or if new ones are needed because
the mandatory tunneling vs. incoming usage collides. Opinions?

--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, 08 Nov 2004 06:27:01 +0000
Date: Sun, 7 Nov 2004 22:26:31 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Presentations, please

As usual, in RADEXT WG we will be preloading the presentations onto a
single laptop.  So if you're going to be presenting tommorrow, please send
in your presentations ASAP.  the wireless network has been somewhat
unreliable so if you have a USB dongle, you might want to bring it as
well.

--
to unsubscribe send 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, 08 Nov 2004 00:52:24 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: New version of IEEE 802 Attributes Draft Available 
Date: Sun, 07 Nov 2004 20:03:11 -0500
Message-Id: <[email-masked]>

http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-02.txt
> 2.1.  Egress-VLANID
>
>    Description
> 
>      The Egress-VLANID attribute represents an allowed IEEE 802 Egress
>      VLANID for this port.  The Egress-VLANID contains two parts: the
>      first part is the VLANID, the second part indicates if this VLANID
>      is allowed for tagged or untagged packets.

  The text following this doesn't define the attribute format, or
where the VLANID goes.  ASCII art would be appreciated.

  Section 1.2 talks about possibly using the "extended attribute"
format, and says that the following lengths are calculated using the
short form.  If so, for consistency, ASCII art of the attributes
showing the short form would be good, even if there isn't consensus
that it's the proper format to use.

  Also, the data types are "Integer32" and "UInt32".  Are these RADIUS
types, or new types?  It should be clarified as to where these types
come from.

>2.3.  VLAN-Name
>
>   Description
...
>      The VLAN-Name attribute contains two parts; the first part is the
>      VLAN name, the second part indicates if frames on the VLAN for
>      this port are to be represented in tagged or untagged format.

  I suggest arranging the attribute so that the "tagged/untagged"
information is at the same offset in the attribute as the
Egress-VLANID attribute.  Putting the value after variable-length
"String" data makes it harder to parse.  Putting the value in a
different place than in the Egress-VLANID attribute creates more
"special-case" considerations in the code.

> 2.4.  User-Priority-Table
...
> Data-Type
>
>      UInt64

  Q: Is this the first proposed 64-bit integer data type in RADIUS?

>2.12.  Origin-Realm
>
>   Description
>
>      The Origin-Realm attribute contains the realm of the originator of
>      a message, as described in [RFC3588], Section 6.4.

  Add missing text: This attribute is defined as an Extended RADIUS attribute.

> 3.1.  Accounting-EAP-Auth-Method
...
>Value
>
>      The Value field is eight octets.  In case of expanded types
>      defined in [RFC3748] Section 5.7, the least significant 32 bits
>      contain the Vendor-Type field, and the next 24 bits contain the
>      Vendor-Id field.

  Leaving 8 bits of... what?

  Again, ASCII art, even using the proposed format from Appendix A
would help clarify the attribute.

  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, 08 Nov 2004 00:48:23 +0000
Date: Sun, 7 Nov 2004 16:48:14 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Final RADEXT Agenda for IETF 61

RADEXT WG Agenda
Monday, November 8, 2004
0900 - 1130

Chairs:
Bernard Aboba <[email-masked]>
David Nelson <[email-masked]>

Preliminaries (10  minutes)
	Minutes
	Bluesheets
	Agenda Bash
	Document Status
        WG Milestones

Documents in WG Last Call

RFC 2486bis, Jari Arkko (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-01.txt

RADIUS Extension for Digest Authentication, Wolfgang Beck (15 minutes)
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt

Location

RADIUS Location Attributes - Hannes Tschofenig (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-01.txt

LAN Applications

LAN attributes - Paul Congdon (10 minutes)
http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-02.txt

Bandwidth Attributes - Farid Adrangi (5 minutes)
http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capability-01.txt

Re-direction Support - Avi Lior (5 minutes)
http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-01.txt

EAP lower layer attribues for AAA protocols - Jari Arkko (5 minutes)
http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-01.txt

Accounting

Chargeable User Identity - Farid Adrangi (10 minutes)
http://www.ietf.org/internet-drafts/draft-adrangi-radius-chargeable-user-identity-02.txt

RADIUS Prepaid - Avi Lior (10 minutes)
http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-06.txt

Management

IPv6 support in the RADIUS MIBs - Dave Nelson (2 minutes)
http://www.ietf.org/rfc/rfc2618.txt
http://www.ietf.org/rfc/rfc2619.txt
http://www.ietf.org/rfc/rfc2620.txt
http://www.ietf.org/rfc/rfc2621.txt

RFC 3576 MIBs - M. Chiba (5 minutes)
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-01.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-01.txt

Wrapup

--
to unsubscribe send a message 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, 08 Nov 2004 00:05:12 +0000
Date: Sun, 7 Nov 2004 16:04:51 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: New version of IEEE 802 Attributes Draft Available

A new version of the IEEE 802 attributes draft has been prepared.  Paul
Congdon has asked me to make the new version of the document available for
your examination:

http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-02.txt

Please send comments to the RADEXT WG mailing list.

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

Delivery-date: Sun, 07 Nov 2004 20:29:32 +0000
Date: Sun, 07 Nov 2004 22:27:15 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Henning Schulzrinne <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, Hannes Tschofenig <[email-masked]>, [email-masked]
Subject: Re: [Geopriv] review of the geopriv radius location attributes draft

Henning Schulzrinne wrote:

>> draft-ietf-simple-rpid-04.txt section 3.5.
> 
> 
> I believe there was agreement on that earlier.

Great!

> See also 
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pidf-lo-03.txt, 
> Section 2.2.3. While the two are the same, there is no reference to the 
> PIDF-LO registry. Since it seems silly to have two different ones, this 
> should be called out.

OK, I didn't realize that. Yes, it should be the same.

--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: Sun, 07 Nov 2004 18:54:19 +0000
Date: Sun, 07 Nov 2004 13:53:49 -0500
From: Henning Schulzrinne <[email-masked]>
To: [email-masked]
CC: "[email-masked]'" <[email-masked]>, Hannes Tschofenig <[email-masked]>, [email-masked]
Subject: Re: [Geopriv] review of the geopriv radius location attributes draft

Jari Arkko wrote:
> 

>>        0 Reserved
>>        1 Coffee Shop
...
>>       14 Educational Institute
>>       15 Public Place
>>       16 Other
> 
> 
> This list feels a bit restrictive. What about "Car"
> or "Healt Institute" or a coffee shop in an airport?
> Suggestion: use the value set (and IANA process) from
> draft-ietf-simple-rpid-04.txt section 3.5.

I believe there was agreement on that earlier.

>>      Method (8 bits):
>>        Describes the way that the location information was
>>        derived or discovered. The following values are currently
>>        defined:
>>        (0) Global Positioning System (GPS)
>>        (1) GPS with assistance (A-GPS)
>>        (2) Manual configured information
>>        (3) Provided by DHCP
>>        (4) Triangulation: triangulated from time-of-arrival,
>>            signal strength or similar measurements
>>        (5) Cell: location of the cellular radio antenna
>>        (6) IEEE 802.11 WLAN access point
> 
> 
> I'd like to make this list a bit more technology independent.
> Or, its OK to give the location information determination
> method (such as A-GPS), but I don't think you should tie it
> to the access technology. Suggest changing the last 2 items
> to "(5) Cell: location of the network's antenna". Or use
> a macro/microcell distinction if that feels better.

See also 
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pidf-lo-03.txt, 
Section 2.2.3. While the two are the same, there is no reference to the 
PIDF-LO registry. Since it seems silly to have two different ones, this 
should be called out.

--
to unsubscribe send a message 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, 07 Nov 2004 16:26:16 +0000
Date: Sun, 07 Nov 2004 17:19:05 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>, Hannes Tschofenig <[email-masked]>, [email-masked]
Subject: review of the geopriv radius location attributes draft

Hannes et al,

I read your document on the way here and I think it
looks overall pretty good. I did have a couple of issues
that I wanted to raise, however. Here they are:

Substantial:

>    During a protocol run it is possible to return Location-Information
>    attributes which provide both location information elements.  If only
>    one location information element is provided then civil location MUST
>    be included in the request.  Additionally, geospatial location MAY be
>    provided.

Why is the civil location the one that needs to be always provided?
What if the access device is a mobile router that has a GPS attached
to it? Then it would have easy access to geospatial location but
the street address would require a huge database... Suggestion:
s/MUST/SHOULD/.

>        0 Reserved
>        1 Coffee Shop
>        2 Hotel
>        3 Airport
>        4 Mall
>        5 Restaurant
>        6 Bus
>        7 Library
>        8 Convention Center
>        9 School
>       10 Office
>       11 Airplane
>       12 Train
>       13 Ship
>       14 Educational Institute
>       15 Public Place
>       16 Other

This list feels a bit restrictive. What about "Car"
or "Healt Institute" or a coffee shop in an airport?
Suggestion: use the value set (and IANA process) from
draft-ietf-simple-rpid-04.txt section 3.5.

>      Time-to-Live (64 bits):
>        NTP timestamp for the 'time-to-live' field.

It is not clear to me if this field contains the "time
of death" of this information, or if this is some sort
of a duration value.

>      Method (8 bits):
>        Describes the way that the location information was
>        derived or discovered. The following values are currently
>        defined:
>        (0) Global Positioning System (GPS)
>        (1) GPS with assistance (A-GPS)
>        (2) Manual configured information
>        (3) Provided by DHCP
>        (4) Triangulation: triangulated from time-of-arrival,
>            signal strength or similar measurements
>        (5) Cell: location of the cellular radio antenna
>        (6) IEEE 802.11 WLAN access point

I'd like to make this list a bit more technology independent.
Or, its OK to give the location information determination
method (such as A-GPS), but I don't think you should tie it
to the access technology. Suggest changing the last 2 items
to "(5) Cell: location of the network's antenna". Or use
a macro/microcell distinction if that feels better.

>        0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |   Type        |  Length       | Code          |  Precision    |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Sighting Time                                                 ~
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Sighting Time                                                 |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Time-to-Live                                                  ~
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Time-to-Live                                                  |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |   Method      |    Location-Info                             ...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
>    time-to-live: This field gives a hint until when it should be
>       considered current.  Note that the time-to-live field is different
>       than the 'retention-expires' rule.  The data type of this field is
>       a string and the format is a 64 bit NTP timestamp [14].

The format, the talk about 64 bits, and "string" appear inconsistent.
I think you mean that the value is a 64 bit integer, not a string.

>      Note Well (variable):
>        This field contains a URI with human readable
>        privacy instructions.

Putting human readable strings about "policy" into max 253
byte fields sounds like a bad idea. Do we really need this?
Suggestion: remove or replace with a URL reference.

>    One way to ensure that the visited network and intermediate networks
>    are incapable to learn the user identity is to use EAP methods that
>    hide the user's identity either actively or passively.  Some EAP
>    methods (such as [16]) protect the user's identity against passive
>    adversaries by utilizing temporal identities.  In some cases the
>    visited network is still able to retrieve the plaintext identity of
>    the user and user identity confidentiality is only provided against
>    eavesdroppers at the wireless link.  Depending on the movement
>    patters of the user, the network topology and available roaming
>    agreements it is possible that a AAA broker is able to see both the
>    plaintext user identity and subsequent temporal identities.
>    Associating location information and the user identity is possible in
>    these cases.
> 
>    It is assumed that the true username is not carried within the
>    initial EAP-Identity Request/Response message exchange.  Support for
>    username privacy is supported with [17].
> 
>    For stronger security and privacy protection active user identity
>    confidentiality is highly suggested.  EAP methods such as [18] or
>    [19] provide such a protection.
> 
>    Unfortunately, most users are not educated about the importance of
>    user identity confidentiality and many EAP methods do not provide
>    active user identity confidentiality.  User identity confidentiality
>    is often treated as an exotic feature which mainly aims to prevent
>    eavesdroppers on the wireless link to learn the user identity of the
>    attached users.  Awareness for this threat type does often not exist.
>    In many cases it is even not possible for users to freely select
>    their favorite authentication and key exchange protocol (based on
>    their security requirements).  Instead the choice is often
>    predetermined by a given architecture.

There seems to be several problems with the above text. First of
all, I do not necessarily agree that [18] and [19] provide better
identity privacy than [16] and [17]. The privacy results depend
highly on configuration in all of the cases. For instance, [16]
says that clients can refuse to give a cleartext identity. Depending
on configuration and back-end side implementation, this is possible
in some networks and not possible in some others. Similarly, [18]
depends highly on the configuration of the trusted public key/CA.
If it is the single server's key then you are very safe. If its
the Verisign general purpose CA, anyone with a web side cert can
get you to reveal your identity.

The second issue is that this is IMHO the wrong document to
talk about identity privacy. You should talk about location
privacy, but identity privacy is a larger subject than
something that EAP methods can do. For instance, we have
identity privacy problems at the MAC, EAP, PPP, IP, ND,
and application layers.

Suggestion: remove the above text and associated references.

>    Knowing
>    the final recipient of the location information is in fact impossible
>    for RADIUS entities.

I'd like the document to talk a little bit about the use of
Diameter Redirect functionality and how that affects the issues
talked about in the security considerations section.

Editorial:

>       rule se.

s/se./set./

>    Location Information may also be reported in accouning messages.

s/accouning/accounting/

>       change their policies using the authroization framework defined in

s/authroization/authorization/

>    network to which the user has a contractal relationship.  The main

s/contractal/contractual/

>    F. Adrangi
>    Intel Corporatation

s/Corporatation/Corporation/

>    network to the home AAA server.  To embedd a Location Object into

s/embedd/embed/

>    location information.  The location infomration may refer to network

s/infomration/information/

>    The home network operator requires location informaion for

s/informaion/information/

>          is useable on constrained devices.

s/useable/usable/

>       issues in more details.

s/details/detail/

>    defined in Section 4.6 of [12] which is reused by [5] we define our

I think its 3.5 of [12], if you look at rev -04.

--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: Sat, 06 Nov 2004 00:50:20 +0000
Date: Fri, 5 Nov 2004 16:50:02 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT Agenda for IETF 61

Since RADEXT WG is meeting first thing Monday morning, we are requesting
that presenters send in their slides to myself and David ASAP.  Thanks in
advance!

Here is the agenda for the meeting:

RADEXT WG Agenda
Monday, November 8, 2004
0900 - 1130

Chairs:
Bernard Aboba <[email-masked]>
David Nelson <[email-masked]>

Preliminaries (15  minutes)
	Minutes
	Bluesheets
	Agenda Bash
	Liaison Requests
	WG Milestones
	Document Status

Documents in WG Last Call

RFC 2486bis, Jari Arkko (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-01.txt

RADIUS Extension for Digest Authentication, Wolfgang Beck (15 minutes)
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt

Other documents

RFC 3576 MIBs - M. Chiba (10 minutes)
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-01.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-01.txt

Chargeable User Identity, Farid Adrangi (10 minutes)
http://www.ietf.org/internet-drafts/draft-adrangi-radius-chargeable-user-identity-02.txt

LAN attributes, Paul Congdon (10 minutes)
http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-02.txt

Redirection, Avi Lior (5 minutes)
http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-01.txt

Prepaid Extensions, Avi Lior (10 minutes)
http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-06.txt

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

Delivery-date: Fri, 05 Nov 2004 16:19:53 +0000
Date: Fri, 5 Nov 2004 08:18:40 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: IETF 61 Agenda - Take Two

Please send agenda items to myself and David Nelson ASAP.

RADEXT WG Agenda
Monday, November 8, 2004
0900 - 1130

Chairs:
Bernard Aboba <[email-masked]>
David Nelson <[email-masked]>

Preliminaries (15  minutes)
	Minutes
	Bluesheets
	Agenda Bash
	Liaison Requests
	WG Milestones
	Document Status

Documents in WG Last Call

RFC 2486bis, Jari Arkko (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-01.txt

RADIUS Extension for Digest Authentication, Wolfgang Beck (15 minutes)
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt

Other documents

RFC 3576 MIBs - M. Chiba (10 minutes)
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-01.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-01.txt

Chargeable User Identity, Farid Adrangi (10 minutes)
http://www.ietf.org/internet-drafts/draft-adrangi-radius-chargeable-user-identity-02.txt

LAN attributes, Paul Congdon (10 minutes)
http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-02.txt

Redirection, Avi Lior (5 minutes)
http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-01.txt

Prepaid Extensions, Avi Lior (10 minutes)
http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-06.txt

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

Envelope-to: [email-masked]
Delivery-date: Thu, 04 Nov 2004 20:01:10 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: [Issue 7] Message Authenticator 
Date: Thu, 04 Nov 2004 15:11:30 -0500
Message-Id: <[email-masked]>

Avi Lior <[email-masked]> wrote:
> I think that Message-Authenticator should be mandatory.

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

Delivery-date: Thu, 04 Nov 2004 16:56:38 +0000
Date: Thu, 4 Nov 2004 08:56:15 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: [email-masked]
Subject: RE: [Issue 7] Message Authenticator

> In this email you say: "Message-Authenticator was not required in RFC 2865,
>  so that it was not sent by legacy RADIUS-clients."
>
> On the issues list you say:
> [Bernard Aboba] Use of Message Authenticator is required by RFC 2865.

The issues list has a typo.  It was required by RFC 2869 only for messages
with EAP-Message attributes.

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

Delivery-date: Thu, 04 Nov 2004 13:36:33 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, [email-masked]
Subject: RE: [Issue 7] Message Authenticator
Date: Thu, 4 Nov 2004 08:35:53 -0500 

Hi Bernard,

I think that Message-Authenticator should be mandatory.

Points of clarification:

In this email you say: "Message-Authenticator was not required in RFC 2865, 
 so that it was not sent by legacy RADIUS-clients."

On the issues list you say: 
[Bernard Aboba] Use of Message Authenticator is required by RFC 2865. 

Can you please clarify these seemly contrary statements.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: November 3, 2004 11:35 PM
> To: [email-masked]
> Subject: Re: [Issue 7] Message Authenticator
> 
> 
> Wolfgang Beck wrote:
> 
> "RFC 2869 is informational. I see that it is useful but
> I hesitate to make it mandatory.
> 
> new text:
> 'Informational RfC 3579 [RFC3579], section 3.2 describes
> a Message-Authenticator attribute which MAY be used to 
> protect the integrity of RADIUS messages.'"
> 
> Omitting Message-Authenticator enables an attacker to forge 
> Access-Request packets.  The reason RFC 3579 could not make 
> use of Message-Authenticator mandatory for all RADIUS packets 
> (just for packets containing an EAP-Message attribute) was 
> because Message-Authenticator was not required in RFC 2865, 
> so that it was not sent by legacy RADIUS-clients.
> 
> That problem does not occur here;  Digest Authentication is a 
> new RADIUS capability.
> 
> --
> to unsubscribe send 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, 04 Nov 2004 12:05:29 +0000
Date: Thu, 04 Nov 2004 14:03:28 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: [Issue 15] Editorial NITs with RFC 2486bis-01

Here's a new revision that addresss both the examples
and nits:

   http://www.arkko.com/publications/nai/naibis.txt
   http://www.arkko.com/publications/nai/naibisdiff.html

Sufficient examples? Anything else?

--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, 04 Nov 2004 11:41:49 +0000
Date: Thu, 04 Nov 2004 13:38:40 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: [Issue 15] Editorial NITs with RFC 2486bis-01

Hi Bernard,

Thanks for the nits check. Inline:

> Section 1.1:  You need an extra line space between definitions.

Yes. XML2RFC changed in this respect a number of revisions ago.
I have now put in the extra lines.

> Change: "ISP- provided" to "ISP-provided"

Ok.

> Section 3, 4 and 5 probably do not require a page break (e.g. can start in
> the middle of the page).

Ok. Hmm... I don't seem to be able to control XML2RFC well enough
prevent this from happening. I'll leave it to the RFC Editor.

> There is no reference to [8] in the document (RFC 2486).

The reference has been added to parts that discuss RFC 2486.

> BTW, what is the status of the SASLPrep document?
> 
> The reference is normative, meaning that RFC 2486bis can't be published
> until it is resolved.

I think it is already an RFC. Checking... no, but its in
the RFC Editor's queue. So no problem.

--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, 04 Nov 2004 11:41:41 +0000
Date: Thu, 04 Nov 2004 13:02:45 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: [Issue 16] Special Characters in RFC 2486bis-01

Bernard Aboba wrote:
> In RFC 2486, "[email-masked]" is a valid NAI, and it would appear
> that this is also true in RFC 2486bis, due to the following rules:
> 
> username = dot-string
> dot-string = string
> dot-string =/ dot-string "." string
> 
> Or am I missing something?

No -- you are not missing anything. My mistake on reading
the ABNF. Sorry! But the ABNF is correct.

> At a minimum, I think we may need additional examples of legal and illegal
> NAIs.

Hmm... I'm not completely sure about that. But I see that you
have some nits e-mail about the document too, so if I have to
submit a new one anyway I could add a firstname.lastname example.
We already have legal/illegal special character examples.

--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, 04 Nov 2004 08:51:12 +0000
content-class: urn:content-classes:message
Subject: CUI: WG Work Item
Date: Thu, 4 Nov 2004 10:50:55 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Bernard,=20

I also think CUI is suitable for a WG item. Currently, the concept of
CUI has been adopted
by several well established roaming organizations and also it has
already been experimented among
number of operators. Thus there seems to be real need for it in various
roaming scenarios where
existing mechanisms were not considered to be sufficient. Should there
be open issues or shortcomings
in the latest Draft those could be resolved within this WG.

Br,
	Jouni

--=20
Jouni Korhonen - Senior Researcher
Emerging Technologies and Innovations
TeliaSonera Finland

>
> Over the last month, there has been considerable discussion of the
> Chargeable User Identity document.
>
> Given the considerable amount of discussion, it would appear that WG
> participants have had sufficient time to determine whether this
document
> is suitable for becoming a RADEXT WG work item:
>
>
http://www.ietf.org/internet-drafts/draft-adrangi-radius-chargeable-user
-identity-02.txt
>
> Therefore, we are going to call for Consensus on whether the document
is
> suitable for becoming a WG work item.
>
> If you believe that the document is suitable please send mail with
"CUI:
> WG Work Item" in the subject, detailing why you think the draft is
> suitable for  becoming a RADEXT WG Work item.
>
> If you believe that there are major problems with the draft or that
the
> draft is unnecessary, please send mail with "CUI: unsuitable" in the
> subject line, and in the body explain your objections.
>
> Thank you!

--
to unsubscribe send a message 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, 04 Nov 2004 06:46:31 +0000
content-class: urn:content-classes:message
Subject: CUI:WG Work Item
Date: Thu, 4 Nov 2004 08:46:01 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

> If you believe that the document is suitable please send mail with =
"CUI:
> WG Work Item" in the subject, detailing why you think the draft is
> suitable for  becoming a RADEXT WG Work item.

Bernard,=20

I think this is suitable for a WG item.  I think such a mechanism is =
needed
in some roaming scenarios, such as ones being developed in GSMA.  The =
current
mechanisms are insufficient. =20

I think the draft could better explain the problem and usage of the CUI, =
and
perhaps contain a section on applicability of this mechanism.

I've been busy with other things recently, but if needed, I can =
contribute to=20
resolving any open issues with this draft.

John

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

Delivery-date: Thu, 04 Nov 2004 05:23:59 +0000
Date: Wed, 3 Nov 2004 21:23:46 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Call for review of draft-ietf-geopriv-radius-lo-01.txt

The following document is a WG work item of the GEOPRIV WG:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-01.txt

Since this document carries GEOPRIV information in RADIUS, we are asking
participants in the RADEXT WG to review the document.  If you have
GEOPRIV-related comments, please post these to the GEOPRIV WG mailing
list.  However, if your comments relate to the draft's use of RADIUS,
please post those comments to the RADEXT WG mailing list.

As usual, please put [Issue] in the Subject line, and post the issues in
the format specified on the RADEXT WG Issues list, so that they can be
tracked:

http://www.drizzle.com/~aboba/RADEXT/

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

Delivery-date: Thu, 04 Nov 2004 05:01:32 +0000
Date: Wed, 3 Nov 2004 21:01:25 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Call for Consensus: Adoption of CUI as a RADEXT WG Work Item

Over the last month, there has been considerable discussion of the
Chargeable User Identity document.

Given the considerable amount of discussion, it would appear that WG
participants have had sufficient time to determine whether this document
is suitable for becoming a RADEXT WG work item:

http://www.ietf.org/internet-drafts/draft-adrangi-radius-chargeable-user-identity-02.txt

Therefore, we are going to call for Consensus on whether the document is
suitable for becoming a WG work item.

If you believe that the document is suitable please send mail with "CUI:
WG Work Item" in the subject, detailing why you think the draft is
suitable for  becoming a RADEXT WG Work item.

If you believe that there are major problems with the draft or that the
draft is unnecessary, please send mail with "CUI: unsuitable" in the
subject line, and in the body explain your objections.

Thank you!

--
to unsubscribe send a message 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, 04 Nov 2004 04:54:50 +0000
Date: Wed, 3 Nov 2004 20:54:34 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Verification of WG consensus on Digest Issues 3, 4, 5, 6, 8, 11

The RADEXT WG Issue list is posted here:
http://www.drizzle.com/~aboba/RADEXT/

For Issues 3, 4, 5, 6, 8, 11 we have a proposed resolution, included in
the -04 draft:
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt

However, review of the WG mailing list did not disclose discussion of the
proposed resolutions, so that WG consensus could not be determined.

If you have read the -04 document and approve of the proposed resolutions
to Issues 3, 4, 5, 6, 8, and 11, as embodied in the -04 document, please
send email to this list with "Digest: Agree" in the subject.  This is
particularly important if you are the submitter of the Issue in question.

If you do not agree with the proposed resolutions, please send email with
[Issue #] in the title, detailing your objections to the
proposed resolutions.

--
to unsubscribe send a message 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, 04 Nov 2004 04:34:51 +0000
Date: Wed, 3 Nov 2004 20:34:37 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: [Issue 7] Message Authenticator

Wolfgang Beck wrote:

"RFC 2869 is informational. I see that it is useful but
I hesitate to make it mandatory.

new text:
'Informational RfC 3579 [RFC3579], section 3.2 describes
a Message-Authenticator attribute which MAY be used to protect the
integrity of RADIUS messages.'"

Omitting Message-Authenticator enables an attacker to forge Access-Request
packets.  The reason RFC 3579 could not make use of Message-Authenticator
mandatory for all RADIUS packets (just for packets containing an
EAP-Message attribute) was because Message-Authenticator was not required
in RFC 2865, so that it was not sent by legacy RADIUS-clients.

That problem does not occur here;  Digest Authentication is a new RADIUS
capability.

--
to unsubscribe send a message 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, 04 Nov 2004 03:58:39 +0000
Date: Wed, 3 Nov 2004 19:58:20 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: [Issue 15] Editorial NITs with RFC 2486bis-01

Issue 15: Editorial NITs with RFC 2486bis-01
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: October 29, 2004
Reference:
Document: RFC2486bis-01
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

Section 1.1:  You need an extra line space between definitions.  For
example, change:

" This document frequently uses the following terms:
Network Access Identifier"

To:
" This document frequently uses the following terms:

Network Access Identifier"

Change: "ISP- provided" to "ISP-provided"

Section 3, 4 and 5 probably do not require a page break (e.g. can start in
the middle of the page).

There is no reference to [8] in the document (RFC 2486).

BTW, what is the status of the SASLPrep document?

The reference is normative, meaning that RFC 2486bis can't be published
until it is 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: Thu, 04 Nov 2004 03:46:28 +0000
Date: Wed, 3 Nov 2004 19:46:09 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: [Issue 16] Special Characters in RFC 2486bis-01

In RFC 2486, "[email-masked]" is a valid NAI, and it would appear
that this is also true in RFC 2486bis, due to the following rules:

username = dot-string
dot-string = string
dot-string =/ dot-string "." string

Or am I missing something?

At a minimum, I think we may need additional examples of legal and illegal
NAIs.

--------------------------------------------------------------------
Issue 16: Special Characters in RFC 2486bis-01
Submitter: Paola Pappalardo
Submitter email address: [email-masked]
Date first submitted: October 29, 2004
Reference: http://ops.ietf.org/lists/radiusext/2004/msg00804.html
Document: RFC2486bis-01
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

I have to handle the Network Access Identifier (NAI) for my work. I have
read the RFC 2486 and I'm a little confused about the use of special
characters,
like  "<" / ">" / "(" / ")" / "[" / "]" / "\" / "."  / "," / ";" / ":" /
"@" / %x22  / Ctl,

in the NAI username.

Can you help me? Can you please give some examples of valid NAI containing
special characters?
[Jari Arkko]
The issue is what "special" characters, not just alphabets
and digits can appear in NAIs. The realm part rules are
according to the usual DNS, which I think allows only "-"
and ".". The user name part allows more special characters,
but disallows some others. A couple of valid examples:

    [email-masked]
    [email-masked]

A couple of invalid examples:

    [email-masked]
    user>[email-masked]

Nevertheless, there's an escape mechanism that allows
even special characters. Example:

    jari\[email-masked]

If you read the new draft you will see that the ABNF syntax is hopefully
easier to read
than in RFC 2486, because the treatment of each character has
been listed on its own line, and you do not have read the
comments to find out what actual characters are allowed.

--
to unsubscribe send a message 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, 04 Nov 2004 01:18:07 +0000
Date: Wed, 3 Nov 2004 17:17:31 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG Agenda for IETF 61

We finally have a confirmed slot at IETF 61.  Here is a preliminary agenda
for the RADEXT WG meeting.  Please send agenda items to myself and David
Nelson ASAP.

RADEXT WG Agenda
Monday, November 8, 2004
0900 - 1130

Chairs:
Bernard Aboba <[email-masked]>
David Nelson <[email-masked]>

Preliminaries (15  minutes)
	Minutes
	Bluesheets
	Agenda Bash
	Liaison Requests
	WG Milestones
	Document Status

Documents in WG Last Call

RFC 2486bis, Jari Arkko (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-01.txt

RADIUS Extension for Digest Authentication, Wolfgang Beck (15 minutes)
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt

Other documents

RFC 3576 MIBs - M. Chiba (5 minutes)
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-01.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-01.txt

Chargeable User Identity, Farid Adrangi (5 minutes)
http://www.ietf.org/internet-drafts/draft-adrangi-radius-chargeable-user-identity-02.txt

LAN attributes, Paul Congdon (5 minutes)
http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-02.txt

Redirection, Avi Lior (5 minutes)
http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-01.txt

Prepaid Extensions, Avi Lior (5 minutes)
http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-06.txt

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

Delivery-date: Tue, 02 Nov 2004 15:07:16 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Meeting Slot at IETF 61
Date: Tue, 2 Nov 2004 10:06:24 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> I will post an update to the list if our meeting schedule
> changes in the Final Agenda.

It has changed in the "Almost Final" Agenda.  The RADEXT WG is now
scheduled to meet on Monday November 8, 2004 from 09:00 to 11:30 (AM)
EST (the morning meeting slot).

--
to unsubscribe send a message 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, 01 Nov 2004 19:06:55 +0000
Content-class: urn:content-classes:message
Subject: RADEXT Meeting Slot at IETF 61
Date: Mon, 1 Nov 2004 14:05:04 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

The RADEXT WG will be meeting at the 61st IETF in Washington, DC on
Monday November 8, 2004 from 19:30 to 22:00 PM EST (evening meeting
slot).  The latest IETF 61 Draft Agenda is posted at:
http://www.ietf.org/meetings/agenda_61.html  I will post an update to
the list if our meeting schedule changes in the Final Agenda.

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