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

From: Glen Zorn <[email-masked]>
Date: Wed, 1 Sep 1999 14:45:47 -0700 (PDT)

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! :-)
 
> 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!

> 
> ---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.

> ---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.

> -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!
> 
> 
>

---

From: Ronnie Ekstein <[email-masked]>
Date: Thu, 09 Sep 1999 16:15:19 +0200

> 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.

> those drafts have _been_ drafts, I'm not holding my breath till they are

agree

> 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...

> 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