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

From: Ronnie Ekstein <[email-masked]>
Date: Wed, 15 Sep 1999 09:43:47 +0200

Glen Zorn wrote:

> On Tue, 31 Aug 1999, MegaZone wrote:
>
> > ---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".
>
> True (and it's even in RFC 2138! :-)

ooops, indeed this is right, but still 2 remarks:
1. Eventhough the Vendor-Specific attribute exists, some vendors still
(also) use
the 'normal'
space of attributes and create their own dictionary of attributes.
2. The use of Vendor-extensions in DIAMETER also allows for Vendor
Specific
messages.

> > 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.
>
> Well...it might be more effective, but it wouldn't reflect the actual
> status of the protocols in the IETF, right?  Given the length of time
> those drafts have _been_ drafts, I'm not holding my breath till they
are
> RFCs!

agree

>
> >
> > ---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.
> >
>
> True, but again, the Signature attribute isn't "official" RADIUS.
>

again, agree, we will see to put some more -draft- status information in
the next
version to show the fuller picture...

>
> > ---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.
> >
>
> Actually, I don't think that either of these are actually protected
_by
> RADIUS_: they are scrambled up, but RADIUS doesn't do the scrambling,
CHAP
> and ARAP do.  So strictly speaking, I think that the draft is accurate
in
> saying that they are send (sic) in cleartext.
>

Agree again with Glenn on this.

thanks a lot for the review, your input is appreciated,
we'll update the draft soon...

Regards,

Ronnie, Yves

---

From: "Beadles, Mark A." <[email-masked]>
Date: Wed, 15 Sep 1999 14:13:36 -0400

From: Ronnie Ekstein [mailto:[email-masked]] 
specific
>> >       extensibility.
>> > ---cut---
>> >
>> > That is an error.  RADIUS most certainly does - the attribute is called
>> > "Vendor-Specific".
>>
(also) use
>space of attributes and create their own dictionary of attributes.

Although there are vendors that do this, they do so in absolute
noncompliance with RADIUS as described in the RFC's.  Nothing prevents
vendors from doing the same thing in COPS or DIAMETER - it's just a bad
idea, and we shouldn't base a protocol review (IMHO) on the bad practices of
those who choose to ignore the protocol standard.

+ Mark Anthony Beadles +  UUNET Product Development  + 
+  [email-masked]   + http://networking.us.uu.net +
+  Voice 614.723.1941  +       Fax 614.723.8407      +