Subject: (radius) 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

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.