Subject: nasreq draft-ekstein-roamops-protcomp-00.txt

From: Ronnie Ekstein <[email-masked]>
Date: Tue, 31 Aug 1999 16:52:35 +0200

The I-D is now available at :
ftp://ftp.ietf.org/internet-drafts/draft-ekstein-roamops-protcomp-00.txt
or
http://www.ietf.org/internet-drafts/draft-ekstein-roamops-protcomp-00.txt

Kind regards,

Ronnie Ekstein

Ronnie Ekstein wrote:

> hi *,
>
> we have recently submitted draft-ekstein-roamops-protcomp-00.txt. The
> draft gives a protocol comparison between the RADIUS, DIAMETER and COPS
> protocols. Although it has been submitted to the roamops group, we think
>
> it is of relevance too for nasreq and aaa WG.
>
> We would be happy to receive improvements/comments on this document.
>
> Abstract
> --------
>
> Although RADIUS, DIAMETER and COPS all serve the purpose of distributing
>
> (some subfunctions of) the AAA service, there are many differences
> between these protocols.
>
> These differences (based on the protocol operation) are briefly compared
>
> with their possible implications on the functionality or applicability
> of the protocol.
>
> Comparison is based upon :
> - the relative support of authentication, authorization, accounting and
> transport of configuration information
> - the extensibility in terms of messages and attributes
> - the support of unsolicited messages
> - the reliability in operation
> - the scalability
> - the way they provide security, both on a hop-by-hop and end-to-end
> basis (in proxy situations)
>
> The draft further discusses the compliance of the RADIUS, DIAMETER and
> COPS protocols to the requirements for the provisioning of "roaming
> capability" for dialup Internet users outlined in RFC 2477.
>  
>
> This is at large 'work in progress' and we solicit any input that might
> help us to improve the quality of the draft.
>
> Kind regards,
>
> Ronnie Ekstein
> Yves T'Joens
> Bernard Sales

---

From: MegaZone <[email-masked]>
Date: Tue, 31 Aug 1999 17:35:22 -0700 (PDT)

---cut---
      Neither  RADIUS  nor  COPS  support  explicitly  vendor   specific
      extensibility.
---cut---

That is an error.  RADIUS most certainly does - the attribute is called
"Vendor-Specific".  I think this document would be more effective if it
took into account the drafts that enhance and extend RFCs 2138/2139 as
there is a lot of capability not in those two RFCs but that does exist
and is in common use today.

---cut---
      A RADIUS client and server maintain between them a shared  secret.
      A  RADIUS  server can authenticate the clients request only if the
      shared secret has been used in the context of password  hiding.  A
      User-Password  attribute  is  the plain-text user password encoded
      with the MD5 digest of the octet stream consisting of  the  shared
      secret  and  the  Authenticator. If the User-Password attribute is
      not available, no other  explicit  authentication  information  is
      available within the request.
---cut---

This is also no longer the case.  The more recent revisions to RADIUS
talk to this point and there are other items to use in place of the
User-Password.  You mention Signature later in your draft.

---cut---
      RADIUS only provides for hiding of  the  User-Password  attribute.
      Other attributes are send in cleartext
---cut---

ARAP-Password, CHAP-Password (this is off the top of my head, so I may
be slightly off on the names), etc, are also protected if used.

-MZ, CISSP #3762
-- 
<URL:mailto:[email-masked]> Gweep, Discordian, Author, Engineer, me..
Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
"A little nonsense now and then, is relished by the wisest men" 781-788-0130
<URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!