Subject: RFC 2486bis issue: "Decorated" NAIs and IDN support
From: Bernard Aboba <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Date: Wed, 29 Jun 2005 16:39:04 -0700 (PDT)

Patrick, Paul & Ted --

We are having difficulty finishing the RFC 2486bis document, due to
an issue relating to th impact of IDN on Network Access Identifier
"decoration".

The issue is that 3GPP wants to be able to "decorate" NAIs in order
to describe source routes between RADIUS realms.  The format of
decoration is similar to the old format for routing email within
UUCP.  For example,  [email-masked] would indicate
that authentication is to be proxied to Microsoft via a local
Access Point attaching to the British Telecom network.

The issue arises because many clients enter the entire NAI in
UTF-8, whereas in some AAA protocols (such as Diameter), the
realm name may be used in a DNS query in order to locate the
Diameter server for that realm.

This means that a user could potentially enter an NAI in UTF-8
that might not be convertable to a valid FQDN in the IDN format.

For example, [email-masked] -> [email-masked]
after it is forwarded by the bt.com RADIUS proxy.  In the latter
construction the realm portion (microsoft.com) may need to be
converted from UTF-8 to IDN to enable use of DNS for service
location.

Can you look at the below thread and give us your feedback on how
we should think about this?

Bernard Aboba
Co-Chair, RADEXT WG

"Oh blinding light,
Oh light that blinds,
I cannot see --
Look out for me!"

-- Firesign Theatre

[BA] Am I correct in saying that the recommended approach implies that
RADIUS
proxies don't have to do any character set translations when processing
"decorated" NAIs?  If so, that is a good thing.

[Jari Arkko]
Well, no you are not correct :-( If the realm part is an IDN-unaware
name slot, then transformations from the username part will
have to do conversions.

On the other hand, it seems to me that conversions are
going to be necessary anyway in some circumstance, and
this choice appears to place the conversion burden on a relatively
rare function, and in a place where its known for sure that
you need to do a conversion. So I think we are picking
the lesser of two evils :-)

(If we choose UTF-8 for realm part then one might ask
if the proxies doing routing or policy lookups based on the
realm part would have to normalize realms before comparisons
and lookups; its perfectly reasonable that implementations
or even users send ASCII based versions of international
domain names.)

[BA] If internaut.com contained an international character set (e.g.
UTF-8),
then a conversion should still not be necessary in RADIUS, since DNS
lookups aren't done on the realm portion, right?

[Jari Arkko]
Well, this assumes that DNS lookups are the only reason
for conversion. I suspect that normalization/canonization
is necessary also for other purposes, such as comparisons,
lookup, and matching in proxies and home servers.

[BA] Question: does this have implications for EAP peer implementations
that
just send UTF-8 in the EAP-Response Identity?  I think it doesn't imply
that they should check that the realm part is compatible with the
"IDN-unaware domain name slot" grammar, but I wanted to check.

[Jari Arkko]
Yes. But my understanding is that implementations that
correctly process international names will ALWAYS have
to do something to the user input that they receive, to
normalize and check it in some manner. Section 2.4 of
our draft lists the requirements for the username part
that we have now. It seems that calling routine a or b
does not matter so much for implementations. Of course
there are likely implementations that just pass input bytes
on, but this appears to be something that has be fixed
anyway.

[BA] The implied requirement is that users send domain names in the same
format
that they are included in the RADIUS proxy routing table.  As Alan noted,
this assumption seems to work today.

[Jari Arkko]
Yes. One case where pure reliance on users might still fail is roaming, if
you have one network which has stored the name in UTF-8 and another
one in ASCII...

[Alan DeKok]

  I'm confused.  If it can be represented in 7-bit ASCII, it's UTF-8
compatible.  The only concern, then, is the UTF-8 extensions to ASCII
which may "map" to 8-bit ASCII.  That's the only situation where the
"same" name can have two representations.

  If that happens, then the users won't be able to authenticate, and
the problem will quickly be brought to the attention of the
appropriate admin.

  As a related question, which user-client implementations permit
entry of data in 8-bit ASCII, and which permit UTF-8?  Maybe I can do
<ALT>-<foo> on a Windows box to type in 8-bit characters.  But I'm
sure I can change the locale, and type in glyphs which end up as
UTF-8.

[Jari Arkko] the user wouldn't know what to enter to get his transaction
routed through the network. That's why I believe its still useful
for the RFC to indicate what the correct format is.

[Alan DeKok]
  I don't think the user has a *choice* as to how to enter his name.  The
user-client interface will most likely make that choice for him.

I just don't see this as a problem.

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

Envelope-to: [email-masked]
Delivery-date: Wed, 29 Jun 2005 18:04:48 +0000
From: "Alan DeKok" <[email-masked]>
To: Jari Arkko <[email-masked]>, Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: Closing the NAIbis i18n discussion 
Date: Wed, 29 Jun 2005 14:03:38 -0400
Message-Id: <[email-masked]>

Jari Arkko <[email-masked]> wrote:
> >The implied requirement is that users send domain names in the same format
> >that they are included in the RADIUS proxy routing table.  As Alan noted,
> >this assumption seems to work today.
> >  
> >
> Yes. One case where pure reliance on users might still fail is roaming, if
> you have one network which has stored the name in UTF-8 and another
> one in ASCII...

  I'm confused.  If it can be represented in 7-bit ASCII, it's UTF-8
compatible.  The only concern, then, is the UTF-8 extensions to ASCII
which may "map" to 8-bit ASCII.  That's the only situation where the
"same" name can have two representations.

  If that happens, then the users won't be able to authenticate, and
the problem will quickly be brought to the attention of the
appropriate admin.

  As a related question, which user-client implementations permit
entry of data in 8-bit ASCII, and which permit UTF-8?  Maybe I can do
<ALT>-<foo> on a Windows box to type in 8-bit characters.  But I'm
sure I can change the locale, and type in glyphs which end up as
UTF-8.

> the user wouldn't know what to enter to get his transaction
> routed through the network. That's why I believe its still useful
> for the RFC to indicate what the correct format is.

  I don't think the user has a *choice* as to how to enter his name.  The 
user-client interface will most likely make that choice for him.

  I just don't see this as a problem.

  Alan DeKok.

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

Delivery-date: Wed, 29 Jun 2005 16:07:41 +0000
Date: Wed, 29 Jun 2005 19:07:18 +0300
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked], Alan DeKok <[email-masked]>
Subject: Re: Closing the NAIbis i18n discussion

Bernard Aboba wrote:

>>Well, no you are not correct :-( If the realm part is an IDN-unaware
>>name slot, then transformations from the username part will
>>have to do conversions.
>>    
>>
>
>Can you give an example?
>  
>
internaut<INTCHARINUTF8>[email-masked] ->
bernarda@internaut<INTCHARINASCII>.com

>[email-masked] -> [email-masked] should not require
>converting internaut.com (straight ASCII), right?
>  
>
Right.

>If internaut.com contained an international character set (e.g. UTF-8),
>then a conversion should still not be necessary in RADIUS, since DNS
>lookups aren't done on the realm portion, right?
>  
>
Well, this assumes that DNS lookups are the only reason
for conversion. I suspect that normalization/canonization
is necessary also for other purposes, such as comparisons,
lookup, and matching in proxies and home servers.

>  
>
>>On the other hand, it seems to me that conversions are
>>going to be necessary anyway in some circumstance, and
>>this choice appears to place the conversion burden on a relatively
>>rare function, and in a place where its known for sure that
>>you need to do a conversion. So I think we are picking
>>the lesser of two evils :-)
>>    
>>
>
>I agree that conversions may need to be done in some circumstances. But
>since this is not a common case (might even be nonexistent in RADIUS),
>there is no need to optimize for it.
>  
>
Right.

>  
>
>>(If we choose UTF-8 for realm part then one might ask
>>if the proxies doing routing or policy lookups based on the
>>realm part would have to normalize realms before comparisons
>>and lookups; its perfectly reasonable that implementations
>>or even users send ASCII based versions of international
>>domain names.)
>>    
>>
>
>The implied requirement is that users send domain names in the same format
>that they are included in the RADIUS proxy routing table.  As Alan noted,
>this assumption seems to work today.
>  
>
Yes. One case where pure reliance on users might still fail is roaming, if
you have one network which has stored the name in UTF-8 and another
one in ASCII... the user wouldn't know what to enter to get his transaction
routed through the network. That's why I believe its still useful
for the RFC to indicate what the correct format is.

>>But this is just my not-so-educated understanding of
>>the situation. Other thoughts?
>>    
>>
>
>I'm even less educated than you.  Perhaps we need to bring in an expert to
>validate this?
>  
>
We already tried...

--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, 29 Jun 2005 13:39:56 +0000
Date: Wed, 29 Jun 2005 06:38:31 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked], Alan DeKok <[email-masked]>
Subject: Re: Closing the NAIbis i18n discussion

> Well, no you are not correct :-( If the realm part is an IDN-unaware
> name slot, then transformations from the username part will
> have to do conversions.

Can you give an example?

[email-masked] -> [email-masked] should not require
converting internaut.com (straight ASCII), right?

If internaut.com contained an international character set (e.g. UTF-8),
then a conversion should still not be necessary in RADIUS, since DNS
lookups aren't done on the realm portion, right?

> On the other hand, it seems to me that conversions are
> going to be necessary anyway in some circumstance, and
> this choice appears to place the conversion burden on a relatively
> rare function, and in a place where its known for sure that
> you need to do a conversion. So I think we are picking
> the lesser of two evils :-)

I agree that conversions may need to be done in some circumstances. But
since this is not a common case (might even be nonexistent in RADIUS),
there is no need to optimize for it.

> (If we choose UTF-8 for realm part then one might ask
> if the proxies doing routing or policy lookups based on the
> realm part would have to normalize realms before comparisons
> and lookups; its perfectly reasonable that implementations
> or even users send ASCII based versions of international
> domain names.)

The implied requirement is that users send domain names in the same format
that they are included in the RADIUS proxy routing table.  As Alan noted,
this assumption seems to work today.

> But this is just my not-so-educated understanding of
> the situation. Other thoughts?

I'm even less educated than you.  Perhaps we need to bring in an expert to
validate this?

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

Delivery-date: Wed, 29 Jun 2005 11:54:01 +0000
Date: Wed, 29 Jun 2005 14:53:26 +0300
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked], Alan DeKok <[email-masked]>
Subject: Re: Closing the NAIbis i18n discussion

Bernard Aboba wrote:

>I think this makes sense.  Perhaps you should cite RFC 3490 in the
>document, to make it clear why this approach was taken.
>  
>
Yes.

>Am I correct in saying that the recommended approach implies that RADIUS
>proxies don't have to do any character set translations when processing
>"decorated" NAIs?  If so, that is a good thing.
>  
>
Well, no you are not correct :-( If the realm part is an IDN-unaware
name slot, then transformations from the username part will
have to do conversions.

On the other hand, it seems to me that conversions are
going to be necessary anyway in some circumstance, and
this choice appears to place the conversion burden on a relatively
rare function, and in a place where its known for sure that
you need to do a conversion. So I think we are picking
the lesser of two evils :-)

(If we choose UTF-8 for realm part then one might ask
if the proxies doing routing or policy lookups based on the
realm part would have to normalize realms before comparisons
and lookups; its perfectly reasonable that implementations
or even users send ASCII based versions of international
domain names.)

>Question: does this have implications for EAP peer implementations that
>just send UTF-8 in the EAP-Response Identity?  I think it doesn't imply
>that they should check that the realm part is compatible with the
>"IDN-unaware domain name slot" grammar, but I wanted to check.
>  
>
Yes. But my understanding is that implementations that
correctly process international names will ALWAYS have
to do something to the user input that they receive, to
normalize and check it in some manner. Section 2.4 of
our draft lists the requirements for the username part
that we have now. It seems that calling routine a or b
does not matter so much for implementations. Of course
there are likely implementations that just pass input bytes
on, but this appears to be something that has be fixed
anyway.

But this is just my not-so-educated understanding of
the situation. Other thoughts?

--Jari

>On Mon, 20 Jun 2005, Jari Arkko wrote:
>
>  
>
>>Hello folks,
>>
>>We need to close this and move ahead. It seems that
>>we have consensus to do as little as possible, though
>>opinions differ as to what that exactly means :-)
>>
>>I'd like to go with UTF-8 usernames + plain old DNS
>>names for the realm part, which was also supported
>>by Alan's e-mail quoted at the end of this message.
>>This seems to work most of the time, and is also
>>according to the MUSTs in RFC 3490:
>>
>>   An "IDN-unaware domain name slot" is defined in this document to be
>>   any domain name slot that is not an IDN-aware domain name slot.
>>   Obviously, this includes any domain name slot whose specification
>>   predates IDNA.
>>
>>That is, our NAIs are IDN-unaware name slots, because
>>2486 < 3490 ;-)
>>
>>   2) Whenever a domain name is put into an IDN-unaware domain name slot
>>      (see section 2), it MUST contain only ASCII characters.
>>
>>That is, RFC 3490 requires us to do this...
>>
>>If the rest of you agree then I will submit the document in a couple
>>of days and we can move on. Otherwise, let me know what I should
>>put in.
>>
>>--Jari
>>
>>Alan DeKok wrote:
>>
>>    
>>
>>>Jari Arkko <[email-masked]> wrote:
>>>
>>>
>>>      
>>>
>>>>>Years of deployment without complaints is a strong indicator that a
>>>>>problem doesn't exist.  Let's let sleeping dogs lie.
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>Ok. But I'd still like to understand this better. Or I really
>>>>need to, because we need to decide whether to
>>>> (a) strip i18n out of the bis draft altogether
>>>> (b) keep current utf-8 + plain-old-dns-name-but-as-idnunaware-
>>>>       name-slot scheme
>>>> (c) change to utf-8 altogether
>>>>        
>>>>
>>> I would say (b).
>>>
>>>      
>>>
>>>>Also, before you answer the above lets try to get some
>>>>understanding on whether "no complaints" means
>>>> (i) no one is using i18n dns names yet. i have some sense
>>>>     that this might be the case, as at least here in Finland
>>>>     I think they allowed the new types of allocations
>>>>     very recently.
>>>>        
>>>>
>>> Mosrly.  i18n domain names have historically been rare.
>>>
>>>      
>>>
>>>> (ii) existing support (just let utf-8 through) is working
>>>>      well
>>>>        
>>>>
>>> Definitely.
>>>
>>>      
>>>
>>>> (iii) solutions from a single vendor work well, but
>>>>       not a lot of interop has been attempted with this
>>>>       particular case
>>>>        
>>>>
>>> I would say that interoperability hasn't been *reported* on.  But
>>>the deployments of RADIUS are so varied that I would be surprised if
>>>interoperability isn't already being tested in live situations.
>>>
>>> I haven't heard of i18n problems with interoperability.  My guess,
>>>therefore, is that such problems are rare.
>>>
>>> Alan DeKok.
>>>
>>>      
>>>
>
>
>  
>

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

Delivery-date: Tue, 28 Jun 2005 20:37:55 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Congdon, Paul T (ProCurve)'" <[email-masked]>, Bernard Aboba <[email-masked]>, "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
Cc: [email-masked]
Subject: RE: Radext vlan,priority, filtering RFC - new draft (00d)
Date: Tue, 28 Jun 2005 15:36:55 -0500

Sorry, I can't find this draft, is it released yet?

Thanks,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Congdon, Paul T (ProCurve)
Sent: Tuesday, June 28, 2005 10:48 AM
To: Bernard Aboba; Sanchez, Mauricio (PNB Roseville)
Cc: [email-masked]
Subject: RE: Radext vlan,priority, filtering RFC - new draft (00d)

> Subject: RE: Radext vlan,priority, filtering RFC - new draft (00d)
> 
> > Here is a new updated draft, -00d.  Changes in this version are:
> > - section 3.5: Propose new NAS-filter-rule argument 
> (redir_cnt) to an 
> > http redirect rule.  Allows a rule to match a set number of times 
> > before NAS removes it from the active rule set.
> 
> Before adding this, I'd like to see if there is widespread 
> support for this particular "whistle".
> 

There are more than 20 people working in GSMA that have requested and
support this feature.  It has been limited to http only and is supported
by the design team.  It is currently in the base draft, so we can
discuss comments around this during the WG review of the document.

Paul

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

--
to unsubscribe send a message 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, 28 Jun 2005 15:49:12 +0000
Content-class: urn:content-classes:message
Subject: RE: Radext vlan,priority, filtering RFC - new draft (00d)
Date: Tue, 28 Jun 2005 08:48:27 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
Cc: <[email-masked]>

=20
> Subject: RE: Radext vlan,priority, filtering RFC - new draft (00d)
>=20
> > Here is a new updated draft, -00d.  Changes in this version are:
> > - section 3.5: Propose new NAS-filter-rule argument=20
> (redir_cnt) to an=20
> > http redirect rule.  Allows a rule to match a set number of times=20
> > before NAS removes it from the active rule set.
>=20
> Before adding this, I'd like to see if there is widespread=20
> support for this particular "whistle".
>=20

There are more than 20 people working in GSMA that have requested and
support this feature.  It has been limited to http only and is supported
by the design team.  It is currently in the base draft, so we can
discuss comments around this during the WG review of the document.

Paul

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

Delivery-date: Mon, 27 Jun 2005 20:09:30 +0000
Content-class: urn:content-classes:message
Subject: RE: Scheduling for IETF-63
Date: Mon, 27 Jun 2005 13:09:09 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>

I would like some time to discuss the filtering, VLANs and priority =
draft (formerly known as IEEE 802 attributes draft).

Paul=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Monday, June 27, 2005 12:44 PM
> To: [email-masked]
> Cc: Nelson, David; Bernard Aboba
> Subject: Scheduling for IETF-63
>=20
> I have requested one 2-hour session for RADEXT at IETF-63. =20
> This is the same amount of time we had at IETF-62.
>=20
> In order to start planning the WG meeting agenda, and to be=20
> sure we can fit all the requested agenda items in the=20
> allotted time, I'm requesting that anyone wishing time on the=20
> RADEXT WG agenda for IETF-63 please send e-mail to the chairs=20
> indicating your request, including the topic, the Internet=20
> Draft name, and the amount of time.
>=20
> Please do this now (or very soon thereafter) as the deadline=20
> for secondary scheduling requests is fast approaching!
>=20
> -- Dave
> =A0
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Mon, 27 Jun 2005 19:45:17 +0000
Content-class: urn:content-classes:message
Subject: Scheduling for IETF-63
Date: Mon, 27 Jun 2005 15:43:34 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, "Bernard Aboba" <[email-masked]>

I have requested one 2-hour session for RADEXT at IETF-63.  This is the =
same amount of time we had at IETF-62.

In order to start planning the WG meeting agenda, and to be sure we can =
fit all the requested agenda items in the allotted time, I'm requesting =
that anyone wishing time on the RADEXT WG agenda for IETF-63 please send =
e-mail to the chairs indicating your request, including the topic, the =
Internet Draft name, and the amount of time.

Please do this now (or very soon thereafter) as the deadline for =
secondary scheduling requests is fast approaching!

-- Dave
=A0

--
to unsubscribe send a message 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, 23 Jun 2005 12:25:18 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Proposed Resolution to Issue 76
Date: Thu, 23 Jun 2005 14:24:44 +0200

Proposed solution:
draft-ietf-radext-digest-auth-02.txt should fix the issue.

The requested and included editorial changes are too numerous
to list them here.

Wolfgang

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

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

Delivery-date: Thu, 23 Jun 2005 02:18:50 +0000
Date: Wed, 22 Jun 2005 19:18:35 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
cc: [email-masked]
Subject: RE: Radext vlan,priority, filtering RFC - new draft (00d)

> Here is a new updated draft, -00d.  Changes in this version are:
> - section 3.5: Propose new NAS-filter-rule argument (redir_cnt) to an
> http redirect rule.  Allows a rule to match a set number of times before
> NAS removes it from the active rule set.

Before adding this, I'd like to see if there is widespread support for
this particular "whistle".

> - section 3.5 & 4.1: Propose new accounting attribute
> (acct-nas-filter-rule) for NAS-filter-rule to provide some insight into
> how many matches have occurred on specific rule(s).

This seems like something that is more appropriate for logging or
management than RADIUS Accounting.  If the desire is to initiate logging,
then it might make sense to add "log" as an appendage to a rule.

> - section 3.6: Added some wording regarding the possible need to
> fragment a qos filter across multiple qos-filter-rule attributes due to
> RADIUS message limits of <253 bytes.

> - section 6: Enumerated need for IANA assignment of new values for
> attributes in this document

OK.

BTW, I am wondering if the group has done a comprehensive look at IEEE 802
documents to understand what RADIUS attributes are needed.  For example,
my understanding is that there are 802.1X implementations that can choose
whether to only allow a single MAC address on a port (more than one MAC
causes port shutdown) or whether to allow shared media (the default).  In
the former mode, the behavior is roughly equivalent to MAC filering in
that only packets originating from the supplicant MAC address are allowed
(e.g. the port cannot operate as a trunk port).

--
to unsubscribe send a message 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, 23 Jun 2005 01:44:28 +0000
Date: Wed, 22 Jun 2005 18:44:11 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked], Alan DeKok <[email-masked]>
Subject: Re: Closing the NAIbis i18n discussion

I think this makes sense.  Perhaps you should cite RFC 3490 in the
document, to make it clear why this approach was taken.

Am I correct in saying that the recommended approach implies that RADIUS
proxies don't have to do any character set translations when processing
"decorated" NAIs?  If so, that is a good thing.

Question: does this have implications for EAP peer implementations that
just send UTF-8 in the EAP-Response Identity?  I think it doesn't imply
that they should check that the realm part is compatible with the
"IDN-unaware domain name slot" grammar, but I wanted to check.

On Mon, 20 Jun 2005, Jari Arkko wrote:

> Hello folks,
>
> We need to close this and move ahead. It seems that
> we have consensus to do as little as possible, though
> opinions differ as to what that exactly means :-)
>
> I'd like to go with UTF-8 usernames + plain old DNS
> names for the realm part, which was also supported
> by Alan's e-mail quoted at the end of this message.
> This seems to work most of the time, and is also
> according to the MUSTs in RFC 3490:
>
>    An "IDN-unaware domain name slot" is defined in this document to be
>    any domain name slot that is not an IDN-aware domain name slot.
>    Obviously, this includes any domain name slot whose specification
>    predates IDNA.
>
> That is, our NAIs are IDN-unaware name slots, because
> 2486 < 3490 ;-)
>
>    2) Whenever a domain name is put into an IDN-unaware domain name slot
>       (see section 2), it MUST contain only ASCII characters.
>
> That is, RFC 3490 requires us to do this...
>
> If the rest of you agree then I will submit the document in a couple
> of days and we can move on. Otherwise, let me know what I should
> put in.
>
> --Jari
>
> Alan DeKok wrote:
>
> >Jari Arkko <[email-masked]> wrote:
> >
> >
> >>> Years of deployment without complaints is a strong indicator that a
> >>>problem doesn't exist.  Let's let sleeping dogs lie.
> >>>
> >>>
> >>>
> >>Ok. But I'd still like to understand this better. Or I really
> >>need to, because we need to decide whether to
> >>  (a) strip i18n out of the bis draft altogether
> >>  (b) keep current utf-8 + plain-old-dns-name-but-as-idnunaware-
> >>        name-slot scheme
> >>  (c) change to utf-8 altogether
> >
> >  I would say (b).
> >
> >>Also, before you answer the above lets try to get some
> >>understanding on whether "no complaints" means
> >>  (i) no one is using i18n dns names yet. i have some sense
> >>      that this might be the case, as at least here in Finland
> >>      I think they allowed the new types of allocations
> >>      very recently.
>
> >  Mosrly.  i18n domain names have historically been rare.
> >
> >>  (ii) existing support (just let utf-8 through) is working
> >>       well
> >
> >  Definitely.
> >
> >>  (iii) solutions from a single vendor work well, but
> >>        not a lot of interop has been attempted with this
> >>        particular case
> >
> >  I would say that interoperability hasn't been *reported* on.  But
> >the deployments of RADIUS are so varied that I would be surprised if
> >interoperability isn't already being tested in live situations.
> >
> >  I haven't heard of i18n problems with interoperability.  My guess,
> >therefore, is that such problems are rare.
> >
> >  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, 23 Jun 2005 01:34:30 +0000
Date: Wed, 22 Jun 2005 18:34:25 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: -03 version of the RADIUS Digest Authentication draft?

Is an -03 version of this document in the works, and if so, when will it
be submitted?

--
to unsubscribe send a message 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, 23 Jun 2005 01:34:18 +0000
Date: Wed, 22 Jun 2005 18:33:27 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG Last Call on Dynamic Authorization Server MIB?

Given that there has not been much comment on this document, I am
wondering if we are ready for WG last call on this and the Client MIB,
once the next revision comes 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: Wed, 22 Jun 2005 19:37:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-zorn-radius-keywrap-04.txt
Date: Wed, 22 Jun 2005 12:37:12 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>, "Zhang, Tiebing" <[email-masked]>, "Jesse Walker" <[email-masked]>, "Joseph Salowey \(jsalowey\)" <[email-masked]>, "Nancy Winget \(ncamwing\)" <[email-masked]>, <[email-masked]>, "Glen Zorn \(gwz\)" <[email-masked]>

Nelson, David <> supposedly scribbled:

> Glen Zorn writes...
>=20

...

> OK, I understand.  This draft is intended to be a "base" protocol,
> which requires a companion "application protocol" draft to be
> complete to the point of specifying what appears on the wire.  I also
> understand that certain items, such as key naming schemes, are not
> commonly agreed upon. I think it would be possible, however, to
> further specify what goes in these fields, without precluding
> application specific variations.  I'll think on this and attempt to
> come up with some text to suggest.     =20

Thanks!  In the meantime, I will post a new draft with the latest =
changes.

>=20
> -- Dave

~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: Wed, 22 Jun 2005 19:20:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-zorn-radius-keywrap-04.txt
Date: Wed, 22 Jun 2005 15:19:12 -0400
From: "Nelson, David" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>
Cc: <[email-masked]>, "Zhang, Tiebing" <[email-masked]>, "Jesse Walker" <[email-masked]>, "Joseph Salowey \(jsalowey\)" <[email-masked]>, "Nancy Winget \(ncamwing\)" <[email-masked]>, <[email-masked]>

Glen Zorn writes...

> As you know, there are basically 2 types of RFCs: protocol
specifications
> & applicability statements.  This document is intended (at least from
my
> POV, my co-authors can chime in here) to remain as strictly as
possible
> within the realm of the former type since there are several other
> interested entities that may define explicit (and possibly
conflicting)
> requirements upon the fields in question.  That said, have you any
> suggestions for text?

OK, I understand.  This draft is intended to be a "base" protocol, which
requires a companion "application protocol" draft to be complete to the
point of specifying what appears on the wire.  I also understand that
certain items, such as key naming schemes, are not commonly agreed upon.
I think it would be possible, however, to further specify what goes in
these fields, without precluding application specific variations.  I'll
think on this and attempt to come up with some text to suggest.

-- 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: Wed, 22 Jun 2005 18:52:10 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-zorn-radius-keywrap-04.txt
Date: Wed, 22 Jun 2005 11:51:47 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>, "Zhang, Tiebing" <[email-masked]>, "Jesse Walker" <[email-masked]>, "Joseph Salowey \(jsalowey\)" <[email-masked]>, "Glen Zorn \(gwz\)" <[email-masked]>, "Nancy Winget \(ncamwing\)" <[email-masked]>, <[email-masked]>

Nelson, David <mailto:[email-masked]> supposedly scribbled:

> I think that the -04 revision is a substantial improvement over some
> earlier versions.  I do have some comments to offer, however.=20

Thank you for your close reading of the draft.  Most of the errors you =
note were artifacts of various revisions and have been repaired.

>=20
> On page 6, the definition of the App Id, KEK ID, and Key ID fields
> contain the sentence "Further specification o the content of this
> field is outside the scope of this document." Other than a basic
> description of the field, which includes a length and an expansion of
> the field name abbreviation, no substantive information is provided.=20
> I think that some additional guidance on the uses and content of
> these fields needs to be included in the document, if there is to be
> any hope of creating multiple, independent interoperable
> implementations using the document alone as a reference.=20

As you know, there are basically 2 types of RFCs: protocol =
specifications & applicability statements.  This document is intended =
(at least from my POV, my co-authors can chime in here) to remain as =
strictly as possible within the realm of the former type since there are =
several other interested entities that may define explicit (and possibly =
conflicting) requirements upon the fields in question.  That said, have =
you any suggestions for text?

...      =20

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: Wed, 22 Jun 2005 15:59:46 +0000
Content-class: urn:content-classes:message
Subject: Comments on draft-zorn-radius-keywrap-04.txt
Date: Wed, 22 Jun 2005 11:55:31 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, "Zhang, Tiebing" <[email-masked]>, "Jesse Walker" <[email-masked]>, "Joseph Salowey" <[email-masked]>
Cc: <[email-masked]>

I think that the -04 revision is a substantial improvement over some =
earlier versions.  I do have some comments to offer, however.

On page 6, the definition of the App Id, KEK ID, and Key ID fields =
contain the sentence "Further specification o the content of this field =
is outside the scope of this document." Other than a basic description =
of the field, which includes a length and an expansion of the field name =
abbreviation, no substantive information is provided.  I think that some =
additional guidance on the uses and content of these fields needs to be =
included in the document, if there is to be any hope of creating =
multiple, independent interoperable implementations using the document =
alone as a reference.

On page 7, the length of the Nonce is specified to be 20 octets, while =
on page 8, the length of the Nonce is specified to be 32 octets.

On page 9, the definition of MAC Type indicates that two values are =
defined in this document, while four types are actually enumerated.

On page 9, the sentence "Further specification o the content of this =
field is outside the scope of this document." appears yet again.  I =
would echo my previous comments as to the required level of description =
in this document.

On page 11, the Implementation Notes indicate that the MAC field is to =
be considered as 16 octets of zero during the hash calculation.  On page =
9, it says that the length of the MAC is algorithm dependent, being one =
of {16, 20, 32 or 64} octets in length.  Should the text on page 11 also =
reflect the differing possible lengths of the MAC, when zero-filling for =
the hash calculation?

Regards,
=A0
Dave
=A0
David B. Nelson
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01810-1008
Phone: (978) 684-1330=A0=20
E-mail: [email-masked]
=A0

--
to unsubscribe send a message 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, 21 Jun 2005 21:05:17 +0000
Content-class: urn:content-classes:message
Subject: FW: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France 
Date: Tue, 21 Jun 2005 17:04:25 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

REMINDER:

There are two (2) Internet-Draft cutoff dates for the 63rd=20
IETF Meeting in Paris, France:

July 11th: Cutoff Date for Initial (i.e., version -00)=20
Internet-Draft Submissions=20

All initial Internet-Drafts (version -00) must be submitted by Monday,=20
July 11th at 9:00 AM ET. As always, all initial submissions with a=20
filename beginning with "draft-ietf" must be approved by the=20
appropriate WG Chair before they can be processed or announced.  The=20
Secretariat would appreciate receiving WG Chair approval by Tuesday,=20
July 5th at 9:00 AM ET.

July 18th: Cutoff Date for Revised (i.e., version -01 and higher)=20
Internet-Draft Submissions=20

All revised Internet-Drafts (version -01 and higher) must be submitted=20
by Monday, July 18th at 9:00 AM ET.

Initial and revised Internet-Drafts received after their respective=20
cutoff dates will not be made available in the Internet-Drafts=20
directory or announced until on or after Monday, August 1st at 9:00=20
AM ET, when Internet-Draft posting resumes.  Please do not wait until=20
the last minute to submit.

PLEASE NOTE THE CHANGE OF PROCEDURE:  If you submit an initial or=20
revised Internet-Draft after their respective cutoff deadlines, then=20
your document will be retained and posted when Internet-Draft=20
processing resumes.  You will no longer be required to resubmit the=20
document.

Thank you for your understanding and cooperation. If you have any=20
questions or concerns, then please send a message to=20
[email-masked].

The IETF Secretariat

FYI: The Internet-Draft cutoff dates as well as other significant dates
for the 63rd IETF Meeting can be found at
http://www.ietf.org/meetings/cutoff_dates_63.html.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

--
to unsubscribe send a message 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, 20 Jun 2005 14:12:16 +0000
Date: Mon, 20 Jun 2005 17:11:52 +0300
From: Jari Arkko <[email-masked]>
To:  [email-masked]
CC: Alan DeKok <[email-masked]>
Subject: Closing the NAIbis i18n discussion

Hello folks,

We need to close this and move ahead. It seems that
we have consensus to do as little as possible, though
opinions differ as to what that exactly means :-)

I'd like to go with UTF-8 usernames + plain old DNS
names for the realm part, which was also supported
by Alan's e-mail quoted at the end of this message.
This seems to work most of the time, and is also
according to the MUSTs in RFC 3490:

   An "IDN-unaware domain name slot" is defined in this document to be
   any domain name slot that is not an IDN-aware domain name slot.
   Obviously, this includes any domain name slot whose specification
   predates IDNA.

That is, our NAIs are IDN-unaware name slots, because
2486 < 3490 ;-)

   2) Whenever a domain name is put into an IDN-unaware domain name slot
      (see section 2), it MUST contain only ASCII characters.

That is, RFC 3490 requires us to do this...

If the rest of you agree then I will submit the document in a couple
of days and we can move on. Otherwise, let me know what I should
put in.

--Jari

Alan DeKok wrote:

>Jari Arkko <[email-masked]> wrote:
>  
>
>>> Years of deployment without complaints is a strong indicator that a
>>>problem doesn't exist.  Let's let sleeping dogs lie.
>>>
>>>      
>>>
>>Ok. But I'd still like to understand this better. Or I really
>>need to, because we need to decide whether to
>>  (a) strip i18n out of the bis draft altogether
>>  (b) keep current utf-8 + plain-old-dns-name-but-as-idnunaware-
>>        name-slot scheme
>>  (c) change to utf-8 altogether
>>    
>>
>
>  I would say (b).
>
>  
>
>>Also, before you answer the above lets try to get some
>>understanding on whether "no complaints" means
>>  (i) no one is using i18n dns names yet. i have some sense
>>      that this might be the case, as at least here in Finland
>>      I think they allowed the new types of allocations
>>      very recently.
>>    
>>
>
>  Mosrly.  i18n domain names have historically been rare.
>
>  
>
>>  (ii) existing support (just let utf-8 through) is working
>>       well
>>    
>>
>
>  Definitely.
>
>  
>
>>  (iii) solutions from a single vendor work well, but
>>        not a lot of interop has been attempted with this
>>        particular case
>>    
>>
>
>  I would say that interoperability hasn't been *reported* on.  But
>the deployments of RADIUS are so varied that I would be surprised if
>interoperability isn't already being tested in live situations.
>
>  I haven't heard of i18n problems with interoperability.  My guess,
>therefore, is that such problems are rare.
>
>  Alan DeKok.
>
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>
>
>
>  
>

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

Delivery-date: Thu, 09 Jun 2005 00:57:42 +0000
Date: Wed, 8 Jun 2005 17:56:53 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: [email-masked]
Subject: Re: Access-Accept & permitted EAP messages

>   Reading RFC 3579, I see that EAP-Request isn't permitted in
> Access-Accept, but it's silent on EAP-Response.
>
>   I ask this because I've recently seen an implementation where an
> invalid Access-Accept is sent in the middle of an EAP session, which
> contains EAP-Response.  The NAS implementation is problematic, too, as
> it thinks the user is "accepted", and sends Accounting-Request for
> that session.

I believe that RFC 3748 prohibits the NAS from forwarding an EAP-Response
to the user, since it is supposed to check the Code, Identifier and Length
fields prior to forwarding.  However, with respect to the Accept/Reject
decision, I think this is correct.

>   The Access-Accept doesn't contain EAP-Success or any MPPE keys, so
> no wireless traffic should pass, but it's still an odd situation.

RFC 3748 allows the EAP peer to figure out that access has been provided
based on lower layer info, provided that the method concluded
successfully.  However in this case the conversation will probably
stall because the EAP-Response is either not delivered or is dropped by
the peer. The lack of keys will cause communication to fail
between the NAS and peer anyway.

>   Section 2.6.3 of RFC 3579 talks about combinations of messages that
> SHOULD NOT be sent by the RADIUS server.  I don't see EAP-Request or
> EAP-Response listed under Access-Accept, which is odd.

This issue is covered in RFC 3748 with respect to authenticator
forwarding.  Also, RFC 3579 does say that a RADIUS server cannot
act as an EAP peer, which implies that it doesn't send EAP Responses.

> Maybe we want to add something to the issues & fixes, saying "the
> only EAP packet allowed in Access-Accept is EAP-Succes".  Any other
> EAP messgae MUST be interpreted as a reject"

I don't think we want to talk about interpretation of EAP messages within
RADIUS, since RFC 3579 states that the Accept/Reject indication is
considered definitive.  RFC 3748 does allow an EAP conversation to
terminate successfully without an EAP Success under some conditions, so
I'm not sure we can prohibit this.

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

Envelope-to: [email-masked]
Delivery-date: Wed, 08 Jun 2005 22:08:28 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Cc: 
Subject: Access-Accept & permitted EAP messages
Message-Id: <[email-masked]>
Date: Wed,  8 Jun 2005 18:06:25 -0400 (EDT)

  Reading RFC 3579, I see that EAP-Request isn't permitted in
Access-Accept, but it's silent on EAP-Response.

  I ask this because I've recently seen an implementation where an
invalid Access-Accept is sent in the middle of an EAP session, which
contains EAP-Response.  The NAS implementation is problematic, too, as
it thinks the user is "accepted", and sends Accounting-Request for
that session.

  The Access-Accept doesn't contain EAP-Success or any MPPE keys, so
no wireless traffic should pass, but it's still an odd situation.

  Section 2.6.3 of RFC 3579 talks about combinations of messages that
SHOULD NOT be sent by the RADIUS server.  I don't see EAP-Request or
EAP-Response listed under Access-Accept, which is odd.

  Maybe we want to add something to the issues & fixes, saying "the
only EAP packet allowed in Access-Accept is EAP-Succes".  Any other
EAP messgae MUST be interpreted as a reject"

  if so, I'll submit an official ISSUE.

  Alan DeKok.

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

Delivery-date: Sun, 05 Jun 2005 21:33:36 +0000
Content-class: urn:content-classes:message
Subject: Issue:  Editorial comments on 3576 client MIB
Date: Sun, 5 Jun 2005 17:32:42 -0400
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

Description of issue: Editorial comments on 3576 client MIB
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: June 5th, 2005
Reference: n/a
Document: draft-ietf-radext-dynauth-client-mib-00.txt
Comment type: E
Priority: 1
Section: various
Rationale/Explanation of issue: Editorial pass

Requested changes:

Section 2
  "[RFC3576] ." -> "[RFC3576]."
Section 5
  #2: "that the DAC shares a secret with." ->
      "with which the DAC shares a secret."
Section 6
  radiusDynAuthClientMIB DESCRIPTION:
    "Remote Access Dialin User Service" ->
    "Remote Authentication Dial In User Service"
  radiusDynAuthServerClientPortNumber DESCRIPTION:
    "The UDP port the RADIUS" ->
    "The UDP destination port that the RADIUS"
  radius DynAuthClientRoundTripTime DESCRIPTION:
    "correponding" -> "corresponding"
  radiusDynAuthClientDisconBadAuthenticators DESCRIPTION:
    "which contained invalid Signature attributes" ->
    "which contained an invalid Response Authenticator"
  radiusDynAuthClientCoABadAuthenticators DESCRIPTION:
    "which contained invalid Signature attributes" ->
    "which contained an invalid Response Authenticator"
Section 7
  "the port number on which" ->
  "the destination port number to which"
Section 10.1
  [DYNSERV]: "Auhtorization" -> "Authorization"

--
to unsubscribe send a message 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, 05 Jun 2005 21:33:25 +0000
Content-class: urn:content-classes:message
Subject: Issue: Editorial comments on 3576 server MIB
Date: Sun, 5 Jun 2005 17:31:48 -0400
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

Description of issue: Editorial comments on 3576 server MIB
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: June 5th, 2005
Reference: n/a
Document: draft-ietf-radext-dynauth-server-mib-00.txt
Comment type: E
Priority: 1
Section: various
Rationale/Explanation of issue: Editorial pass

Requested changes:

Section 2
  "[RFC3576] ." -> "[RFC3576]."
Section 5
  Figure 1: "user 2" -> "User 2"
  #2: "that the DAS shares a secret with." ->
      "with which the DAS shares a secret."
Section 6
  radiusDynAuthServerMIB DESCRIPTION:
    "Remote Access Dialin User Service" ->
    "Remote Authentication Dial In User Service"
  radiusDynAuthServDisconUserSessRemoved DESCRIPTION:
    "In the case this Dynamic Autorization Server has no=20
     knowledge on..." ->
    "In the case that this Dynamic Authorization Server=20
     has no knowledge of..."
  radiusDynAuthServDisconBadAuthenticators DESCRIPTION:
    "which contained invalid Signature attributes" ->
    "which contained an invalid Request Authenticator"
  radiusDynAuthServCoAUserSessChanged DESCRIPTION:
    "Cient" -> "Client"
    "multiple user sessions authorization ->
      "multiple user sessions' authorization"=20
    "In the case this Dynamic Autorization Server has=20
     no knowledge on" ->
      "In the case that this Dynamic Authorization Server
       has no knowledge of"
  radiusDynAuthServCoABadAuthenticators DESCRIPTION:
    "which contained invalid Signature attributes" ->
    "which contained an invalid Request Authenticator"
  radiusDynAuthServCoAPacketsDropped DESCRIPTION:
    "clisdfauthenticators" -> "authenticators"
Section 10
  [DYNCLNT]: "Auhtorization" -> "Authorization"

--
to unsubscribe send a message 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, 03 Jun 2005 20:59:08 +0000
Date: Fri, 03 Jun 2005 13:58:47 -0700
From: Murtaza Chiba <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: Request for Review of RFC 3576 MIB documents

Thanks Bernard!  Some responses inline.

Bernard Aboba wrote:
> Review of
> http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-00.txt
> 
> pp. 3:
> No need to start each new Section on a separate page.
> 

Ok!

> Section 4:
> I would prefer that these MIB documents use the same terminology as RFC
> 3576, rather than inventing new terminology.
> 
> Why can't we just state up front that a DynAuthClient = RADIUS Server,
> DynAuthServer = RADIUS Client, and avoid using the DAC and DAS
> abbreviations?
> 

One reason is that the client need not be limited to a RADIUS Server. 
Infact it can be any entity that shares a secret and uses the interfaces 
specified by RFC3576, for e.g. a Rating Engine or a Captive Portal.

> Section 5
> "This table contains one row for each DAS that the DAC shares a secret with."
> 
> RFC 3576 only talks about secrets shared between RADIUS clients and
> servers, not between a DAS and a DAC.
> 

Kind of same as above.

> Section 6
> 
> radiusDynAuthClientInvalidServerAddresses
> 
> Do we want to combine CoA and Disconnect statistics in one variable?
> 
>                 "The number of RADIUS Disconnect-Response packets
>                  which contained invalid Signature attributes
>                  received from this Dynamic Authorization server."
> 

I guess we can separate the stats for DM and CoA messages.

> What is a Signature Attribute?  Do you mean Message-Authenticator? I
> thought we decided that this attribute couldn't be used in RFC 3576.
> 

I believe Stefaan was referring to the Authenticator in the packet.  I 
agree that there is a bootstrapping problem with using 
Signature/Message-Authenticator attribute.

Thanks much for your review.

Regards,
Murtaza

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

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

Delivery-date: Fri, 03 Jun 2005 20:41:39 +0000
Date: Fri, 03 Jun 2005 13:40:55 -0700
From: Murtaza Chiba <[email-masked]>
To: Jari Arkko <[email-masked]>
CC: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: Request for Review of RFC 3576 MIB documents

Thanks Jari!

Regards,
Murtaza

Jari Arkko wrote:
> 
> Hi Bernard,
> 
> I'm not a MIB expert, but I looked at this:
> 
>> http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-00.txt 
>>
>>  
>>
> It seemed reasonable. Just a few editorial nits:
> 
>>               Auhtorization Server MIB",
> 
> 
> s/Authroization/Authorization/
> 
>>                  reception of the correponding Disconnect or CoA reply.
> 
> 
> 
> s/corre/corres/
> 
> --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: Thu, 02 Jun 2005 21:36:49 +0000
Date: Thu, 2 Jun 2005 14:36:27 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: Request for Review of RFC 3576 MIB documents

Review of
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-00.txt

pp. 3:
No need to start each new Section on a separate page.

Section 4:
I would prefer that these MIB documents use the same terminology as RFC
3576, rather than inventing new terminology.

Why can't we just state up front that a DynAuthClient = RADIUS Server,
DynAuthServer = RADIUS Client, and avoid using the DAC and DAS
abbreviations?

Section 5
"This table contains one row for each DAS that the DAC shares a secret with."

RFC 3576 only talks about secrets shared between RADIUS clients and
servers, not between a DAS and a DAC.

Section 6

radiusDynAuthClientInvalidServerAddresses

Do we want to combine CoA and Disconnect statistics in one variable?

                "The number of RADIUS Disconnect-Response packets
                 which contained invalid Signature attributes
                 received from this Dynamic Authorization server."

What is a Signature Attribute?  Do you mean Message-Authenticator? I
thought we decided that this attribute couldn't be used in RFC 3576.

Same issue on Signature Attribute in the Server document.

--
to unsubscribe send a message 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, 02 Jun 2005 20:53:41 +0000
Date: Thu, 02 Jun 2005 23:53:29 +0300
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Request for Review of RFC 3576 MIB documents

Hi Bernard,

I'm not a MIB expert, but I looked at this:

>http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-00.txt
>  
>
It seemed reasonable. Just a few editorial nits:

>               Auhtorization Server MIB",

s/Authroization/Authorization/

>                  reception of the correponding Disconnect or CoA reply.

s/corre/corres/

--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, 02 Jun 2005 20:34:45 +0000
Date: Thu, 2 Jun 2005 13:34:10 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Request for Review of RFC 3576 MIB documents

The RFC 3576 MIB documents have recently become RADEXT WG work items:

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

We would like to request volunteers to review these specifications.

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