Re: RADIUS keywrap attributes

[Jari Arkko <jari.arkko@piuha.net>]

Re: charter prohibition on new security mechanisms. I tend to agree
with David on this. While we do not want to develop (say) RADIUS-over-TLS,
addressing the security issues in specific attributes is within scope,
if those attributes themselves on the charter.

Re: draft-zorn vs. draft-aboba. I think that from a 10.000 ft perspective
these are really the same thing, just different in details and have
some different deployment impacts. Perhaps we can leave the
choice between them until we've decided if we need this work
to begin with.

Re: IESG expectations, charter constraints, NIST requirements:
I think its pretty obvious that we are dealing with several
sets of different types of requirements, not all of
which always match the real world out there. For instance,
I think the Diameter redirect scheme is pretty good, but its
very likely that most or even all usage is going to be through
proxies, just as we already do today. But having this scheme
at least made it possible to publish an IETF RFC, and even
the non-redirect usage of Diameter EAP is much better than
the vendor specific attributes that most people use today.
I think it would be useful to ask ourselves if we can make
a similar positive step, not necessarily reaching all goals
but improving what we have today. At the end of the day,
that's what matters. So, I have some questions:

 o   Do we believe we have an issue in the existing usage?
      (I think we do)

 o   Do we have a clear target for this work?
      (Yes we do, wireless LANs.)

 o   Does it fit our overall plan for the system that we
      want to provide?
      (Yes, its the missing part in the network access
      authentication system.)

 o   If we do something, will that actually be deployed
      by a significant number of users, or are we using it
      just as an checkbox item to pass through IESG/IEEE/
      NIST/unsuspecting customer?
      (Here I think we need more input...)

 o   Do we expect to find a solution that can reasonably
      be expected to fit existing networks without a lot
      of additional effort from vendors/network managers?
      (I don't know, but this is crucial in order to make
      a real impact.)

 o   Do we have the manpower/expertise to do this?
      (You tell me.)

--Jari


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>