Subject: Accounting for subsets of total traffic

From: Stefan Winter <[email-masked]>
Date: Wed, 30 Mar 2011 19:27:00 +0200

Hi,

this is what I had in mind today:

245.1    Accounting-Traffic-Group    TLV
245.1.1    Accounting-Group-Id        ENUM
        1 = IPv4
        2 = IPv6
245.1.2    Accounting-Group-Name    STRING
245.1.3    Acct-Input-Octets        64-Bit-Counter
245.1.4    Acct-Output-Octets        64-Bit-Counter
245.1.5    Acct-Input-Packets        64-Bit-Counter
245.1.6    Acct-Output-Packets        64-Bit-Counter

Example

Accounting-Traffic-Group
    Accounting-Group-Id = IPv6
    Acct-Input-Octets = 4500
    Acct-Output-Octets = 1200
    Acct-Input-Packets = 30
    Acct-Output-Octets = 10

Accounting-Traffic-Group
    Accounting-Group-Name = "Traffic on TCP/80 to Google, all IP versions"
    Acct-Input-Octets = 450
    Acct-Output-Octets = 120
    Acct-Input-Packets = 3
    Acct-Output-Octets = 1

The group is to contain *either* -Id (enums assigned by IETF process)
*or* -Name with some string if you want to express some very specialised
(read: weird) statistics to report about (and they don't have to bug
IETF to get a value).

There can be multiple groups in one acct packet (especially IPv4, IPv6
are probably handy). There shouldn't be a requirement that the sum is
the total bytes/packets in the session; and that means the "original"
Acct-(Input/Output)-(Packets/Bytes) still remain in the accounting
packet to report the grand total.

I used 245 because the total length can grow beyond 252 - the string can
be potentially large.

I am aware that I used 64-Bit Counters even though that datatype doesn't
exist. That's because -Gigawords is a terrible hack around the 32-Bit
limitation of integers; I think it might be about time to change that.

If this thinking is in an acceptable general direction, I'm happy to put
it into a draft as soon as I'm back home with a shell access to xml2rfc.

Greetings,

Stefan Winter

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

---

From: Alan DeKok <[email-masked]>
Date: Wed, 30 Mar 2011 19:41:07 +0200

> limitation of integers; I think it might be about time to change that.

  If there's an expression interest on the list, it might as well be
added to the extended attrs draft.

> it into a draft as soon as I'm back home with a shell access to xml2rfc.

  It looks interesting.

  Alan DeKok.

---

From: Mark Smith <[email-masked]>
Date: Fri, 1 Apr 2011 09:32:34 +1030

Hi,

> added to the extended attrs draft.

I think there would be a very useful benefit in 64 bit data types. I've 
recently been having to spend quite a bit of time performing a variety 
of 4.2Gig uploads/downloads just to verify correct gigawords handling in 
new RADIUS accounting code. 64 bit counters would mean one less thing to 
handle in accounting code, and one less thing to have to worry about 
testing.

>> it into a draft as soon as I'm back home with a shell access to xml2rfc.

Regards,
Mark.

Delivery-date: Thu, 31 Mar 2011 23:03:41 +0000
Date: Fri, 1 Apr 2011 09:32:34 +1030
From: Mark Smith <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: Stefan Winter <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Accounting for subsets of total traffic

Hi,

> added to the extended attrs draft.

I think there would be a very useful benefit in 64 bit data types. I've 
recently been having to spend quite a bit of time performing a variety 
of 4.2Gig uploads/downloads just to verify correct gigawords handling in 
new RADIUS accounting code. 64 bit counters would mean one less thing to 
handle in accounting code, and one less thing to have to worry about 
testing.

>> it into a draft as soon as I'm back home with a shell access to xml2rfc.

Regards,
Mark.

Delivery-date: Thu, 31 Mar 2011 10:10:02 +0000
Date: Thu, 31 Mar 2011 12:08:56 +0200
From: Stefan Winter <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Notification: draft-winter-radext-fancyaccounting-00

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9AE9B3DDF8AFDC7A817372F2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

as discussed, I've written up the idea about fancy accounting in an I-D.
URL:

https://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting/

Please comment if you find the time - especially those people who need
the IPv6 accounting!

idnits told me that the Intended Status can't possibly be
Standards-track - RADIUS Accounting itself is only informational :-/

Greetings,

Stefan Winter

-------- Original-Nachricht --------
Betreff: 	New Version Notification for
draft-winter-radext-fancyaccounting-00
Datum: 	Thu, 31 Mar 2011 03:02:44 -0700 (PDT)
Von: 	IETF I-D Submission Tool <[email-masked]>
An: 	[email-masked]

A new version of I-D, draft-winter-radext-fancyaccounting-00.txt has been=
 successfully submitted by Stefan Winter and posted to the IETF repositor=
y.

Filename:	 draft-winter-radext-fancyaccounting
Revision:	 00
Title:		 RADIUS Accounting for traffic classes
Creation_date:	 2011-03-31
WG ID:		 Independent Submission
Number_of_pages: 7

Abstract:
This document specifies new attributes for RADIUS Accounting to
enable NAS reporting of subsets of the total traffic in a user
session.
                                                                         =
        =20

The IETF Secretariat.

--------------enig9AE9B3DDF8AFDC7A817372F2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig9AE9B3DDF8AFDC7A817372F2--

Delivery-date: Wed, 30 Mar 2011 17:41:36 +0000
Date: Wed, 30 Mar 2011 19:41:07 +0200
From: Alan DeKok <[email-masked]>
To: Stefan Winter <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Accounting for subsets of total traffic

  It looks interesting.

  Alan DeKok.

Delivery-date: Wed, 30 Mar 2011 17:25:43 +0000
Date: Wed, 30 Mar 2011 19:27:00 +0200
From: Stefan Winter <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Accounting for subsets of total traffic

Hi,

Example

Accounting-Traffic-Group

Accounting-Traffic-Group

Greetings,

Stefan Winter

Delivery-date: Tue, 29 Mar 2011 13:05:03 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Tue, 29 Mar 2011 13:04:01 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #61: DNS attribute for IPv4?

#61: DNS attribute for IPv4?

Comment(by wdec@…):

 Agreed, with some minor wordsmithing perhaps I'll add the proposed text.

-- 
---------------------------------------+------------------------------------
 Reporter:  aland@…                    |       Owner:  wdec@…        
     Type:  defect                     |      Status:  assigned      
 Priority:  minor                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:                
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/61#comment:4>
radext <http://tools.ietf.org/radext/>

Delivery-date: Tue, 29 Mar 2011 08:55:11 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: IETF 80 RADEXT Agenda - Final
Date: Tue, 29 Mar 2011 01:54:08 -0700

--_eaa479c1-57f6-4514-85a0-a01551b166f1_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

RADEXT WG IETF 80 Agenda

Chairs:
Bernard Aboba <bernard_aboba at hotmail.com
Mauricio Sanchez <mauricio.sanchez at hp.com

Jabber room: radext at jabber.ietf.org (Please join)

Wednesday=2C March 30=2C 2011
0900 - 1130
Karlin II and III

09:00 - 09:20=2C Preliminaries (20 minutes)

Audio/Video & Remote Presentation Debugging
Note Well
Note Takers
Jabber scribe
Agenda bash
Document Status

IPv6 Items (45 minutes)

9:20 - 9:35 AM RADIUS Attributes for IPv6 Access Networks (15 minutes)
http://tools.ietf.org/html/draft-ietf-radext-ipv6-access

9:35 AM - 9:50 AM RADIUS Attributes for Dual Stack Access=2C L. Yeh (15 min=
utes)
http://tools.ietf.org/html/draft-yeh-radext-dual-stack-access

9:50 AM - 10:05 AM RADIUS Attributes for 6rd=2C Sheng Jiang (15 minutes)
http://tools.ietf.org/html/draft-ietf-softwire-6rd-radius-attrib

Security Work Items (60 minutes)

10:05 - 10:25 AM Crypto-Agility Requirements for RADIUS (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements

10:25 AM - 10:35 AM RADIUS over TLS=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec

10:35 AM - 10:45 AM Dynamic Peer Discovery=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

10:45 AM - 10:55 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dtls

10:55 - 11:05 AM RADIUS Protocol Extensions=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radius-extensions

Discussion and Wrap-up (25 minutes)

11:05 =96 11:20 AM Discussion (15 minutes)
11:20 - 11:30 AM Next Steps: WG Chairs & ADs (10 minutes) 		 	   		  =

--_eaa479c1-57f6-4514-85a0-a01551b166f1_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
RADEXT WG IETF 80 Agenda<br><br>Chairs:<br>Bernard Aboba &lt=3Bbernard_abob=
a at hotmail.com<br>Mauricio Sanchez &lt=3Bmauricio.sanchez at hp.com<br><b=
r>Jabber room: radext at jabber.ietf.org (Please join)<br><br>Wednesday=2C =
March 30=2C 2011<br>0900 - 1130<br>Karlin II and III<br><br>09:00 - 09:20=
=2C Preliminaries (20 minutes)<br><br>Audio/Video &amp=3B Remote Presentati=
on Debugging<br>Note Well<br>Note Takers<br>Jabber scribe<br>Agenda bash<br=
>Document Status<br><br>IPv6 Items (45 minutes)<br><br>9:20 - 9:35 AM RADIU=
S Attributes for IPv6 Access Networks (15 minutes)<br>http://tools.ietf.org=
/html/draft-ietf-radext-ipv6-access<br><br>9:35 AM - 9:50 AM RADIUS Attribu=
tes for Dual Stack Access=2C L. Yeh (15 minutes)<br>http://tools.ietf.org/h=
tml/draft-yeh-radext-dual-stack-access<br><br>9:50 AM - 10:05 AM RADIUS Att=
ributes for 6rd=2C Sheng Jiang (15 minutes)<br>http://tools.ietf.org/html/d=
raft-ietf-softwire-6rd-radius-attrib<br><br>Security Work Items (60 minutes=
)<br><br>10:05 - 10:25 AM Crypto-Agility Requirements for RADIUS (20 minute=
s)<br>http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requireme=
nts<br><br>10:25 AM - 10:35 AM RADIUS over TLS=2C Stefan Winter (10 minutes=
)<br>http://tools.ietf.org/html/draft-ietf-radext-radsec<br><br>10:35 AM - =
10:45 AM Dynamic Peer Discovery=2C Stefan Winter (10 minutes)<br>http://too=
ls.ietf.org/html/draft-ietf-radext-dynamic-discovery<br><br>10:45 AM - 10:5=
5 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)<br>http://tools.ietf.org/h=
tml/draft-ietf-radext-dtls<br><br>10:55 - 11:05 AM RADIUS Protocol Extensio=
ns=2C Alan DeKok (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-rade=
xt-radius-extensions<br><br>Discussion and Wrap-up (25 minutes)<br><br>11:0=
5 =96 11:20 AM Discussion (15 minutes)<br>11:20 - 11:30 AM Next Steps: WG C=
hairs &amp=3B ADs (10 minutes) 		 	   		  </body>
</html>=

--_eaa479c1-57f6-4514-85a0-a01551b166f1_--

Delivery-date: Mon, 28 Mar 2011 16:04:44 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Mon, 28 Mar 2011 16:03:35 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #71: Section 2.3 and 3.3

#71: Section 2.3 and 3.3

Comment(by wdec@…):

 Well, but it seems that there is a key distintiction between the routes
 that are advertised *to* the client by the NAS as being reachable via the
 NAS vs those that are installed to point to the client. Using one
 attribute, eg Framed-IPv6-Route, for both appears to be more than an
 implementation question. It's about the intended semantics IMO.

 How about this as new text?

     An IPv6 Route Information option, defined in [RFC4191] is intended to

         be used to inform a host connected to the NAS that a specific
 route
         is reachable via the NAS. This is particularly desirable in cases
         where the RG or host are multi-homed to different NASes as shown
 in
         Figure 1.

         This document specifies the RADIUS attribute that allows the AAA
         system to provision the announcement by the NAS to an accessing
 host. The NAS may advertise this route using the method defined in
 [RFC4191] or using other equivalent
         methods.

         The distinction and separation between this attribute and the
 Framed-
         IPv6-Route attribute defined in [RFC3633] is needed due to the
 need
         to have the information carried by this attribute advertised to an
         attaching client.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  wdec@…        
     Type:  defect                     |      Status:  assigned      
 Priority:  major                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:  1.0           
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/71#comment:3>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sat, 26 Mar 2011 06:30:24 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Question to implementers of Framed-IPv6-Route
Date: Fri, 25 Mar 2011 23:30:03 -0700

--_d196902c-a730-478d-8b74-b80b2aafac21_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The question has arisen as to what NAS implementers of Framed-IPv6-Route do=
 with the attribute.=20

The attribute (defined in RFC 3162) is defined using language similar to th=
at of Framed-Route in
RFC 2865=2C so one might assume a similar use.  However=2C RFC 3162 did not=
 define a Framed-IPv6-Routing
attribute to parallel the Framed-Routing attribute defined in RFC 2865=2C s=
o that it is possible that
implementers did not use Framed-Ipv6-Route in a similar way to the Framed-R=
oute/Framed-Routing
attributes defined in RFC 2865.=20

If you have implemented Framed-Ipv6-Route on a NAS=2C please tell us what y=
ou do with the information:

1. Do you announce the routes via RA?
2. Do you look at Framed-Routing to determine if the routes are redistribut=
ed into an IGP?
 		 	   		  =

--_d196902c-a730-478d-8b74-b80b2aafac21_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
The question has arisen as to what NAS implementers of Framed-IPv6-Route do=
 with the attribute. <br><br>The attribute (defined in RFC 3162) is defined=
 using language similar to that of Framed-Route in<br>RFC 2865=2C so one mi=
ght assume a similar use.&nbsp=3B However=2C RFC 3162 did not define a Fram=
ed-IPv6-Routing<br>attribute to parallel the Framed-Routing attribute defin=
ed in RFC 2865=2C so that it is possible that<br>implementers did not use F=
ramed-Ipv6-Route in a similar way to the Framed-Route/Framed-Routing<br>att=
ributes defined in RFC 2865. <br><br>If you have implemented Framed-Ipv6-Ro=
ute on a NAS=2C please tell us what you do with the information:<br><br>1. =
Do you announce the routes via RA?<br>2. Do you look at Framed-Routing to d=
etermine if the routes are redistributed into an IGP?<br> 		 	   		  </body=
</html>=

--_d196902c-a730-478d-8b74-b80b2aafac21_--

Delivery-date: Sat, 26 Mar 2011 06:23:49 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Sat, 26 Mar 2011 06:23:25 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #71: Section 2.3 and 3.3

#71: Section 2.3 and 3.3

Comment(by bernard_aboba@…):

 It seems to me that we want to enable use of routes in advertisements as
 well as in routing protocols, and possibly both at once.  RFC 3162 defines
 Framed-IPv6-Route, and the intent there was to enable inclusion in router
 advertisements, as well as potential redistribution in IGPs, depending on
 the value of Framed-Routing.  The question is how it was implemented.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  wdec@…        
     Type:  defect                     |      Status:  assigned      
 Priority:  major                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:  1.0           
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/71#comment:2>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sat, 26 Mar 2011 06:13:21 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Sat, 26 Mar 2011 06:12:07 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #69: Section 1

#69: Section 1

Comment(by bernard_aboba@…):

 The RFC 3162 text on Framed-IPv6-Route is included below.  The text is
 analagous to that used to define Framed-Route in RFC 2865, Section 5.22.
 Note that RFC 2865 also defines Framed-Routing (Section 5.10), which
 determines how or if an IGP is used.
 If Framed-Routing = None or Listen, then I wouldn't expect routes to be
 redistributed into an IGP.  The question is what existing implementations
 do with Framed-IPv6-Route and whether this is influenced by the value of
 Framed-Routing.

 2.5.  Framed-IPv6-Route

    Description

       This Attribute provides routing information to be configured for
       the user on the NAS.  It is used in the Access-Accept packet and
       can appear multiple times.

    A summary of the Framed-IPv6-Route Attribute format is shown below.
    The fields are transmitted from left to right.

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

    Type

       99 for Framed-IPv6-Route

    Length

       >=3

    Text

       The Text field is one or more octets, and its contents are
       implementation dependent.  The field is not NUL (hex 00)
       terminated.  It is intended to be human readable and MUST NOT
       affect operation of the protocol.

       For IPv6 routes, it SHOULD contain a destination prefix optionally
       followed by a slash and a decimal length specifier stating how
       many high order bits of the prefix to use.  That is followed by a
       space, a gateway address, a space, and one or more metrics
       (encoded in decimal) separated by spaces.  Prefixes and addresses
       are formatted as described in [16].  For example,
       "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1".

       Whenever the gateway address is the IPv6 unspecified address the
       IP address of the user SHOULD be used as the gateway address.  The
       unspecified address can be expressed in any of the acceptable
       formats described in [16].  For example, "2000:0:0:106::/64 :: 1".

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  wdec@…        
     Type:  defect                     |      Status:  assigned      
 Priority:  major                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:  1.0           
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/radext/trac/ticket/69#comment:3>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 25 Mar 2011 00:39:06 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Presentations
Date: Thu, 24 Mar 2011 17:37:32 -0700

--_9ac3b4a7-ceec-46a7-a851-85a7455545b2_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

If you are presenting at IETF 80=2C please get your slides in ASAP.   Agend=
a is given below.=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RADEXT WG IETF 80 Agenda

Chairs:
Bernard Aboba <bernard_aboba at hotmail.com
Mauricio Sanchez <mauricio.sanchez at hp.com

Jabber room: radext at jabber.ietf.org (Please join)

Wednesday=2C March 30=2C 2011
0900 - 1130
Karlin II and III

09:00 - 09:20=2C Preliminaries (20 minutes)

Audio/Video & Remote Presentation Debugging
Note Well
Note Takers
Jabber scribe
Agenda bash
Document Status

IPv6 Items (45 minutes)

9:20 - 9:35 AM RADIUS Attributes for IPv6 Access Networks (15 minutes)
http://tools.ietf.org/html/draft-ietf-radext-ipv6-access

9:35 AM - 9:50 AM RADIUS Attributes for Dual Stack Access=2C L. Yeh (15 min=
utes)
http://tools.ietf.org/html/draft-yeh-radext-dual-stack-access

9:50 AM - 10:05 AM RADIUS Attributes for 6rd=2C Sheng Jiang (15 minutes)
http://tools.ietf.org/html/draft-ietf-softwire-6rd-radius-attrib

Security Work Items (60 minutes)

10:05 - 10:25 AM Crypto-Agility Requirements for RADIUS (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements

10:25 AM - 10:35 AM RADIUS over TLS=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec

10:35 AM - 10:45 AM Dynamic Peer Discovery=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

10:45 AM - 10:55 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dtls

10:55 - 11:05 AM RADIUS Protocol Extensions=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radius-extensions

Discussion and Wrap-up (25 minutes)
 		 	   		  =

--_9ac3b4a7-ceec-46a7-a851-85a7455545b2_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
If you are presenting at IETF 80=2C please get your slides in ASAP.&nbsp=3B=
&nbsp=3B Agenda is given below. <br><br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D<br>RADEXT WG IETF 80 Agenda<br><br>Chairs:<br>Bernard Ab=
oba &lt=3Bbernard_aboba at hotmail.com<br>Mauricio Sanchez &lt=3Bmauricio.s=
anchez at hp.com<br><br>Jabber room: radext at jabber.ietf.org (Please join=
)<br><br>Wednesday=2C March 30=2C 2011<br>0900 - 1130<br>Karlin II and III<=
br><br>09:00 - 09:20=2C Preliminaries (20 minutes)<br><br>Audio/Video &amp=
=3B Remote Presentation Debugging<br>Note Well<br>Note Takers<br>Jabber scr=
ibe<br>Agenda bash<br>Document Status<br><br>IPv6 Items (45 minutes)<br><br=
>9:20 - 9:35 AM RADIUS Attributes for IPv6 Access Networks (15 minutes)<br>=
http://tools.ietf.org/html/draft-ietf-radext-ipv6-access<br><br>9:35 AM - 9=
:50 AM RADIUS Attributes for Dual Stack Access=2C L. Yeh (15 minutes)<br>ht=
tp://tools.ietf.org/html/draft-yeh-radext-dual-stack-access<br><br>9:50 AM =
- 10:05 AM RADIUS Attributes for 6rd=2C Sheng Jiang (15 minutes)<br>http://=
tools.ietf.org/html/draft-ietf-softwire-6rd-radius-attrib<br><br>Security W=
ork Items (60 minutes)<br><br>10:05 - 10:25 AM Crypto-Agility Requirements =
for RADIUS (20 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-cry=
pto-agility-requirements<br><br>10:25 AM - 10:35 AM RADIUS over TLS=2C Stef=
an Winter (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-rads=
ec<br><br>10:35 AM - 10:45 AM Dynamic Peer Discovery=2C Stefan Winter (10 m=
inutes)<br>http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery<b=
r><br>10:45 AM - 10:55 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)<br>ht=
tp://tools.ietf.org/html/draft-ietf-radext-dtls<br><br>10:55 - 11:05 AM RAD=
IUS Protocol Extensions=2C Alan DeKok (10 minutes)<br>http://tools.ietf.org=
/html/draft-ietf-radext-radius-extensions<br><br>Discussion and Wrap-up (25=
 minutes)<br> 		 	   		  </body>
</html>=

--_9ac3b4a7-ceec-46a7-a851-85a7455545b2_--

Delivery-date: Sat, 19 Mar 2011 07:09:16 +0000
Date: Sat, 19 Mar 2011 08:08:16 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [IANA #278793] Registration of RADIUS Attribute Values and RFC 3575

Bernard Aboba wrote:
> Note that the Tunnel-Type and Tunnel-Medium-Type attributes are not called out as an exception, only Service-Type. 
> If the intent was to exempt RFC 2868, those attributes would have been included as exceptions but they are not. 
> 
> Therefore, it looks to me like the omission of RFC 2868 in the Updates: header is an errata.  

  I agree.

  IIRC, there are a number of other inconsistencies in the IANA
registry.  I ran into that a while ago when doing some research, but
never made a specific note of the problem.  I'll see if I can track that
down.

  Alan DeKok.

Delivery-date: Fri, 18 Mar 2011 23:33:40 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
CC: <[email-masked]>
Subject: RE: [IANA #278793] Registration of RADIUS Attribute Values and RFC 3575 
Date: Fri, 18 Mar 2011 16:32:24 -0700

RFC 3575 Section 2.1 states the following:

   Certain attributes (for example, NAS-Port-Type) in RADIUS define a
   list of values to correspond with various meanings.  There can be 4
   billion (2^32) values for each attribute.  Additional values can be
   allocated by the Designated Expert.  The exception to this policy is
   the Service-Type attribute (6), whose values define new modes of
   operation for RADIUS.  Values 1-16 of the Service-Type attribute have
   been allocated.  Allocation of new Service-Type values are by IETF
   Consensus.  The intention is that any allocation will be accompanied
   by a published RFC.

Note that the Tunnel-Type and Tunnel-Medium-Type attributes are not =
called out as an exception, only Service-Type.=20
If the intent was to exempt RFC 2868, those attributes would have been =
included as exceptions but they are not.=20

Therefore, it looks to me like the omission of RFC 2868 in the Updates: =
header is an errata. =20

What do other WG participants think?

-----Original Message-----
From: Amanda Baber via RT [mailto:[email-masked]]=20
Sent: Friday, March 18, 2011 2:59 PM
To: [email-masked]
Subject: [IANA #278793] Registration of RADIUS Attribute Values and RFC =
3575=20

Hi,

I'm afraid I lost track of this message about fixing IANA's descriptions =
of RADIUS registration procedures.=20

Given RFC 3575, all of the RADIUS attribute values but 6 (Service-Type),
64 (Tunnel-Type), and 65 (Tunnel-Medium-Type) are now listed as Expert =
Review registries. Those remaining three are listed as IETF Consensus.
Please see

http://www.iana.org/assignments/radius-types

The issue with Tunnel-Type and Tunnel-Medium-Type, which has come up =
before, is that RFC2868 specifically calls them IETF Consensus =
registries, and RFC3575 doesn't update RFC2868. Is this reading correct, =
or does RFC3575 supersede 2868 anyway?

Since we're not sure what to do about Tunnel-Type and =
Tunnel-Medium-Type, the directory at http://www.iana.org/protocols/ =
currently says, "Registration procedure varies by attribute."

Do we need to make any changes?

thanks,
Amanda

On Tue Nov 10 01:45:42 2009, [email-masked] wrote:
> Recently on the RADEXT WG mailing list, an issue has been raised about =

> the IANA allocation procedures for RADIUS attribute values:
>=20
> http://ops.ietf.org/lists/radiusext/2009/msg00625.html
>=20
> =20
>=20
> As noted in RFC 3575, Section 2.1:
>=20
> =20
>=20
>    Certain attributes (for example, NAS-Port-Type) in RADIUS define a
>=20
>    list of values to correspond with various meanings.  There can be 4
>=20
>    billion (2^32) values for each attribute.  Additional values can be
>=20
>    allocated by the Designated Expert.  The exception to this policy=20
> is
>=20
>    the Service-Type attribute (6), whose values define new modes of
>=20
>    operation for RADIUS.  Values 1-16 of the Service-Type attribute=20
> have
>=20
>    been allocated.  Allocation of new Service-Type values are by IETF
>=20
>    Consensus.  The intention is that any allocation will be=20
> accompanied
>=20
>    by a published RFC.
>=20
> =20
>=20
> Given the above text, it is my understanding that according to RFC=20
> 3575, additional values for RADIUS attributes (with the exception of=20
> the Service-Type attribute (6)) are to be allocated by Designated =
Expert.
>=20
> =20
>=20
> However, within the IANA RADIUS registry=20
> (http://www.iana.org/protocols/) RADIUS attribute values are listed as =
requiring Standards Action.
>=20
> =20
>=20
> We have already had one instance in which the insistence on Standards
Action
> has resulted in a large delay in value allocation with the resulting
use of
> Vendor-Specific Values as described in RFC 2822.  Given that RFC 3575=20
> specifically indicates that standards action is not required for
allocation
> of values for any RADIUS attribute other than Service-Type, there is=20
> not much room for interpretation here and I would like to make sure=20
> that this problem is corrected as soon as possible.
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> =20
>=20

Delivery-date: Tue, 15 Mar 2011 17:40:44 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Alper Yegin <[email-masked]>
Date: Tue, 15 Mar 2011 13:39:35 -0400
Subject: [IANA #409959] Genreral Request for Assignements
Accept-Language: en-US
acceptlanguage: en-US

--_000_C9A51C9711D20avibridgewatersystemscom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

 Hi Bernard,

Thank you for the review of the NAS-Port-Type IANA request for assignment. =
 In a previous email you were seeking answers to the following questions:
Bernard wrote:
Can someone answer the following questions?
1. What is different between WiMAX WiFi and normal IEEE 802.11?  We already=
 have a number of IEEE 802.11 NAS-Port-types allocated and have proposed ad=
ditional data for this.
2. Why do DHCP and a location service need NAS-Port-Type values?
3. Why should we just allocate a generic WiMAX NAS-Port and let additional =
data be included in a WiMAX Forum VSA?
The general answer to your question is as follows:
For a given session, the WIMAX AAA Server interacts with many different WiM=
AX network elements and also non-WiMAX network elements.  The approach take=
n by WiMAX is to have an explicit indication from the NAS as to the context=
 of the RADIUS access-request.  The NAS-Port-Type is viewed as the attribut=
e to provide that information.
WRT 1) the WiMAX AAA needs to be able to differentiate between a normal WiF=
i Access and a WiMAX NAS which is an a WiFI-WiMAX IWK NAS which has additio=
nal behaviours over and above the "normal" wifi AP.  T

WRT 2) Again, WiMAX AAA needs to differentiate between the request from bot=
h these entities because the AAA behaviour is different when request comes =
from  a DHCP server vs., a Location Based Server.
WRT 3)  WiMAX would just be inventing our own NAS-Port-Type attribute.  We =
thought the idea is that we reuse attributes when we can. Since there doesn=
't seem to be a lack of number space associated with NAS-Port-Type there do=
esn't seem to be a reason to invent our own attribute.

-- Avi Lior
--Bridgewater Systems

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

<html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:=
 space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-si=
ze: 14px; font-family: Calibri, sans-serif; "><div><div><div>&nbsp;Hi Berna=
rd,</div><div><br></div><div>Thank you for the review of the NAS-Port-Type =
IANA request for assignment. &nbsp;In a previous email you were seeking ans=
wers to the following questions:</div><div><span class=3D"Apple-style-span"=
 style=3D"font-family: Times; font-size: medium; -webkit-border-horizontal-=
spacing: 2px; -webkit-border-vertical-spacing: 2px; "><p class=3D"MsoNormal=
" style=3D"margin-bottom: 12pt; "><span style=3D"font-size: 10pt; font-fami=
ly: Tahoma, sans-serif; ">Bernard wrote:</span></p><p class=3D"MsoNormal" s=
tyle=3D"margin-bottom: 12pt; "><span style=3D"font-size: 10pt; font-family:=
 Tahoma, sans-serif; ">Can someone answer the following questions?<o:p></o:=
p></span></p><p class=3D"MsoNormal" style=3D"margin-bottom: 12pt; "><span s=
tyle=3D"font-size: 10pt; font-family: Tahoma, sans-serif; ">1. What is diff=
erent between WiMAX WiFi and normal IEEE 802.11?&nbsp; We already have a nu=
mber of IEEE 802.11 NAS-Port-types allocated and have proposed additional d=
ata for this.<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"margin-b=
ottom: 12pt; "><span style=3D"font-size: 10pt; font-family: Tahoma, sans-se=
rif; ">2. Why do DHCP and a location service need NAS-Port-Type values?&nbs=
p;<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"margin-bottom: 12pt=
; "><span style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; ">3. W=
hy should we just allocate a generic WiMAX NAS-Port and let additional data=
 be included in a WiMAX Forum VSA?</span></p><p class=3D"MsoNormal" style=
=3D"margin-bottom: 12pt; "><span style=3D"font-size: 10pt; font-family: Tah=
oma, sans-serif; ">The general answer to your question is as follows:</span=
></p><p class=3D"MsoNormal" style=3D"margin-bottom: 12pt; "><font class=3D"=
Apple-style-span" face=3D"Tahoma,sans-serif" size=3D"3"><span class=3D"Appl=
e-style-span" style=3D"font-size: 13px;">For a given session, the WIMAX AAA=
 Server interacts with many different WiMAX network elements and also non-W=
iMAX network elements. &nbsp;The approach taken by WiMAX is to have an expl=
icit indication from the NAS as to the context of the RADIUS access-request=
. &nbsp;The NAS-Port-Type is viewed as the attribute to provide that inform=
ation.</span></font></p><p class=3D"MsoNormal" style=3D"margin-bottom: 12pt=
; "><font class=3D"Apple-style-span" face=3D"Tahoma,sans-serif" size=3D"3">=
<span class=3D"Apple-style-span" style=3D"font-size: 13px;">WRT 1) the WiMA=
X AAA needs to be able to differentiate between a normal WiFi Access and a =
WiMAX NAS which is an a WiFI-WiMAX IWK NAS which has additional behaviours =
over and above the "normal" wifi AP. &nbsp;T</span></font></p><p class=3D"M=
soNormal" style=3D"margin-bottom: 12pt; "><font class=3D"Apple-style-span" =
face=3D"Tahoma,sans-serif" size=3D"3"><span class=3D"Apple-style-span" styl=
e=3D"font-size: 13px;"><br></span></font></p><p class=3D"MsoNormal" style=
=3D"margin-bottom: 12pt; "><font class=3D"Apple-style-span" face=3D"Tahoma,=
sans-serif" size=3D"3"><span class=3D"Apple-style-span" style=3D"font-size:=
 13px;">WRT 2) Again, WiMAX AAA needs to differentiate between the request =
from both these entities because the AAA behaviour is different when reques=
t comes from &nbsp;a DHCP server vs., a Location Based Server.</span></font=
></p><p class=3D"MsoNormal" style=3D"margin-bottom: 12pt; "><font class=3D"=
Apple-style-span" face=3D"Tahoma,sans-serif" size=3D"3"><span class=3D"Appl=
e-style-span" style=3D"font-size: 13px;">WRT 3) &nbsp;WiMAX would just be i=
nventing our own NAS-Port-Type attribute. &nbsp;We thought the idea is that=
 we reuse attributes when we can. Since there doesn't seem to be a lack of =
number space associated with NAS-Port-Type there doesn't seem to be a reaso=
n to invent our own attribute.</span></font></p><p class=3D"MsoNormal" styl=
e=3D"margin-bottom: 12pt; "><font class=3D"Apple-style-span" face=3D"Tahoma=
,sans-serif" size=3D"3"><span class=3D"Apple-style-span" style=3D"font-size=
: 13px;"><br></span></font></p></span></div><div><div><div>-- Avi Lior</div=
><div>--Bridgewater Systems</div><div><br></div></div></div></div></div></b=
ody></html>

--_000_C9A51C9711D20avibridgewatersystemscom_--

Delivery-date: Tue, 15 Mar 2011 06:09:56 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RADEXT Agenda for IETF 80 - Take 3
Date: Mon, 14 Mar 2011 23:09:01 -0700

--_439a6b67-6c2a-4271-8933-8640607a6667_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Sorry for the confusion relating to the IPv6 presentations.  Here is a revi=
sed agenda.=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RADEXT WG IETF 80 Agenda

Chairs:
Bernard Aboba <bernard_aboba at hotmail.com
Mauricio Sanchez <mauricio.sanchez at hp.com

Jabber room: radext at jabber.ietf.org (Please join)

Wednesday=2C March 30=2C 2011

0900 - 1130

Karlin II and III

09:00 - 09:20=2C Preliminaries (20 minutes)

Audio/Video & Remote Presentation Debugging
Note Well
Note Takers
Jabber scribe
Agenda bash
Document Status

IPv6 Items (45 minutes)

9:20 - 9:35 AM RADIUS Attributes for IPv6 Access Networks (15 minutes)
http://tools.ietf.org/html/draft-ietf-radext-ipv6-access

9:35 AM - 9:50 AM RADIUS Attributes for Dual Stack Access=2C L. Yeh (15 min=
utes)
http://tools.ietf.org/html/draft-yeh-radext-dual-stack-access

9:50 AM - 10:05 AM RADIUS Attributes for 6rd=2C Sheng Jiang (15 minutes)
http://tools.ietf.org/html/draft-ietf-softwire-6rd-radius-attrib

Security Work Items (60 minutes)

10:05 - 10:25 AM Crypto-Agility Requirements for RADIUS (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements

10:25 AM - 10:35 AM RADIUS over TLS=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec

10:35 AM - 10:45 AM Dynamic Peer Discovery=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

10:45 AM - 10:55 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dtls

10:55 - 11:05 AM RADIUS Protocol Extensions=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radius-extensions

Discussion and Wrap-up (25 minutes)

11:05 =96 11:20 AM Discussion (15 minutes)
11:20 - 11:30 AM Next Steps: WG Chairs & ADs (10 minutes)

 		 	   		  =

--_439a6b67-6c2a-4271-8933-8640607a6667_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
<br>Sorry for the confusion relating to the IPv6 presentations.&nbsp=3B Her=
e is a revised agenda. <br><br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>RADEXT WG IETF 80 Agenda<br><br>Chairs:<br>Bernard Aboba &lt=3Bberna=
rd_aboba at hotmail.com<br>Mauricio Sanchez &lt=3Bmauricio.sanchez at hp.co=
m<br><br>Jabber room: radext at jabber.ietf.org (Please join)<br><br>Wednes=
day=2C March 30=2C 2011<br><br>0900 - 1130<br><br>Karlin II and III<br><br>=
09:00 - 09:20=2C Preliminaries (20 minutes)<br><br>Audio/Video &amp=3B Remo=
te Presentation Debugging<br>Note Well<br>Note Takers<br>Jabber scribe<br>A=
genda bash<br>Document Status<br><br>IPv6 Items (45 minutes)<br><br>9:20 - =
9:35 AM RADIUS Attributes for IPv6 Access Networks (15 minutes)<br>http://t=
ools.ietf.org/html/draft-ietf-radext-ipv6-access<br><br>9:35 AM - 9:50 AM R=
ADIUS Attributes for Dual Stack Access=2C L. Yeh (15 minutes)<br>http://too=
ls.ietf.org/html/draft-yeh-radext-dual-stack-access<br><br>9:50 AM - 10:05 =
AM RADIUS Attributes for 6rd=2C Sheng Jiang (15 minutes)<br>http://tools.ie=
tf.org/html/draft-ietf-softwire-6rd-radius-attrib<br><br>Security Work Item=
s (60 minutes)<br><br>10:05 - 10:25 AM Crypto-Agility Requirements for RADI=
US (20 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-crypto-agil=
ity-requirements<br><br>10:25 AM - 10:35 AM RADIUS over TLS=2C Stefan Winte=
r (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-radsec<br><b=
r>10:35 AM - 10:45 AM Dynamic Peer Discovery=2C Stefan Winter (10 minutes)<=
br>http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery<br><br>10=
:45 AM - 10:55 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)<br>http://too=
ls.ietf.org/html/draft-ietf-radext-dtls<br><br>10:55 - 11:05 AM RADIUS Prot=
ocol Extensions=2C Alan DeKok (10 minutes)<br>http://tools.ietf.org/html/dr=
aft-ietf-radext-radius-extensions<br><br>Discussion and Wrap-up (25 minutes=
)<br><br>11:05 =96 11:20 AM Discussion (15 minutes)<br>11:20 - 11:30 AM Nex=
t Steps: WG Chairs &amp=3B ADs (10 minutes)<br><br> 		 	   		  </body>
</html>=

--_439a6b67-6c2a-4271-8933-8640607a6667_--

Delivery-date: Tue, 15 Mar 2011 02:37:37 +0000
Date: Tue, 15 Mar 2011 02:36:32 +0000
From: Jiangsheng <[email-masked]>
Subject: RE: RADEXT WG Agenda for IETF 80 - Take Two
To: Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Accept-Language: en-GB, zh-CN, en-US

Dear RADEXT chairs,

We did send a request for presentation as early as March 4th. It is an soft=
wire WG draft, which is IPv6 relevant.

"RADIUS Attribute for 6rd"
draft-ietf-softwire-6rd-radius-attrib update for radext WG review.

The presentation should be less than 5 mins, 10 mins slot should be enough =
including discussion.

Thanks and regards,

Sheng

From: [email-masked] [[email-masked]] on behalf=
 of Bernard Aboba [[email-masked]]
Sent: 14 March 2011 15:14
To: [email-masked]
Subject: RADEXT WG Agenda for IETF 80 - Take Two

RADEXT WG IETF 80 Agenda=20

Chairs:
Bernard Aboba <bernard_aboba at hotmail.com>
Mauricio Sanchez <mauricio.sanchez at hp.com>

Jabber room:  radext at jabber.ietf.org (Please join)

Wednesday, March 30, 2011

0900 - 1130

Karlin II and III

09:00 - 09:20, Preliminaries

     Debugging
     Note Well
     Note Takers
     Jabber scribe
     Agenda bash
     Document Status

IPv6 Items (40 minutes)

9:20 - 9:40 AM RADIUS Attributes for IPv6 Access Networks (20 minutes)

http://tools.ietf.org/html/draft-ietf-radext-ipv6-access

9:40 AM - 9:50 AM  RADIUS Attributes for Dual Stack Access, L. Yeh (10 minu=
tes)
http://tools.ietf.org/html/draft-yeh-radext-dual-stack-access

9:50 AM - 10:00 AM RADIUS Extensions for Dual Stack Lite, R. Magliione (10 =
minutes)

http://tools.ietf.org/html/draft-ietf-softwire-dslite-radius-ext

Security Work Items (60 minutes)

10:00 - 10:20 AM Crypto-Agility Requirements for RADIUS (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements

10:20 AM - 10:30 AM RADIUS over TLS, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec

10:30 AM - 10:40 AM Dynamic Peer Discovery, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

10:40 AM - 10:50 AM RADIUS over DTLS, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dtls

10:50 - 11:00 AM RADIUS Protocol Extensions, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radius-extensions

Discussion and Wrap-up (30 minutes)

11:00 =96 11:15 AM Discussion (15 minutes)
11:15 - 11:30  AM Next Steps:  WG Chairs & ADs (15 minutes) =

Delivery-date: Mon, 14 Mar 2011 19:17:29 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-ipv6-access-04.txt
Date: Mon, 14 Mar 2011 12:15:02 -0700

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : RADIUS attributes for IPv6 Access Networks
	Author(s)       : B. Lourdelet, et al.
	Filename        : draft-ietf-radext-ipv6-access-04.txt
	Pages           : 13
	Date            : 2011-03-14

This document specifies additional IPv6 RADIUS attributes useful in
residential broadband network deployments.  The attributes, which are
used for authorization and accounting, enable assignment of a host
IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an
IPv6 route announced via router advertisement, and assignment of a
named IPv6 delegated prefix pool.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-ipv6-access-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

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

--NextPart--

Delivery-date: Mon, 14 Mar 2011 18:43:59 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Mon, 14 Mar 2011 18:43:43 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #74: Section 3.2

#74: Section 3.2

Changes (by wdec@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Will clarify that order of attributes is supposed to be reflected in the
 client advertisement.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:  wdec@…        
     Type:  defect                     |       Status:  closed        
 Priority:  minor                      |    Milestone:  milestone1    
Component:  ipv6-access                |      Version:  1.0           
 Severity:  In WG Last Call            |   Resolution:  fixed         
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/74#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 14 Mar 2011 18:42:11 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Mon, 14 Mar 2011 18:41:57 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #68: Abstract

#68: Abstract

Changes (by wdec@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Resolved as proposed.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:  wdec@…        
     Type:  defect                     |       Status:  closed        
 Priority:  minor                      |    Milestone:  milestone1    
Component:  ipv6-access                |      Version:  1.0           
 Severity:  In WG Last Call            |   Resolution:  fixed         
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/68#comment:2>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 14 Mar 2011 18:41:20 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Mon, 14 Mar 2011 18:41:07 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #62: Use of "Address"

#62: Use of "Address"

Changes (by wdec@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Resolved as suggested.

-- 
---------------------------------------+------------------------------------
 Reporter:  aland@…                    |        Owner:  wdec@…        
     Type:  defect                     |       Status:  closed        
 Priority:  minor                      |    Milestone:  milestone1    
Component:  ipv6-access                |      Version:                
 Severity:  In WG Last Call            |   Resolution:  fixed         
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/62#comment:2>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 14 Mar 2011 18:39:10 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Mon, 14 Mar 2011 18:38:44 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #61: DNS attribute for IPv4?

#61: DNS attribute for IPv4?

Changes (by wdec@…):

  * status:  new => assigned

Comment:

 IETF spec, no, existing implementations however do things like
 http://freeradius.org/rfc/rfc2548.html#MS-Primary-DNS-Server.

 Let me know how you'd like to see this represented. We didn't want to
 provide links to specific implementations, but also not hide from the fact
 that limited VSAs are being used.

-- 
---------------------------------------+------------------------------------
 Reporter:  aland@…                    |       Owner:  wdec@…        
     Type:  defect                     |      Status:  assigned      
 Priority:  minor                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:                
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/61#comment:3>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 14 Mar 2011 18:26:58 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Mon, 14 Mar 2011 18:26:33 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #77: Section 2

#77: Section 2

Changes (by wdec@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Resolved as proposed.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:  wdec@…        
     Type:  defect                     |       Status:  closed        
 Priority:  major                      |    Milestone:  milestone1    
Component:  ipv6-access                |      Version:  1.0           
 Severity:  In WG Last Call            |   Resolution:  fixed         
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/77#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 14 Mar 2011 18:02:26 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Mon, 14 Mar 2011 18:02:12 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #76: Section 6

#76: Section 6

Changes (by wdec@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Resolved as proposed

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:  wdec@…        
     Type:  defect                     |       Status:  closed        
 Priority:  major                      |    Milestone:  milestone1    
Component:  ipv6-access                |      Version:  1.0           
 Severity:  In WG Last Call            |   Resolution:  fixed         
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/76#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 14 Mar 2011 17:59:54 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Mon, 14 Mar 2011 17:59:12 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #70: Section 2.1

#70: Section 2.1

Changes (by wdec@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Resolved as proposed

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:  wdec@…        
     Type:  defect                     |       Status:  closed        
 Priority:  major                      |    Milestone:  milestone1    
Component:  ipv6-access                |      Version:  1.0           
 Severity:  In WG Last Call            |   Resolution:  fixed         
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/70#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 14 Mar 2011 16:44:09 +0000
From: Bernard Aboba <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: Remote Presentation at IETF 80
Date: Mon, 14 Mar 2011 09:44:52 -0700

------=_NextPart_000_0031_01CBE22C.782F3830
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

If you are on the IETF 80 agenda and are interested in presenting remotely,
let me know. 

The IETF has not had good experiences with remote presentation based on PSTN
gateways, 

but newer technologies are available that permit the use of HD audio, so
perhaps this will work better. 

------=_NextPart_000_0031_01CBE22C.782F3830
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META =
HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 12 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>If you are =
on the IETF 80 agenda and are interested in presenting remotely, let me =
know. <o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>The IETF has not had good experiences with remote =
presentation based on PSTN gateways, <o:p></o:p></p><p =
class=3DMsoNormal>but newer technologies are available that permit the =
use of HD audio, so perhaps this will work better. =
<o:p></o:p></p></div></body></html>
------=_NextPart_000_0031_01CBE22C.782F3830--

Delivery-date: Mon, 14 Mar 2011 13:37:35 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Mon, 14 Mar 2011 13:37:18 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #75: Section 3.6

#75: Section 3.6

Changes (by wdec@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Resolved as proposed.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:  wdec@…        
     Type:  defect                     |       Status:  closed        
 Priority:  blocker                    |    Milestone:  milestone1    
Component:  ipv6-access                |      Version:  1.0           
 Severity:  In WG Last Call            |   Resolution:  fixed         
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/75#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 14 Mar 2011 13:36:39 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Mon, 14 Mar 2011 13:36:08 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #69: Section 1

#69: Section 1

Changes (by wdec@…):

  * status:  new => assigned

Comment:

 Agreed with one caveat. I'm not sure that the framed-ipv6-route was
 intended for use with RIPng. It seems more like being intended to be
 intended for the NAS to install the specified route towards the client,
 which then may be redistributed into some IGP. This is different than
 advertising a route to a client by means of ICMPv6 or DHCPv6.

 Awaiting a response.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  wdec@…        
     Type:  defect                     |      Status:  assigned      
 Priority:  major                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:  1.0           
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/69#comment:2>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 14 Mar 2011 13:22:16 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Mon, 14 Mar 2011 13:21:46 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #71: Section 2.3 and 3.3

#71: Section 2.3 and 3.3

Changes (by wdec@…):

  * status:  new => assigned

Comment:

 New description reads:

  An IPv6 Route Information option, defined in [RFC4191] is intended to
    be used to inform a host connected to the NAS that a specific route
    is reachable via the NAS.  This is particularly desirable in cases
    where the RG or host are multi-homed to different NASes as shown in
    Figure 1.

    This document specifies the RADIUS attribute that allows the AAA
    system to provision the announcement by the NAS of a specific Route
    Information Option to an accessing host.  The NAS may advertise this
    route using the method defined in [RFC4191] or using other equivalent
    methods.

    The distinction and separation between this attribute and the Framed-
    IPv6-Route attribute defined in [RFC3633] is needed due to the need
    to have the information carried by this attribute advertised to an
    attaching client.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  wdec@…        
     Type:  defect                     |      Status:  assigned      
 Priority:  major                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:  1.0           
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/71#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 14 Mar 2011 13:00:46 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Mon, 14 Mar 2011 13:00:32 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #72: Section 2.4

#72: Section 2.4

Changes (by wdec@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Resolved as proposed

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:  wdec@…        
     Type:  defect                     |       Status:  closed        
 Priority:  major                      |    Milestone:  milestone1    
Component:  ipv6-access                |      Version:  1.0           
 Severity:  In WG Last Call            |   Resolution:  fixed         
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/72#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 14 Mar 2011 12:59:04 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Mon, 14 Mar 2011 12:58:05 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #73: Section 3.1

#73: Section 3.1

Changes (by wdec@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Resolved as proposed.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:  wdec@…        
     Type:  defect                     |       Status:  closed        
 Priority:  blocker                    |    Milestone:  milestone1    
Component:  ipv6-access                |      Version:  1.0           
 Severity:  In WG Last Call            |   Resolution:  fixed         
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/73#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 14 Mar 2011 08:32:11 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-radsec-08.txt
Date: Mon, 14 Mar 2011 01:30:01 -0700

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : TLS encryption for RADIUS
	Author(s)       : S. Winter, et al.
	Filename        : draft-ietf-radext-radsec-08.txt
	Pages           : 19
	Date            : 2011-03-14

This document specifies security on the transport layer (TLS) for the
RADIUS protocol when transmitted over TCP.  This enables dynamic
trust relationships between RADIUS servers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

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

--NextPart--

Delivery-date: Mon, 14 Mar 2011 07:15:49 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RADEXT WG Agenda for IETF 80 - Take Two
Date: Mon, 14 Mar 2011 00:14:39 -0700

--_c1e356c3-d7e5-4884-9fbb-1c82064e628f_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

RADEXT WG IETF 80 Agenda=20

=20

Chairs:

Bernard Aboba <bernard_aboba at hotmail.com>

Mauricio Sanchez <mauricio.sanchez at hp.com>

=20

Jabber room:  radext at jabber.ietf.org (Please join)

=20

Wednesday=2C March 30=2C 2011

=20

0900 - 1130

=20

Karlin II and III

=20

09:00 - 09:20=2C Preliminaries

=20

     Debugging

     Note Well

     Note Takers

     Jabber scribe

     Agenda bash

     Document Status
IPv6 Items (40 minutes)

9:20 - 9:40 AM RADIUS Attributes for IPv6 Access Networks (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-ipv6-access
9:40 AM - 9:50 AM  RADIUS Attributes for Dual Stack Access=2C L. Yeh (10 mi=
nutes)http://tools.ietf.org/html/draft-yeh-radext-dual-stack-access
9:50 AM - 10:00 AM RADIUS Extensions for Dual Stack Lite=2C R. Magliione (1=
0 minutes)
http://tools.ietf.org/html/draft-ietf-softwire-dslite-radius-ext

Security Work Items (60 minutes)

 10:00 - 10:20 AM Crypto-Agility Requirements for RADIUS (20 minutes)http:/=
/tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements

10:20 AM - 10:30 AM RADIUS over TLS=2C Stefan Winter (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-radsec

=20

10:30 AM - 10:40 AM Dynamic Peer Discovery=2C Stefan Winter (10
minutes)

http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

=20

10:40 AM - 10:50 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-dtls

=20

10:50 - 11:00 AM RADIUS Protocol Extensions=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radius-extensions

Discussion and Wrap-up (30 minutes)

 =20

11:00 =96 11:15 AM Discussion (15 minutes)

11:15 - 11:30  AM Next Steps:  WG Chairs & ADs (15 minutes) 		 	   		  =

--_c1e356c3-d7e5-4884-9fbb-1c82064e628f_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
<p class=3D"MsoNormal">RADEXT WG IETF 80 Agenda </p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">Chairs:</p>

<p class=3D"MsoNormal">Bernard Aboba &lt=3Bbernard_aboba at hotmail.com&gt=
=3B</p>

<p class=3D"MsoNormal">Mauricio Sanchez &lt=3Bmauricio.sanchez at hp.com&gt=
=3B</p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">Jabber room:&nbsp=3B radext at jabber.ietf.org (Plea=
se join)</p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">Wednesday=2C March 30=2C 2011</p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">0900 - 1130</p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">Karlin II and III<br></p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">09:00 - 09:20=2C Preliminaries</p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Debugging</p>

<p class=3D"MsoNormal">&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Note Well</p>

<p class=3D"MsoNormal">&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Note Takers</p>

<p class=3D"MsoNormal">&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Jabber scribe</p>

<p class=3D"MsoNormal">&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Agenda bash</p>

<p class=3D"MsoNormal">&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Document Status</p>=
<br>IPv6 Items (40 minutes)<br><p class=3D"MsoNormal"><br></p><p class=3D"M=
soNormal">9:20 - 9:40 AM RADIUS Attributes for IPv6 Access Networks (20 min=
utes)<br></p><p class=3D"MsoNormal">http://tools.ietf.org/html/draft-ietf-r=
adext-ipv6-access</p><p class=3D"MsoNormal"><br></p><p class=3D"MsoNormal">=
9:40 AM - 9:50 AM&nbsp=3B RADIUS Attributes for Dual Stack Access=2C L. Yeh=
 (10 minutes)</p><p class=3D"MsoNormal">http://tools.ietf.org/html/draft-ye=
h-radext-dual-stack-access</p><p class=3D"MsoNormal"><br></p><p class=3D"Ms=
oNormal">9:50 AM - 10:00 AM RADIUS Extensions for Dual Stack Lite=2C R. Mag=
liione (10 minutes)<br></p><p class=3D"MsoNormal">http://tools.ietf.org/htm=
l/draft-ietf-softwire-dslite-radius-ext<br></p><p class=3D"MsoNormal"><br><=
/p>

<p class=3D"MsoNormal">Security Work Items (60 minutes)</p>

<p class=3D"MsoNormal">&nbsp=3B</p><p class=3D"MsoNormal">10:00 - 10:20 AM =
Crypto-Agility Requirements for RADIUS (20 minutes)</p><p class=3D"MsoNorma=
l">http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements=
</p>

<p class=3D"MsoNormal"><br></p><p class=3D"MsoNormal">10:20 AM - 10:30 AM R=
ADIUS over TLS=2C Stefan Winter (10 minutes)</p>

<p class=3D"MsoNormal">http://tools.ietf.org/html/draft-ietf-radext-radsec<=
/p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">10:30 AM - 10:40 AM Dynamic Peer Discovery=2C Stefan=
 Winter (10
minutes)</p>

<p class=3D"MsoNormal">http://tools.ietf.org/html/draft-ietf-radext-dynamic=
-discovery</p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">10:40 AM - 10:50 AM RADIUS over DTLS=2C Alan DeKok (=
10 minutes)</p>

<p class=3D"MsoNormal">http://tools.ietf.org/html/draft-ietf-radext-dtls</p=

<p class=3D"MsoNormal">&nbsp=3B</p>

10:50 - 11:00 AM RADIUS Protocol Extensions=2C Alan DeKok (10 minutes)<br>h=
ttp://tools.ietf.org/html/draft-ietf-radext-radius-extensions<br><br><p cla=
ss=3D"MsoNormal">Discussion and Wrap-up (30 minutes)</p>

<p class=3D"MsoNormal">&nbsp=3B <br></p>

<p class=3D"MsoNormal">11:00 =96 11:15 AM Discussion (15 minutes)</p>

11:15 - 11:30&nbsp=3B AM Next Steps:&nbsp=3B WG Chairs &amp=3B ADs (15 minu=
tes) 		 	   		  </body>
</html>=

--_c1e356c3-d7e5-4884-9fbb-1c82064e628f_--

Delivery-date: Sun, 13 Mar 2011 13:32:27 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-crypto-agility-requirements-04.txt
Date: Sun, 13 Mar 2011 06:30:01 -0700

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)
	Author(s)       : D. Nelson
	Filename        : draft-ietf-radext-crypto-agility-requirements-04.txt
	Pages           : 11
	Date            : 2011-03-12

This memo describes the requirements for a crypto-agility solution
for Remote Authentication Dial-In User Service (RADIUS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-crypto-agility-requirements-04.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Sun, 13 Mar 2011 01:40:12 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sun, 13 Mar 2011 01:38:43 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #23: Comments

#23: Comments

Comment(by bernard_aboba@…):

 It is not clear to me what is meant by "MUST use the existing mechanisms".
 RADIUS does not include a version field, nor is any negotiation mechanism
 defined in any of the existing RADIUS RFCs.  Recommend that this phrase be
 deleted.

 Also, there is a simple workaround to the issue of probing delays:
 upgrade the responder (e.g. RADIUS server) first, so that a crypto-agile
 request will always receive a response.

 The proposed revision to Section 2 is as follows:

 2.  A Working Definition of Crypto-Agility

    A generalized definition of crypto-agility was offered up at the
    RADEXT WG session during IETF-68.  Crypto-Agility is the ability of a
    protocol to adapt to evolving cryptography and security requirements.
    This may include the provision of a modular mechanism to allow
    cryptographic algorithms to be updated without substantial disruption
    to fielded implementations.  It may provide for the dynamic
    negotiation and installation of cryptographic algorithms within
    protocol implementations (think of Dynamic-Link Libraries (DLL)).

    In the specific context of the RADIUS protocol and RADIUS
    implementations, crypto-agility may be better defined as the ability
    of RADIUS implementations to automatically negotiate cryptographic
    algorithms for use in RADIUS exchanges, including the algorithms used
    to integrity protect and authenticate RADIUS packets and to hide
    RADIUS Attributes.  This capability covers all RADIUS message types:
    Access-Request/Response, Accounting-Request/Response, CoA/Disconnect-
    Request/Response, and Status-Server.  Negotiation of cryptographic
    algorithms MAY occur within the RADIUS protocol, or within a lower
    layer such as the transport layer.

    Since RADIUS is a request/response protocol, the ability to negotiate
    cryptographic algorithms within a single RADIUS exchange is
    inherently limited.  While a RADIUS request can provide a list of
    supported cryptographic algorithms which can selected for use within
    a response, prior to the receipt of a response, the cryptographic
    algorithms utilized to provide security services within the request
    will need to be determined a-priori.

    Proposals MUST NOT introduce new capabilities negotiation features
    into the RADIUS protocol and crypto-agility solutions SHOULD NOT
    require changes to the RADIUS operational model as defined in "RADIUS
    Design Guidelines" [RFC6158] Section 3.1 and Appendix A.4.
    Similarly, a proposal SHOULD focus on the crypto-agility problem and
    nothing else.  For example, proposals SHOULD NOT require new
    attribute formats and SHOULD be compatible with the guidance provided
    in [RFC6158] Section 2.3.

    Acceptable solutions for determining the mechanisms to be used within
    a request include manual configuration as well as backward compatible
    negotiation techniques such as those described in Section 4.3.
    Solutions for determining the mechanisms to be used in a response
    include manual configuration and "advertise and select" mechanisms
    (e.g. selection within the response from mechanisms advertised in a
    request).

 The proposed revision to Section 4.3 is as follows:

 4.3.  Backwards Compatibility

    Solutions to the problem MUST demonstrate backward compatibility with
    existing RADIUS implementations.  That is, an implementation that
    supports both the crypto-agility solution and legacy mechanisms MUST
    be able to talk with legacy RADIUS clients and servers (using the
    legacy mechanisms).

    While backward compatibility is needed to ease the transition between
    legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is
    only appropriate prior to the compromise of those mechanisms.  After
    legacy mechanisms have been compromised, secure algorithms MUST be
    used, so that backward compatibility is no longer possible.

    In order to enable a request to be handled both by legacy as well as
    crypto-agile implementations, a request can be secured with legacy
    algorithms as well as more secure algorithms.  While this approach
    permits the initial use of legacy algorithms between crypto-agile
    implementations, if the responder indicates support for crypto-
    agility, future requests can omit use of legacy algorithms, instead
    utilizing mechanisms indicated in the response.

    This approach minimizes the response delay from both legacy and
    crypto-agile implementations.  However, it is viable only where
    legacy hidden attributes (e.g. User-Password) are not included within
    requests.

    Probing techniques can avoid the use of legacy algorithms between
    crypto-agile implementations.  An initial request can omit use of
    legacy mechanisms, and if a response is received, then the recipient
    can be assumed to be crypto-agile and future requests to that
    recipient can utilize secure mechanisms.  Similarly, the responder
    can assume that the requester supports crypto-agility and can
    prohibit use of legacy mechanisms in future requests.

    If a response is not received, in the absence of information
    indicating responder support for crypto-agility (such as pre-
    configuration or previous receipt of a crypto-agile response), a new
    request can be composed utilizing legacy mechanisms.

    Since legacy implementations not supporting crypto-agility will
    silently discard requests not protected by legacy algorithms rather
    than returning an error, repeated requests may be required to
    distinguish lack of support for crypto-agility from packet loss or
    other failure conditions.  As a result, probing techniques can delay
    initial communication between crypto-agile requesters and legacy
    responders.  This can be addressed by upgrading the responders (e.g.
    RADIUS servers) first.

-- 
----------------------------------+-----------------------------------------
 Reporter:  glenzorn@…            |        Owner:  bernard_aboba@…          
     Type:  defect                |       Status:  closed                   
 Priority:  major                 |    Milestone:  milestone1               
Component:  Crypto-Agility        |      Version:  1.0                      
 Severity:  Active WG Document    |   Resolution:  fixed                    
 Keywords:                        |  
----------------------------------+-----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/23#comment:4>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sun, 13 Mar 2011 00:29:41 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sun, 13 Mar 2011 00:28:35 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #91: Citation for MD5 security Issues

#91: Citation for MD5 security Issues

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Proposed resolution is to change Section 3 to the following:

 3.  The Current State of RADIUS Security

    RADIUS packets, as defined in [RFC2865], are protected by an MD5
    message integrity check (MIC), within the Authenticator field of
    RADIUS packets other than Access-Request [RFC2865] and Status-Server
    [RFC5997].  The Message-Authenticator Attribute utilizes HMAC-MD5 to
    authenticate and integrity protect RADIUS packets.

    While RADIUS does not support confidentiality of entire packets,
    various RADIUS attributes support encrypted (also known as "hidden")
    values, including: User-Password (defined in [RFC2865] Section 5.2),
    Tunnel-Password (defined in [RFC2868] Section 3.5), and various
    Vendor-Specific Attributes, such as the MS-MPPE-Send-Key and MS-MPPE-
    Recv-Key attributes (defined in [RFC2548] Section 2.4).  Generally
    speaking, the hiding mechanism uses a stream cipher based on a key
    stream from an MD5 digest.  Attacks against this mechanism are
    described in [RFC3579] Section 4.3.4.

    "Updated Security Considerations for the MD5 Message-Digest and the
    HMAC-MD5 Algorithms" [RFC6151] discusses security considerations for
    use of the MD5 and HMAC-MD5 algorithms.  While the advances in MD5
    collisions do not immediately compromise the use of MD5 or HMAC-MD5
    for the purposes used within RADIUS absent knowledge of the RADIUS
    shared secret, the progress toward compromise of MD5's basic
    cryptographic assumptions has resulted in the deprecation of MD5
    usage in a variety of applications.  As noted in [RFC6151] Section 2:

       MD5 is no longer acceptable where collision resistance is required
       such as digital signatures.  It is not urgent to stop using MD5 in
       other ways, such as HMAC-MD5; however, since MD5 must not be used
 for
       digital signatures, new protocol designs should not employ HMAC-MD5.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  major                      |    Milestone:  milestone1
Component:  Crypto-Agility             |      Version:  1.0       
 Severity:  Active WG Document         |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/91#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sun, 13 Mar 2011 00:10:18 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sun, 13 Mar 2011 00:09:03 -0000
Reply-To: [email-masked]
Subject: [radext] #91: Citation for MD5 security Issues

#91: Citation for MD5 security Issues

 The document currently does not provide any citations relating to MD5 or
 HMAC-MD5 security considerations.  At a minimum, I'd suggested citing "MD5
 and HMAC-MD5 Security Considerations " RFC 6151.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  major                      |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/91>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sat, 12 Mar 2011 23:54:00 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sat, 12 Mar 2011 23:52:53 -0000
Reply-To: [email-masked]
Subject: [radext] #90: Process for publication and selection

#90: Process for publication and selection

 Nowhere in the document is the approach to publication of crypto-agility
 solutions described, nor does the document describe how standards track
 crypto-agility mechanisms will be selected.

 Previously the RADEXT WG has utilized WG consensus to determine whether to
 adopt a crypto-agility proposal as a WG work item. Initial proposals are
 to be published as EXPERIMENTAL, and multiple implementations of WG work
 items are now in progress.

 One potential approach to evaluating standards track submissions is as
 follows:

 1. Require documents submitted for consideration on the standards track to
 include an evaluation against the Crypto-agility requirements, stating
 whether they are compliant, conditionally compliant, or non-compliant.
 Documents published as EXPERIMENTAL could also include such an evaluation
 (though it wouldn't be required).

 2. Determine the success of the experiments based on implementation
 experience. Factors that may be relevant include performance, required
 footprint, and demonstrated interoperability between multiple independent
 implementations.

 3. Based on requirements evaluation and experiment writeups, the RADEXT WG
 can make the decision of whether to promote a crypto-agility proposal to
 the standards track.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  critical                   |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/90>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sat, 12 Mar 2011 23:35:06 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sat, 12 Mar 2011 23:33:53 -0000
Reply-To: [email-masked]
Subject: [radext] #89: Key Wrap and Password Hiding Requirements

#89: Key Wrap and Password Hiding Requirements

 The properties of a key and a password are different.  Yet in several
 places, the document seems unclear about whether requirements for
 negotiation of Key-Wrap algorithms are distinct from requirements relating
 to hiding of passwords.

 For example, Section 1.3 states the following:

    The RADEXT WG will propose one or more specifications to remediate
    any identified deficiencies in the crypto-agility properties of the
    RADIUS protocol.  The known deficiencies include the issue of
    negotiation of substitute algorithms for the message digest
    functions, the key-wrap functions, and the password-hiding function.
    Additionally, at least one mandatory to implement cryptographic
    algorithm will be defined in each of these areas, as required.

 This would seem to imply that negotiation of algorithms for key-wrap is
 distinct from algorithms for "password hiding".

 Section 2 says this:

    Negotiation of cryptographic
    algorithms MAY occur within the RADIUS protocol, or within a lower
    layer such as the transport layer.

 While confidentiality can be provided in the transport layer, is it
 possible to provide keywrap functionality in this layer?

 Section 4.2 says:

    Proposals MUST support the negotiation of cryptographic algorithms
    for per-packet integrity/authentication protection.  It is
    RECOMMENDED that solutions provide support for confidentiality,
    either by supporting encryption of entire RADIUS packets or by
    encrypting individual RADIUS attributes.  This includes providing
    support for improving the confidentiality of existing encrypted
    (sometimes referred to as "hidden") attributes as well as encrypting
    attributes (such as location attributes) that are currently
    transmitted in cleartext.  Proposals supporting confidentiality MUST
    support the negotiation of cryptographic algorithms for encryption.

 This text appears to treat all encrypted attributes the same.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  critical                   |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/89>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sat, 12 Mar 2011 23:18:18 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sat, 12 Mar 2011 23:17:35 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #88: NITs

#88: NITs

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  minor                      |    Milestone:  milestone1
Component:  Crypto-Agility             |      Version:  1.0       
 Severity:  Active WG Document         |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/88#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sat, 12 Mar 2011 23:17:49 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sat, 12 Mar 2011 23:16:56 -0000
Reply-To: [email-masked]
Subject: [radext] #88: NITs

#88: NITs

 In Section 4.5, Status-Server is left out of the list of RADIUS message to
 which crypto-agility should apply.

 Several mispellings should be fixed:

 "biding" -> bidding
 "negotation" -> negotiation

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  minor                      |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/88>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sat, 12 Mar 2011 23:09:33 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sat, 12 Mar 2011 23:08:34 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #22: Review

#22: Review

Comment(by bernard_aboba@…):

 It isn't clear to me how "Hint and Reject" techniques apply, since legacy
 implementations will silently discard crypto-agile requests that don't
 utilize legacy mechanisms, without sending an error-message.  So the
 reality is more like "Choose and Silent Discard".  This can make it hard
 for a requester to distinguish lack of support for crypto-agility from
 packet loss or some other failure.

 Unless a request utilizing "Hint and Accept" is protected by legacy
 methods, a legacy implementation will silently discard it, this approach
 is only possible if the responder is crypto-agile, and even then, it only
 applies to the response, not the request, which needs to be protected by
 mechanisms that are chosen apriori.  Yet the document talks about the need
 to protect all RADIUS messages, not just responses.

 The reality is that in the absence of information about the capabilities
 of the responder, the requester will need to make a decision on what
 algorithms to use to protect the request.  If legacy mechanisms are
 included, then there will be potential consequences, regardless of what
 other algorithms are used.   So it is desirable to avoid use of legacy
 algorithms between crypto-agile implementations.   Also, information from
 previous responses could be used to determine what mechanisms to use to
 protect subsequent requests.

 Since Section 4.3 is about backward compatibility, it needs to talk about
 some of these issues, and put forward some potential approaches to solving
 the problem that can address security issues in both requests and
 responses.

 The suggested resolution is to change Section 4.3 to the following:

 4.3.  Backwards Compatibility

    Solutions to the problem MUST demonstrate backward compatibility with
    existing RADIUS implementations.  That is, an implementation that
    supports both the crypto-agility solution and legacy mechanisms MUST
    be able to talk with legacy RADIUS clients and servers (using the
    legacy mechanisms).  Proposals MUST NOT introduce new capabilities
    negotation features into the RADIUS protocol, but rather MUST use the
    existing mechanisms.

    While backward compatibility is needed to ease the transition between
    legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is
    only appropriate prior to the compromise of those mechanisms.  After
    legacy algorithms have been compromised, secure algorithms MUST be
    used, so that backward compatibility is no longer possible.

    Acceptable solutions to determining which set of mechanisms is used
    (with a particular peer) include some kind of negotiation, and manual
    configuration.  In order to enable a request to be handled both by
    legacy as well as crypto-agile implementations, a request can be
    secured with legacy algorithms as well as more secure algorithms.
    While this approach permits the initial use of legacy algorithms
    between crypto-agile implementations, if the responder indicates
    support for crypto-agility, future requests can omit use of legacy
    algorithms.

    This approach minimizes the response delay from both legacy and
    crypto-agile implementations.  However, it is viable only where
    legacy hidden attributes (e.g. User-Password) are not included within
    requests, and where compromise of the legacy algorithm and RADIUS
    shared secret does not compromise secure algorithms.

    Probing techniques can be used to avoid the use of legacy algorithms
    between crypto-agile implementations.  An initial request can omit
    use of legacy algorithms, and if a response is received, then the
    recipient can be assumed to be crypto-agile and future requests to
    that recipient can utilize secure algorithms.  Similarly, the
    responder can assume that the requester supports crypto-agility and
    can prohibit use of legacy algorithms in future requests.

    If a response is not received, in the absence of information
    indicating responder support for crypto-agility (such as pre-
    configuration or previous receipt of a crypto-agile response), a new
    request can be composed utilizing legacy algorithms.

    Since legacy implementations not supporting crypto-agility will
    silently discard requests not protected by legacy algorithms rather
    than returning an error, repeated requests may be required to
    distinguish lack of support for crypto-agility from packet loss or
    other failure conditions.  As a result, probing techniques can delay
    initial communication between crypto-agile requesters and legacy
    responders.

    Crypto-agility solutions SHOULD NOT require changes to the RADIUS
    operational model as defined in "RADIUS Design Guidelines" [RFC6158]
    Section 3.1 and Appendix A.4.  Similarly, a proposal SHOULD focus on
    the crypto-agility problem and nothing else.  For example, proposals
    SHOULD NOT require new attribute formats and SHOULD be compatible
    with the guidance provided in [RFC6158] Section 2.3.

-- 
--------------------------------+-------------------------------------------
 Reporter:  jsalowey@…          |        Owner:  bernard_aboba@…          
     Type:  defect              |       Status:  closed                   
 Priority:  major               |    Milestone:  milestone1               
Component:  Crypto-Agility      |      Version:  1.0                      
 Severity:  Active WG Document  |   Resolution:  fixed                    
 Keywords:                      |  
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/22#comment:2>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sat, 12 Mar 2011 22:55:24 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sat, 12 Mar 2011 22:54:17 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #23: Comments

#23: Comments

Comment(by bernard_aboba@…):

 This still isn't quite right.  While negotiation within a single RADIUS
 request/response is limited,  there are potential techniques that could be
 utilized over multiple exchanges.  Currently, the text doesn't describe
 the limitations or lay out some of the possibilities, nor does it discuss
 the implications for backwards compatibility for security or performance.

 Suggested resolution is as follows:

 Change Section 2 to the following:

 2.  A Working Definition of Crypto-Agility

    A generalized definition of crypto-agility was offered up at the
    RADEXT WG session during IETF-68.  Crypto-Agility is the ability of a
    protocol to adapt to evolving cryptography and security requirements.
    This may include the provision of a modular mechanism to allow
    cryptographic algorithms to be updated without substantial disruption
    to fielded implementations.  It may provide for the dynamic
    negotiation and installation of cryptographic algorithms within
    protocol implementations (think of Dynamic-Link Libraries (DLL)).

    In the specific context of the RADIUS protocol and RADIUS
    implementations, crypto-agility may be better defined as the ability
    of RADIUS implementations to automatically negotiate cryptographic
    algorithms for use in RADIUS exchanges, including the algorithms used
    to integrity protect and authenticate RADIUS packets and to hide
    RADIUS Attributes.  This capability covers all RADIUS message types:
    Access-Request/Response, Accounting-Request/Response, CoA/Disconnect-
    Request/Response, and Status-Server.  Negotiation of cryptographic
    algorithms MAY occur within the RADIUS protocol, or within a lower
    layer such as the transport layer.

    Since RADIUS is a request/response protocol, the ability to negotiate
    cryptographic algorithms within a single RADIUS exchange is
    inherently limited.  While a RADIUS request can provide a list of
    supported cryptographic algorithms which can selected for use within
    a response, prior to the receipt of a response, the cryptographic
    algorithms utilized to provide security services within the request
    will need to be determined a-priori.  Techniques that can be used for
    negotiation over multiple request/response exchanges are described in
    Section 4.3.

 Change the third paragraph of Section 4.2 to the following:

    Crypto-agility solutions MUST avoid security compromise, even in
    situations where the existing cryptographic algorithms utilized by
    RADIUS implementations are shown to be weak enough to provide little
    or no security (e.g. in event of compromise of the legacy RADIUS
    shared secret).  Included in this would be protection against bidding
    down attacks.  In analyzing the resilience of a crypto-agility
    solution, it can be assumed that RADIUS requesters and responders can
    be configured to require the use of new secure algorithms in the
    event of a compromise of existing cryptographic algorithms or the
    legacy RADIUS shared secret.

 Change Section 4.3 to the following:

 4.3.  Backwards Compatibility

    Solutions to the problem MUST demonstrate backward compatibility with
    existing RADIUS implementations.  That is, an implementation that
    supports both the crypto-agility solution and legacy mechanisms MUST
    be able to talk with legacy RADIUS clients and servers (using the
    legacy mechanisms).  Proposals MUST NOT introduce new capabilities
    negotation features into the RADIUS protocol, but rather MUST use the
    existing mechanisms.

    While backward compatibility is needed to ease the transition between
    legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is
    only appropriate prior to the compromise of those mechanisms.  After
    legacy algorithms have been compromised, secure algorithms MUST be
    used, so that backward compatibility is no longer possible.

    Acceptable solutions to determining which set of mechanisms is used
    (with a particular peer) include some kind of negotiation, and manual
    configuration.  In order to enable a request to be handled both by
    legacy as well as crypto-agile implementations, a request can be
    secured with legacy algorithms as well as more secure algorithms.
    While this approach permits the initial use of legacy algorithms
    between crypto-agile implementations, if the responder indicates
    support for crypto-agility, future requests can omit use of legacy
    algorithms.

    This approach minimizes the response delay from both legacy and
    crypto-agile implementations.  However, it is viable only where
    legacy hidden attributes (e.g. User-Password) are not included within
    requests, and where compromise of the legacy algorithm and RADIUS
    shared secret does not compromise secure algorithms.

    Probing techniques can be used to avoid the use of legacy algorithms
    between crypto-agile implementations.  An initial request can omit
    use of legacy algorithms, and if a response is received, then the
    recipient can be assumed to be crypto-agile and future requests to
    that recipient can utilize secure algorithms.  Similarly, the
    responder can assume that the requester supports crypto-agility and
    can prohibit use of legacy algorithms in future requests.

    If a response is not received, in the absence of information
    indicating responder support for crypto-agility (such as pre-
    configuration or previous receipt of a crypto-agile response), a new
    request can be composed utilizing legacy algorithms.

    Since legacy implementations not supporting crypto-agility will
    silently discard requests not protected by legacy algorithms rather
    than returning an error, repeated requests may be required to
    distinguish lack of support for crypto-agility from packet loss or
    other failure conditions.  As a result, probing techniques can delay
    initial communication between crypto-agile requesters and legacy
    responders.

    Crypto-agility solutions SHOULD NOT require changes to the RADIUS
    operational model as defined in "RADIUS Design Guidelines" [RFC6158]
    Section 3.1 and Appendix A.4.  Similarly, a proposal SHOULD focus on
    the crypto-agility problem and nothing else.  For example, proposals
    SHOULD NOT require new attribute formats and SHOULD be compatible
    with the guidance provided in [RFC6158] Section 2.3.

-- 
----------------------------------+-----------------------------------------
 Reporter:  glenzorn@…            |        Owner:  bernard_aboba@…          
     Type:  defect                |       Status:  closed                   
 Priority:  major                 |    Milestone:  milestone1               
Component:  Crypto-Agility        |      Version:  1.0                      
 Severity:  Active WG Document    |   Resolution:  fixed                    
 Keywords:                        |  
----------------------------------+-----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/23#comment:3>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sat, 12 Mar 2011 22:23:16 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sat, 12 Mar 2011 22:21:36 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #86: MD5 Stream Cipher Weaknesses

#86: MD5 Stream Cipher Weaknesses

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Note that the Access-Request isn't the only RADIUS packet not protected by
 a MIC in the Authenticator field;  Status-Server also isn't protected that
 way.

 The proposed resolution is to change Section 3 to the following:

 3.  The Current State of RADIUS Security

    RADIUS packets, as defined in [RFC2865], are protected by an MD5
    message integrity check (MIC), within the Authenticator field of
    RADIUS packets other than Access-Request [RFC2865] and Status-Server
    [RFC5997].  The Message-Authenticator Attribute utilizes HMAC-MD5 to
    authenticate and integrity protect RADIUS packets.

    While RADIUS does not support confidentiality of entire packets,
    various RADIUS attributes support encrypted (also known as "hidden")
    values, including: User-Password [RFC2865, section 5.2], Tunnel-
    Password [RFC2868, section 3.5], and various Vendor-Specific
    Attributes, such as the MS-MPPE-Send-Key and MS-MPPE-Recv-Key
    attributes defined in [RFC2548, section 2.4].  Generally speaking,
    the hiding mechanism uses a stream cipher based on a key stream from
    an MD5 digest.  Attacks against this mechanism are described in
    [RFC3579] Section 4.3.4.

    Recent work on MD5 collisions does not immediately compromise these
    functions absent knowledge of the RADIUS shared secret.  However, the
    progress toward compromise of MD5's basic cryptographic assumptions
    has resulted in the deprecation of MD5 usage in a variety of
    applications.

 Add the following references to Section 8:

 [RFC2548]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
            2548, March 1999.

 [RFC2868]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
            and I. Goyret, "RADIUS Attributes for Tunnel Protocol
            Support", RFC 2868, June 2000.

 [RFC5997]  DeKok, A., "Use of Status-Server Packets in the Remote
            Authentication Dialin User Service (RADIUS) Protocol", RFC
            5997, August 2011.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  major                      |    Milestone:  milestone1
Component:  Crypto-Agility             |      Version:  1.0       
 Severity:  Active WG Document         |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/86#comment:1>
radext <http://tools.ietf.org/radext/>

Envelope-to: [email-masked]
Delivery-date: Sat, 12 Mar 2011 02:14:37 +0000
To: [email-masked], [email-masked]
Subject: BCP 158, RFC 6158 on RADIUS Design Guidelines
From: [email-masked]
Cc: [email-masked], [email-masked]
Message-Id: <[email-masked]>
Date: Fri, 11 Mar 2011 18:13:15 -0800 (PST)

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

        BCP 158        
        RFC 6158

        Title:      RADIUS Design Guidelines 
        Author:     A. DeKok, Ed.,
                    G. Weber
        Status:     Best Current Practice
        Stream:     IETF
        Date:       March 2011
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      38
        Characters: 89319
        See Also:   BCP0158

        I-D Tag:    draft-ietf-radext-design-19.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6158.txt

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, within the
IETF as well as other Standards Development Organizations (SDOs).
This memo documents an Internet Best Current Practice.

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

BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

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

The RFC Editor Team
Association Management Solutions, LLC

Delivery-date: Fri, 11 Mar 2011 14:04:03 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 11 Mar 2011 14:02:54 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #3: Review of RTLS document (part 1, Technical)

#3: Review of RTLS document (part 1, Technical)

Comment(by stefan.winter@…):

 - TLS negotiation text rewritten as suggested

 - certificate validation from trusted sources: removed; this will be dealt
 with in the dynamic discovery draft. Only a note in the non-normative
 section remains.

 - Client Identity: still needs some discussion, will be up on the slide
 deck at IETF 80

 - DAC: as discussed on the ML, all traffic should go through the same
 port. A client does not have to be a DAC; if it's not, it is required to
 NAK the DA traffic though.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  stefan.winter@…         
     Type:  defect                     |      Status:  new                     
 Priority:  major                      |   Milestone:  milestone1              
Component:  radsec                     |     Version:  1.0                     
 Severity:  In WG Last Call            |    Keywords:                          
---------------------------------------+------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/radext/trac/ticket/3#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 07 Mar 2011 22:23:30 +0000
Date: Mon, 07 Mar 2011 14:22:27 -0800
From: Tina Tsou <[email-masked]>
Subject: RADIUS Attributes for Dual Stack Access
To: [email-masked]

Hi all,
https://datatracker.ietf.org/doc/draft-yeh-radext-dual-stack-access/?include
_text=1
submitted.

Filename:	 draft-yeh-radext-dual-stack-access
Revision:	 00
Title:		 RADIUS Attributes for Dual Stack Access
Creation_date:	 2011-03-07
WG ID:		 Independent Submission
Number_of_pages: 11

Abstract:
This document specifies the RADIUS attributes for IPv4 and IPv6 dual
stack access, which are intended to be used in the AAA processes for
the transfer of user's configuration from AAA server to NAS and
traffic statistics reporting from NAS to AAA server.  The new
attributes cover a specified user type for NAS to allocate the proper
resource and employ the right mechanism for the users; and a batch of
IPv4 and IPv6 traffic statistics for the differentiated accounting
policies on the AAA server.

I would like to say something about this
draft-yeh-radext-dual-stack-access-00.
1. draft-ietf-radext-ipv6-access is valid.

2. draft-yeh-radext-dual-stack-access-00 talks about 13 attributes. The
following 6 attributes in draft-yeh-radext-dual-stack-access-00 are similar
to draft-maglione-radext-ipv6-acct-extensions, which expired.
o  Acct-Input-IPv6-Octets
o  Acct-Output-IPv6-Octets
o  Acct-Input-IPv6-Packets
o  Acct-Output-IPv6-Packets
o  Acct-Input-IPv6-Gigawords
o  Acct-Output-IPv6-Gigawords

3. There is one work item of IPv6-only in WG RADEXT, would the WG tell me
whether we would like to have a new work item for dual-stack?

Thanks.

We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

Delivery-date: Sun, 06 Mar 2011 06:59:09 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sun, 06 Mar 2011 06:58:45 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #87: Guidance on mandatory-to-implement algorithms

#87: Guidance on mandatory-to-implement algorithms

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  critical                   |    Milestone:  milestone1
Component:  Crypto-Agility             |      Version:  1.0       
 Severity:  Active WG Document         |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/87#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sun, 06 Mar 2011 06:59:01 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sun, 06 Mar 2011 06:58:05 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #23: Comments

#23: Comments

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Updated proposal.  Add the following text to the end of Section 2:

    Negotiation of cryptographic algorithms MAY occur within the RADIUS
    protocol, or within a lower layer such as the transport layer.  Since
    RADIUS is a request/response protocol, the ability to negotiate
    cryptographic algorithms within RADIUS is inherently limited.  While
    a RADIUS request can provide a list of supported cryptographic
    algorithms which can selected for use within a response, prior to the
    receipt of a response, the cryptographic algorithms utilized to
    provide security services within the request will need to be pre-
    configured.  Since legacy implementations not supporting crypto-
    agility will silently discard requests not protected by legacy
    algorithms, in the absence of knowledge about the capabilities of the
    recipient, requests will need to be protected by legacy algorithms.

 Within Section 4.3 delete:

    Included in such negotiation techniques are "hint and
    accept" and "hint and reject" mechanisms, where the NAS (RADIUS
    client) provides a list of supported algorithms and the RADIUS server
    selects one.

-- 
----------------------------------+-----------------------------------------
 Reporter:  glenzorn@…            |        Owner:  bernard_aboba@…          
     Type:  defect                |       Status:  closed                   
 Priority:  major                 |    Milestone:  milestone1               
Component:  Crypto-Agility        |      Version:  1.0                      
 Severity:  Active WG Document    |   Resolution:  fixed                    
 Keywords:                        |  
----------------------------------+-----------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/23#comment:2>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sun, 06 Mar 2011 04:56:15 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sun, 06 Mar 2011 04:55:27 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #23: Comments

#23: Comments

Comment(by bernard_aboba@…):

 It is proposed that we change the following text in Section 4.3:

    Proposals MUST NOT introduce new capabilities negotation features
    into the RADIUS protocol, but rather MUST use the existing
    mechanisms.  Included in such negotiation techniques are "hint and
    accept" and "hint and reject" mechanisms, where the NAS (RADIUS
    client) provides a list of supported algorithms and the RADIUS server
    selects one.

 To:

 Negotiation of cryptographic algorithms MAY occur within the
 RADIUS protocol, or within a lower layer such as the transport
 layer.  Since RADIUS is a request/response protocol, the ability to
 negotiate cryptographic algorithms within RADIUS is inherently
 limited.  While a RADIUS request can provide a list of supported
 cryptographic algorithms which can selected for use within a response,
 prior to the receipt of a response, the cryptographic algorithms
 utilized to provide security services within the request will need to be
 pre-configured.
 Since legacy implementations not supporting crypto-agility will
 silently discard requests not protected by legacy algorithms,
 in the absence of knowledge about the capabilities of the
 recipient, requests will need to be protected by legacy algorithms.

-- 
----------------------------------+-----------------------------------------
 Reporter:  glenzorn@…            |       Owner:  bernard_aboba@…          
     Type:  defect                |      Status:  new                      
 Priority:  major                 |   Milestone:  milestone1               
Component:  Crypto-Agility        |     Version:  1.0                      
 Severity:  Active WG Document    |    Keywords:                           
----------------------------------+-----------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/23#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sun, 06 Mar 2011 03:12:19 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sun, 06 Mar 2011 03:11:52 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #85: Confidentiality Requirements

#85: Confidentiality Requirements

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Proposal is to change the existing text to the following:

 Proposals MUST support the negotiation of cryptographic algorithms
 for per-packet integrity/authentication protection.
 It is RECOMMENDED that solutions provide support for confidentiality,
 either by supporting encryption of entire RADIUS packets or
 by encrypting individual RADIUS attributes.
 This includes providing support for improving the confidentiality of
 existing encrypted (sometimes referred to as "hidden")
 attributes as well as encrypting attributes (such as location attributes)
 that are currently transmitted in cleartext.
 Proposals supporting confidentiality MUST support the negotiation
 of cryptographic algorithms for encryption.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  major                      |    Milestone:  milestone1
Component:  Crypto-Agility             |      Version:  1.0       
 Severity:  Active WG Document         |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/85#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sun, 06 Mar 2011 03:00:50 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sun, 06 Mar 2011 03:00:32 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #84: Requirements Language

#84: Requirements Language

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  minor                      |    Milestone:  milestone1
Component:  Crypto-Agility             |      Version:  1.0       
 Severity:  Active WG Document         |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/84#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sun, 06 Mar 2011 02:51:15 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sun, 06 Mar 2011 02:50:16 -0000
Reply-To: [email-masked]
Subject: [radext] #87: Guidance on mandatory-to-implement algorithms

#87: Guidance on mandatory-to-implement algorithms

 Section 4.2 does not provide any guidance as to what cryptographic
 algorithms are acceptable for designation as mandatory-to-implement, nor
 does it reference any such guidance.

 My recommendation is that the following paragraph be added to Section 4.2:

 Guidance on acceptable algorithms can be found in [NIST-SP800-131A].
 It is RECOMMENDED that mandatory-to-implement cryptographic
 algorithms be chosen from among those classified as "Acceptable"
 with no known deprecation date within [NIST-SP800-131A].

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  critical                   |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/87>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sat, 05 Mar 2011 22:25:19 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sat, 05 Mar 2011 22:25:02 -0000
Reply-To: [email-masked]
Subject: [radext] #86: MD5 Stream Cipher Weaknesses

#86: MD5 Stream Cipher Weaknesses

 Section 3 states:

 RADIUS packets, as defined in [RFC2865], are protected by an MD5
 message integrity check (MIC), within the Authenticator field of
 RADIUS packets other than Access-Request.  The Message-Authenticator
 Attribute utilizes HMAC-MD5 to authenticate and integrity protect
 RADIUS packets.  Various RADIUS attributes support encrypted
 (also known as "hidden") values,
 including: User-Password, Tunnel-Password, and various Vendor-
 Specific Attributes.  Generally speaking, the hiding mechanism uses a
 stream cipher based on a key stream from an MD5 digest.

 Recent work on MD5 collisions does not immediately compromise any of
 these methods, absent knowledge of the RADIUS shared secret.
 However, the progress toward compromise of MD5's basic cryptographic
 assumptions has resulted in the deprecation of MD5 usage in a variety
 of applications.

 The weaknesses of MD5 stream ciphers is independent of MD5 collision
 issues and therefore it is not accurate to state that there is no
 compromise absent knowledge of the shared secret.  For example, were the
 RADIUS authenticator to repeat, a known plaintext attack on hidden
 attributes such as User-Password is possible.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  major                      |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/86>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sat, 05 Mar 2011 22:16:18 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sat, 05 Mar 2011 22:15:34 -0000
Reply-To: [email-masked]
Subject: [radext] #85: Confidentiality Requirements

#85: Confidentiality Requirements

 Section 4.3 states:

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

 This paragraph is confusing along multiple dimensions.

 Since RADIUS is a transactional protocol, it is not possible to
 "negotiate" algorithms for use in a RADIUS request; algorithm(s) must be
 chosen.  Also, it is not clear whether negotiation as referred to here
 would refer to encryption of entire RADIUS packets or just individual
 attributes.  Also does "encryption of existing attributes" imply that
 attributes can be doubly encrypted?

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  major                      |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/85>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sat, 05 Mar 2011 20:59:40 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sat, 05 Mar 2011 20:58:26 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #22: Review

#22: Review

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 The proposed resolution is as follows:

 Within Section 4.3, change the following text:

    Proposals MUST NOT introduce new capabilities negotation features
    into the RADIUS protocol, but rather MUST use the existing
    mechanisms.  Included in such negotiation techniques are "hint and
    accept" and "hint and reject" mechanisms, where the NAS (RADIUS
    client) provides a list of supported algorithms and the RADIUS server
    selects one.

 to:

    Proposals MUST NOT introduce new capabilities negotiation features
    into the RADIUS protocol, but rather MUST use existing mechanisms.
    Negotiation techniques include "hint and accept" and "hint and
    reject" mechanisms, where the RADIUS request provides a list of
    supported algorithms and one is selected in the response.  Since it
    is necessary to integrity protect the list of algorithms, at least
    one ciphersuite needs to be used to protect the request and response.

-- 
--------------------------------+-------------------------------------------
 Reporter:  jsalowey@…          |        Owner:  bernard_aboba@…          
     Type:  defect              |       Status:  closed                   
 Priority:  major               |    Milestone:  milestone1               
Component:  Crypto-Agility      |      Version:  1.0                      
 Severity:  Active WG Document  |   Resolution:  fixed                    
 Keywords:                      |  
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/22#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 04 Mar 2011 09:39:13 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Fri, 04 Mar 2011 09:38:51 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #60: Behavior in response to CoA-Request

#60: Behavior in response to CoA-Request

Changes (by stefan.winter@…):

  * status:  new => closed
  * resolution:  => worksforme

Comment:

 A poll was held on the WG mailing list to determine whether Auth/Acct/CoA
 should be on separte connections (separate ports).
 The poll favoured to stay on one port for all traffic. This requires a
 RADIUS/TLS enabled DAS to implement a CoA-NAK as an indication of
 unwillingness to process CoA requests.
 This is in line with the text of the -07 draft and remains unchanged for
 -08.

 -08 will include further text regarding RADIUS Accounting. For reference,
 the text for both packet types in -08 is below:

 (4) RADIUS [RFC2865] used negative ICMP responses to a newly allocated UDP
 port to signal that a peer RADIUS server does not support reception and
 processing of the packet types in [RFC5176]. These packet types are listed
 as to be received in RADIUS/TLS implementations.  Note well: it is not
 required for an implementation to actually process these packet types.  It
 is sufficient that upon receiving such a packet, an unconditional NAK is
 sent back to indicate that the action is not supported.

 (5) RADIUS [RFC2865] used negative ICMP responses to a newly allocated UDP
 port to signal that a peer RADIUS server does not support reception and
 processing of RADIUS Accounting packets.  There is no RADIUS datagram to
 signal an Accounting NAK.  Clients may be misconfigured to send Accounting
 packets to a RADIUS/TLS server which does not wish to process their
 Accounting packet.  The server will need to silently drop the packet.  The
 client will need to deduce from the absence of replies that it is
 misconfigured; no negative ICMP response will reveal this.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:  stefan.winter@…         
     Type:  defect                     |       Status:  closed                  
 Priority:  major                      |    Milestone:  milestone1              
Component:  radsec                     |      Version:  1.0                     
 Severity:  In WG Last Call            |   Resolution:  worksforme              
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/60#comment:2>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 04 Mar 2011 09:33:29 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Fri, 04 Mar 2011 09:32:53 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #56: Review

#56: Review

Changes (by stefan.winter@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 All editorial changes in the review are addressed in the upcoming -08
 version. Regarding connection backoff, the following text is in -08:

 2.3.  Connection Setup

    RADIUS/TLS nodes

    1.  establish TCP connections as per [I-D.ietf-radext-tcp-transport].
 Failure to connect leads to continuous retries, with exponentially growing
 intervals between every try.  If multiple servers are defined, the node
 MAY attempt to establish a connection to these other servers in parallel,
 in order to implement quick failover.

 I hope that this closes the issue.

-- 
---------------------------------------+------------------------------------
 Reporter:  aland@…                    |        Owner:  stefan.winter@…         
     Type:  defect                     |       Status:  closed                  
 Priority:  major                      |    Milestone:  milestone1              
Component:  radsec                     |      Version:  1.0                     
 Severity:  Active WG Document         |   Resolution:  fixed                   
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/56#comment:2>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 04 Mar 2011 08:58:23 +0000
Date:	Fri, 04 Mar 2011 11:57:30 +0300
From:	Victor Gamov <[email-masked]>
Organization: Eurocomm.net
To:	[email-masked]
Subject: Re: I-D Action:draft-ietf-radext-radius-extensions-00.txt

This is a multi-part message in MIME format.
--------------010001090701010201070304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 02.03.2011 16:08, Victor Gamov wrote:
> Hi All !
>
> To extend Type space and allow large values I propose following
> format with new unassigned Type:
>
> 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=0 | Actual Length |
> +---------------+---------------+-------------------------------+ |
> New Type (up to 65535 types) |Long Value (up to 65529 bytes)..
> +---------------+---------------+---------------+---------------+
>
> Incompatible implementations will generate reject or discard such
> attributes due Length=0.

Some explanations

If RADIUS-client wants to deliver long-value attribute to RADIUS-server,
then this server and client needs to realize some mechanism to allow
such values. Any splitting or other -- its need to be realized into both
server and clinet.

If client wants to deliver any important info by new (compatible)
mechanism but server does not know anything about this mechanism, so
this important info will be not processed by server.  And client does
not know about it!
If server drop or reject packets with Length=0 then client know about it.

If RADIUS-server send replies with important long-value attributes with
Length=0 then client drops such packets and session never started.
Client may send Acct-Stop by failure and server clear info about session
early started (from the point of view of RADIUS-server)

-- 
CU,
Victor Gamov

--------------010001090701010201070304
Content-Type: text/x-vcard; charset=utf-8;
 name="vit.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="vit.vcf"

begin:vcard
fn:Victor Gamov
n:Gamov;Victor
email;internet:[email-masked]
tel;work:sip:[email-masked]
x-mozilla-html:FALSE
version:2.1
end:vcard

--------------010001090701010201070304--

Delivery-date: Fri, 04 Mar 2011 06:54:42 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Call for Agenda Items
Date: Thu, 3 Mar 2011 22:54:14 -0800

--_b7802388-12e8-4e75-bc91-b116697b581b_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

This is a call for agenda items at the RADEXT WG session at IETF 80 in Prag=
ue=2C CZ.  The WG is scheduled to meet on Wednesday morning from 9 AM to 11=
:30 AM.   Remote presentation can be arranged=2C so feel free to suggest an=
 agenda item even if you cannot be physically present.=20

Here is a strawman agenda:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RADEXT WG IETF 80 Agenda=20

=20

Chairs:

Bernard Aboba <bernard_aboba at hotmail.com>

Mauricio Sanchez <mauricio.sanchez at hp.com>

=20

Jabber room:  radext at jabber.ietf.org (Please join)

=20

Wednesday=2C March 30=2C 2011

=20

0900 - 1130

=20

Karlin II and III

=20

09:00 - 09:20=2C Preliminaries

=20

     Debugging

     Note Well

     Note Takers

     Jabber scribe

     Agenda bash

     Document Status
Documented completing WG Last Call (20 minutes)
9:20 - 9:40 AM RADIUS Attributes for IPv6 Access Networks (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-ipv6-access

WG Work Items (60 minutes)

 9:40 - 10:00 AM Crypto-Agility Requirements for RADIUS (20 minutes)http://=
tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements

10:00 AM - 10:10 AM RADIUS over TLS=2C Stefan Winter (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-radsec

=20

10:10 AM - 10:20 AM Dynamic Peer Discovery=2C Stefan Winter (10
minutes)

http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

=20

10:20 AM - 10:40 AM RADIUS over DTLS=2C Alan DeKok (20 minutes)

http://tools.ietf.org/html/draft-ietf-radext-dtls

=20

10:40 - 11:00 AM RADIUS Protocol Extensions=2C Alan DeKok (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radius-extensions

Discussion and Wrap-up (30 minutes)

 =20

11:00 =96 11:15 AM Discussion (15 minutes)

11:15 - 11:30  AM Next Steps:  WG Chairs & ADs (15 minutes)
 		 	   		  =

--_b7802388-12e8-4e75-bc91-b116697b581b_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
This is a call for agenda items at the RADEXT WG session at IETF 80 in Prag=
ue=2C CZ.&nbsp=3B The WG is scheduled to meet on Wednesday morning from 9 A=
M to 11:30 AM. &nbsp=3B Remote presentation can be arranged=2C so feel free=
 to suggest an agenda item even if you cannot be physically present. <br><b=
r>Here is a strawman agenda:<br><br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br><p class=3D"MsoNormal">RADEXT WG IETF 80=
 Agenda </p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">Chairs:</p>

<p class=3D"MsoNormal">Bernard Aboba &lt=3Bbernard_aboba at hotmail.com&gt=
=3B</p>

<p class=3D"MsoNormal">Mauricio Sanchez &lt=3Bmauricio.sanchez at hp.com&gt=
=3B</p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">Jabber room:&nbsp=3B radext at jabber.ietf.org (Plea=
se join)</p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">Wednesday=2C March 30=2C 2011</p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">0900 - 1130</p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">Karlin II and III<br></p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">09:00 - 09:20=2C Preliminaries</p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Debugging</p>

<p class=3D"MsoNormal">&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Note Well</p>

<p class=3D"MsoNormal">&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Note Takers</p>

<p class=3D"MsoNormal">&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Jabber scribe</p>

<p class=3D"MsoNormal">&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Agenda bash</p>

<p class=3D"MsoNormal">&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Document Status</p>=
<br>Documented completing WG Last Call (20 minutes)<p class=3D"MsoNormal"><=
br></p><p class=3D"MsoNormal">9:20 - 9:40 AM RADIUS Attributes for IPv6 Acc=
ess Networks (20 minutes)<br></p><p class=3D"MsoNormal">http://tools.ietf.o=
rg/html/draft-ietf-radext-ipv6-access</p><p class=3D"MsoNormal"><br></p>

<p class=3D"MsoNormal">WG Work Items (60 minutes)</p>

<p class=3D"MsoNormal">&nbsp=3B</p><p class=3D"MsoNormal">9:40 - 10:00 AM C=
rypto-Agility Requirements for RADIUS (20 minutes)</p><p class=3D"MsoNormal=
">http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements<=
/p>

<p class=3D"MsoNormal"><br></p><p class=3D"MsoNormal"></p><p class=3D"MsoNo=
rmal">10:00 AM - 10:10 AM RADIUS over TLS=2C Stefan Winter (10 minutes)</p>

<p class=3D"MsoNormal">http://tools.ietf.org/html/draft-ietf-radext-radsec<=
/p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">10:10 AM - 10:20 AM Dynamic Peer Discovery=2C Stefan=
 Winter (10
minutes)</p>

<p class=3D"MsoNormal">http://tools.ietf.org/html/draft-ietf-radext-dynamic=
-discovery</p>

<p class=3D"MsoNormal">&nbsp=3B</p>

<p class=3D"MsoNormal">10:20 AM - 10:40 AM RADIUS over DTLS=2C Alan DeKok (=
20 minutes)</p>

<p class=3D"MsoNormal">http://tools.ietf.org/html/draft-ietf-radext-dtls</p=

<p class=3D"MsoNormal">&nbsp=3B</p>

10:40 - 11:00 AM RADIUS Protocol Extensions=2C Alan DeKok (20 minutes)<br>h=
ttp://tools.ietf.org/html/draft-ietf-radext-radius-extensions<br><br><p cla=
ss=3D"MsoNormal">Discussion and Wrap-up (30 minutes)</p>

<p class=3D"MsoNormal">&nbsp=3B <br></p>

<p class=3D"MsoNormal">11:00 =96 11:15 AM Discussion (15 minutes)</p>

11:15 - 11:30&nbsp=3B AM Next Steps:&nbsp=3B WG Chairs &amp=3B ADs (15 minu=
tes)<br> 		 	   		  </body>
</html>=

--_b7802388-12e8-4e75-bc91-b116697b581b_--

Delivery-date: Fri, 04 Mar 2011 06:28:19 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 04 Mar 2011 06:28:04 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #81: Location Privacy

#81: Location Privacy

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Recommendation is to change the text to:

    It is RECOMMENDED for proposals to provide for the encryption
    of existing attributes.  This includes existing "hidden" attributes
    as well as attributes (such as location attributes) that require
    confidentiality.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  major                      |    Milestone:  milestone1
Component:  Crypto-Agility             |      Version:  1.0       
 Severity:  Active WG Document         |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/81#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 04 Mar 2011 06:25:29 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 04 Mar 2011 06:25:08 -0000
Reply-To: [email-masked]
Subject: [radext] #84: Requirements Language

#84: Requirements Language

 Add the following text to the Requirements Language text on page 1:

    A RADIUS crypto-agility solution is not compliant with this
    specification if it fails to satisfy one or more of the MUST or MUST
    NOT statements.  A solution that satisfies all the MUST, MUST NOT,
    SHOULD, and SHOULD NOT statements is said to be "unconditionally
    compliant"; one that satisfies all the MUST and MUST NOT statements
    but not all the SHOULD or SHOULD NOT requirements is said to be
    "conditionally compliant".

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  minor                      |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/84>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 04 Mar 2011 06:15:34 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 04 Mar 2011 06:15:18 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #21: Crypto-Agility thoughts

#21: Crypto-Agility thoughts

Changes (by bernard_aboba@…):

  * status:  assigned => closed
  * resolution:  => fixed

-- 
-----------------------------------+----------------------------------------
 Reporter:  Pasi.Eronen@…          |        Owner:  bernard_aboba@…          
     Type:  defect                 |       Status:  closed                   
 Priority:  blocker                |    Milestone:  milestone1               
Component:  Crypto-Agility         |      Version:  1.0                      
 Severity:  Active WG Document     |   Resolution:  fixed                    
 Keywords:                         |  
-----------------------------------+----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/21#comment:2>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 04 Mar 2011 06:12:20 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 04 Mar 2011 06:12:08 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #83: AKM Requirements

#83: AKM Requirements

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  major                      |    Milestone:  milestone1
Component:  Crypto-Agility             |      Version:  1.0       
 Severity:  Active WG Document         |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/83#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 04 Mar 2011 06:11:48 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Fri, 04 Mar 2011 06:11:37 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #78: Pre-November 2008 Copyright Notice

#78: Pre-November 2008 Copyright Notice

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:  d.b.nelson@…          
     Type:  defect                     |       Status:  closed                
 Priority:  minor                      |    Milestone:  milestone1            
Component:  Crypto-Agility             |      Version:  1.0                   
 Severity:  Active WG Document         |   Resolution:  fixed                 
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/78#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 04 Mar 2011 06:11:33 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 04 Mar 2011 06:11:22 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #79: Reference issues

#79: Reference issues

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  minor                      |    Milestone:  milestone1
Component:  Crypto-Agility             |      Version:  1.0       
 Severity:  Active WG Document         |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/79#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 04 Mar 2011 06:11:21 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 04 Mar 2011 06:10:58 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #80: Section 3

#80: Section 3

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  minor                      |    Milestone:  milestone1
Component:  Crypto-Agility             |      Version:  1.0       
 Severity:  Active WG Document         |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/80#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 04 Mar 2011 06:11:13 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 04 Mar 2011 06:10:30 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #82: Diameter compatibliity

#82: Diameter compatibliity

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  minor                      |    Milestone:  milestone1
Component:  Crypto-Agility             |      Version:  1.0       
 Severity:  Active WG Document         |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/82#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 04 Mar 2011 05:02:11 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-crypto-agility-requirements-03.txt
Date: Thu, 03 Mar 2011 21:00:02 -0800

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)
	Author(s)       : D. Nelson
	Filename        : draft-ietf-radext-crypto-agility-requirements-03.txt
	Pages           : 9
	Date            : 2011-03-03

This memo describes the requirements for a crypto-agility solution
for Remote Authentication Dial-In User Service (RADIUS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-crypto-agility-requirements-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Thu, 03 Mar 2011 23:52:26 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Thu, 03 Mar 2011 23:51:32 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #21: Crypto-Agility thoughts

#21: Crypto-Agility thoughts

Changes (by bernard_aboba@…):

  * status:  new => assigned

Comment:

 Here is a proposed resolution to this issue:

 Hop-by-hop/end-to-end:

 Much of RFC 4962 is open to multiple interpretations, and some parts
 of it can be read as requiring more than hop-by-hop security. IMHO
 exactly the same parts can also be read as saying hop-by-hop can be
 sufficient (when done properly), and I think this document should
 explicitly say it's interpreting 4962 the latter way.

 [BA] The document already incorporates most of the security advice in
 RFC 4962 relevant to AAA protocols.  However, there appear to be a
 few requirements that are not included.  To clarify their interpretation,
 it is recommended that we add the following text to Section 4.2:

 In addition to the above goals, [RFC4962] Section 2 describes
 the following additional security requirements for AAA protocols:

 1.      Strong, fresh session keys.  RFC 4962 Section 2 states:

          "The AAA protocol MUST ensure that the keying material supplied
 as
          an input to session key derivation is fresh...  The mechanism
 used
          to generate session keys MUST ensure that the disclosure of one
          session key does not aid the attacker in discovering any other
          session keys."`

          RADIUS crypto-agility solutions are REQUIRED to generate fresh
          session keys for use between the RADIUS client and server.
          In order to prevent the disclosure of one session key from aiding
          an attacker in discovering other session keys,
          RADIUS crypto-agility solutions are
          RECOMMENDED to support Perfect Forward Secrecy (PFS) with
          respect to session keys negotiated between the RADIUS client
          and server.

 2.     Limit key scope.  RFC 4962 Section 2 states:

          "Following the principle of least privilege, parties MUST NOT
          have access to keying material that is not needed to perform
          their role."

          In order to enable a NAS and RADIUS server to transmit
          keying material directly between each other, it is RECOMMENDED
 that
          a RADIUS crypto-agility solution be compatible with NAI-based
          Dynamic Peer Discovery [RADYN] as well as that it support the
          use of public key credentials for authentication between the
          NAS and RADIUS server.  For compatibility with existing
          operations, RADIUS crypto-agility solutions SHOULD also support
          pre-shared key credentials.

 3.     Prevent the Domino effect.  RFC 4962 Section 2 states:

          "Likewise, compromise of a single
          authenticator MUST NOT compromise keying material held by any
          other authenticator within the system."

          In order to prevent the domino effect, RADIUS crypto-agility
          solutions MUST enable each RADIUS client and server pair to
          authenticate utilizing unique credentials.

 Forward secrecy:

 Sometimes RADIUS is used to deliver keys (like EAP MSK) that will be
 used (perhaps indirectly via additional key derivation steps) to
 encrypt information that may be valuable for a long time. Given this,
 the document needs some discussion about "forward secrecy" (whether
 revealing the long-term credential allows decrypting all past
 communications), and if the conclusion is that crypto-agility
 solutions don't need to support forward secrecy (even as
 optional-to-use feature), explain the rationale behind this
 conclusion.

 [BA] The need to support PFS derives from the
 RFC 4962 requirements, so it is proposed that this be added to
 the Section 4.2 requirements as a recommendation.

 Authentication/long-term credentials:

 Authenticating the RADIUS client and server will require (manual)
 configuration of some kinds of credentials (currently, the RADIUS
 shared secret). The document should say something about what kinds of
 long-term authentication credentials (for RADIUS entities) the
 crypto-agility solutions are expected to support.

 Presumably, they MUST support pair-wise shared secrets. Other
 possibilities for long-term credentials could include e.g. X.509
 certificates with PKI, public keys without certification
 infrastructure (generate keypair + configure fingerprint of peer's
 key), or Kerberos. Even if the conclusion is that nothing else than
 pairwise shared secrets is needed, that should be said in the document
 (with rationale explaining why).

 [BA] The need to support public-key credentials derives
 from the requirement for direct transport of keys and the need
 for pair-wise shared secrets derives from current operational
 practice.  So it is proposed that recommendations relating to
 support for these credential types
 be added to Section 4.2.

 Replay protection:

 Section 4.2 says "Proposals MUST support replay protection. The
 existing mechanisms for replay protection are considered adequate and
 should be maintained." I think the latter sentence needs some
 clarification. If the intent is to say replay protection provided by
 the current mechanisms (i.e., basically none for Access-Request
 messages) is good enough, I would disagree with that (or at least
 would expect to see an explanation why that's the case for
 Access-Requests). If the intent is something else, the text needs
 to be clearer.

 [BA] The proposal is that the following text within Section 4.2:

    Proposals MUST support replay protection.  The existing mechanisms
    for replay protection are considered adequate and should be
    maintained.

 be changed to the following:

    Proposals MUST support per-packet replay protection for all
    RADIUS message types.

 Meaning of negotiation:

 The document says proposals MUST support negotiation of cryptographic
 algorithms. Does "negotiation" here mean picking which algorithm to
 use in the protocol (RADIUS client and server figure out an algorithm
 supported by both of them), or would negotiation between system
 administrators meet this requirement?

 I assume the WG has rough consensus about what this means, and
 ordinarily, I would have automatically assumed it's the former. But
 some earlier proposals in this space have supported only the latter
 kind (which does provide some kind of algorithm agility -- it's better
 than hardcoding MD5 -- but could mean synchronized manual work for
 every transition)...

 [BA] The proposal is that the following text in Section 2:

    "of RADIUS implementations to negotiate cryptographic algorithms"

 be changed to:

    "of RADIUS implementations to automatically negotiate cryptographic
 algorithms"

 Automated Key Management:

 Well... RADIUS certainly requires only O(n) keys, but on the other
 hand, the amount of data encrypted with a single key is not
 necessarily small (when considering the "value of the data" and time
 aspects -- in terms of gigabytes, it's probably small compared to what
 decent algorithms can handle).

 And if you anyway support negotiating the algorithms (in the
 protocol), generating a fresh session key may not be that much extra
 effort, and may be needed anyway since the key can depend on the
 selected algorithm (if you negotiate 256-bit AES, you need a 256-bit
 key; if it's 3DES, 168 bits, etc.). And the solutions should avoid
 using the same cryptographic key with multiple algorithms (and the
 easiest way to ensure this would probably be fresh session keys).

 Generating a fresh session key probably also simplifies replay
 protection (it's the obvious time to e.g. reset counters to zero), but
 other approaches to replays are certainly feasible.

 And obviously, forward secrecy and supporting any other types of
 long-term credentials than shared secrets requires automated key
 management of some kind.

 So, I think the conclusion here needs at the very least some
 qualification and additional explanation.

 *If* a solution not supporting forward secrecy and not supporting
 other types of credentials is acceptable, *and* replay protection is
 solved in certain way, *and* the solution can ensure that the
 negotiated algorithms get keys appropriate for them, *and* the
 solution can ensure that two algorithms don't use the same key, then
 you might get away with no AKM. But even then, AKM might be less work.

 [BA] The requirement for a fresh session key derives from RFC 4962,
 Since a fresh session key can be derived from a pre-shared key
 via the exchange of nonces, this doesn't necessarily imply AKM.

 However, the requirement for PFS  as well as for direct key
 transport between a NAS and RADIUS server do effectively imply
 AKM.

 The proposal is to change Section 4.6 to the following:

 4.6. Applicability of Automated Key Management Requirements

    [RFC4107]  provides guidelines for when automated key management is
    necessary.  At the IETF-70 meeting, and leading up to that meeting,
    the RADEXT WG debated whether or not RFC 4107 would require a RADIUS
    Crypto-Agility solution to feature Automated Key Management (AKM).
    The working group determined that AKM was not inherently required for
    RADIUS based on the following points:

    o  RFC 4107 requires AKM for protocols that involve O(n^2) keys.
       This does not apply to RADIUS deployments, which require O(n) keys.

    o  Requirements for session key freshness can be met without AKM,
       for example, by utilizing a pre-shared key along with an exchange
       of nonces.

    o  RADIUS does not require the encryption of large amounts of data in
       a short time.

    o  Organizations already have operational practices to manage
       existing RADIUS shared secrets to address key changes required
       through personnel changes.

    o  The crypto-agility solution can avoid use cryptographic modes of
       operation such as a counter mode cipher that require frequent key
       changes.

    However, the same time, it is recognized that features recommended
    in Section 4.2 such as support for PFS and direct transport of keys
    between a NAS and RADIUS server, can only be provided by a solution
    supporting AKM.  As a result, support for Automated Key Management
    is RECOMMENDED within a RADIUS crypto-agility solution.

 Compromise of legacy shared secret:

 Section 4.2 says "Crypto-agility solutions MUST avoid security
 compromise, even in situations where the existing cryptographic
 algorithms utilized by RADIUS implementations are shown to be weak
 enough to provide little or no security (e.g. in event of compromise
 of the legacy RADIUS shared secret). Included in this would be
 protection against bidding down attacks."

 If interpreted literally, this requirement could be very difficult
 to meet (perhaps impossible).

 It seems to assume that for this particular peer, the administrator
 has configured two different shared secrets (one for the current
 security mechanisms, another for the new ones), but has not configured
 whether to use the old or new mechanisms (with this particular peer),
 and instead, that is negotiated somehow.

 If the attacker knows the legacy shared secret, and has complete
 control over the communication channel (and in particular, can drop
 messages going from A to B), then it seems the attacker will be
 indistinguishable from a valid peer that supports only the legacy
 mechanisms (and does not know the new shared secret), and detecting
 bidding down will not be possible.

 Preventing bidding down in less extreme cases of compromise is of
 course both possible and desirable (e.g. if the algorithms are just
 weak but not breakable in real time, or if the attacker doesn't have
 complete control over the communications). And the administrator could
 always configure just the "new shared secret", if he/she knows that
 the peer supports it.

 [BA] Propose that the following text in Section 4.2:

    Crypto-agility solutions MUST avoid security compromise, even in
    situations where the existing cryptographic algorithms utilized by
    RADIUS implementations are shown to be weak enough to provide little
    or no security (e.g. in event of compromise of the legacy RADIUS
    shared secret).  Included in this would be protection against bidding
    down attacks.

 be changed to:

    Crypto-agility solutions MUST avoid security compromise, even in
    situations where the existing cryptographic algorithms utilized by
    RADIUS implementations are shown to be weak enough to provide little
    or no security (e.g. in event of compromise of the legacy RADIUS
    shared secret).  Included in this would be protection against bidding
    down attacks.  In analyzing the resilience of a crypto-agility
    solution, it can be assumed that the RADIUS server can be configured
    to require the use of new secure algorithms in the event of a
 compromise of
    existing cryptographic algorithms or the legacy RADIUS shared
    secret.

 Backward compatibility/negotiation:

 Section 4.3 says "Solutions to the problem MUST demonstrate backward
 compatibility with existing RADIUS implementations. That is, a
 crypto-agility solution needs to be able to send packets that a legacy
 RADIUS client or server will receive and process successfully.
 Similarly, a crypto-agility solution needs to be capable of receiving
 and processing packets from a legacy RADIUS client or server."

 The intent of this paragraph is probably right, but currently, it's
 somewhat open to multiple interpretations. Would something like this
 capture the intent?

 "Solutions to the problem MUST demonstrate backward compatibility with
 existing RADIUS implementations. That is, an implementation that
 supports both the crypto-agility solution and legacy mechanisms MUST
 be able to talk with legacy RADIUS clients and servers (using the
 legacy mechanisms). Acceptable solutions to determining which set of
 mechanisms is used (with a particular peer) include some kind of
 negotiation, and manual configuration."

 Note that *not* meeting this requirement would actually be quite
 difficult... if the intent of this paragraph was to require some kind
 of negotiation (interpreted loosely -- anything more automatic than
 manual configuration), the text should say so.

 [BA] Recommend that the following text in Section 4.3:

 "Solutions to the problem MUST demonstrate backward
 compatibility with existing RADIUS implementations. That is, a
 crypto-agility solution needs to be able to send packets that a legacy
 RADIUS client or server will receive and process successfully.
 Similarly, a crypto-agility solution needs to be capable of receiving
 and processing packets from a legacy RADIUS client or server."

 be changed to:

 "Solutions to the problem MUST demonstrate backward compatibility with
 existing RADIUS implementations. That is, an implementation that
 supports both the crypto-agility solution and legacy mechanisms MUST
 be able to talk with legacy RADIUS clients and servers (using the
 legacy mechanisms). Acceptable solutions to determining which set of
 mechanisms is used (with a particular peer) include some kind of
 negotiation, and manual configuration."

 "Operational model"?

 Section 4.3 says "Crypto-agility solutions SHOULD NOT require changes
 to the RADIUS operational model, such as the introduction of new
 commands or maintenance of [additional] state on the RADIUS server."

 I'm not sure what "operational" means here -- at first I thought it
 might mean "operations and management" (so the requirement would be
 basically "SHOULD not complicate life for administrators"), but the
 two examples given don't seem to fit that very well. And it seems any
 solution that e.g. derives fresh session keys will involve some small
 (but greater than zero) amount of additional state on clients and
 servers.

 If the intent was really operations and management, perhaps the should
 be rephased something like "When using long-term shared secrets for
 authentication, crypto-agility solutions SHOULD NOT require more
 operations and management work than the current solutions."

 "RADIUS service?"

 Section 4.3 says "For example, proposals SHOULD NOT .. include
 definition of new RADIUS services."

 What's a RADIUS service -- i.e. what types of proposals this
 definition would disqualify? (In RFC 2865, "service" is defined as the
 service provided by the NAS to the user, but that definition doesn't
 seem applicable here.)

 [BA] Proposal is to change the following text in Section 4.3:

    Crypto-agility solutions SHOULD NOT require changes to the RADIUS
    operational model, such as the introduction of new commands or
    maintenance of [additional] state on the RADIUS server.  Similarly, a
    proposal SHOULD focus on the crypto-agility problem and nothing else.
    For example, proposals SHOULD NOT require new attribute formats or
    include definition of new RADIUS services.

 to the following:

 "Crypto-agility solutions SHOULD NOT require
 changes to the RADIUS operational model as defined in
 "RADIUS Design Guidelines" [RFC 6158] Section 3.1 and
 Appendix A.4.  Similarly, a proposal SHOULD focus on the
 crypto-agility problem and nothing else.  For example, proposals
 SHOULD NOT require new attribute formats and SHOULD be compatible
 with the guidance provided in [RFC 6158] Section 2.3."

-- 
-----------------------------------+----------------------------------------
 Reporter:  Pasi.Eronen@…          |       Owner:  bernard_aboba@…          
     Type:  defect                 |      Status:  assigned                 
 Priority:  blocker                |   Milestone:  milestone1               
Component:  Crypto-Agility         |     Version:  1.0                      
 Severity:  Active WG Document     |    Keywords:                           
-----------------------------------+----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/21#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Thu, 03 Mar 2011 22:05:52 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Request for Review:  Crypto-Agility Requirements for RADIUS
Date: Thu, 3 Mar 2011 14:05:34 -0800

--_4e65e252-c223-4839-9942-87e6258b2db4_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

This is a request for review of "Crypto-Agility Requirements for RADIUS".  =
The document may be found here:
http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements

The "Request for Review" will last until March 17=2C 2011.

RADEXT
 WG Participants are encouraged to read the document and post issues in=20
the TRAC database (see below for details on how to do this) or on the=20
RADEXT WG mailing list.=20

When all the open issues on this document are addressed=2C the document wil=
l go to WG last call.=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
1.       To submit an issue in TRAC=2C you first need to login to the RADEX=
T WG site on the tools server:  http://tools.ietf.org/wg/radext/trac/login=
=20

2.       If you don=92t already have a login ID=2C you can obtain one by na=
vigating to this site:   http://trac.tools.ietf.org/newlogin

3.       Once you have obtained an account=2C and have logged in=2C you can=
 file an issue by navigating to the  ticket entry form: http://trac.tools.i=
etf.org/wg/radext/trac/newticket

4.       When opening an issue:

a.     =20
 The Type: field should be set to =93defect=94 for an issue with the curren=
t
 document text=2C or =93enhancement=94 for a proposed addition of=20
functionality (such as an additional requirement).=20
b.      The=20
Priority: field is set based on the severity of the Issue.   For=20
example=2C editorial issues are typically =93minor=94 or =93trivial=94.=20
c.       The Milestone: field should be set to milestone1 (useless=2C I kno=
w).=20
d.      The Component: field should be set to the document you are filing t=
he issue on. =20
e.      The Version: field should be set to =931.0=94.=20
f.      =20
 The Severity: field should be set to based on the status of the=20
document (e.g. =93In WG Last Call=94 for a document in WG last call)
g.        The Keywords: and CC: fields can be left blank unless inspiration=
 seizes you.=20
h.      The Assign To: field is generally filled in with the email address =
of the editor.=20

5.     =20
 Typically it won=92t be necessary to enclose a file with the ticket=2C but=
=20
if you need to=2C select =93I have files to attach to this ticket=94.=20

6.     =20
 If you want to preview your Issue=2C click on the =93Preview=94 button.  W=
hen
 you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but=
ton.=20

7.       If you want to update an issue=2C go to the "View Tickets" page: h=
ttp://trac.tools.ietf.org/wg/radext/trac/report/1  Click on the ticket # yo=
u want to update=2C and then modify the ticket fields as required  		 	   	=
	  =

--_4e65e252-c223-4839-9942-87e6258b2db4_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
This is a request for review of "Crypto-Agility Requirements for RADIUS".&n=
bsp=3B The document may be found here:<br>http://tools.ietf.org/html/draft-=
ietf-radext-crypto-agility-requirements<br><br>The "Request for Review" wil=
l last until March 17=2C 2011.<br><br>RADEXT
 WG Participants are encouraged to read the document and post issues in=20
the TRAC database (see below for details on how to do this) or on the=20
RADEXT WG mailing list. <br><br>When all the open issues on this document a=
re addressed=2C the document will go to WG last call. <br><br>=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><p class=3D"MsoNormal" style=3D"=
margin-bottom: 12pt=3B"><span style=3D"font-size: 10pt=3B font-family: &quo=
t=3BVerdana&quot=3B=2C&quot=3Bsans-serif&quot=3B=3B">1.&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B&nbsp=3B To submit an issue in TRAC=2C you first need t=
o login to the RADEXT WG site on the tools server:&nbsp=3B <a rel=3D"nofoll=
ow" href=3D"http://tools.ietf.org/wg/radext/trac/login">http://tools.ietf.o=
rg/wg/radext/trac/login</a> <br><br>2.&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B If you don=92t already have a login ID=2C you can obtain one by=
 navigating to this site:&nbsp=3B&nbsp=3B <a rel=3D"nofollow" href=3D"http:=
//trac.tools.ietf.org/newlogin">http://trac.tools.ietf.org/newlogin</a><br>=
<br>3.&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Once you have obtain=
ed an account=2C and have logged in=2C you can file an issue by navigating =
to the&nbsp=3B ticket entry form: <a rel=3D"nofollow" href=3D"http://trac.t=
ools.ietf.org/wg/radext/trac/newticket">http://trac.tools.ietf.org/wg/radex=
t/trac/newticket</a><br><br>4.&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B When opening an issue:<br><br>a.&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B
 The Type: field should be set to =93defect=94 for an issue with the curren=
t
 document text=2C or =93enhancement=94 for a proposed addition of=20
functionality (such as an additional requirement). <br>b.&nbsp=3B&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B The=20
Priority: field is set based on the severity of the Issue.&nbsp=3B&nbsp=3B =
For=20
example=2C editorial issues are typically =93minor=94 or =93trivial=94. <br=
>c.&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B The Milestone: field sh=
ould be set to milestone1 (useless=2C I know). <br>d.&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B The Component: field should be set to the document you =
are filing the issue on.&nbsp=3B <br>e.&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbs=
p=3B The Version: field should be set to =931.0=94. <br>f.&nbsp=3B&nbsp=3B&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B
 The Severity: field should be set to based on the status of the=20
document (e.g. =93In WG Last Call=94 for a document in WG last call)<br>g.&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B The Keywords: and C=
C: fields can be left blank unless inspiration seizes you. <br>h.&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B&nbsp=3B The Assign To: field is generally filled in =
with the email address of the editor. <br><br>5.&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B
 Typically it won=92t be necessary to enclose a file with the ticket=2C but=
=20
if you need to=2C select =93I have files to attach to this ticket=94. <br><=
br>6.&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B
 If you want to preview your Issue=2C click on the =93Preview=94 button.&nb=
sp=3B When
 you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but=
ton. <br><br>7.&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B If you want=
 to update an issue=2C go to the "View Tickets" page: <a rel=3D"nofollow" h=
ref=3D"http://trac.tools.ietf.org/wg/radext/trac/report/1">http://trac.tool=
s.ietf.org/wg/radext/trac/report/1</a>&nbsp=3B Click on the ticket # you wa=
nt to update=2C and then modify the ticket fields as required</span><span s=
tyle=3D"font-size: 11pt=3B font-family: &quot=3BCalibri&quot=3B=2C&quot=3Bs=
ans-serif&quot=3B=3B"></span></p><p class=3D"MsoNormal">&nbsp=3B</p> 		 	  =
 		  </body>
</html>=

--_4e65e252-c223-4839-9942-87e6258b2db4_--

Delivery-date: Thu, 03 Mar 2011 22:01:35 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Thu, 03 Mar 2011 22:01:23 -0000
Reply-To: [email-masked]
Subject: [radext] #83: AKM Requirements

#83: AKM Requirements

 Section 4.6 states:

    Automated key management is required for RADIUS crypto agility
    solutions that use cryptographic modes of operation that require
    frequent key changes.

 Shouldn't "required" be capitalized here?

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  major                      |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/83>
radext <http://tools.ietf.org/radext/>

Delivery-date: Thu, 03 Mar 2011 21:59:16 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Thu, 03 Mar 2011 21:59:01 -0000
Reply-To: [email-masked]
Subject: [radext] #82: Diameter compatibliity

#82: Diameter compatibliity

 Section 4.5 states:

    Proposals MUST include a Diameter compatibility section, although it
    is expected that the work will occur purely within RADIUS or in the
    transport, and therefore does not affect message data that is
    exchanged with Diameter.

 [BA] Since a Diameter compatibility section is no longer required, I
 recommend that this be changed to the following:

    Since it is expected that the work will occur purely within RADIUS
    or in the transport, message data exchanged with Diameter SHOULD NOT
    be affected.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  minor                      |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/82>
radext <http://tools.ietf.org/radext/>

Delivery-date: Thu, 03 Mar 2011 21:56:46 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Thu, 03 Mar 2011 21:56:25 -0000
Reply-To: [email-masked]
Subject: [radext] #81: Location Privacy

#81: Location Privacy

 Section 4.2 states:

 If
    possible, it is desirable for proposals to provide for the encryption
    of existing attributes.  This includes existing "hidden" attributes
    as well as attributes (such as location attributes) that require
    confidentiality.

 [BA] GEOPRIV requirements are described in RFC 3693; this should probably
 be referenced here.  Also, "desirable" appears to be used as a synonym for
 RECOMMENDED here.  Should this be changed?

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  major                      |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/81>
radext <http://tools.ietf.org/radext/>

Delivery-date: Thu, 03 Mar 2011 21:48:46 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Thu, 03 Mar 2011 21:48:30 -0000
Reply-To: [email-masked]
Subject: [radext] #80: Section 3

#80: Section 3

 This section isn't just about encryption, but the state of RADIUS security
 in general.  Suggest the following re-write:

 3.  The Current State of RADIUS Security

    RADIUS packets, as defined in [RFC2865], are protected by an MD5
    message integrity check (MIC), within the Authenticator field of
    RADIUS packets other than Access-Request.  The Message-Authenticator
    Attribute utilizes HMAC-MD5 to authenticate and integrity protect
    RADIUS packets.  Various RADIUS attributes support hidden values,
    including: User-Password, Tunnel-Password, and various Vendor-
    Specific Attributes.  Generally speaking, the hiding mechanism uses a
    stream cipher based on a key stream from an MD5 digest.

    Recent work on MD5 collisions does not immediately compromise any of
    these methods, absent knowledge of the RADIUS shared secret.
    However, the progress toward compromise of MD5's basic cryptographic
    assumptions has resulted in the deprecation of MD5 usage in a variety
    of applications.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  minor                      |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/80>
radext <http://tools.ietf.org/radext/>

Delivery-date: Thu, 03 Mar 2011 21:46:38 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Thu, 03 Mar 2011 21:46:22 -0000
Reply-To: [email-masked]
Subject: [radext] #79: Reference issues

#79: Reference issues

 idnits currently finds the following NITs relating to references in the
 -02 document:

 Checking references for intended status: Informational
 ----------------------------------------------------------------------------

   == Unused Reference: 'RFC2865' is defined on line 293, but no explicit
      reference was found in the text
      '[RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
 "Rem...'

   == Unused Reference: 'RFC3162' is defined on line 297, but no explicit
      reference was found in the text
      '[RFC3162]  Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
 RF...'

   == Unused Reference: 'RFC3579' is defined on line 300, but no explicit
      reference was found in the text
      '[RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote
 Authentication...'

   == Unused Reference: 'RFC4962' is defined on line 307, but no explicit
      reference was found in the text
      '[RFC4962]  Housley, R. and B. Aboba, "Guidance for Authentication,
 A...'

 Looking through the document, each of the "unused" references are actually
 included, but not in the referenced form (e.g. RFC 2865 instead of
 [RFC2865]).  This should be cleaned up.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  minor                      |   Milestone:  milestone1
Component:  Crypto-Agility             |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/79>
radext <http://tools.ietf.org/radext/>

Delivery-date: Thu, 03 Mar 2011 21:44:12 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Thu, 03 Mar 2011 21:43:44 -0000
Reply-To: [email-masked]
Subject: [radext] #78: Pre-November 2008 Copyright Notice

#78: Pre-November 2008 Copyright Notice

 The current -02 document does not utilize the pre-November 2008 copyright
 notice.   This issue is filed in case the authors wish to change the
 notice.  Otherwise, this issue can be resolved "won't fix".  Here is what
 the pre-November 2008 notice looks like;

 Copyright Notice

    Copyright (c) 2011 IETF Trust and the persons identified as the
    document authors.  All rights reserved.

    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
    carefully, as they describe your rights and restrictions with
    respect to this document.  Code Components extracted from this
    document must include Simplified BSD License text as described in
    Section 4.e of the Trust Legal Provisions and are provided without
    warranty as described in the BSD License.

    This document may contain material from IETF Documents or IETF
    Contributions published or made publicly available before November
    10, 2008.  The person(s) controlling the copyright in some of this
    material may not have granted the IETF Trust the right to allow
    modifications of such material outside the IETF Standards Process.
    Without obtaining an adequate license from the person(s) controlling
    the copyright in such materials, this document may not be modified
    outside the IETF Standards Process, and derivative works of it may
    not be created outside the IETF Standards Process, except to format
    it for publication as an RFC or to translate it into languages other
    than English.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  d.b.nelson@…          
     Type:  defect                     |      Status:  new                   
 Priority:  minor                      |   Milestone:  milestone1            
Component:  Crypto-Agility             |     Version:  1.0                   
 Severity:  Active WG Document         |    Keywords:                        
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/78>
radext <http://tools.ietf.org/radext/>

Delivery-date: Thu, 03 Mar 2011 21:17:20 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-crypto-agility-requirements-02.txt
Date: Thu, 03 Mar 2011 13:15:02 -0800

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)
	Author(s)       : D. Nelson
	Filename        : draft-ietf-radext-crypto-agility-requirements-02.txt
	Pages           : 8
	Date            : 2011-03-03

This memo describes the requirements for a crypto-agility solution
for Remote Authentication Dial-In User Service (RADIUS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

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

--NextPart--

Delivery-date: Wed, 02 Mar 2011 13:09:34 +0000
Date:	Wed, 02 Mar 2011 16:08:22 +0300
From:	Victor Gamov <[email-masked]>
Organization: Eurocomm.net
To:	[email-masked]
Subject: Re: I-D Action:draft-ietf-radext-radius-extensions-00.txt

This is a multi-part message in MIME format.
--------------050005050407040405020306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi All !

To extend Type space and allow large values I propose following format 
with new unassigned Type:

  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=0   |        Actual Length          |
+---------------+---------------+-------------------------------+
| New Type (up to 65535 types)  |Long Value (up to 65529 bytes)..
+---------------+---------------+---------------+---------------+

Incompatible implementations will generate reject or discard such 
attributes due Length=0.

To allow VSA with extended types (more than 255) and values (Type is new 
unassigned type):

  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=0   |        Actual Length          |
+---------------+---------------+-------------------------------+
|                           Vendor ID                           |
+---------------+---------------+---------------+---------------+
|            VSA Type           |Long Value (up to 65525 bytes)..
+---------------+---------------+---------------+---------------+

In more general, second format may be used to extend RADIUS-standard 
attributes when 'Vendor ID' = 0

--
CU,
Victor Gamov

--------------050005050407040405020306
Content-Type: text/x-vcard; charset=utf-8;
 name="vit.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="vit.vcf"

begin:vcard
fn:Victor Gamov
n:Gamov;Victor
email;internet:[email-masked]
tel;work:sip:[email-masked]
x-mozilla-html:FALSE
version:2.1
end:vcard

--------------050005050407040405020306--