Subject: Re: no overall type in Extended Attributes

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Aug 2008 19:19:07 -0700 (PDT)

Glen Zorn said:

"As I mentioned a couple of times at the Dublin session, the current
definition of the Extended Attributes 
(http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-0
4.txt) doesn't in general allow the definition of an overall type for the
Attribute in question:  an Extended Attribute is basically just an 
unordered set of TLVs.  This fact doesn't bother me much, if at all, but 
the second time I mentioned it there was some grumbling from the crowd, so 
I thought I'd bring it up one more time on the list..."

One question is how the grouping semantic differs from that of Diameter 
(RFC 3588), and what the impact is.  Looking at RFC 3588, it does seem 
that the agbility to name and define a Grouped AVP has some advantages. 

For example, it enables a formal definition of the grouped AVP, including 
a grammar.  Without this, it is possible that the loose semantics would affect 
interoperability (e.g. arbitrary attribute groupings might not be 
supported understood).  

>From RFC 3588 Section 4.4:

4.4.  Grouped AVP Values

   The Diameter protocol allows AVP values of type 'Grouped.'  This
   implies that the Data field is actually a sequence of AVPs.  It is
   possible to include an AVP with a Grouped type within a Grouped type,
   that is, to nest them.  AVPs within an AVP of type Grouped have the
   same padding requirements as non-Grouped AVPs, as defined in Section
   4.

   The AVP Code numbering space of all AVPs included in a Grouped AVP is
   the same as for non-grouped AVPs.  Further, if any of the AVPs
   encapsulated within a Grouped AVP has the 'M' (mandatory) bit set,
   the Grouped AVP itself MUST also include the 'M' bit set.

   Every Grouped AVP defined MUST include a corresponding grammar, using
   ABNF [ABNF] (with modifications), as defined below.

      grouped-avp-def  = name "::=" avp

      name-fmt         = ALPHA *(ALPHA / DIGIT / "-")

      name             = name-fmt
                         ; The name has to be the name of an AVP,
                         ; defined in the base or extended Diameter
                         ; specifications.

      avp              = header  [ *fixed] [ *required] [ *optional]
                         [ *fixed]

      header           = "<" "AVP-Header:" avpcode [vendor] ">"

      avpcode          = 1*DIGIT
                         ; The AVP Code assigned to the Grouped AVP

      vendor           = 1*DIGIT
                         ; The Vendor-ID assigned to the Grouped AVP.
                         ; If absent, the default value of zero is
                         ; used.

4.4.1.  Example AVP with a Grouped Data type

   The Example-AVP (AVP Code 999999) is of type Grouped and is used to
   clarify how Grouped AVP values work.  The Grouped Data field has the
   following ABNF grammar:

      Example-AVP  ::= < AVP Header: 999999 >
                       { Origin-Host }
                     1*{ Session-Id }
                      *[ AVP ]

   An Example-AVP with Grouped Data follows.

   The Origin-Host AVP is required (Section 6.3).  In this case:

      Origin-Host = "example.com".

   One or more Session-Ids must follow.  Here there are two:

      Session-Id =
        "grump.example.com:33041;23432;893;0AF3B81"

      Session-Id =
        "grump.example.com:33054;23561;2358;0AF3B82"

   optional AVPs included are

      Recovery-Policy = <binary>
         2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35
         2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5
         c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd
         f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a
         cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119
         26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c
         1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92

      Futuristic-Acct-Record = <binary>
         fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0
         57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8
         17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c
         41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067
         d3427475e49968f841

   The data for the optional AVPs is represented in hex since the format
   of these AVPs is neither known at the time of definition of the
   Example-AVP group, nor (likely) at the time when the example instance
   of this AVP is interpreted - except by Diameter implementations which
   support the same set of AVPs.  The encoding example illustrates how
   padding is used and how length fields are calculated.  Also note that
   AVPs may be present in the Grouped AVP value which the receiver
   cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record
   AVPs).

   This AVP would be encoded as follows:

           0       1       2       3       4       5       6       7
       +-------+-------+-------+-------+-------+-------+-------+-------+
     0 |     Example AVP Header (AVP Code = 999999), Length = 468      |
       +-------+-------+-------+-------+-------+-------+-------+-------+
     8 |     Origin-Host AVP Header (AVP Code = 264), Length = 19      |
       +-------+-------+-------+-------+-------+-------+-------+-------+
    16 |  'e'  |  'x'  |  'a'  |  'm'  |  'p'  |  'l'  |  'e'  |  '.'  |
       +-------+-------+-------+-------+-------+-------+-------+-------+
    24 |  'c'  |  'o'  |  'm'  |Padding|     Session-Id AVP Header     |
       +-------+-------+-------+-------+-------+-------+-------+-------+
    32 | (AVP Code = 263), Length = 50 |  'g'  |  'r'  |  'u'  |  'm'  |
       +-------+-------+-------+-------+-------+-------+-------+-------+
                                     . . .
       +-------+-------+-------+-------+-------+-------+-------+-------+
    64 |  'A'  |  'F'  |  '3'  |  'B'  |  '8'  |  '1'  |Padding|Padding|
       +-------+-------+-------+-------+-------+-------+-------+-------+
    72 |     Session-Id AVP Header (AVP Code = 263), Length = 51       |
       +-------+-------+-------+-------+-------+-------+-------+-------+
    80 |  'g'  |  'r'  |  'u'  |  'm'  |  'p'  |  '.'  |  'e'  |  'x'  |
       +-------+-------+-------+-------+-------+-------+-------+-------+
                                     . . .
       +-------+-------+-------+-------+-------+-------+-------+-------+
   104 |  '0'  |  'A'  |  'F'  |  '3'  |  'B'  |  '8'  |  '2'  |Padding|
       +-------+-------+-------+-------+-------+-------+-------+-------+
   112 |   Recovery-Policy Header (AVP Code = 8341), Length = 223      |
       +-------+-------+-------+-------+-------+-------+-------+-------+
   120 |  0x21 | 0x63  | 0xbc  | 0x1d  | 0x0a  | 0xd8  | 0x23  | 0x71  |
       +-------+-------+-------+-------+-------+-------+-------+-------+
                                     . . .
       +-------+-------+-------+-------+-------+-------+-------+-------+
   320 |  0x2f | 0xd7  | 0x96  | 0x6b  | 0x8c  | 0x7f  | 0x92  |Padding|
       +-------+-------+-------+-------+-------+-------+-------+-------+
   328 | Futuristic-Acct-Record Header (AVP Code = 15930), Length = 137|
       +-------+-------+-------+-------+-------+-------+-------+-------+
   336 |  0xfe | 0x19  | 0xda  | 0x58  | 0x02  | 0xac  | 0xd9  | 0x8b  |
       +-------+-------+-------+-------+-------+-------+-------+-------+
                                     . . .
       +-------+-------+-------+-------+-------+-------+-------+-------+
   464 |  0x41 |Padding|Padding|Padding|
       +-------+-------+-------+-------+

--
to unsubscribe send 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: "Glen Zorn" <[email-masked]>
Date: Thu, 14 Aug 2008 18:26:49 +0700

> that the agbility to name and define a Grouped AVP has some advantages.

Perhaps, but it also has disadvantages (such as the awkwardness of defining
new AVPs for simple, ad-hoc situations.

> a grammar.  

It's not clear that this is actually an advantage: a large majority of the
confusion I've seen reported by Diameter developers has been caused by ABNF.

> Without this, it is possible that the loose semantics would
> affect

I don't see how this could happen except for essentially the same reasons as
in Diameter (despite the over-specification of the protocol).  From your
quotation of RFC 3588 below:

'The data for the optional AVPs is represented in hex since the format of
these AVPs is neither known at the time of definition of the Example-AVP
group, nor (likely) at the time when the example instance of this AVP is
interpreted - except by Diameter implementations which support the same set
of AVPs...note that AVPs may be present in the Grouped AVP value which the
receiver cannot interpret...'

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 27 Aug 2008 11:21:51 +0700

...

> Looking at RFC 3588, it does seem

OK, so I've run into a situation when working on a set of attributes for
WiMAX that just begs for a named, multi-TLV attribute.  I guess it does seem
that the extended attributes should be able to handle this situation, fixing
one of the inadequacies (IMHO) of legacy RADIUS attributes, but right now
they can't.  Any suggestions for fixing this problem (as painlessly as
possible :-)? 

...

---

From: Alan DeKok <[email-masked]>
Date: Wed, 27 Aug 2008 08:27:22 +0200

Glen Zorn wrote:
> WiMAX that just begs for a named, multi-TLV attribute.

  Could you be more specific?

>  I guess it does seem

  Painlessly killing RADIUS has been off of the table for a while.
We're stuck with painful solutions.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 27 Aug 2008 15:38:35 +0700

>   Could you be more specific?

About what?

>   Painlessly killing RADIUS has been off of the table for a while.

Who's talking about "killing RADIUS"?  Do we have differing definitions of a
"dead" protocol?

---

From: Alan DeKok <[email-masked]>
Date: Wed, 27 Aug 2008 10:42:32 +0200

>>   Could you be more specific?

  A named, multi-TLV attribute.

  Most attributes have names.  Most attributes are TLV's.  The
Extended-Attribute encapsulates multiple TLV's.

  So... what's a "named, multi-TLV attribute"?  An attribute inside of
the Extended-Attribute that can carry other TLV's?  Like what's done in
WiMAX?

  It's a good idea.  And if most vendors have to add WiMAX support
anyways, much of the code will already exist.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 27 Aug 2008 15:54:24 +0700

Alan DeKok [mailto:[email-masked]] writes:

> >>> OK, so I've run into a situation when working on a set of
> attributes
> >> for

Maybe I didn't say it correctly.  I want to name a group of TLVs, I guess.
to get a structure like that of, say the MS-CHAP-CPW-1 Attribute only using
the TLV construct,

> the Extended-Attribute that can carry other TLV's?  Like what's done in

Maybe, I'm open; that's why I asked :-).

---

From: Alan DeKok <[email-masked]>
Date: Wed, 27 Aug 2008 11:05:06 +0200

> to get a structure like that of, say the MS-CHAP-CPW-1 Attribute only using

  Isn't that what the tags are for?

  Foo:1 = 1
  Bar:1 = "hello"
  BaZ:1 = "foo"

  It's not a nice name, but it's a name.

> Maybe, I'm open; that's why I asked :-).

  The main difficulty with that is it's hard to distinguish between
different sets of nested TLV's.  Requiring them to be grouped would help.

  e.g.  An "encapsulating tlv" has sub-tlv's A, B, and C.  What do you
do if you want to send *two* copies of "encapsulating tlv", each with
different values for A, B, and C?

  My guess would to use tags.  The sub-tlv's can be referred to as
"A:1", which would mean "A, encapsulated in it's TLV, which is
encapsulated in Extended-Attribute, which is encapsulated in
Vendor-Specific."

  Ugh.  But it works:

   A:1 = foo
   B:1 = 1
   C:1 = 1.2.3.4
   A:2 = bar
   B:2 = 42
   C:2 = 192.168.0.1

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 27 Aug 2008 16:22:57 +0700

>   Isn't that what the tags are for?

Not historically.  In RFC 2869, for example, the Tag field is used to group
sets of attributes in an ad-hoc fashion: there's no requirement placed on
the actual membership  of the groups & different groups can contain
different sets of attributes in the same message.

>   It's not a nice name, but it's a name.

It's a very inefficient encapsulation, too, since all of the TLVs could be
carried in a single extended attribute.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 27 Aug 2008 13:38:52 +0200

> different sets of attributes in the same message.

  Then I'm not clear on why the extended attribute format has tags.  I
thought it was about grouping TLV's?

> carried in a single extended attribute.

  But they can be... the draft says that multiple attributes can go into
one Extended-Attribute, so long as it's not fragmented.  Since the
extended attibute *header* contains the tag, all of the attributes it
encapsulates inherit that tag.

  Or am I missing something completely?

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 27 Aug 2008 20:12:16 +0700

> thought it was about grouping TLV's?

Hmm.  I seem to be having some serious problems communicating today,
or...anyway, I used the word "group" or its plural 3 times in one sentence.
How do you get the idea that tags aren't used for grouping?

> encapsulates inherit that tag.

OK, how would you specify this behavior in a document so that humans could
actually understand it?

>   Or am I missing something completely?

Or maybe I am...

---

From: Alan DeKok <[email-masked]>
Date: Wed, 27 Aug 2008 16:27:41 +0200

> How do you get the idea that tags aren't used for grouping?

  I think they *are* used for grouping.  You said you wanted to name a
group of TLV's.  I think you can't name the *group*, but you can say
"all of the attributes with tag 1".  That both defines, and names, the
group.

  The RFC 2868 naming for tagged attributes is commonly
Attribute-Name:Tag, or "Attribute-Name = Tag:value".  That method could
be used for tagged extended attributes.

> OK, how would you specify this behavior in a document so that humans could

  Multiple attributes can be packed into one Extended-Attribute, so long
as the M bit is zero.  Attributes having different tags MUST be packet
into different Extended-Attributes.

  i.e. if we use a short-cut terminology E(T,foo) meaning "Extended
Attribute with tag T, and contents foo, we have:

  E(1, Foo = 1 | Bar = hello)
  E(1, Foo = 1), E(1, Bar = hello)

  Both meaning "attribute Foo with value 1, tag 1 ALONG WITH attribute
Bar with value hello, tag 1).

  In practice, these attributes would be referred to as:

	Foo:1 = 1
	Bar:1 = hello

  or

	Foo = 1:1
	Bar = 1:hello

  Existing RADIUS attribute parsers handle both formats above.  The only
change is an extra piece of information for the attributes saying "pack
these as extended attributes".  But that's an issue for the dictionaries
and the packet encoding/decoding functions.  It's *shouldn't* affect the
parsing of the textual form of the attributes in server policies.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 28 Aug 2008 20:42:30 +0700

Alan DeKok [mailto:[email-masked]] writes:

> group of TLV's.  

No, I said that I want to name an attribute that consists of a group of
TLVs, not the same thing.  For example: a cryptosuite consists of a an
encryption algorithm identifier and an integrity-protection algorithm
identifier.  Multiple cryptosuite attributes can be in the same message.
Both the integrity-protection and encryption algorithms MUST be present or
the cryptosystem attribute is malformed.  I know how to do this easily & in
a way that comprehensible in Diameter or w/a legacy RADIUS attribute.
Apparently it is not possible to specify such a thing in an easily
comprehensible fashion using Extended Attributes.  I consider this to be a
problem (now -- I didn't before because I hadn't run into this,
short-sighted, I know); I'm not sure why (given your sympathetic concern for
programmers who would separate the word "hello" into 5 different attributes
;-) do not.

...

---

From: Alan DeKok <[email-masked]>
Date: Thu, 28 Aug 2008 16:00:28 +0200

Glen Zorn wrote:
> TLVs, not the same thing.

  Hmm... the number space for the Extended-Types is flat.  So one
attribute cannot "consist of" a group of TLV's.

>  For example: a cryptosuite consists of a an

  Diameter has a "group" attribute, which is easy.  I don't know how to
do this with a legacy attribute, other than via a complex type.

> programmers who would separate the word "hello" into 5 different attributes

  I don't see a problem with sub-TLV's, like is done for WiMAX.  The
various vendors will be implementing WiMAX anyways, so adding sub-TLV's
here wouldn't be a problem.

  This would involve extending the RADIUS data model to include a "tlv"
type.  If the format is the normal 8-bit type, 8-bit data, it would be
compatible with the WiMAX definition, the 3GPP definitions, and perhaps
some other vendor-specific definitions.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 29 Aug 2008 23:50:08 +0700

> do this with a legacy attribute, other than via a complex type.

Right.  The example is related to security...anyway, here's an idea: how
about breaking the Ext-Type field into 2 8-bit fields one of which stays in
the Extended Attribute header (giving naming capability for the attribute
itself) & the other staying in the TLV header?

---

From: Alan DeKok <[email-masked]>
Date: Sun, 31 Aug 2008 17:59:10 +0200

> itself) & the other staying in the TLV header?  

  Are we back to 8-bit types for the Extended-Attribute?

  Alan DeKok.

Delivery-date: Sun, 31 Aug 2008 16:01:47 +0000
Date: Sun, 31 Aug 2008 17:59:10 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: no overall type in Extended Attributes

> itself) & the other staying in the TLV header?  

  Are we back to 8-bit types for the Extended-Attribute?

  Alan DeKok.

Delivery-date: Sat, 30 Aug 2008 11:26:16 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>
Subject: New version of encrypted attributes draft
Date: Sat, 30 Aug 2008 18:23:25 +0700

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Transmitting Confidential Data in RADIUS
	Author(s)       : G. Zorn, et al.
	Filename        : draft-zorn-radius-encattr-12.txt
	Pages           : 24
	Date            : 2008-08-08

This document defines a set of Type-Length-Value (TLV) tuples which,
when encapsulated in RADIUS Extended Attributes, are designed to
allow the secure transmission of sensitive or confidential data
(including encryption keys) between RADIUS clients and servers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-12.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/draft-zorn-radius-encattr-12.txt

Delivery-date: Sat, 30 Aug 2008 10:10:07 +0000
From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-ietf-radext-design-05.txt 
Date: Tue, 26 Aug 2008 08:30:01 -0700 (PDT)
Cc: [email-masked]
Reply-To: [email-masked]

--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 Design Guidelines
	Author(s)       : G. Weber, et al.
	Filename        : draft-ietf-radext-design-05.txt
	Pages           : 36
	Date            : 2008-08-26

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, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-05.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-design-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

Delivery-date: Sat, 30 Aug 2008 05:30:00 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Abhishek Tiwari'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Subject: I-D Action:draft-tiwari-radext-tunnel-type-01.txt (fwd)
Date: Sat, 30 Aug 2008 12:27:07 +0700

Abhishek Tiwari [mailto:[email-masked]] writes:

> I have submitted the new draft addressing the most of the feedbacks
> received from Glen - except splitting the draft into two (individual
> tunnel id request for each tunnel).

Actually, that suggestion was more in the realm of "help you get it
published" than "something wrong w/the draft" anyway.  I suspect that it may
be difficult to round up IETF consensus around a proprietary tunnel type w/o
providing considerably more detail but I've been wrong before.  Good luck!

...

Delivery-date: Sat, 30 Aug 2008 05:13:06 +0000
From: Abhishek Tiwari <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Sat, 30 Aug 2008 13:10:46 +0800
Subject: RE: Subject: I-D Action:draft-tiwari-radext-tunnel-type-01.txt (fwd)
Accept-Language: en-US
acceptlanguage: en-US

I have submitted the new draft addressing the most of the feedbacks receive=
d from Glen - except splitting the draft into two (individual tunnel id req=
uest for each tunnel).

Abhishek

-----Original Message-----
From: Glen Zorn [mailto:[email-masked]]
Sent: Friday, August 15, 2008 5:54 PM
To: Abhishek Tiwari
Cc: [email-masked]
Subject: RE: Subject: I-D Action:draft-tiwari-radext-tunnel-type-01.txt (fw=
d)

Glancing over this:

Since there's only one author, it would be good to move the apostrophe in
"Authors'" left.

In the table in Section 3, move the abbreviation (ESP) next to "Payload".

Since new values of the Tunnel-Type Attribute are allocated by IETF
Consensus, it might be a better idea to separate this into 2 docs, one for
the ESP value & the other for the proprietary one.  In fact, because the
spec for the Microsoft Secure Socket Tunneling Protocol is public & appears
fairly stable, I would prefer that the allocation be part of an
Informational RFC describing the protocol.  At the very least, though, the
name needs to be changed to "Microsoft's Secure Socket Tunneling Protocol"
(or something similar) that identifies its proprietary nature.

Delivery-date: Fri, 29 Aug 2008 16:52:53 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'radext mailing list'" <[email-masked]>
Subject: RE: no overall type in Extended Attributes
Date: Fri, 29 Aug 2008 23:50:08 +0700

Delivery-date: Thu, 28 Aug 2008 14:03:18 +0000
Date: Thu, 28 Aug 2008 16:00:28 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: no overall type in Extended Attributes

  Alan DeKok.

Delivery-date: Thu, 28 Aug 2008 13:45:09 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'radext mailing list'" <[email-masked]>
Subject: RE: no overall type in Extended Attributes
Date: Thu, 28 Aug 2008 20:42:30 +0700

...

Delivery-date: Wed, 27 Aug 2008 14:29:16 +0000
Date: Wed, 27 Aug 2008 16:27:41 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: no overall type in Extended Attributes

	Foo:1 = 1
	Bar:1 = hello

  or

	Foo = 1:1
	Bar = 1:hello

  Alan DeKok.

Delivery-date: Wed, 27 Aug 2008 13:17:27 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'David B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Wed, 27 Aug 2008 20:16:09 +0700

Alan DeKok [mailto:[email-masked]] writes:

> Glen Zorn wrote:
> > Alright, how about this?
> >
> >    M (More)
> >
> >       The More Flag is one (1) bit in length and MUST be present.
> When
> >       a value to be transmitted exceeds 246 octets in length it is
> >       fragmented over two or more Extended Attributes.  If the More
> Flag
> >       is set (1), this indicates that the Value field of the Extended
> >       Attribute contains a fragment of a larger value, which is
> >       continued in the next Extended Attribute of the same Ext-Type.
> >       When the More Flag is clear (0), the final (or only) fragment
> of
> >       the value is contained in the Extended Attribute.  Any Extended
> > 	Attributes containing multiple fragments of the same value MUST
> be
> > 	in order and MUST be consecutive attributes in the packet.
> 
>   Looks good to me.

OK, cool.  I'll just change the last sentence to say "Any Extended
Attributes containing fragments of the same value MUST be in order and MUST
be consecutive attributes in the packet." because an Extended Attribute
can't contain multiple fragments (my bad ;-).

Delivery-date: Wed, 27 Aug 2008 13:13:58 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'radext mailing list'" <[email-masked]>
Subject: RE: no overall type in Extended Attributes
Date: Wed, 27 Aug 2008 20:12:16 +0700

Or maybe I am...

Delivery-date: Wed, 27 Aug 2008 12:27:11 +0000
Date: Wed, 27 Aug 2008 14:25:50 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: "'David B. Nelson'" <[email-masked]>,  [email-masked]
Subject: Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

Glen Zorn wrote:
> Alright, how about this?
> 
>    M (More)
> 
>       The More Flag is one (1) bit in length and MUST be present.  When
>       a value to be transmitted exceeds 246 octets in length it is
>       fragmented over two or more Extended Attributes.  If the More Flag
>       is set (1), this indicates that the Value field of the Extended
>       Attribute contains a fragment of a larger value, which is
>       continued in the next Extended Attribute of the same Ext-Type.
>       When the More Flag is clear (0), the final (or only) fragment of
>       the value is contained in the Extended Attribute.  Any Extended 
> 	Attributes containing multiple fragments of the same value MUST be 
> 	in order and MUST be consecutive attributes in the packet.

  Looks good to me.

  Alan DeKok.

Delivery-date: Wed, 27 Aug 2008 11:40:38 +0000
Date: Wed, 27 Aug 2008 13:38:52 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: no overall type in Extended Attributes

  Alan DeKok.

Delivery-date: Wed, 27 Aug 2008 09:24:56 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: no overall type in Extended Attributes
Date: Wed, 27 Aug 2008 16:22:57 +0700

Delivery-date: Wed, 27 Aug 2008 09:06:34 +0000
Date: Wed, 27 Aug 2008 11:05:06 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: [email-masked]
Subject: Re: no overall type in Extended Attributes

  Foo:1 = 1
  Bar:1 = "hello"
  BaZ:1 = "foo"

  Ugh.  But it works:

   A:1 = foo
   B:1 = 1
   C:1 = 1.2.3.4
   A:2 = bar
   B:2 = 42
   C:2 = 192.168.0.1

  Alan DeKok.

Delivery-date: Wed, 27 Aug 2008 08:56:29 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: no overall type in Extended Attributes
Date: Wed, 27 Aug 2008 15:54:24 +0700

Delivery-date: Wed, 27 Aug 2008 08:43:48 +0000
Date: Wed, 27 Aug 2008 10:42:32 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: [email-masked]
Subject: Re: no overall type in Extended Attributes

  Alan DeKok.

Delivery-date: Wed, 27 Aug 2008 08:41:03 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: no overall type in Extended Attributes
Date: Wed, 27 Aug 2008 15:38:35 +0700

About what?

Delivery-date: Wed, 27 Aug 2008 06:29:05 +0000
Date: Wed, 27 Aug 2008 08:27:22 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'Bernard Aboba' <[email-masked]>, [email-masked]
Subject: Re: no overall type in Extended Attributes

  Alan DeKok.

Delivery-date: Wed, 27 Aug 2008 04:23:59 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: no overall type in Extended Attributes
Date: Wed, 27 Aug 2008 11:21:51 +0700

...

...

Delivery-date: Wed, 27 Aug 2008 03:31:14 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: Revised Last look: RADIUS Design Guidelines
Date: Tue, 26 Aug 2008 20:31:02 -0700

The RADIUS Design Guidelines has recently been revised to reflect
the issues filed in RADEXT WG last call, and a draft PROTO writeup
has been submitted for WG inspection.  

The new document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-05.txt

The PROTO writeup is available here:
http://ops.ietf.org/lists/radiusext/2008/msg00522.html

If you filed an issue in RADEXT WG last call, please examine the
latest revision in order to determine whether the issue was resolved
to your satisfaction. 

Also, if you have not yet read the document, please do so. 

If you have comments on either the document or the PROTO writeup (see
previous message), please post them to the RADEXT WG mailing list
([email-masked]).  Document issues should be encapsulated 
in the format described in the RADEXT Issues List 
(http://www.drizzle.com/~aboba/RADEXT)

This "last look" will complete on September 7, 2008. 

Delivery-date: Wed, 27 Aug 2008 03:30:27 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: Revised PROTO: RADIUS Design Guidelines
Date: Tue, 26 Aug 2008 20:30:12 -0700

Title:  RADIUS Design Guidelines
I-D:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-05.txt
 
Status: Best Current Practice
 
Response to template:
 
1) Have the chairs personally reviewed this version of the ID and do
   they believe this ID is sufficiently baked to forward to the IESG
   for publication?
 
Yes.
 
2) Has the document had adequate review from both key WG members and
   key non-WG members? Do you have any concerns about the depth or
   breadth of the reviews that have been performed?
 
Yes. The ID has had 2 working group last calls.
 
3) Do you have concerns that the document needs more review from a
   particular (broader) perspective (e.g., security, operational
   complexity, someone familiar with AAA, etc.)?
 
No concerns.  
 
4) Do you have any specific concerns/issues with this document that
   you believe the ADs and/or IESG should be aware of? For example,
   perhaps you are uncomfortable with certain parts of the document,
   or whether there really is a need for it, etc., but at the same
   time these issues have been discussed in the WG and the WG has
   indicated it wishes to advance the document anyway.
 
No.
 
5) How solid is the WG consensus behind this document?  Does it
   represent the strong concurrence of a few individuals, with others
   being silent, or does the WG as a whole understand and agree with
   it?
 
There is solid consensus behind this document.  The overall approach
to the document has been extensively discussed, both in IETF meetings
and on the mailing list.  Over a dozen people have commented on various
aspects of the document during its development.  The issues raised in
WG last call, available for inspection at 
http://www.drizzle.com/~aboba/RADEXT/, were resolved in the -05
version of the document.
 
6) Has anyone threatened an appeal or otherwise indicated extreme
   discontent?  If so, please summarize what are they upset about.
 
No.
 
7) Have the chairs verified that the document adheres to _all_ of the
   ID nits?  (see http://www.ietf.org/ID-nits.html).
 
Yes. An output of the run on this revision of the ID by the online nits
checker:
 
idnits 2.08.10 

tmp/draft-ietf-radext-design-05.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
 
----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
 
----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
 
----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
 
----------------------------------------------------------------------------

     No issues found here.

  Checking references for intended status: Best Current Practice
 
----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative
references
     to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '8' on line 1431
     'The Text field consists of UTF-8 encoded 10646 [8] characters....'

     Summary: 0 errors (**), 0 warnings (==), 1 comment (--).

8) Does the document a) split references into normative/informative,
   and b) are there normative references to IDs, where the IDs are not
   also ready for advancement or are otherwise in an unclear state?
   (Note: the RFC editor will not publish an RFC with normative
   references to IDs, it will delay publication until all such IDs are
   also ready for publication as RFCs.)
 
The document does split references into normative and informative ones.
There are no normative references to IDs.
 
9) For Standards Track and BCP documents, the IESG approval
   announcement includes a writeup section with the following
   sections:
 
   - Technical Summary
 
   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, both within the
   IETF as well as other Standards Development Organizations (SDOs). 
 
   - Working Group Summary
 
    There have been 2 WGLCs on the document.  Much of the discussion on
    the document has centered around the design guidelines 
    surrounding complex attributes, as well as the relationship of the
    RADIUS Vendor-Specific Attribute (VSA) and the Standard attribute
    space.  There was also considerable discussion relating to the
    process for review of RADIUS attributes specified by SDOs.  
    Ultimately, a consensus developed behind a model similar to that
    described in [RFC4663]. 

Delivery-date: Wed, 27 Aug 2008 03:27:14 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: Last look: RADIUS Design Guidelines
Date: Tue, 26 Aug 2008 20:26:44 -0700

The RADIUS Design Guidelines has recently been revised to reflect
the issues filed in RADEXT WG last call, and a draft PROTO writeup
has been submitted for WG inspection.  

The new document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-06.txt

The PROTO writeup is available here:
http://ops.ietf.org/lists/radiusext/2008/msg00520.html

If you filed an issue in RADEXT WG last call, please examine the
latest revision in order to determine whether the issue was resolved
to your satisfaction. 

Also, if you have not yet read the document, please do so. 

If you have comments on either the document or the PROTO writeup (see
previous message), please post them to the RADEXT WG mailing list
([email-masked]).  Document issues should be encapsulated 
in the format described in the RADEXT Issues List 
(http://www.drizzle.com/~aboba/RADEXT)

This "last look" will complete on September 7, 2008. 

Delivery-date: Wed, 27 Aug 2008 03:07:41 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: PROTO: RADIUS Design Guidelines
Date: Tue, 26 Aug 2008 20:06:26 -0700

Title:  RADIUS Design Guidelines
I-D:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-06.txt
 
Status: Best Current Practice
 
Response to template:
 
1) Have the chairs personally reviewed this version of the ID and do
   they believe this ID is sufficiently baked to forward to the IESG
   for publication?
 
Yes.
 
2) Has the document had adequate review from both key WG members and
   key non-WG members? Do you have any concerns about the depth or
   breadth of the reviews that have been performed?
 
Yes. The ID has had 2 working group last calls.
 
3) Do you have concerns that the document needs more review from a
   particular (broader) perspective (e.g., security, operational
   complexity, someone familiar with AAA, etc.)?
 
No concerns.  
 
4) Do you have any specific concerns/issues with this document that
   you believe the ADs and/or IESG should be aware of? For example,
   perhaps you are uncomfortable with certain parts of the document,
   or whether there really is a need for it, etc., but at the same
   time these issues have been discussed in the WG and the WG has
   indicated it wishes to advance the document anyway.
 
No.
 
5) How solid is the WG consensus behind this document?  Does it
   represent the strong concurrence of a few individuals, with others
   being silent, or does the WG as a whole understand and agree with
   it?
 
There is solid consensus behind this document.  The overall approach
to the document has been extensively discussed, both in IETF meetings
and on the mailing list.  Over a dozen people have commented on various
aspects of the document during its development.  The issues raised in
WG last call, available for inspection at 
http://www.drizzle.com/~aboba/RADEXT/, were resolved in the -06
version of the document.
 
6) Has anyone threatened an appeal or otherwise indicated extreme
   discontent?  If so, please summarize what are they upset about.
 
No.
 
7) Have the chairs verified that the document adheres to _all_ of the
   ID nits?  (see http://www.ietf.org/ID-nits.html).
 
Yes. An output of the run on this revision of the ID by the online nits
checker:
 
idnits 2.08.10 

tmp/draft-ietf-radext-design-05.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
 
----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
 
----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
 
----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
 
----------------------------------------------------------------------------

     No issues found here.

  Checking references for intended status: Best Current Practice
 
----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative
references
     to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '8' on line 1431
     'The Text field consists of UTF-8 encoded 10646 [8] characters....'

     Summary: 0 errors (**), 0 warnings (==), 1 comment (--).

8) Does the document a) split references into normative/informative,
   and b) are there normative references to IDs, where the IDs are not
   also ready for advancement or are otherwise in an unclear state?
   (Note: the RFC editor will not publish an RFC with normative
   references to IDs, it will delay publication until all such IDs are
   also ready for publication as RFCs.)
 
The document does split references into normative and informative ones.
There are no normative references to IDs.
 
9) For Standards Track and BCP documents, the IESG approval
   announcement includes a writeup section with the following
   sections:
 
   - Technical Summary
 
   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, both within the
   IETF as well as other Standards Development Organizations (SDOs). 
 
   - Working Group Summary
 
    There have been 2 WGLCs on the document.  Much of the discussion on
    the document has centered around the design guidelines 
    surrounding complex attributes, as well as the relationship of the
    RADIUS Vendor-Specific Attribute (VSA) and the Standard attribute
    space.  There was also considerable discussion relating to the
    process for review of RADIUS attributes specified by SDOs.  
    Ultimately, a consensus developed behind a model similar to that
    described in [RFC4663]. 

Delivery-date: Tue, 26 Aug 2008 15:30:29 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-design-05.txt 
Date: Tue, 26 Aug 2008 08:30:01 -0700 (PDT)

--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 Design Guidelines
	Author(s)       : G. Weber, et al.
	Filename        : draft-ietf-radext-design-05.txt
	Pages           : 36
	Date            : 2008-08-26

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, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-05.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-design-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Tue, 26 Aug 2008 15:22:03 +0000
Date: Tue, 26 Aug 2008 17:20:13 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: Comment on draft-ietf-radext-design-04.txt, Appendix A

Bernard Aboba wrote:
> There are a few cases where the text in Appendix A is not backed by 
> discussion in the rest of the document, and vice versa.  
...

  I've updated the document as suggested, with some minor word smithing.
 It should show up soon as an announcement.

  Alan DeKok.

Delivery-date: Mon, 25 Aug 2008 21:58:27 +0000
Date: Mon, 25 Aug 2008 23:57:08 +0200
From: Alan DeKok <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-radext-status-server-01.txt

[email-masked] wrote:
> 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		: Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol

  The changes from -00 reflect the discussion at the WG meeting in
Dublin.  Text on using the CoA port has been added.

  I don't think there's much else to do with the document at this point.

  Alan DeKok.

Delivery-date: Mon, 25 Aug 2008 21:15:41 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-status-server-01.txt 
Date: Mon, 25 Aug 2008 14:15:01 -0700 (PDT)

--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		: Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol
	Author(s)	: A. DeKok
	Filename	: draft-ietf-radext-status-server-01.txt
	Pages		: 28
	Date		: 2008-8-25
	
RFC 2865 defines a Status-Server code for use in RADIUS, but labels
   it as "Experimental" without further discussion.  This document
   describes a practical use for the Status-Server packet code, which is
   to let clients query the status of a RADIUS server.  These queries,
   and responses (if any) enable the client to make more informed
   decisions.  The result is a more stable, and more robust RADIUS
   architecture.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-01.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-status-server-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Fri, 22 Aug 2008 15:44:38 +0000
Date: Fri, 22 Aug 2008 17:44:09 +0200
From: Stefan Winter <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-radext-radsec-01.txt

Hi,

this version reflects the discussions from IETF-72.

* normative section in the beginning, informative afterwards with 
explanations
* forbid integrity-only ciphers
* fixed shared "secret" ["radsec" for now, as I don't quite remember 
what we settled for, if anything]

Most of it is text re-shuffling, two notable changes:

* previous versions left CoA and Disconnect unspecified. The current 
draft includes it, the basic rationale being that to implement RadSec, 
new code is necessary anyways and the burden of at least answering to a 
Req with a NAK can be demanded IMO.
* one of the SHOULD ciphers which is based on MD5 is gone. It felt a bit 
awkward to complain about RADIUS' MD5 usage and then recommend a MD5 
based cipher.

If you have comments, I'll be happy to ignore them for the next two 
weeks, since I'll be at a completely-offline vacation. I'll get back to 
IETF business after that.

Greetings,

Stefan Winter

[email-masked] schrieb:
> 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 over TCP (RadSec)
> 	Author(s)       : S. Winter, et al.
> 	Filename        : draft-ietf-radext-radsec-01.txt
> 	Pages           : 17
> 	Date            : 2008-08-22
>
> This document specifies security on the transport layer (TLS) for the
> RADIUS protocol [RFC2865] when transmitted over TCP
> [I-D.dekok-radext-tcp-transport].  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-01.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.
>   

Delivery-date: Fri, 22 Aug 2008 14:31:05 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-radsec-01.txt 
Date: Fri, 22 Aug 2008 07:30:01 -0700 (PDT)

--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 over TCP (RadSec)
	Author(s)       : S. Winter, et al.
	Filename        : draft-ietf-radext-radsec-01.txt
	Pages           : 17
	Date            : 2008-08-22

This document specifies security on the transport layer (TLS) for the
RADIUS protocol [RFC2865] when transmitted over TCP
[I-D.dekok-radext-tcp-transport].  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-01.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-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Mon, 18 Aug 2008 21:21:45 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS"
Date: Mon, 18 Aug 2008 17:21:21 -0400
Organization: Elbrys Networks, Inc.

Joseph Salowey writes...

> [Joe] There is some confusion.

I think an example packet exchange, showing how the client and server
"negotiate" the algorithm they will mutually use would be helpful.

> [Joe] I'll try to provide some text by the end of the week.

Thanks.

Delivery-date: Mon, 18 Aug 2008 21:06:23 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS"
Date: Mon, 18 Aug 2008 14:05:48 -0700
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of David B. Nelson
> Sent: Friday, August 15, 2008 10:17 AM
> To: [email-masked]
> Subject: RE: REMINDER: RADEXT WG Last Call on "Crypto-Agility=20
> Requirements for RADIUS"
>=20
> Joseph Salowey writes...
>=20
> > 1. Section 4.2:
> >=20
> > In cases where the client needs to protect all or part of=20
> the radius=20
> > request the "hint and select" negotiation the client would provide=20
> > more than a hint when it chooses the algorithms for protection.
> > Perhaps hint and select is not quite the right term, may be specify=20
> > and select?
>=20
> While adding a more robust form of capabilities negotiation=20
> to RADIUS might be a useful thing, it's not a charted work=20
> item.  I think we are stuck with the current "hint and=20
> select" paradigm that is common usage in RADIUS today.
>=20
> Perhaps I've misunderstood your comment.  Could you give an example?
>=20
[Joe] There is some confusion.  I don't want to change the behavior, I
just think the term "hint and select" is a bit misleading since the
client will have to select some algorithm to protect its messages.  This
is a bit more than a "hint".  The client can "hint to the server what it
supports. =20

> > 2. Section 4.6:
> >=20
> > Section 4.6 makes reference to security considerations text=20
> about key=20
> > management.  Shouldn't this text be in this document?
>=20
> Yes, I think so.  Would anyone like to propose some text and=20
> a citation into RFC 4017?
>=20
[Joe] I'll try to provide some text by the end of the week. =20

>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
>=20

Delivery-date: Sun, 17 Aug 2008 10:13:29 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Comments  on "Crypto-Agility Requirements for RADIUS"
Date: Sun, 17 Aug 2008 17:11:37 +0700

David B. Nelson <mailto://[email-masked]> writes: 

> 
> Glen Zorn writes...
> 
> > What documents?
> 
> Those defining the cipher suites to be used.  Surely we're not going to
> attempt to define them within a RADIUS document?

Define what?  Whether the algorithm is mandatory to implement for use in
RADIUS?  I sincerely hope so!

> 
> > Since an Experimental RFC holds no standing as a standard, how can it
> > specify _anything_ as mandatory?
> 
> Sorry to be repetitive, buy why not?
> 
> > The last time I checked (please correct me if I'm wrong), the "hint"
> was
> > from a NAS to a server regarding what the NAS wanted returned.  In
> many
> > cases, these "hints" would not be anything of the sort; instead, they
> will
> > be a simple statement of the algorithm used by the NAS.
> 
> How is that not a hint?  

Some definitions of "hint":

an indirect suggestion
a slight indication
a clue

What about any of those suggests a declarative statement?

...

> > The only way that I can think of for the server to refuse the
> > "hint" would be if we were to hi-jack the Access-Challenge message,
> > which in itself constitutes a novel negotiation method for RADIUS.
> 
> Well, yes.  We discussed that briefly during an ill-fated attempt to
> add
> generic capabilities negotiation to RADIUS.  So, yes there is no "NAK"
> and
> counter-proposal capability, simply offer and accept or offer and
> reject.  I
> fail to see why that would not allow a rudimentary form of crypto-
> agility.
> The way a server refuses the hint by means of an Access-Reject message.

And the client knows that this is a refusal of this particular hint (instead
of the multiple other conditions that might elicit an Access-Reject how,
exactly?  Parsing the Reply-Message Attribute that may or may not be
present?

...

> 
> > > > Given that this is new and presumably desirable functionality,
> > > > why is a simple upgrade path not sufficient?
> > >
> > > A "fork-lift" upgrade?  :-)
> >
> > Hardly. New messages and or capabilities can fairly easily be
> introduced
> > in a piece-meal fashion, as long as it is done with care.
> 
> Well _that_ sounds a bit like "and a miracle occurs here".  

I guess miracles really do happen every day then ;-): support for EAP,
dynamic authorization, 802.11...

...

Delivery-date: Sun, 17 Aug 2008 09:47:57 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Issue 250
Date: Sun, 17 Aug 2008 16:30:25 +0700

"In section 5, the Ext-Length field is defined as the length of the Extended
Attribute.  I think you mean it's the length of the TLV (multiple TLVs can
be
in the Extended Attribute).  I think that would make the value ">=3", not
">=4"."

That being the case, maybe it would be more descriptive to make the names of
the fields to "TLV-type" & "TLV-Length"?

"It's probably worth calling out any artifacts of overloading attribute 26
which wouldn't apply to standard attributes in the original number space
(or apply to overloading a new attribute instead of 26)."  

Of course, since it's only the format that needs to be inherited from VSAs,
the overall Type can be changed...

"For example, attribute 26 is already specifically excluded from some RADIUS
message
types, e.g. CoA-NAK,"

Just out of curiosity, does anyone know why that is so?  

"so new Extended Attributes couldn't be included in
those messages, but new standard attribute could be."  

Extended Attributes could be legalized for those messages in the exactly the
same way as for new "standard" attributes: through an updating RFC.

"Also, are malformed VSAs always treated just like malformed non-VSAs?"

Don't the rules defined in RFC 2865 apply to all attributes?

"I think it would be useful to explicitly mention if recursive grouping is
allowed and that Extended Attributes cannot be grouped with non-Extended
Attributes."

I have no idea how recursive grouping could be done with this scheme, but if
it could I don't know why you would want to outlaw it; one of the benefits
of the (apparently confusing) sanctioning of Ext-Types 0-256 is that it
makes it impossible to encapsulate legacy attributes in Extended Attributes
(although the legacy attribute space _could_ be duplicated in the first 257
slots, possibly a decent idea...

"It's probably useful to mention what happens when an Extended Attribute's
tag is non-zero and it contains multiple TLVs (this does not seem to be
excluded -as multiple TLVs are when the M-bit is on)."

I thought that that was obvious...what is unclear?

Delivery-date: Sun, 17 Aug 2008 07:35:51 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>
Cc: <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Sun, 17 Aug 2008 14:34:40 +0700

David B. Nelson <mailto://[email-masked]> writes:

> >   See RFC 3579 Section 3.1:
> >
> >       If multiple
> >       EAP-Message attributes are contained within an Access-Request
> or
> >       Access-Challenge packet, they MUST be in order and they MUST be
> >       consecutive attributes in the Access-Request or Access-
> Challenge
> >       packet.
> 
> Damn.  When did that sneak in there?  :-)

Well, let's see, it was in 2869, so about 10 years ago :-)

Delivery-date: Sun, 17 Aug 2008 07:29:17 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: "'Greg Weber'" <[email-masked]>, "'Hannes Tschofenig'" <[email-masked]>, <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Sun, 17 Aug 2008 14:27:13 +0700

Bernard Aboba [mailto:[email-masked]] writes:

...

> > Be that as it may, the link points to an issue raised by Bernard re:
> the
> > Fixes draft.
> 
> On Mozilla, the link does point to Issue 250.  
> What browser were you
> using?

IE 7.0.6.  Investigating further w/Opera & Safari, it appears that IE is not
handling references to internal points in the HTML file correctly: it just
opens radissues2.html & quits, leaving the pointer at the beginning (issue
#200).  Opera & Safari position the pointer correctly (after a (long) while
;-). 

...

Delivery-date: Sun, 17 Aug 2008 04:43:06 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Sun, 17 Aug 2008 00:42:04 -0400

>   See RFC 3579 Section 3.1:
> 
>       If multiple
>       EAP-Message attributes are contained within an Access-Request or
>       Access-Challenge packet, they MUST be in order and they MUST be
>       consecutive attributes in the Access-Request or Access-Challenge
>       packet.

Damn.  When did that sneak in there?  :-)

Delivery-date: Sat, 16 Aug 2008 17:11:11 +0000
Date: Sat, 16 Aug 2008 10:10:37 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Glen Zorn <[email-masked]>
cc: 'Greg Weber' <[email-masked]>,  'Hannes Tschofenig' <[email-masked]>, [email-masked]
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

> 1) As you know, the issues list is not an official WG document, but a tool
> for the use of the Chairs & as such its state has no bearing on the status
> of a document.
> 2) All 3 of the issues assigned to the extended attributes document appear
> to actually refer to RFC 5080.

Issues 225, 250 and 251 all refer to the Extended Attributes document. 

> I suspect Hannes was referring to the open issues section in the draft's
> text, not the list maintained by the chairs.  Regarding the latter, the 
> issue that I filed (#250) was intended for your -00 draft, not RFC 5080.  
> 
> Be that as it may, the link points to an issue raised by Bernard re: the
> Fixes draft.

On Mozilla, the link does point to Issue 250.  What browser were you 
using? 

> I haven't read your current draft version yet to see if these comments were addressed;
> there was no response on the list -that I recall.  

Delivery-date: Sat, 16 Aug 2008 14:27:46 +0000
Date: Sat, 16 Aug 2008 16:26:36 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: [email-masked]
Subject: Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

David B. Nelson wrote:
> Glen Zorn writes...
>> ...   Any Extended
>> 	 Attributes containing multiple fragments of the same value MUST be
>> 	 in order and MUST be consecutive attributes in the packet.
> 
> It's the last sentence that I claim adds new requirements to RADIUS.  This
> is not required for EAP-Message Attributes,

  Nope.  See RFC 3579 Section 3.1:

       If multiple
      EAP-Message attributes are contained within an Access-Request or
      Access-Challenge packet, they MUST be in order and they MUST be
      consecutive attributes in the Access-Request or Access-Challenge
      packet.

  MUST be consecutive attributes would seem pretty clear.

> nor any others that I'm aware
> of.  I'm stopping short of claiming that this new requirement isn't backward
> compatible.  I can easily envision implementations where this would not be
> any sort of burden to enforce.  I'm just wondering if there are any
> implementations where it would be a burden?  I also see the advantage in
> terms of ease of implementation of parsing and reconstruction.

  It's a PITA to root through the packet, looking for the next attribute
which *might* be the same... and which isn't consecutive.  I've done
this for the previous version of the Extended-Attributes.  It's awkward.
 It's much easier just to check: Next attribute is the same?  Nope?
Dump the packet as malformed.

  It makes for less code, and fewer chances for programming errors.

  Alan DeKok.

Delivery-date: Sat, 16 Aug 2008 14:15:52 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Sat, 16 Aug 2008 10:15:45 -0400

Clarifying...

> > 	 Attributes containing multiple fragments of the same value MUST be
> > 	 in order and MUST be consecutive attributes in the packet.
> 
> It's the last sentence that I claim adds new requirements to RADIUS

I'm talking about the second MUST in that sentence.

Delivery-date: Sat, 16 Aug 2008 14:13:43 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Comments  on "Crypto-Agility Requirements for RADIUS"
Date: Sat, 16 Aug 2008 10:13:26 -0400

Glen Zorn writes...

> What documents?

Those defining the cipher suites to be used.  Surely we're not going to
attempt to define them within a RADIUS document?

> Since an Experimental RFC holds no standing as a standard, how can it
> specify _anything_ as mandatory?

Sorry to be repetitive, buy why not?

> The last time I checked (please correct me if I'm wrong), the "hint" was
> from a NAS to a server regarding what the NAS wanted returned.  In many
> cases, these "hints" would not be anything of the sort; instead, they will
> be a simple statement of the algorithm used by the NAS.

How is that not a hint?  Sorry, but I simply don't see where you're going
with this.

> Examples are the User-Password Attribute & request
> authentication/integrity protection.

Eh?

> The only way that I can think of for the server to refuse the
> "hint" would be if we were to hi-jack the Access-Challenge message,
> which in itself constitutes a novel negotiation method for RADIUS.

Well, yes.  We discussed that briefly during an ill-fated attempt to add
generic capabilities negotiation to RADIUS.  So, yes there is no "NAK" and
counter-proposal capability, simply offer and accept or offer and reject.  I
fail to see why that would not allow a rudimentary form of crypto-agility.
The way a server refuses the hint by means of an Access-Reject message.

> > Therefore, it's reasonable to say that "Just use IPSec."
> > is out of scope for RADIUS crypto-agility.
> 
> The text to which I was referring is "Therefore, it is expected that
> proposals will utilize other techniques".

Well, if "Just use IPSec" is out of scope, doesn't it follow that "proposals
will use other methods" [besides IPSec)?  Again, I simply don't see where
you're going with this.

> > > I would _really_ like to see some rationale for this requirement
> > > (aside from "backward compatibility is sacred and must never be
> > > questioned" ;-).
> >
> > Given that the RADIUS protocol doesn't have a protocol version field,
> > maintaining backward compatibility seems pretty basic.
> 
> OK, so that sounds an awful lot like " backward compatibility is sacred
> and must never be questioned" to me.

If you say so...

> > > Given that this is new and presumably desirable functionality,
> > > why is a simple upgrade path not sufficient?
> >
> > A "fork-lift" upgrade?  :-)
> 
> Hardly. New messages and or capabilities can fairly easily be introduced
> in a piece-meal fashion, as long as it is done with care.

Well _that_ sounds a bit like "and a miracle occurs here".  That which is a
simple upgrade path to some is a deployment nightmare to others.  We need to
be a bit more specific, I think.

Delivery-date: Sat, 16 Aug 2008 13:59:13 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Sat, 16 Aug 2008 09:59:03 -0400

Glen Zorn writes...

>    M (More)
> 
>       The More Flag is one (1) bit in length and MUST be present.  When
>       a value to be transmitted exceeds 246 octets in length it is
>       fragmented over two or more Extended Attributes.  If the More Flag
>       is set (1), this indicates that the Value field of the Extended
>       Attribute contains a fragment of a larger value, which is
>       continued in the next Extended Attribute of the same Ext-Type.
>       When the More Flag is clear (0), the final (or only) fragment of
>       the value is contained in the Extended Attribute.  Any Extended
> 	 Attributes containing multiple fragments of the same value MUST be
> 	 in order and MUST be consecutive attributes in the packet.

It's the last sentence that I claim adds new requirements to RADIUS.  This
is not required for EAP-Message Attributes, nor any others that I'm aware
of.  I'm stopping short of claiming that this new requirement isn't backward
compatible.  I can easily envision implementations where this would not be
any sort of burden to enforce.  I'm just wondering if there are any
implementations where it would be a burden?  I also see the advantage in
terms of ease of implementation of parsing and reconstruction.

Delivery-date: Sat, 16 Aug 2008 13:51:34 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Sat, 16 Aug 2008 09:50:42 -0400

Glen Zorn writes...

> > > Actually, I'd just as soon discard the examples: this draft has
> > > way too much flavor of a tutorial for my taste...
> >
> >   Sure.
> 
> Great!  Anybody married to section 6?  If not, it's gone...

I think examples sections (in this or any other document) are
extraordinarily helpful.  They help the reader to understand the details,
and the help the author by bringing to light incongruities in the normative
text.  I wouldn't be so quick to dispense with that section.  That fact that
it is raising issues tells me it has value.

Delivery-date: Sat, 16 Aug 2008 10:26:17 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Sat, 16 Aug 2008 17:25:06 +0700

Alan DeKok <mailto://[email-masked]> writes:

> 
> Glen Zorn wrote:
> > OK, are you saying that the existing text isn't clear?  It seems
> pretty
> > precise to me, should it be more vague (e.g., "long" & "short")?
> 
>   I just wanted to be sure I understood it.

OK.

> 
> >>       Two (2) octets.  Up-to-date values of the Ext-Type field are
> >>       specified in the most recent "Assigned Numbers" [IANA].
> Values
> >>       XXXX-YYYY are reserved.
> >>
> >>   I would suggest reserving the top 1K: 64512-65535
> >
> > Rationale?
> 
>   Numbers are better than XXXX-YYYY. :)  As for using the top 1K rather
> than 256, or 32, or 4.... it's small enough that we likely won't need
> the attribute numbers later, and large enough it gives a lot of room to
> work with.
> 
>   I'd say 32 may be too small, and anything over 1K is likely too
> large.

OK.  Any other opinions?

> 
> > Actually, I'd just as soon discard the examples: this draft has way
> too much
> > flavor of a tutorial for my taste...
> 
>   Sure.

Great!  Anybody married to section 6?  If not, it's gone...

> 
> >>   The examples could also given broken-out hex encoding of the
> >> attributes, which may be clearer than the ASCII art diagrams.  e.g.
> >>
> >>   1a 0f 00 00 00 00 00 01 01 08 48 65 6c 6c 6f
> >
> > You're joking, right?
> 
>   Other RFC's have hex examples...

Sure, but I thought that we were writing not with any expectation of a
reasonable level of shared knowledge but for the LCD...

> 
> >>   I suggest leaving the first 0..255 attributes as unallocated, in
> >> order
> >> to avoid confusion with legacy RADIUS attributes.
> >
> > Presumably the people who would get confused are those who have to be
> told
> > to protect against buffer overflows (& send "hello" as five separate
> > attributes), right?
> 
>   Yes.
> 
>   I should put up a web page listing all of the "creative"
> interpretation of the RFC's.  Some people have put a lot of effort into
> doing the most inventive things.

"There is no end to the folly of men..."

Delivery-date: Sat, 16 Aug 2008 10:15:10 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'David B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Sat, 16 Aug 2008 17:13:42 +0700

Alan DeKok <mailto://[email-masked]> writes:

> Glen Zorn wrote:
> > I believe that he meant that all fragments of a given attribute must
> be
> > contiguous in the original packet...
> 
>   RFC 3579, Section 3.1:
> 
>       If multiple
>       EAP-Message attributes are contained within an Access-Request or
>       Access-Challenge packet, they MUST be in order and they MUST be
>       consecutive attributes in the Access-Request or Access-Challenge
>       packet.
> 
>   Requiring this for Extended-Attribute is a good idea.

Alright, how about this?

   M (More)

      The More Flag is one (1) bit in length and MUST be present.  When
      a value to be transmitted exceeds 246 octets in length it is
      fragmented over two or more Extended Attributes.  If the More Flag
      is set (1), this indicates that the Value field of the Extended
      Attribute contains a fragment of a larger value, which is
      continued in the next Extended Attribute of the same Ext-Type.
      When the More Flag is clear (0), the final (or only) fragment of
      the value is contained in the Extended Attribute.  Any Extended 
	Attributes containing multiple fragments of the same value MUST be 
	in order and MUST be consecutive attributes in the packet.

Delivery-date: Sat, 16 Aug 2008 08:18:55 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Comments  on "Crypto-Agility Requirements for RADIUS"
Date: Sat, 16 Aug 2008 15:17:03 +0700

David B. Nelson <mailto://[email-masked]> writes:

> Glen Zorn writes...
> 
> > The WG Charter states that all of the existing crypto-agility
> > proposals are to be published as Experimental RFCs.  In that case,
> > how can the requirement that " at least one mandatory to implement
> > algorithm will be defined" (section 1.2) be fulfilled?
> 
> Why not?  The algorithms are defined in existing documents.

What documents?  Since an Experimental RFC holds no standing as a standard,
how can it specify _anything_ as mandatory?

...

> > Technical comments:
> >
> > Section 2, paragraph 2 states:
> >
> >    In the specific context of the RADIUS protocol and RADIUS
> >    implementations, crypto-agility may be better defined as the
> ability
> >    of RADIUS implementations to negotiate cryptographic algorithms
> for
> >    use in RADIUS exchanges, including the cryptographic algorithms
> used
> >    to protect RADIUS packets and to hide RADIUS Attributes.  This
> >    capability covers all RADIUS message types: Access-
> Request/Response,
> >    Accounting-Request/Response, and CoA/Disconnect-Request/Response.
> >
> > Since RADIUS has no negotiation method of I'm aware (hint &
> > accept/ignore is hardly a negotiation mechanism)...
> 
> Yeah, but it's what we've got.
> 
> >... I find these statements very curious, especially in light of the
> > earlier statement (section 2, paragraph 3) that the password-hiding
> > function will be negotiable.  Basically, what is being called for is
> > impossible in the context of the RADIUS protocol, implying that the
> > negotiations would take place outside of RADIUS (e.g., in TLS).
> 
> That wasn't what I understood when I transcribed that text.  It's true
> that
> "hint and consent" is a bit crude, but I'd like to see a more in-depth
> technical exploration of why you think it makes crypto-agility
> impossible
> within RADIUS

The last time I checked (please correct me if I'm wrong), the "hint" was
from a NAS to a server regarding what the NAS wanted returned.  In many
cases, these "hints" would not be anything of the sort; instead, they will
be a simple statement of the algorithm used by the NAS.  Examples are the
User-Password Attribute & request authentication/integrity protection.  The
only way that I can think of for the server to refuse the "hint" would be if
we were to hi-jack the Access-Challenge message, which in itself constitutes
a novel negotiation method for RADIUS.

> 
> > Section 4.1:
> > Once again, assuming a solution.  State the requirements that a
> solution
> > must meet, not your personal assumptions about the form which the
> solution
> > will take.  I say "personal" because a fair subset of the active WG
> (of
> > which this document is purportedly a product) _does not_ share the
> > expectation that " proposals will utilize other techniques".
> 
> I take that text to means that RADIUS over IPSec has already been
> defined,
> and therefore proposing RADIUS over IPSec is not what we're looking for
> to
> address RADIUS crypto-agility.  After all, if an existing solution
> needs
> everyone's needs, why waste time on a requirements document, never mind
> a
> solution document?  Therefore, it's reasonable to say that "Just use
> IPSec."
> is out of scope for RADIUS crypto-agility.

The text to which I was referring is "Therefore, it is expected that
proposals will utilize other techniques".

> 
> > Section 4.2, paragraph 2 states:
> >
> >    Included in negotiation techniques are "hint and consent"
> mechanisms
> >    where the NAS provides a list of algorithms and the server selects
> >    one.
> >
> > If the server is required to select from the list it can hardly be
> > called a hint.  Once again, I can't see at all how this mechanism
> > could be made to work in the case of the Access-Request message.
> 
> Please explain.

See above.

> 
> > Section 4.3, paragraph 1 states:
> >
> >    Solutions to the problem MUST demonstrate backward compatibility
> >    with existing RADIUS implementations.
> >
> > I would _really_ like to see some rationale for this requirement
> > (aside from "backward compatibility is sacred and must never be
> > questioned" ;-).
> 
> Given that the RADIUS protocol doesn't have a protocol version field,
> maintaining backward compatibility seems pretty basic.

OK, so that sounds an awful lot like " backward compatibility is sacred and
must never be questioned" to me.  

> 
> > Given that this is new and presumably desirable functionality,
> > why is a simple upgrade path not sufficient?
> 
> A "fork-lift" upgrade?  :-)

Hardly. New messages and or capabilities can fairly easily be introduced in
a piece-meal fashion, as long as it is done with care.

Delivery-date: Sat, 16 Aug 2008 06:12:12 +0000
Date: Sat, 16 Aug 2008 08:10:26 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: "'David B. Nelson'" <[email-masked]>,  [email-masked]
Subject: Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

Glen Zorn wrote:
> I believe that he meant that all fragments of a given attribute must be
> contiguous in the original packet...

  RFC 3579, Section 3.1:

      If multiple
      EAP-Message attributes are contained within an Access-Request or
      Access-Challenge packet, they MUST be in order and they MUST be
      consecutive attributes in the Access-Request or Access-Challenge
      packet.

  Requiring this for Extended-Attribute is a good idea.

  Alan DeKok.

Delivery-date: Fri, 15 Aug 2008 22:45:04 +0000
Content-class: urn:content-classes:message
Subject: RE: Help me about RFC3576
Date: Fri, 15 Aug 2008 15:43:59 -0700
From: "Murtaza Chiba (mchiba)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8FF28.741696EA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
Included radius extensions WG.   Not sure what was decided in the bis
portion.
=20
Thanks,
-Murtaza

________________________________

	From: Cuong Hoang Bui [mailto:[email-masked]]=20
	Sent: Friday, August 15, 2008 1:11 PM
	To: Murtaza Chiba (mchiba)
	Subject: Help me about RFC3576
=09
=09
Dear Mr. Chiba,

I have a question related to CoA messages.
If both supported attribute(s) and unsupported attribute(s) are included
in CoA-Request message, then what happens? NAS doesn't process packets
and return CoA-NAK back to Radius server or it processes only supported
attributes, but should it send CoA-NAK or CoA-ACK back to RADIUS server?

Thank you

Regards
Cuong
=09

------_=_NextPart_001_01C8FF28.741696EA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16674" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D578094222-15082008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Included radius extensions WG.&nbsp;&nbsp; Not =
sure what=20
was decided in the bis portion.</FONT></SPAN></DIV>
<DIV><SPAN class=3D578094222-15082008><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D578094222-15082008><FONT face=3DArial color=3D#0000ff =

size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D578094222-15082008><FONT face=3DArial color=3D#0000ff =

size=3D2>-Murtaza</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><BR></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Cuong Hoang Bui=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Friday, August 15, =
2008 1:11=20
  PM<BR><B>To:</B> Murtaza Chiba (mchiba)<BR><B>Subject:</B> Help me =
about=20
  RFC3576<BR></FONT><BR></DIV>
  <DIV></DIV>
  <TABLE cellSpacing=3D0 cellPadding=3D0 border=3D0>
    <TBODY>
    <TR>
      <TD vAlign=3Dtop>Dear Mr. Chiba,<BR><BR>I have a question related =
to CoA=20
        messages.<BR>If both supported attribute(s) and unsupported =
attribute(s)=20
        are included in CoA-Request message, then what happens? NAS =
doesn't=20
        process packets and return CoA-NAK back to Radius server or it =
processes=20
        only supported attributes, but should it send CoA-NAK or CoA-ACK =
back to=20
        RADIUS server?<BR><BR>Thank=20
  =
you<BR><BR>Regards<BR>Cuong<BR></TD></TR></TBODY></TABLE><BR></BLOCKQUOTE=
></BODY></HTML>

------_=_NextPart_001_01C8FF28.741696EA--

Delivery-date: Fri, 15 Aug 2008 17:36:14 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Comments  on "Crypto-Agility Requirements for RADIUS"
Date: Fri, 15 Aug 2008 13:35:20 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...

> The WG Charter states that all of the existing crypto-agility
> proposals are to be published as Experimental RFCs.  In that case,
> how can the requirement that " at least one mandatory to implement 
> algorithm will be defined" (section 1.2) be fulfilled?

Why not?  The algorithms are defined in existing documents.

> Front page header:
> Since the source of the document is stated in section 1.1 to be
> the radext WG, David's role should probably be "Editor".

Yes.

> Section 1.2:
> s/propose one of more Internet Drafts/propose one or more Internet-Drafts/
> 
> Section 2:
> s/Crypto-Agility is the ability for/Crypto-agility is the ability of/

OK.

> Section 4.5, paragraph 5 states:
> 
>    Editorial Note: With the expected acceptance of the proposed RADEXT
>    WG Charter revision, some of the issues raised in the preceding
>    paragraphs become moot, and this section ought to be revised to
>    reflect the revised charter.
> 
> Haven't those charter revisions already taken place?

As of submission of the -00 draft, the IESG was still deliberating the
re-charter request.  Will be fixed in -01.

> Technical comments:
> 
> Section 2, paragraph 2 states:
> 
>    In the specific context of the RADIUS protocol and RADIUS
>    implementations, crypto-agility may be better defined as the ability
>    of RADIUS implementations to negotiate cryptographic algorithms for
>    use in RADIUS exchanges, including the cryptographic algorithms used
>    to protect RADIUS packets and to hide RADIUS Attributes.  This
>    capability covers all RADIUS message types: Access-Request/Response,
>    Accounting-Request/Response, and CoA/Disconnect-Request/Response.
> 
> Since RADIUS has no negotiation method of I'm aware (hint & 
> accept/ignore is hardly a negotiation mechanism)...

Yeah, but it's what we've got.

>... I find these statements very curious, especially in light of the
> earlier statement (section 2, paragraph 3) that the password-hiding
> function will be negotiable.  Basically, what is being called for is
> impossible in the context of the RADIUS protocol, implying that the
> negotiations would take place outside of RADIUS (e.g., in TLS).

That wasn't what I understood when I transcribed that text.  It's true that
"hint and consent" is a bit crude, but I'd like to see a more in-depth
technical exploration of why you think it makes crypto-agility impossible
within RADIUS

> Section 4.1:
> Once again, assuming a solution.  State the requirements that a solution
> must meet, not your personal assumptions about the form which the solution
> will take.  I say "personal" because a fair subset of the active WG (of
> which this document is purportedly a product) _does not_ share the
> expectation that " proposals will utilize other techniques".

I take that text to means that RADIUS over IPSec has already been defined,
and therefore proposing RADIUS over IPSec is not what we're looking for to
address RADIUS crypto-agility.  After all, if an existing solution needs
everyone's needs, why waste time on a requirements document, never mind a
solution document?  Therefore, it's reasonable to say that "Just use IPSec."
is out of scope for RADIUS crypto-agility.

> Section 4.2, paragraph 2 states:
> 
>    Included in negotiation techniques are "hint and consent" mechanisms
>    where the NAS provides a list of algorithms and the server selects
>    one.
> 
> If the server is required to select from the list it can hardly be 
> called a hint.  Once again, I can't see at all how this mechanism 
> could be made to work in the case of the Access-Request message.

Please explain.

> Section 4.3, paragraph 1 states:
> 
>    Solutions to the problem MUST demonstrate backward compatibility
>    with existing RADIUS implementations.
> 
> I would _really_ like to see some rationale for this requirement 
> (aside from "backward compatibility is sacred and must never be 
> questioned" ;-).

Given that the RADIUS protocol doesn't have a protocol version field,
maintaining backward compatibility seems pretty basic.

> Given that this is new and presumably desirable functionality,
> why is a simple upgrade path not sufficient?

A "fork-lift" upgrade?  :-)

Delivery-date: Fri, 15 Aug 2008 17:17:48 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS"
Date: Fri, 15 Aug 2008 13:17:12 -0400
Organization: Elbrys Networks, Inc.

Joseph Salowey writes...

> 1. Section 4.2:
> 
> In cases where the client needs to protect all or part of the radius
> request the "hint and select" negotiation the client would provide 
> more than a hint when it chooses the algorithms for protection. 
> Perhaps hint and select is not quite the right term, may be specify
> and select?

While adding a more robust form of capabilities negotiation to RADIUS might
be a useful thing, it's not a charted work item.  I think we are stuck with
the current "hint and select" paradigm that is common usage in RADIUS today.

Perhaps I've misunderstood your comment.  Could you give an example?

> 2. Section 4.6:
> 
> Section 4.6 makes reference to security considerations text about key
> management.  Shouldn't this text be in this document?

Yes, I think so.  Would anyone like to propose some text and a citation into
RFC 4017?

Delivery-date: Fri, 15 Aug 2008 17:02:38 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Greg Weber'" <[email-masked]>
Cc: "'Hannes Tschofenig'" <[email-masked]>, <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Sat, 16 Aug 2008 00:01:35 +0700

This is a multipart message in MIME format.

------=_NextPart_000_009D_01C8FF33.48B203A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Greg Weber [mailto:[email-masked]]  writes:

On Fri, Aug 15, 2008 at 11:50 AM, Glen Zorn <[email-masked]> wrote:

.

I haven't read 

your current draft version yet to see if these comments were addressed;

there was no response on the list -that I recall.  

Probably not, since it was an individual submission & last time I checked
the authors of such have no obligation to respond to the WG, which in turn
has no control over the work.  

Of course, since the draft is now a WG item I'd love to address your
comments (if I could only see them ;-).

These were my comments on the -00 WG draft:

  http://ops.ietf.org/lists/radiusext/2008/msg00095.html

Thanks!

Not sure if these have been addressed or obviated by now- or if they

were originally valid...

Greg 

.

------=_NextPart_000_009D_01C8FF33.48B203A0
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=3DContent-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:12.0pt;
	font-family:"Times New Roman","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;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</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=3DSection1>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div>

<p class=3DMsoNormal><span style=3D'color:#00B050'>Greg Weber
[mailto:[email-masked]] &nbsp;writes:<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal>On Fri, Aug 15, 2008 at 11:50 AM, Glen Zorn &lt;<a
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
wrote:<o:p></o:p></p>

<div>

<div>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div>

<div>

<div>

<p><span =
style=3D'font-size:11.0pt;color:#1F497D'>&#8230;</span><o:p></o:p></p>

<p><span =
style=3D'font-size:11.0pt;color:#7030A0'>&nbsp;</span><o:p></o:p></p>

<p>I haven't read&nbsp;<o:p></o:p></p>

</div>

<div>

<p>your current draft version yet to see if these comments were =
addressed;<o:p></o:p></p>

</div>

</div>

<div>

<div>

<p>there was no response on the list -that I recall. =
&nbsp;<o:p></o:p></p>

<p><span =
style=3D'font-size:11.0pt;color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<p><span style=3D'font-size:11.0pt;color:#7030A0'>Probably not, since it =
was an
individual submission &amp; last time I checked the authors of such have =
no
obligation to respond to the WG, which in turn has no control over the
work.&nbsp; </span><o:p></o:p></p>

<p><span =
style=3D'font-size:11.0pt;color:#1F497D'>&nbsp;</span><o:p></o:p></p>

</div>

<p><span style=3D'font-size:11.0pt;color:#1F497D'>Of course, since the =
draft is
now a WG item I'd love to address your comments (if I could only see =
them ;-).</span><o:p></o:p></p>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>These were my comments on the -00 WG =
draft:<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;&nbsp;<a
href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00095.html">http://op=
s.ietf.org/lists/radiusext/2008/msg00095.html</a><o:p></o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#00B050'>Thanks!<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal>Not sure if these have been addressed or obviated =
by now- or
if they<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>were originally valid...<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>Greg&nbsp;<o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid #CCCCCC =
1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>

<div>

<div>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div>

<div>

<p><span =
style=3D'font-size:11.0pt;color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<p><span =
style=3D'font-size:11.0pt;color:#1F497D'>&#8230;</span><o:p></o:p></p>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

</blockquote>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_009D_01C8FF33.48B203A0--

Delivery-date: Fri, 15 Aug 2008 17:00:56 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'Stefan Winter'" <[email-masked]>, <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Fri, 15 Aug 2008 23:59:37 +0700

Alan DeKok [mailto:[email-masked]] writes:

> Glen Zorn wrote:
> >> Alan's wording "The More Flag MUST NOT be set if the Length is less
> >> than
> >> 255." sounds good to me.
> >
> > My point was that making these kinds of rules is pointless: if
> someone wants
> > to split "Hello" into 5 separate attributes they either have a very
> good
> > reason to do so that none of us can foresee or they will soon be
> finding
> > gainful employment in a different field.  In any case, it's not
> possible to
> > protect people from their own stupidity (besides, they could still do
> it
> > with tags).
> 
>   It's only one sentence.  

A sentence here, a sentence there & pretty soon you're outlawing driving
while blindfolded (http://www.whatcar.com/news-article.aspx?NA=229117)...

> And it will stop the stupid people from
> afflicting everyone else.

No, they can still do it (even more stupidly) with tags...

> 
>   RFC 2865 has comments saying:
> 
>       The secret MUST NOT be empty (length 0) since this would allow
>       packets to be trivially forged.
> 
>   Which were inserted because of real-world exposure to implementations
> having *no* configuration for shared secrets. (i.e. they were always
> NUL).

That may be stupid, or not, depending upon the level of other security in
the network...

Delivery-date: Fri, 15 Aug 2008 16:44:07 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Stefan Winter'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Fri, 15 Aug 2008 23:42:20 +0700

Stefan Weber <maito://[email-masked]> writes:

...

> TLV encoding rules: Ext-Length field misses its unit ... (in octets)...

OK

> 
> Example in Figure 3: VSA Length. 7 + 9 = 16, not 15.

OK

...

> Some nitbits:
> 
> - Intro: "101 or so have been". Or so sound a bit colloquial.
> - first example: "Extended-Type *of* 257 by IANA." ( not 0f)

OK

...

Delivery-date: Fri, 15 Aug 2008 16:09:05 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Fri, 15 Aug 2008 23:07:50 +0700

Alan DeKok <mailto://[email-masked]> writes:

...

> Section 4:
> ...
>    o  The final octet of the header contains the More flag and Tag
>       field.  If the one bit More flag is set (1) this indicates that
>       the encapsulated TLV is continued in the following Extended
>       Attribute; if the More flag is clear (0) then all of the
>       encapsulated TLVs fit into the current Extended Attribute.  The
>       More flag MUST NOT be set if the Extended Attribute contains more
>       than one TLV.
> 
>   To be clear: this means that the Extended-Attribute can encapsulate
> multiple TLV's if they're short, or only one TLV if it's long.

OK, are you saying that the existing text isn't clear?  It seems pretty
precise to me, should it be more vague (e.g., "long" & "short")?

> 
> 
> Section 5:
> 
>    M (More)
> 
>       The More Flag is one (1) bit in length and MUST be present.  When
>       a value to be transmitted exceeds 246 octets in length it is
>       fragmented over two or more Extended Attributes.  If the More
> Flag
>       is set (1), this indicates that the Value field of the Extended
>       Attribute contains a fragment of a larger value, which is
>       continued in the next Extended Attribute of the same Ext-Type.
> 
>   Can we add a MUST?  i.e. If the More Flag is set, the next attribute
> MUST be an Extended-Attribute of the same Extended-Type.

Fine

...

>    Ext-Type
> 
>       Two (2) octets.  Up-to-date values of the Ext-Type field are
>       specified in the most recent "Assigned Numbers" [IANA].  Values
>       XXXX-YYYY are reserved.
> 
>   I would suggest reserving the top 1K: 64512-65535

Rationale?

...

>    Consider the following structure:
> 
>      struct
>        Integer a;
>        String  b;
>        Integer c;
>      endStruct
> 
>   What syntax is this?  I think I understand it, but I'm not sure
> everyone will come to a shared understanding.  Maybe instead the
> example
> can be given by reference to existing RADIUS data types.  e.g. A
> structure of RADIUS data types (integer, text, integer) would
> previously
> have to be encoded as three separate and independent attributes.  

Previously, such a structure was impossible to encode in RADIUS.

> Here,
> it can be encoded as 3 attributes sharing a common tag.

Or as 3 TLVs in a single attribute (depending upon the length of the string.

> 
>   Reading the rest of the example, I find the b(4,5) syntax very
> awkward.  I suggest discarding it, and just referring to the diagrams.

Actually, I'd just as soon discard the examples: this draft has way too much
flavor of a tutorial for my taste...

> 
>   The examples could also given broken-out hex encoding of the
> attributes, which may be clearer than the ASCII art diagrams.  e.g.
> 
>   1a 0f 00 00 00 00 00 01 01 08 48 65 6c 6c 6f

You're joking, right?

> 
> 7.  Security Considerations
> 
>    I suggest adding a note that a new attribute encoding is an
> opportunity for buffer overflows, inadequate checks, etc.  Implementors
> SHOULD take care to validate the lengths, etc. before decoding the
> contents of the attributes.
> 
> 8.  IANA Considerations
> ...
>    It also requires that IANA set up a new registry for the RADIUS
>    Extended Attribute Types.
> 
>   I suggest leaving the first 0..255 attributes as unallocated, in
> order
> to avoid confusion with legacy RADIUS attributes.

Presumably the people who would get confused are those who have to be told
to protect against buffer overflows (& send "hello" as five separate
attributes), right?

...

Delivery-date: Fri, 15 Aug 2008 16:01:16 +0000
Date: Fri, 15 Aug 2008 12:00:59 -0400
From: "Greg Weber" <[email-masked]>
To: "Glen Zorn" <[email-masked]>
Subject: Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Cc: "Hannes Tschofenig" <[email-masked]>, [email-masked]

------=_Part_90886_12638339.1218816059680
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Fri, Aug 15, 2008 at 11:50 AM, Glen Zorn <[email-masked]> wrote:

>     =85
>
>
>
> I haven't read
>
> your current draft version yet to see if these comments were addressed;
>
> there was no response on the list -that I recall.
>
>
>
> Probably not, since it was an individual submission & last time I checked
> the authors of such have no obligation to respond to the WG, which in tur=
n
> has no control over the work.
>
>
>
> Of course, since the draft is now a WG item I'd love to address your
> comments (if I could only see them ;-).
>

These were my comments on the -00 WG draft:
  http://ops.ietf.org/lists/radiusext/2008/msg00095.html
Not sure if these have been addressed or obviated by now- or if they
were originally valid...

Greg

> =85

------=_Part_90886_12638339.1218816059680
Content-Type: text/html; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote">On Fri, Aug 15, 2008 at=
 11:50 AM, Glen Zorn <span dir=3D"ltr">&lt;<a href=3D"mailto:glenzorn@comca=
st.net">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex;">

<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">

<div>

<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">

<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">

<div>

<div><div class=3D"Ih2E3d">

<div>

<p><span style=3D"font-size:11.0pt;color:#1F497D">=85</span></p>

<p><span style=3D"font-size:11.0pt;color:#7030A0">&nbsp;</span></p>

<p>I haven&#39;t read&nbsp;</p>

</div>

<div>

<p>your current draft version yet to see if these comments were
addressed;</p>

</div>

</div><div><div class=3D"Ih2E3d">

<p>there was no response on the list -that I recall. &nbsp;</p>

<p><span style=3D"font-size:11.0pt;color:#1F497D">&nbsp;</span></p>

<p><span style=3D"font-size:11.0pt;color:#7030A0">Probably not, since it wa=
s an individual submission &amp; last
time I checked the authors of such have no obligation to respond to the WG,=
 which
in turn has no control over the work.&nbsp; </span></p>

<p><span style=3D"font-size:11.0pt;color:#1F497D">&nbsp;</span></p>

</div><p><span style=3D"font-size:11.0pt;color:#1F497D">Of course, since th=
e draft is now a WG item I&#39;d love to address your
comments (if I could only see them ;-).</span></p></div></div></div></div><=
/div></div></div></blockquote><div><br></div><div>These were my comments on=
 the -00 WG draft:</div><div>&nbsp;&nbsp;<a href=3D"http://ops.ietf.org/lis=
ts/radiusext/2008/msg00095.html">http://ops.ietf.org/lists/radiusext/2008/m=
sg00095.html</a></div>
<div>Not sure if these have been addressed or obviated by now- or if they</=
div><div>were originally valid...</div><div><br></div><div>Greg&nbsp;</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">
<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><div style=3D"borde=
r:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div style=
=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><di=
v><div><div>
<p><span style=3D"font-size:11.0pt;color:#1F497D"></span></p>

<p><span style=3D"font-size:11.0pt;color:#1F497D">&nbsp;</span></p>

<p><span style=3D"font-size:11.0pt;color:#1F497D">=85</span></p>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

</blockquote></div><br></div>

------=_Part_90886_12638339.1218816059680--

Delivery-date: Fri, 15 Aug 2008 15:52:26 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Glen Zorn'" <[email-masked]>, "'Greg Weber'" <[email-masked]>
Cc: "'Hannes Tschofenig'" <[email-masked]>, <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Fri, 15 Aug 2008 22:50:31 +0700

This is a multipart message in MIME format.

------=_NextPart_000_005C_01C8FF29.66F45610
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

.

I haven't read 

your current draft version yet to see if these comments were addressed;

there was no response on the list -that I recall.  

Probably not, since it was an individual submission & last time I checked
the authors of such have no obligation to respond to the WG, which in turn
has no control over the work.  

Of course, since the draft is now a WG item I'd love to address your
comments (if I could only see them ;-).

.

------=_NextPart_000_005C_01C8FF29.66F45610
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=3DContent-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;}
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","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;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</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=3DSection1>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Arial =
Black","sans-serif";
color:#1F497D'>&#8230;<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Arial =
Black","sans-serif";
color:#7030A0'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal>I haven't read&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>your current draft version yet to see if these =
comments were
addressed;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>there was no response on the list -that I recall. =
&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Arial =
Black","sans-serif";
color:#7030A0'>Probably not, since it was an individual submission &amp; =
last
time I checked the authors of such have no obligation to respond to the =
WG, which
in turn has no control over the work.&nbsp; <o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Arial =
Black","sans-serif";
color:#1F497D'>Of course, since the draft is now a WG item I'd love to =
address your
comments (if I could only see them ;-).<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Arial =
Black","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Arial =
Black","sans-serif";
color:#1F497D'>&#8230;<o:p></o:p></span></p>

</div>

</div>

</div>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_005C_01C8FF29.66F45610--

Delivery-date: Fri, 15 Aug 2008 15:03:40 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Greg Weber'" <[email-masked]>
Cc: "'Hannes Tschofenig'" <[email-masked]>, <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Fri, 15 Aug 2008 22:01:38 +0700

This is a multipart message in MIME format.

------=_NextPart_000_0054_01C8FF22.8F31DDC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Greg Weber [mailto:[email-masked]]  writes:

On Fri, Aug 15, 2008 at 6:10 AM, Glen Zorn <[email-masked]> wrote:

Hannes Tschofenig <mailto:// [email-masked]> writes:

> Bernard,
>
> why is there is a working group last call on this document given that
> it
> still has an open issue section giving me the impression that the
> document is far from being ready?

1) As you know, the issues list is not an official WG document, but a tool
for the use of the Chairs & as such its state has no bearing on the status
of a document.
2) All 3 of the issues assigned to the extended attributes document appear
to actually refer to RFC 5080.

I suspect Hannes was referring to the open issues section in the draft's
text,

not the list maintained by the chairs.  Regarding the latter, the issue that
I

filed (#250) was intended for your -00 draft, not RFC 5080.  

Be that as it may, the link points to an issue raised by Bernard re: the
Fixes draft.

I haven't read 

your current draft version yet to see if these comments were addressed;

there was no response on the list -that I recall.  

Probably not, since it was an individual submission & last time I checked
the authors of such have no obligation to respond to the WG, which in turn
has no control over the work.  

Greg

>
> Ciao
> Hannes
>
> Bernard Aboba wrote:
> > This is a reminder of the RADEXT WG Last Call on "Extended
> > RADIUS Attributes", prior to requesting that the IESG publish it as a
> Proposed Standard.
> >
> > The document is available here:
> > http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-
> attributes-04.txt
> >
> > WG Last Call was originally to have completed on August 10, 2008.
> > However, due to lack of response to the RADEXT WG last call,
> > we will be extending the WG last call to August 31, 2008.  Please
> > review the document and post your comments to the RADEXT WG mailing
> list
> > ([email-masked]) in the format described on the RADEXT WG
> Issues
> > list (http://www.drizzle.com/~aboba/RADEXT/).
> >
> > If you have read the document and approve of its publication, but
> have no
> > comments, please also post this to the list.
> >
> > --

------=_NextPart_000_0054_01C8FF22.8F31DDC0
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=3DContent-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;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","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-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</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=3DSection1>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Greg
Weber [mailto:[email-masked]] &nbsp;writes:<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'><br>
</span>On Fri, Aug 15, 2008 at 6:10 AM, Glen Zorn &lt;<a
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
wrote:<o:p></o:p></p>

<div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>Hannes Tschofenig =
&lt;mailto://
<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&g=
t;
writes:<br>
<br>
&gt; Bernard,<br>
&gt;<br>
&gt; why is there is a working group last call on this document given =
that<br>
&gt; it<br>
&gt; still has an open issue section giving me the impression that =
the<br>
&gt; document is far from being ready?<o:p></o:p></p>

</div>

<p class=3DMsoNormal>1) As you know, the issues list is not an official =
WG
document, but a tool<br>
for the use of the Chairs &amp; as such its state has no bearing on the =
status<br>
of a document.<br>
2) All 3 of the issues assigned to the extended attributes document =
appear<br>
to actually refer to RFC 5080.<o:p></o:p></p>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>I suspect Hannes was referring to the open issues =
section in
the draft's text,<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>not the list maintained by the chairs. =
&nbsp;Regarding the
latter, the issue that I<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>filed (#250) was intended for your -00 draft, not =
RFC 5080.
&nbsp;<span style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Arial =
Black","sans-serif";
color:#7030A0'>Be that as it may, the link points to an issue raised by =
Bernard
re: the Fixes draft.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Arial =
Black","sans-serif";
color:#7030A0'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal>I haven't read&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>your current draft version yet to see if these =
comments were
addressed;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>there was no response on the list -that I recall. =
&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Arial =
Black","sans-serif";
color:#7030A0'>Probably not, since it was an individual submission &amp; =
last
time I checked the authors of such have no obligation to respond to the =
WG,
which in turn has no control over the work.&nbsp; <o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>Greg<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid #CCCCCC =
1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<div>

<p class=3DMsoNormal><br>
&gt;<br>
&gt; Ciao<br>
&gt; Hannes<br>
&gt;<br>
&gt; Bernard Aboba wrote:<br>
&gt; &gt; This is a reminder of the RADEXT WG Last Call on =
&quot;Extended<br>
&gt; &gt; RADIUS Attributes&quot;, prior to requesting that the IESG =
publish it
as a<br>
&gt; Proposed Standard.<br>
&gt; &gt;<br>
&gt; &gt; The document is available here:<br>
&gt; &gt; <a
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-"
target=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-radext-e=
xtended-</a><br>
&gt; attributes-04.txt<br>
&gt; &gt;<br>
&gt; &gt; WG Last Call was originally to have completed on August 10, =
2008.<br>
&gt; &gt; However, due to lack of response to the RADEXT WG last =
call,<br>
&gt; &gt; we will be extending the WG last call to August 31, 2008.
&nbsp;Please<br>
&gt; &gt; review the document and post your comments to the RADEXT WG =
mailing<br>
&gt; list<br>
&gt; &gt; (<a =
href=3D"mailto:[email-masked]">[email-masked]</a>)
in the format described on the RADEXT WG<br>
&gt; Issues<br>
&gt; &gt; list (<a href=3D"http://www.drizzle.com/~aboba/RADEXT/" =
target=3D"_blank">http://www.drizzle.com/~aboba/RADEXT/</a>).<br>
&gt; &gt;<br>
&gt; &gt; If you have read the document and approve of its publication, =
but<br>
&gt; have no<br>
&gt; &gt; comments, please also post this to the list.<br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; to unsubscribe send a message to <a
href=3D"mailto:[email-masked]">[email-masked]=
.org</a>
with<br>
&gt; &gt; the word 'unsubscribe' in a single line as the message text =
body.<br>
&gt; &gt; archive: &lt;<a href=3D"http://psg.com/lists/radiusext/" =
target=3D"_blank">http://psg.com/lists/radiusext/</a>&gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; to unsubscribe send a message to <a
href=3D"mailto:[email-masked]">[email-masked]=
.org</a>
with<br>
&gt; the word 'unsubscribe' in a single line as the message text =
body.<br>
&gt; archive: &lt;<a href=3D"http://psg.com/lists/radiusext/" =
target=3D"_blank">http://psg.com/lists/radiusext/</a>&gt;<br>
<br>
<br>
<br>
--<br>
to unsubscribe send a message to <a =
href=3D"mailto:[email-masked]">[email-masked]=
.org</a>
with<br>
the word 'unsubscribe' in a single line as the message text body.<br>
archive: &lt;<a href=3D"http://psg.com/lists/radiusext/" =
target=3D"_blank">http://psg.com/lists/radiusext/</a>&gt;<o:p></o:p></p>

</div>

</div>

</blockquote>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_0054_01C8FF22.8F31DDC0--

Delivery-date: Fri, 15 Aug 2008 13:45:25 +0000
Date: Fri, 15 Aug 2008 09:44:51 -0400
From: "Greg Weber" <[email-masked]>
To: "Glen Zorn" <[email-masked]>
Subject: Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Cc: "Hannes Tschofenig" <[email-masked]>, [email-masked]

------=_Part_88201_1355597.1218807891739
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Fri, Aug 15, 2008 at 6:10 AM, Glen Zorn <[email-masked]> wrote:

> Hannes Tschofenig <mailto:// [email-masked]> writes:
>
> > Bernard,
> >
> > why is there is a working group last call on this document given that
> > it
> > still has an open issue section giving me the impression that the
> > document is far from being ready?
>
> 1) As you know, the issues list is not an official WG document, but a tool
> for the use of the Chairs & as such its state has no bearing on the status
> of a document.
> 2) All 3 of the issues assigned to the extended attributes document appear
> to actually refer to RFC 5080.

I suspect Hannes was referring to the open issues section in the draft's
text,
not the list maintained by the chairs.  Regarding the latter, the issue that
I
filed (#250) was intended for your -00 draft, not RFC 5080.  I haven't read
your current draft version yet to see if these comments were addressed;
there was no response on the list -that I recall.

Greg

>
>
> >
> > Ciao
> > Hannes
> >
> > Bernard Aboba wrote:
> > > This is a reminder of the RADEXT WG Last Call on "Extended
> > > RADIUS Attributes", prior to requesting that the IESG publish it as a
> > Proposed Standard.
> > >
> > > The document is available here:
> > > http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-
> > attributes-04.txt
> > >
> > > WG Last Call was originally to have completed on August 10, 2008.
> > > However, due to lack of response to the RADEXT WG last call,
> > > we will be extending the WG last call to August 31, 2008.  Please
> > > review the document and post your comments to the RADEXT WG mailing
> > list
> > > ([email-masked]) in the format described on the RADEXT WG
> > Issues
> > > list (http://www.drizzle.com/~aboba/RADEXT/).
> > >
> > > If you have read the document and approve of its publication, but
> > have no
> > > comments, please also post this to the list.
> > >
> > > --

------=_Part_88201_1355597.1218807891739
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Aug 15, 2008 at 6:10 AM, Glen Zorn <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">Hannes Tschofenig &lt;mailto:// <a href="mailto:[email-masked]">[email-masked]</a>&gt; writes:<br>
<br>
&gt; Bernard,<br>
&gt;<br>
&gt; why is there is a working group last call on this document given that<br>
&gt; it<br>
&gt; still has an open issue section giving me the impression that the<br>
&gt; document is far from being ready?<br>
<br>
</div>1) As you know, the issues list is not an official WG document, but a tool<br>
for the use of the Chairs &amp; as such its state has no bearing on the status<br>
of a document.<br>
2) All 3 of the issues assigned to the extended attributes document appear<br>
to actually refer to RFC 5080.</blockquote><div><br></div><div>I suspect Hannes was referring to the open issues section in the draft&#39;s text,</div><div>not the list maintained by the chairs. &nbsp;Regarding the latter, the issue that I</div>
<div>filed (#250) was intended for your -00 draft, not RFC 5080. &nbsp;I haven&#39;t read&nbsp;</div><div>your current draft version yet to see if these comments were addressed;</div><div>there was no response on the list -that I recall. &nbsp;</div>
<div><br></div><div>Greg</div><div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<div><div></div><div class="Wj3C7c"><br>
&gt;<br>
&gt; Ciao<br>
&gt; Hannes<br>
&gt;<br>
&gt; Bernard Aboba wrote:<br>
&gt; &gt; This is a reminder of the RADEXT WG Last Call on &quot;Extended<br>
&gt; &gt; RADIUS Attributes&quot;, prior to requesting that the IESG publish it as a<br>
&gt; Proposed Standard.<br>
&gt; &gt;<br>
&gt; &gt; The document is available here:<br>
&gt; &gt; <a href="http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-" target="_blank">http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-</a><br>
&gt; attributes-04.txt<br>
&gt; &gt;<br>
&gt; &gt; WG Last Call was originally to have completed on August 10, 2008.<br>
&gt; &gt; However, due to lack of response to the RADEXT WG last call,<br>
&gt; &gt; we will be extending the WG last call to August 31, 2008. &nbsp;Please<br>
&gt; &gt; review the document and post your comments to the RADEXT WG mailing<br>
&gt; list<br>
&gt; &gt; (<a href="mailto:[email-masked]">[email-masked]</a>) in the format described on the RADEXT WG<br>
&gt; Issues<br>
&gt; &gt; list (<a href="http://www.drizzle.com/~aboba/RADEXT/" target="_blank">http://www.drizzle.com/~aboba/RADEXT/</a>).<br>
&gt; &gt;<br>
&gt; &gt; If you have read the document and approve of its publication, but<br>
&gt; have no<br>
&gt; &gt; comments, please also post this to the list.<br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; to unsubscribe send a message to <a href="mailto:[email-masked]">[email-masked]</a> with<br>
&gt; &gt; the word &#39;unsubscribe&#39; in a single line as the message text body.<br>
&gt; &gt; archive: &lt;<a href="http://psg.com/lists/radiusext/" target="_blank">http://psg.com/lists/radiusext/</a>&gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; to unsubscribe send a message to <a href="mailto:[email-masked]">[email-masked]</a> with<br>
&gt; the word &#39;unsubscribe&#39; in a single line as the message text body.<br>
&gt; archive: &lt;<a href="http://psg.com/lists/radiusext/" target="_blank">http://psg.com/lists/radiusext/</a>&gt;<br>
<br>
<br>
<br>
--<br>
to unsubscribe send a message to <a href="mailto:[email-masked]">[email-masked]</a> with<br>
the word &#39;unsubscribe&#39; in a single line as the message text body.<br>
archive: &lt;<a href="http://psg.com/lists/radiusext/" target="_blank">http://psg.com/lists/radiusext/</a>&gt;<br>
</div></div></blockquote></div><br></div>

------=_Part_88201_1355597.1218807891739--

Delivery-date: Fri, 15 Aug 2008 12:26:19 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Subject: I-D Action:draft-tiwari-radext-tunnel-type-01.txt (fwd)
Date: Fri, 15 Aug 2008 19:24:23 +0700

Glancing over this:

Since there's only one author, it would be good to move the apostrophe in
"Authors'" left.  

In the table in Section 3, move the abbreviation (ESP) next to "Payload".

Since new values of the Tunnel-Type Attribute are allocated by IETF
Consensus, it might be a better idea to separate this into 2 docs, one for
the ESP value & the other for the proprietary one.  In fact, because the
spec for the Microsoft Secure Socket Tunneling Protocol is public & appears
fairly stable, I would prefer that the allocation be part of an
Informational RFC describing the protocol.  At the very least, though, the
name needs to be changed to "Microsoft's Secure Socket Tunneling Protocol"
(or something similar) that identifies its proprietary nature.

Delivery-date: Fri, 15 Aug 2008 10:11:59 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Hannes Tschofenig'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Fri, 15 Aug 2008 17:10:33 +0700

Hannes Tschofenig <mailto:// [email-masked]> writes:

> Bernard,
> 
> why is there is a working group last call on this document given that
> it
> still has an open issue section giving me the impression that the
> document is far from being ready?

1) As you know, the issues list is not an official WG document, but a tool
for the use of the Chairs & as such its state has no bearing on the status
of a document.
2) All 3 of the issues assigned to the extended attributes document appear
to actually refer to RFC 5080.

> 
> Ciao
> Hannes
> 
> Bernard Aboba wrote:
> > This is a reminder of the RADEXT WG Last Call on "Extended
> > RADIUS Attributes", prior to requesting that the IESG publish it as a
> Proposed Standard.
> >
> > The document is available here:
> > http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-
> attributes-04.txt
> >
> > WG Last Call was originally to have completed on August 10, 2008.
> > However, due to lack of response to the RADEXT WG last call,
> > we will be extending the WG last call to August 31, 2008.  Please
> > review the document and post your comments to the RADEXT WG mailing
> list
> > ([email-masked]) in the format described on the RADEXT WG
> Issues
> > list (http://www.drizzle.com/~aboba/RADEXT/).
> >
> > If you have read the document and approve of its publication, but
> have no
> > comments, please also post this to the list.
> >
> > --

Delivery-date: Fri, 15 Aug 2008 08:55:45 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
Subject: Comments  on "Crypto-Agility Requirements for RADIUS"
Date: Fri, 15 Aug 2008 15:53:55 +0700

Questions:

The WG Charter states that all of the existing crypto-agility proposals are
to be published as Experimental RFCs.  In that case, how can the requirement
that " at least one mandatory to implement algorithm will be defined"
(section 1.2) be fulfilled?

Editorial comments:

Front page header:
Since the source of the document is stated in section 1.1 to be the radext
WG, David's role should probably be "Editor".

Section 1.2:
s/propose one of more Internet Drafts/propose one or more Internet-Drafts/

Section 2:
s/Crypto-Agility is the ability for/Crypto-agility is the ability of/

Section 4.5, paragraph 5 states:

   Editorial Note: With the expected acceptance of the proposed RADEXT
   WG Charter revision, some of the issues raised in the preceding
   paragraphs become moot, and this section ought to be revised to
   reflect the revised charter.

Haven't those charter revisions already taken place?

Technical comments:

Section 2, paragraph 2 states:

   In the specific context of the RADIUS protocol and RADIUS
   implementations, crypto-agility may be better defined as the ability
   of RADIUS implementations to negotiate cryptographic algorithms for
   use in RADIUS exchanges, including the cryptographic algorithms used
   to protect RADIUS packets and to hide RADIUS Attributes.  This
   capability covers all RADIUS message types: Access-Request/Response,
   Accounting-Request/Response, and CoA/Disconnect-Request/Response.

Since RADIUS has no negotiation method of I'm aware (hint & accept/ignore is
hardly a negotiation mechanism) I find these statements very curious,
especially in light of the earlier statement (section 2, paragraph 3) that
the password-hiding function will be negotiable.  Basically, what is being
called for is impossible in the context of the RADIUS protocol, implying
that the negotiations would take place outside of RADIUS (e.g., in TLS).  I
think that it is at least inappropriate in a requirements document, in that
it assumes a solution.

Section 4.1: 
Once again, assuming a solution.  State the requirements that a solution
must meet, not your personal assumptions about the form which the solution
will take.  I say "personal" because a fair subset of the active WG (of
which this document is purportedly a product) _does not_ share the
expectation that " proposals will utilize other techniques".

Section 4.2, paragraph 2 states:

   Included in negotiation techniques are "hint and consent" mechanisms
   where the NAS provides a list of algorithms and the server selects
   one.

If the server is required to select from the list it can hardly be called a
hint.  Once again, I can't see at all how this mechanism could be made to
work in the case of the Access-Request message.

Section 4.3, paragraph 1 states:

   Solutions to the problem MUST demonstrate backward compatibility with
   existing RADIUS implementations.  

I would _really_ like to see some rationale for this requirement (aside from
"backward compatibility is sacred and must never be questioned" ;-).  Given
that this is new and presumably desirable functionality, why is a simple
upgrade path not sufficient?

Section 4.5, paragraph 3 states:

   Crypto-agility solutions SHOULD NOT require fundamental changes to
   the RADIUS operational model, such as the introduction of new
   commands or maintenance of state on the RADIUS server.  

OK, I'll bite: how, exactly, does the introduction of a new command
fundamentally change the RADIUS operational model?

Delivery-date: Fri, 15 Aug 2008 06:51:06 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>
Cc: "'Alan DeKok'" <[email-masked]>, <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Fri, 15 Aug 2008 13:49:14 +0700

David B. Nelson <mailto:// [email-masked]> writes:

> Alan DeKok writes...
> 
> >   Inserting *other* attributes in between a fragemented attribute
> > is annoying and pointless.  It's better to forbid this, and to
> > declare that packets failing this test are malformed, and SHOULD
> > be silently discarded.
> 
> I think this would introduce a new, non-backwards-compatible
> requirement.
> Today, RADIUS requires that attributes of the same type not be re-
> ordered in
> the PDU, e.g. by proxies. There is no such requirement for attributes
> of
> differing types.

I believe that he meant that all fragments of a given attribute must be
contiguous in the original packet...

> 
> >   What does "Foo(0,4)" mean?
> 
> I suppose it means the TLV with Type Code 4, assigned within the IETF
> allocation, i.e. Attribute 26, Vendor-ID 0.

This would be a perfectly reasonable interpretation, but it actually means
"octets 0-4 of attribute Foo".

...

Delivery-date: Thu, 14 Aug 2008 20:05:07 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS"
Date: Thu, 14 Aug 2008 13:04:34 -0700
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

I have read the draft and for the most part it looks good.

I have a few comments:

1. Section 4.2:

In cases where the client needs to protect all or part of the radius
request the "hint and select" negotiation the client would provide more
than a hint when it chooses the algorithms for protection.  Perhaps hint
and select is not quite the right term, may be specify and select?  The
client specifies what it uses and can specify a list it supports that
the server can use.=20

2. Section 4.6:

Section 4.6 makes reference to security considerations text about key
management.  Shouldn't this text be in this document?

Thanks,

Joe

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Wednesday, August 13, 2008 7:06 PM
> To: [email-masked]
> Subject: REMINDER: RADEXT WG Last Call on "Crypto-Agility=20
> Requirements for RADIUS"
>=20
> This is a reminder of the ongoing RADEXT WG Last Call on=20
> "Crypto-Agility Requirements for RADIUS" prior to requesting=20
> that the IESG publish it as an Informational RFC.=20
> =20
> The document is available here:
>
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-req
uirements-00.txt
> =20
> WG Last Call was to have lasted until August 10, 2008.   Since there=20
> have been no comments posted yet, we will extend the last=20
> call for another two weeks (until August 31, 2008).  Please=20
> review the document and post your comments to the RADEXT WG=20
> mailing list
> ([email-masked]) in the format described on the=20
> RADEXT WG Issues=20
> list (http://www.drizzle.com/~aboba/RADEXT/).  =20
> =20
> If you have read the document and approve of its publication,=20
> but have no comments, please also post this to the list.=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
>=20

Delivery-date: Thu, 14 Aug 2008 20:05:01 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS"
Date: Thu, 14 Aug 2008 13:04:34 -0700
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

I have read the draft and for the most part it looks good.

I have a few comments:

1. Section 4.2:

In cases where the client needs to protect all or part of the radius
request the "hint and select" negotiation the client would provide more
than a hint when it chooses the algorithms for protection.  Perhaps hint
and select is not quite the right term, may be specify and select?  The
client specifies what it uses and can specify a list it supports that
the server can use.=20

2. Section 4.6:

Section 4.6 makes reference to security considerations text about key
management.  Shouldn't this text be in this document?

Thanks,

Joe

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Wednesday, August 13, 2008 7:06 PM
> To: [email-masked]
> Subject: REMINDER: RADEXT WG Last Call on "Crypto-Agility=20
> Requirements for RADIUS"
>=20
> This is a reminder of the ongoing RADEXT WG Last Call on=20
> "Crypto-Agility Requirements for RADIUS" prior to requesting=20
> that the IESG publish it as an Informational RFC.=20
> =20
> The document is available here:
>
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-req
uirements-00.txt
> =20
> WG Last Call was to have lasted until August 10, 2008.   Since there=20
> have been no comments posted yet, we will extend the last=20
> call for another two weeks (until August 31, 2008).  Please=20
> review the document and post your comments to the RADEXT WG=20
> mailing list
> ([email-masked]) in the format described on the=20
> RADEXT WG Issues=20
> list (http://www.drizzle.com/~aboba/RADEXT/).  =20
> =20
> If you have read the document and approve of its publication,=20
> but have no comments, please also post this to the list.=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
>=20

Delivery-date: Thu, 14 Aug 2008 19:47:42 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Thu, 14 Aug 2008 15:47:23 -0400
Organization: Elbrys Networks, Inc.

> > Yes, we do.  I can cite numerous examples.
> 
>   Where?

Section 7.1 of RFC 2865.  Section 2.1 of RFC 3580.  Section 2.2 of RFC 5176.
Section 2.1.1 of RFC 5080.  Section 6 of RFC 5090.

This is not an exhaustive list, but rather a sampling.

Delivery-date: Thu, 14 Aug 2008 19:27:50 +0000
Date: Thu, 14 Aug 2008 21:26:52 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'Stefan Winter' <[email-masked]>, [email-masked]
Subject: Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

Glen Zorn wrote:
>> Alan's wording "The More Flag MUST NOT be set if the Length is less
>> than
>> 255." sounds good to me.
> 
> My point was that making these kinds of rules is pointless: if someone wants
> to split "Hello" into 5 separate attributes they either have a very good
> reason to do so that none of us can foresee or they will soon be finding
> gainful employment in a different field.  In any case, it's not possible to
> protect people from their own stupidity (besides, they could still do it
> with tags).

  It's only one sentence.  And it will stop the stupid people from
afflicting everyone else.

  RFC 2865 has comments saying:

      The secret MUST NOT be empty (length 0) since this would allow
      packets to be trivially forged.

  Which were inserted because of real-world exposure to implementations
having *no* configuration for shared secrets. (i.e. they were always NUL).

  Alan DeKok.

Delivery-date: Thu, 14 Aug 2008 19:24:57 +0000
Date: Thu, 14 Aug 2008 21:23:32 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: [email-masked]
Subject: Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

David B. Nelson wrote:
> I think this would introduce a new, non-backwards-compatible requirement.
> Today, RADIUS requires that attributes of the same type not be re-ordered in
> the PDU, e.g. by proxies. There is no such requirement for attributes of
> differing types.

  That's not *quite* what I meant.

  What I meant was interspersing attributes of disparate types.  I'm not
aware of any implementation that does this (e.g. for EAP-Message).  But
I've learned to be paranoid about RADIUS specifications.

>>   What does "Foo(0,4)" mean?
> 
> I suppose it means the TLV with Type Code 4, assigned within the IETF
> allocation, i.e. Attribute 26, Vendor-ID 0.

  Nope.  Read the rest of the doc.  It means "octets 0 through 4 of
attribute Foo".

> There is a long-standing typographical tradition of listing attributes as
> Attribute-Name (##).

  References?

[ struct ]
>>   What syntax is this?
> 
> Pseudo-code?  Maybe actually using ANSI C would be more universal.  I think
> the RADIUS data types are not a good way to express this concept, as
> witnessed by confusion in various drafts over the years. 

  I'm just asking for a definition of the terminology and concepts
referred to in the draft.  What's an "Integer", or a "String"?  Do these
relate to C definitions?  RADIUS?

> How is that different from good coding guidelines for *any* implementation
> of *any* protocol?  What about the on-the-wire protocol involved raises
> these risks?

  Er... nothing.

>> 9.  Open Issues
>>
>>    What is the numbering scheme for attributes that will be used by RFC
>>    writers going forward?  For example today we write user-name(1).
>>
>>   Uh... We do?
> 
> Yes, we do.  I can cite numerous examples.

  Where?

  Alan DeKok.

Delivery-date: Thu, 14 Aug 2008 17:37:08 +0000
Date: Thu, 14 Aug 2008 20:36:58 +0300
From: Hannes Tschofenig <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

Bernard,

why is there is a working group last call on this document given that it 
still has an open issue section giving me the impression that the 
document is far from being ready?

Ciao
Hannes

Bernard Aboba wrote:
> This is a reminder of the RADEXT WG Last Call on "Extended 
> RADIUS Attributes", prior to requesting that the IESG publish it as a Proposed Standard. 
>  
> The document is available here:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt
>  
> WG Last Call was originally to have completed on August 10, 2008.   
> However, due to lack of response to the RADEXT WG last call, 
> we will be extending the WG last call to August 31, 2008.  Please 
> review the document and post your comments to the RADEXT WG mailing list 
> ([email-masked]) in the format described on the RADEXT WG Issues 
> list (http://www.drizzle.com/~aboba/RADEXT/).   
>  
> If you have read the document and approve of its publication, but have no
> comments, please also post this to the list. 
>
> --

Delivery-date: Thu, 14 Aug 2008 17:35:05 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Stefan Winter'" <[email-masked]>
Cc: <[email-masked]>, "'Romascanu, Dan \(Dan\)'" <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Fri, 15 Aug 2008 00:33:40 +0700

Stefan Winter [mailto:[email-masked]] writes:

> Hi,
>=20
> >> Maybe just put a note like "If you are a total moron, stop
> >> reading now." in the Abstract?
> >>
> >
> > There certainly should be some other ways to say it.
> >
>=20
> Alan's wording "The More Flag MUST NOT be set if the Length is less
> than
> 255." sounds good to me.

My point was that making these kinds of rules is pointless: if someone =
wants
to split "Hello" into 5 separate attributes they either have a very good
reason to do so that none of us can foresee or they will soon be finding
gainful employment in a different field.  In any case, it's not possible =
to
protect people from their own stupidity (besides, they could still do it
with tags).

>=20
> Stefan
>=20
>=20
> --
>=20
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education =
Nationale et
> de la Recherche
> 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
>=20
> Tel: +352 424409 1
> Fax: +352 422473

Delivery-date: Thu, 14 Aug 2008 17:28:37 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'Alan DeKok'" <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Thu, 14 Aug 2008 13:27:42 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

>   Inserting *other* attributes in between a fragemented attribute
> is annoying and pointless.  It's better to forbid this, and to 
> declare that packets failing this test are malformed, and SHOULD
> be silently discarded.

I think this would introduce a new, non-backwards-compatible requirement.
Today, RADIUS requires that attributes of the same type not be re-ordered in
the PDU, e.g. by proxies. There is no such requirement for attributes of
differing types.

>   What does "Foo(0,4)" mean?

I suppose it means the TLV with Type Code 4, assigned within the IETF
allocation, i.e. Attribute 26, Vendor-ID 0.

Why not just refer to it as "Foo"?

There is a long-standing typographical tradition of listing attributes as
Attribute-Name (##).

>    Consider the following structure:
> 
>      struct
>        Integer a;
>        String  b;
>        Integer c;
>      endStruct
> 
>   What syntax is this?

Pseudo-code?  Maybe actually using ANSI C would be more universal.  I think
the RADIUS data types are not a good way to express this concept, as
witnessed by confusion in various drafts over the years. 

>   Reading the rest of the example, I find the b(4,5) syntax very
> awkward.

I think that's part of Glen's [potential] issue.

> 7.  Security Considerations
> 
>    I suggest adding a note that a new attribute encoding is an
> opportunity for buffer overflows, inadequate checks, etc. 
> Implementors SHOULD take care to validate the lengths, etc. 
> before decoding the contents of the attributes.

How is that different from good coding guidelines for *any* implementation
of *any* protocol?  What about the on-the-wire protocol involved raises
these risks?

> 9.  Open Issues
> 
>    What is the numbering scheme for attributes that will be used by RFC
>    writers going forward?  For example today we write user-name(1).
> 
>   Uh... We do?

Yes, we do.  I can cite numerous examples.

Delivery-date: Thu, 14 Aug 2008 11:41:34 +0000
Date: Thu, 14 Aug 2008 13:40:56 +0200
From: Stefan Winter <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
CC: Glen Zorn <[email-masked]>, [email-masked]
Subject: Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

Hi,

>> Maybe just put a note like "If you are a total moron, stop 
>> reading now." in the Abstract?
>>     
>
> There certainly should be some other ways to say it. 
>   

Alan's wording "The More Flag MUST NOT be set if the Length is less than 
255." sounds good to me.

Stefan

-- 

Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

Delivery-date: Thu, 14 Aug 2008 11:33:30 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Thu, 14 Aug 2008 13:32:59 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Glen Zorn" <[email-masked]>, "Stefan Winter" <[email-masked]>
Cc: <[email-masked]>

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Glen Zorn
> Sent: Thursday, August 14, 2008 2:10 PM
> To: 'Stefan Winter'
> Cc: [email-masked]
> Subject: RE: REMINDER: RADEXT WG Last call on "Extended=20
> RADIUS Attributes"
>=20
> Stefan Winter <mailto://[email-masked]> writes:
>=20

...

> > There also is no clarification whether fragmenting should=20
> only occur=20
> > when it is needed. Without requiring this, a compliant=20
> implementation=20
> > could as well split the 5-byte data "Hello" into five fragments. I=20
> > suggest to add a bit of wording to strongly discourage that.
>=20
> Maybe just put a note like "If you are a total moron, stop=20
> reading now." in the Abstract?
>=20
> ...

There certainly should be some other ways to say it.=20

Dan

Delivery-date: Thu, 14 Aug 2008 11:28:15 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: no overall type in Extended Attributes
Date: Thu, 14 Aug 2008 18:26:49 +0700

Delivery-date: Thu, 14 Aug 2008 11:11:21 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Stefan Winter'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Date: Thu, 14 Aug 2008 18:10:19 +0700

Stefan Winter <mailto://[email-masked]> writes:

> Hello,
> 
> a few comments:
> 
> TLV encoding and M flag: All examples stuff the maximum payload into
> the first fragment, set the M bit and put the remainder into the next
> fragment. This is fine and sensible, but not enforced in the
> description.
> One might also do any other split of the data, like if there is a 300
> byte data to be transmitted, 150 in the first fragment, 150 in the
> second.
> There also is no clarification whether fragmenting should only occur
> when it is needed. Without requiring this, a compliant implementation
> could as well split the 5-byte data "Hello" into five fragments. I
> suggest to add a bit of wording to strongly discourage that.

Maybe just put a note like "If you are a total moron, stop reading now." in
the Abstract?

...

> Finally, Security Considerations: This section is rather short, I
> suggest to expand the "TBD" :-)

Text is welcome.

...

Delivery-date: Thu, 14 Aug 2008 10:40:50 +0000
Date: Thu, 14 Aug 2008 12:39:28 +0200
From: Alan DeKok <[email-masked]>
To: [email-masked]
Subject: Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

Stefan Winter wrote:
> One might also do any other split of the data, like if there is a 300
> byte data to be transmitted, 150 in the first fragment, 150 in the second.
> There also is no clarification whether fragmenting should only occur
> when it is needed. Without requiring this, a compliant implementation
> could as well split the 5-byte data "Hello" into five fragments. I
> suggest to add a bit of wording to strongly discourage that.

  I would say:

  The More Flag MUST NOT be set if the Length is less than 255.

> - is it worth mentioning that this encoding is not the only one
> possible, since the order of the struct members doesn't need to be
> preserved during marshalling?

  Yes.  Attributes don't have order in RADIUS.

  Alan DeKok.

Delivery-date: Thu, 14 Aug 2008 10:07:56 +0000
Date: Thu, 14 Aug 2008 12:07:35 +0200
From: Stefan Winter <[email-masked]>
To: [email-masked]
Subject: Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

 > A corrected figure is below:

Oh well. Add a line-break at the obvious place.

Stefan

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

Delivery-date: Thu, 14 Aug 2008 09:56:55 +0000
Date: Thu, 14 Aug 2008 11:56:39 +0200
From: Stefan Winter <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

Hello,

a few comments:

TLV encoding and M flag: All examples stuff the maximum payload into the first fragment, set the M bit and put the remainder into the next fragment. This is fine and sensible, but not enforced in the description.
One might also do any other split of the data, like if there is a 300 byte data to be transmitted, 150 in the first fragment, 150 in the second.
There also is no clarification whether fragmenting should only occur when it is needed. Without requiring this, a compliant implementation could as well split the 5-byte data "Hello" into five fragments. I suggest to add a bit of wording to strongly discourage that.

TLV encoding rules: Ext-Length field misses its unit ... (in octets)...

Example in Figure 3: VSA Length. 7 + 9 = 16, not 15.

Figure 4: 

- is it worth mentioning that this encoding is not the only one possible, since the order of the struct members doesn't need to be preserved during marshalling? 

- There is a one-off in the encoding of String b. b is 251 octets, i.e. comprised of b[0] thru b[250].
The first fragment can (correct in the figure) hold up to 245 characters, i.e b[0] thru b[244]. Six(!) characters remain, b[245] thru b[250]. The encoding of the second fragment needs to be changed for a TLV data length of 6, which also changes Ext-Length to 3 + 6 = 9 and VSA-Length to 7 + 9 + 7 = 23. The byte-order of the last integer is odd, it looks like the last two bytes are swapped. This is neither big- not little-endian, and I suspect it's an error.
A corrected figure is below:

                        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 (26)   |    Length     |          Vendor-Id
   |               |  (7+9+7=23)   |             (0)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-Id (cont)        |M|    Tag      |    Ext-Type
                 (0)               |0|    (42)     |      (0)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Ext-Type (cont)|   Ext-Length  |     Value     |               |
         (259)     |   (3 + 6 = 9) |      (e)      |      ( )      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |               |               |    
   |      (e)      |      (n)      |      (d)      |      (.)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Ext-Type (cont) Ext-type (cont)|   Ext-Length  |               |
         (0)             (271)     |   (3 + 4 = 7) |    (0x12)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |               |               |
   |    (0x34)     |     (0x56)    |     (0x78)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Some nitbits: 

- Intro: "101 or so have been". Or so sound a bit colloquial.
- first example: "Extended-Type *of* 257 by IANA." ( not 0f)

Finally, Security Considerations: This section is rather short, I suggest to expand the "TBD" :-)

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

Delivery-date: Thu, 14 Aug 2008 09:29:58 +0000
Date: Thu, 14 Aug 2008 11:28:01 +0200
From: Alan DeKok <[email-masked]>
To: [email-masked]
Subject: Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

Bernard Aboba wrote:
> This is a reminder of the RADEXT WG Last Call on "Extended 
> RADIUS Attributes", prior to requesting that the IESG publish it as a Proposed Standard. 

Submitter name: Alan DeKok
Submitter email address: [email-masked]
Date first submitted: Aug 14 2008
Reference:
Document: [EXTEN]
Comment type: T
Priority: 2

Section 4:
...
   o  The final octet of the header contains the More flag and Tag
      field.  If the one bit More flag is set (1) this indicates that
      the encapsulated TLV is continued in the following Extended
      Attribute; if the More flag is clear (0) then all of the
      encapsulated TLVs fit into the current Extended Attribute.  The
      More flag MUST NOT be set if the Extended Attribute contains more
      than one TLV.

  To be clear: this means that the Extended-Attribute can encapsulate
multiple TLV's if they're short, or only one TLV if it's long.

Section 5:

   M (More)

      The More Flag is one (1) bit in length and MUST be present.  When
      a value to be transmitted exceeds 246 octets in length it is
      fragmented over two or more Extended Attributes.  If the More Flag
      is set (1), this indicates that the Value field of the Extended
      Attribute contains a fragment of a larger value, which is
      continued in the next Extended Attribute of the same Ext-Type.

  Can we add a MUST?  i.e. If the More Flag is set, the next attribute
MUST be an Extended-Attribute of the same Extended-Type.

  Inserting *other* attributes in between a fragemented attribute is
annoying and pointless.  It's better to forbid this, and to declare that
packets failing this test are malformed, and SHOULD be silently discarded.

   Ext-Type

      Two (2) octets.  Up-to-date values of the Ext-Type field are
      specified in the most recent "Assigned Numbers" [IANA].  Values
      XXXX-YYYY are reserved.

  I would suggest reserving the top 1K: 64512-65535

6.  Examples

   Consider an attribute called Foo of type String.  Foo has been
   allocated an Extended-Type 0f 257 by IANA.  The following figure
   shows the encoding of Foo(0,4) = "Hello":

  What does "Foo(0,4)" mean?  This is the first reference in that
document to that attribute naming scheme.  (I presume it's an attribute
naming scheme).  Why not just refer to it as "Foo"?

  The diagram also has Ext-Type (16 bits) of 257 split between two bytes
(8 bits) of 0 and 257.  I welcome the novel ability to count to 257 in
an 8-bit field, but perhaps this could be corrected. :)

  The examples should use numbers from the reserved space (i.e. 64512),
and not from the IANA allocated space (257).  The examples also use the
attribute name "Foo" multiple times.  It should instead use unique names.

   Figure 2 below
   illustrates the encoding of the first 7 octets of the first Extended
   Attribute (Foo(0,6) = "Hello W"), while Figure 3 shows how the second
   attribute (Foo(246,250) = "e end.") is encoded.

  Hmm... So Foo(N,M) is a reference to the fragments?  I don't see why
this is necessary.  We don't do it for EAP-Message.  I would suggest
just referring to it as "Foo", and "the first fragment (octets 0 through
245)", and "the second fragment (octets 246 through 250).

...
   Consider the following structure:

     struct
       Integer a;
       String  b;
       Integer c;
     endStruct

  What syntax is this?  I think I understand it, but I'm not sure
everyone will come to a shared understanding.  Maybe instead the example
can be given by reference to existing RADIUS data types.  e.g. A
structure of RADIUS data types (integer, text, integer) would previously
have to be encoded as three separate and independent attributes.  Here,
it can be encoded as 3 attributes sharing a common tag.

  Reading the rest of the example, I find the b(4,5) syntax very
awkward.  I suggest discarding it, and just referring to the diagrams.

  The examples could also given broken-out hex encoding of the
attributes, which may be clearer than the ASCII art diagrams.  e.g.

  1a 0f 00 00 00 00 00 01 01 08 48 65 6c 6c 6f

7.  Security Considerations

   I suggest adding a note that a new attribute encoding is an
opportunity for buffer overflows, inadequate checks, etc.  Implementors
SHOULD take care to validate the lengths, etc. before decoding the
contents of the attributes.

8.  IANA Considerations
...
   It also requires that IANA set up a new registry for the RADIUS
   Extended Attribute Types.

  I suggest leaving the first 0..255 attributes as unallocated, in order
to avoid confusion with legacy RADIUS attributes.

9.  Open Issues

   What is the numbering scheme for attributes that will be used by RFC
   writers going forward?  For example today we write user-name(1).

  Uh... We do?  I've never seen that in an RFC.  I suggest deleting this
section entirely.

  Alan DeKok.

Delivery-date: Thu, 14 Aug 2008 02:20:00 +0000
Date: Wed, 13 Aug 2008 19:19:07 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: no overall type in Extended Attributes

Glen Zorn said:

4.4.  Grouped AVP Values

      name             = name-fmt

      avpcode          = 1*DIGIT

      vendor           = 1*DIGIT

      Session-Id =

      Session-Id =

           0       1       2       3       4       5       6       7

Delivery-date: Thu, 14 Aug 2008 02:09:45 +0000
Date: Wed, 13 Aug 2008 19:08:57 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Subject: I-D Action:draft-tiwari-radext-tunnel-type-01.txt (fwd)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : New Tunnel-Type Values
	Author(s)       : A. Tiwari
	Filename        : draft-tiwari-radext-tunnel-type-01.txt
	Pages           : 6
	Date            : 2008-08-10

This document defines a set of values for the Tunnel-Type RADIUS
Attribute.

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

<ftp://ftp.ietf.org/internet-drafts/draft-tiwari-radext-tunnel-type-01.txt>

Delivery-date: Thu, 14 Aug 2008 02:07:34 +0000
Date: Wed, 13 Aug 2008 19:06:49 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: Request for Minutes, Slides

If you took minutes at the RADEXT WG meeting at IETF 72, please send them 
to me ([email-masked]) and/or Dave Nelson. 

Also, if you presented and did not send slides, please do so. 

Delivery-date: Thu, 14 Aug 2008 02:07:27 +0000
Date: Wed, 13 Aug 2008 19:06:24 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

This is a reminder of the RADEXT WG Last Call on "Extended 
RADIUS Attributes", prior to requesting that the IESG publish it as a Proposed Standard. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt
 
WG Last Call was originally to have completed on August 10, 2008.   
However, due to lack of response to the RADEXT WG last call, 
we will be extending the WG last call to August 31, 2008.  Please 
review the document and post your comments to the RADEXT WG mailing list 
([email-masked]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 

Delivery-date: Thu, 14 Aug 2008 02:07:19 +0000
Date: Wed, 13 Aug 2008 19:05:48 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS"

This is a reminder of the ongoing RADEXT WG Last Call on "Crypto-Agility 
Requirements for RADIUS" prior to requesting that the IESG publish it as 
an Informational RFC. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-00.txt
 
WG Last Call was to have lasted until August 10, 2008.   Since there 
have been no comments posted yet, we will extend the last call for 
another two weeks (until August 31, 2008).  Please 
review the document and post your comments to the RADEXT WG mailing list 
([email-masked]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 

Delivery-date: Tue, 12 Aug 2008 13:58:48 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: no overall type in Extended Attributes
Date: Tue, 12 Aug 2008 20:55:50 +0700

David B. Nelson <mailto://[email-masked]>  writes:

> Glen Zorn writes...
> 
> > ...the current definition of the Extended Attributes
> > doesn't in general allow the definition of an overall type for the
> > unordered set of TLVs.
> In other words, the Extended Attribute is a "super attribute" or
> "wrapper
> attribute" that contains other "attributes", 

In other words, the Extended Attributes have the same qualities as RFC 2865
VSAs.

> which you refer to as
> "TLVs",
> to distinguish them from standalone attributes.
> 
> The issue is that one cannot "name" any particular group of aggregated
> TLVs.

I wouldn't call it an "issue" -- whether it's an issue is what is to be
determined.  It is a characteristic.

> One solution is to simply add a Group-Name TLV to the Extended
> Attribute.
> I'm not sure that addresses the intended use, however.  I suspect that
> the
> use is to "call up" a pre-defined grouping by name.

I don't know what use it would actually be, outside of making discussions of
the protocol a little easier.  It certainly doesn't modify the operation of
the protocol.

> 
> I think I'd like to see some "real-world" examples of use cases
> discussed
> here before I would want to attempt to make a decision on whether this
> is a
> serious issue or not.
> 
> 
> 
> --

Delivery-date: Tue, 12 Aug 2008 12:41:26 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: no overall type in Extended Attributes
Date: Tue, 12 Aug 2008 08:40:18 -0400

Glen Zorn writes...

> ...the current definition of the Extended Attributes
> doesn't in general allow the definition of an overall type for the
> unordered set of TLVs.

In other words, the Extended Attribute is a "super attribute" or "wrapper
attribute" that contains other "attributes", which you refer to as "TLVs",
to distinguish them from standalone attributes.

The issue is that one cannot "name" any particular group of aggregated TLVs.
One solution is to simply add a Group-Name TLV to the Extended Attribute.
I'm not sure that addresses the intended use, however.  I suspect that the
use is to "call up" a pre-defined grouping by name.

I think I'd like to see some "real-world" examples of use cases discussed
here before I would want to attempt to make a decision on whether this is a
serious issue or not.

Delivery-date: Tue, 12 Aug 2008 11:45:16 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>
Subject: no overall type in Extended Attributes
Date: Tue, 12 Aug 2008 18:42:28 +0700

As I mentioned a couple of times at the Dublin session, the current
definition of the Extended Attributes 
(http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-0
4.txt) doesn't in general allow the definition of an overall type for the
Attribute in question:  an Extended Attribute is basically just an unordered
set of TLVs.  This fact doesn't bother me much, if at all, but the second
time I mentioned it there was some grumbling from the crowd, so I thought
I'd bring it up one more time on the list...

Delivery-date: Sun, 10 Aug 2008 12:30:19 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Request for NAS-Port-Type Allocation
Date: Sun, 10 Aug 2008 08:29:20 -0400

Glen Zorn writes...

> In fact, it may fall apart at 35, since a NAS-Port-Type was
> assigned for PHS (AKA PIAFS) in RFC 2865...

And your point is that Next Generation PHS is not sufficiently
differentiated from PHS?  I think I might agree, on the general principle
that "next generation" is always relative, and what do you call the sequel?

So you've made a concrete and useful contribution to expert review.
Congratulations!

We should probably request that IANA list this entry as "PHS-MOU" and not
"Next Generation PHS".

As long as the nomenclature is unambiguous and there is some reference to a
specification, standards forum, corporation or individual that can be
contacted by anyone who really wants to know "What is this port type,
exactly?", I think it's fine.

Delivery-date: Sun, 10 Aug 2008 11:16:03 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Request for NAS-Port-Type Allocation
Date: Sun, 10 Aug 2008 18:12:55 +0700

David B. Nelson writes:

> Glen Zorn writes...
> 
> > ...the difference between uranium-238 and u-235 certainly seems
> > subtle to me (what's a couple of neutrons between friends? ;-)
> > but is certainly not subtle to a modern physicist...
> 
> Sure.  However, if you need U-238, and get mislabeled U-235 by mistake,
> you
> may not be satisfied.
> 
> > I wonder how many other people on this list did?
> 
> I did.
> 
> > In fact, I'm still not sure what, exactly, makes it unique enough
> > to require a separate number but (given that there are 3,999,999,965
> > of them left) I really don't care.
> 
> Would you care if, say a million of so of them were all assigned for
> "IEEE
> Wireless"?  I'd find that horribly confusing.  All I'm looking for is
> enough
> review to make sure that the naming is sufficiently clear such that
> "caveat
> emptor" can reasonably apply.  

Since we're tripping the light fantastic here, the expert review process
falls apart with more than a few entries anyway (if there were only a
million port types it would take more than a month to _scan_ them @ 1/sec.,
8 hrs./day).  In fact, it may fall apart at 35, since a NAS-Port-Type was
assigned for PHS (AKA PIAFS) in RFC 2865...

...

Delivery-date: Sat, 09 Aug 2008 18:24:54 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Request for NAS-Port-Type Allocation
Date: Sat, 9 Aug 2008 14:23:33 -0400

Glen Zorn writes...

> ...the difference between uranium-238 and u-235 certainly seems
> subtle to me (what's a couple of neutrons between friends? ;-)
> but is certainly not subtle to a modern physicist...

Sure.  However, if you need U-238, and get mislabeled U-235 by mistake, you
may not be satisfied.

> I wonder how many other people on this list did?

I did.

> In fact, I'm still not sure what, exactly, makes it unique enough
> to require a separate number but (given that there are 3,999,999,965
> of them left) I really don't care.

Would you care if, say a million of so of them were all assigned for "IEEE
Wireless"?  I'd find that horribly confusing.  All I'm looking for is enough
review to make sure that the naming is sufficiently clear such that "caveat
emptor" can reasonably apply.  Truth/accuracy in labeling.  If folks want to
get assignments for their "secret sauce" specialized flavors of ports, I
agree, there is no scarcity issue.  I think there is an accuracy of
nomenclature issue.  I don't think it's fair to require IANA to make that
judgment.

Delivery-date: Sat, 09 Aug 2008 10:06:32 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Request for NAS-Port-Type Allocation
Date: Sat, 9 Aug 2008 17:03:40 +0700

David B. Nelson <mailto://[email-masked]> writes:

> Glen Zorn writes...
> 
> > I forgot: what is the rationale behind such careful rationing
> > of the 4 billion (!) NAS-Port-Type values again?
> 
> I don't think the value is in rationing.  As you point out, it's not an
> overly scarce resource.  I think the value is in maintaining a decent
> signal-to-noise ratio in the IANA registry.  Given that there are 4
> billion
> possible values, 

Micro-managing the namespace is a waste of time.

> it's preferable to avoid duplicates or nearly-
> duplicates
> with ambiguously subtle distinctions.

The level of distinction that is considered to be subtle tends to vary both
with the state of the art & the expertise of the observer: the difference
between uranium-238 and u-235 certainly seems subtle to me (what's a couple
of neutrons between friends? ;-) but is certainly not subtle to a modern
physicist & even less so to a maker of atomic bombs.  My point is that,
because NAS-Port-Type values generally represent L2 protocols, it is
somewhat likely that IETF "experts" will lack the expertise to make these
kinds of decisions in the exotic cases anyway.  The current request is a
case in point: I will admit that I had no idea what PHS was (let alone
PHS-MoU) until I went off to the Web site to check.  I wonder how many other
people on this list did?  In fact, I'm still not sure what, exactly, makes
it unique enough to require a separate number but (given that there are
3,999,999,965 of them left) I really don't care.

...

Delivery-date: Fri, 08 Aug 2008 19:11:48 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Request for NAS-Port-Type Allocation
Date: Fri, 8 Aug 2008 15:09:57 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...

> I forgot: what is the rationale behind such careful rationing
> of the 4 billion (!) NAS-Port-Type values again?

I don't think the value is in rationing.  As you point out, it's not an
overly scarce resource.  I think the value is in maintaining a decent
signal-to-noise ratio in the IANA registry.  Given that there are 4 billion
possible values, it's preferable to avoid duplicates or nearly-duplicates
with ambiguously subtle distinctions.

Delivery-date: Fri, 08 Aug 2008 14:17:36 +0000
Date: Fri, 8 Aug 2008 11:16:16 -0300
From: "Claudio Lapidus" <[email-masked]>
To: "Glen Zorn" <[email-masked]>, "Bernard Aboba" <[email-masked]>,  [email-masked]
Subject: Re: Request for NAS-Port-Type Allocation

On Fri, Aug 8, 2008 at 2:16 AM, Glen Zorn <[email-masked]> wrote:
> what is the
> rationale behind such careful rationing of the 4 billion (!) NAS-Port-Type
> values again?

Hmm, perhaps is it that every new value will need to be properly
understood by all existing implementations, which in turn will need to
be retrofitted to handle it?

regards,
cl.

Delivery-date: Fri, 08 Aug 2008 05:18:33 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Request for NAS-Port-Type Allocation
Date: Fri, 8 Aug 2008 12:16:33 +0700

Bernard Aboba <mailto://[email-masked]> writes:

> The IANA has received a request for a new NAS-Port-Type allocation.  As
> stated in RFC 3575, Section 2.1:
> 
>    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.
> 
> Are there any objections to granting the allocation as requested below?

My only objection is to being bothered with it ;-).  I forgot: what is the
rationale behind such careful rationing of the 4 billion (!) NAS-Port-Type
values again?

...

Delivery-date: Sun, 03 Aug 2008 15:28:48 +0000
From: Avi Lior <[email-masked]>
To: Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sun, 3 Aug 2008 11:27:02 -0400
Subject: RE: Request for NAS-Port-Type Allocation
Accept-Language: en-US
acceptlanguage: en-US

Looks fine to me as well.

________________________________________
From: [email-masked] [[email-masked]] On Behalf=
 Of Bernard Aboba [[email-masked]]
Sent: Friday, August 01, 2008 4:14 AM
To: [email-masked]
Subject: Request for NAS-Port-Type Allocation

The IANA has received a request for a new NAS-Port-Type allocation.  As
stated in RFC 3575, Section 2.1:

   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.

Are there any objections to granting the allocation as requested below?

Contact Name :
Tomohiro Ichida

Contact Email :
[email-masked]

Type of Assignment :
I request the allocation of new NAS-Port-TYPE.

http://www.iana.org/assignments/radius-types
Values for RADIUS Attribute 61, NAS-Port-Type [RFC2865]:

Registry :
The value is "Wireless - XGP"

Description :
There is a standardization organization as PHS-MOU.
We'd like to prescribe the new number in NAS-PORT-TYPE.
And We'd like to use its number by the next generation PHS system.
it is same as "Wireless - CDMA2000","Wireless - IEEE 802.16"

PHS-MOU is explained as follows this URL
 http://www.phsmou.org/

Additional Info :
 The "Next Generation PHS" specification is is being made.
 A document is not open to the public,sorry.

Delivery-date: Fri, 01 Aug 2008 12:40:58 +0000
Content-class: urn:content-classes:message
Subject: RE: [dhcwg] draft-lourdelet-radext-ipv6-dhcp-00 published
Date: Fri, 1 Aug 2008 14:40:03 +0200
From: "Benoit Lourdelet (blourdel)" <[email-masked]>
To: "Ralph Droms (rdroms)" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

FYI,

This individual work will be included in a revision of RFC3162 that Glen
Zorn and I are going to work on.

Regards

Benoit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ralph Droms (rdroms)
Sent: Wednesday, July 30, 2008 4:23 PM
To: [email-masked]; [email-masked]
Subject: Re: [dhcwg] draft-lourdelet-radext-ipv6-dhcp-00 published

Correction.  On a link with no router advertisements you need to
configure any addresses and prefixes manually and separately.

There is no expectation that the prefix from an assigned address is
necessarily on the link.  On-link prefixes are independent from assigned
addresses.

- Ralph

On Jul 30, 2008, at 8:01 AM, Hemant Singh (shemant) wrote:
>> What about the scenario where there is no router in the network or=20
>> not
> announcing router advertisement with prefix options? What length of=20
> prefix the >DHCPv6 client should use for address assignment?
>
>> Best Regards,
>> 	Janos
>
>
>
> There is no provision in DHCPv6 to include prefix length in a message=20
> to the client - I have said so several times to the DHCPv6 mailer. =20
> Check the email archives.  In a router-less network, you are hosed. =20
> You have to configure an address and prefix length manually.
>
> Hemant

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

Delivery-date: Fri, 01 Aug 2008 11:22:54 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Request for NAS-Port-Type Allocation
Date: Fri, 1 Aug 2008 07:21:47 -0400

Bernard Aboba writes...

> Are there any objections to granting the allocation as requested below?

None from me.

Delivery-date: Fri, 01 Aug 2008 08:36:38 +0000
Date: Fri, 01 Aug 2008 10:35:02 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: Request for NAS-Port-Type Allocation

Bernard Aboba wrote:
> Are there any objections to granting the allocation as requested below?

  It looks fine to me.

  Alan DeKok.

Delivery-date: Fri, 01 Aug 2008 08:15:58 +0000
Date: Fri, 1 Aug 2008 01:14:29 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Request for NAS-Port-Type Allocation

The IANA has received a request for a new NAS-Port-Type allocation.  As 
stated in RFC 3575, Section 2.1:

   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.

Are there any objections to granting the allocation as requested below?

Contact Name :
Tomohiro Ichida

Contact Email :
[email-masked]

Type of Assignment :
I request the allocation of new NAS-Port-TYPE.

http://www.iana.org/assignments/radius-types
Values for RADIUS Attribute 61, NAS-Port-Type [RFC2865]:

Registry :
The value is "Wireless - XGP"

Description :
There is a standardization organization as PHS-MOU.
We'd like to prescribe the new number in NAS-PORT-TYPE.
And We'd like to use its number by the next generation PHS system.
it is same as "Wireless - CDMA2000","Wireless - IEEE 802.16"

PHS-MOU is explained as follows this URL
 http://www.phsmou.org/

Additional Info :
 The "Next Generation PHS" specification is is being made.
 A document is not open to the public,sorry.