Subject: Issue status update

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 10 Sep 2008 15:55:44 -0700

In going through the open Issues posted on the RADEXT Issues list
(http://www.drizzle.com/~aboba/RADEXT) I was unclear about the status of the
following issues. Can the document authors provide an update on whether the
issues are open, pending or closed? 

Extended Attributes 

Issue Number

Status

Type

Description

Owner

Issue 225

Pending

Technical

Review <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 225> 

Alan DeKok <mailto:[email-masked]> 

Issue 250

Pending

Technical

Comments <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 250> 

Greg Weber <mailto:[email-masked]> 

Issue 251

Pending

Technical

Review <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 251> 

Bernard Aboba <mailto:[email-masked]> 

Issue 272

Pending

Technical

No <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 272>  overall
type in Extended Attributes

Glen Zorn <mailto:[email-masked]> 

RADIUS Crypto-Agility Requirements

Issue Number

Status

Type

Description

Owner

Issue 274

Pending

Technical

Review <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 274> 

Joe Salowey <mailto:[email-masked]> 

Issue 275

Pending

Technical

Comments <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 275> 

Glen Zorn <mailto:[email-masked]>

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 11 Sep 2008 11:24:37 -0400

Bernard Aboba writes...

> In going through the open Issues posted on the RADEXT 
> Issues list (http://www.drizzle.com/~aboba/RADEXT) 
> I was unclear about the status of the following issues.
> 

In think we are waiting form some suggested text that Joe Salowey offered to
draft, regarding key management references and security considerations.

There is also a basic issue with the use of the existing RADIUS "hint"
mechanism to implement some rudimentary form of capability advertisement.

While I'm sympathetic to the limitations of this mechanism, unless the WG
thinks we should expand the charter scope to create a more robust form of
capabilities negotiation, I think it would be a mistake to add that as a
requirement for crypto-agility.   In short, I suggest we reject these
comment.

--
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: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 12 Sep 2008 10:44:31 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David B. Nelson
> Sent: Thursday, September 11, 2008 8:25 AM
> To: [email-masked]
> Subject: RE: Issue status update
> 
> Bernard Aboba writes...
> 
> > (http://www.drizzle.com/~aboba/RADEXT)
> In think we are waiting form some suggested text that Joe 
> Salowey offered to draft, regarding key management references 
> and security considerations.
> 
[Joe] Thanks for the reminder.  

> While I'm sympathetic to the limitations of this mechanism, 
> unless the WG thinks we should expand the charter scope to 
> create a more robust form of capabilities negotiation, I 
> think it would be a mistake to add that as a
[Joe] I think most of the comments relating to the negotiation were that
the term "hint and consent" does not represent what is possible in
RADIUS.  I don't think there was desire to change the behavior, just to
have the definition reflect the reality of the situation. 

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

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 12 Sep 2008 20:36:47 -0700

> > mechanism to implement some rudimentary form of capability

I don't remember any discussion of capability advertisement.

> > requirement for crypto-agility.   

>From the newly updated charter: "This work item will include documentation
of RADIUS crypto-agility requirements,
as well as development of one or more Experimental RFCs providing support
for negotiation of alternative cryptographic algorithms to protect RADIUS."
So, are you saying that it's OK for negotiation to be part of the work item,
but not the requirements? 

> In short, I suggest we reject these
> > comment.
> >

As I mentioned before, unless the radext Chairs intend to unilaterally
redefine the English word "negotiation", something needs to change.  There
is no hinting involved in an Access-Request regarding e.g. the protection
method used with a modern analog of the User-Password Attribute, only a
statement of what was done.  If the server can't decrypt an attribute it
finds in an Access-Request, what does it do (apparently some folks seem to
think that issuing an Access-Reject is just fine in this case, without any
indication of the reason for the failure, on the grounds that "that's what
we have" (?!)).  In any case, there doesn't exist a definition of
"negotiation" of which I'm aware that doesn't include discussion (meaning >1
message).

...