Vendor-Specific attribute with rlm_rest

classic Classic list List threaded Threaded
15 messages Options
| Threaded
Open this post in threaded view
|

Vendor-Specific attribute with rlm_rest

Michael A Carpenter - macarpen@us.ibm.com
I'm trying to return the Vendor-Specific attribute with value "H=4,I=4" using the rlm_rest module. I've tried the following authorization response payloads:

{"Attr-26": "0x483d342c493d34"}

{"Vendor-Specific": "H=4,I=4"}

Both resulted in error:

(0) aaa-api: Processing response header
(0) aaa-api:   Status : 200 (OK)
(0) aaa-api:   Type   : json (application/json)
(0) aaa-api: Parsing attribute "Attr-26"
(0) aaa-api: EXPAND 0x483d342c493d34
(0) aaa-api:    --> 0x483d342c493d34
(0) aaa-api: WARNING: Incompatible value assignment for attribute "Vendor-Specific", skipping...

(1) aaa-api: Processing response header
(1) aaa-api:   Status : 200 (OK)
(1) aaa-api:   Type   : json (application/json)
(1) aaa-api: Parsing attribute "Vendor-Specific"
(1) aaa-api: EXPAND H=4,I=4
(1) aaa-api:    --> H=4,I=4
(1) aaa-api: WARNING: Incompatible value assignment for attribute "Vendor-Specific", skipping...

Any suggestions for what might be incompatible about the value?

# radiusd -v
radiusd: FreeRADIUS Version 3.0.20, for host x86_64-alpine-linux-musl, built on Apr 20 2020 at 16:30:06

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Vendor-Specific attribute with rlm_rest

Bjørn Mork
"Michael A Carpenter - [hidden email]" <[hidden email]>
writes:

> I'm trying to return the Vendor-Specific attribute with value "H=4,I=4" using the rlm_rest module. I've tried the following authorization response payloads:
>
> {"Attr-26": "0x483d342c493d34"}
>
> {"Vendor-Specific": "H=4,I=4"}
>
> Both resulted in error:
>
> (0) aaa-api: Processing response header
> (0) aaa-api:   Status : 200 (OK)
> (0) aaa-api:   Type   : json (application/json)
> (0) aaa-api: Parsing attribute "Attr-26"
> (0) aaa-api: EXPAND 0x483d342c493d34
> (0) aaa-api:    --> 0x483d342c493d34
> (0) aaa-api: WARNING: Incompatible value assignment for attribute "Vendor-Specific", skipping...
>
> (1) aaa-api: Processing response header
> (1) aaa-api:   Status : 200 (OK)
> (1) aaa-api:   Type   : json (application/json)
> (1) aaa-api: Parsing attribute "Vendor-Specific"
> (1) aaa-api: EXPAND H=4,I=4
> (1) aaa-api:    --> H=4,I=4
> (1) aaa-api: WARNING: Incompatible value assignment for attribute "Vendor-Specific", skipping...
>
> Any suggestions for what might be incompatible about the value?

It must be prefixed with a type, length and enterprise number.  See
https://tools.ietf.org/html/rfc2865#section-5.26



Bjørn

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Vendor-Specific attribute with rlm_rest

Bjørn Mork
Bjørn Mork <[hidden email]> writes:

> "Michael A Carpenter - [hidden email]" <[hidden email]>
> writes:
>
>> I'm trying to return the Vendor-Specific attribute with value "H=4,I=4" using the rlm_rest module. I've tried the following authorization response payloads:
>>
>> {"Attr-26": "0x483d342c493d34"}
>>
>> {"Vendor-Specific": "H=4,I=4"}
>>
>> Both resulted in error:
>>
>> (0) aaa-api: Processing response header
>> (0) aaa-api:   Status : 200 (OK)
>> (0) aaa-api:   Type   : json (application/json)
>> (0) aaa-api: Parsing attribute "Attr-26"
>> (0) aaa-api: EXPAND 0x483d342c493d34
>> (0) aaa-api:    --> 0x483d342c493d34
>> (0) aaa-api: WARNING: Incompatible value assignment for attribute "Vendor-Specific", skipping...
>>
>> (1) aaa-api: Processing response header
>> (1) aaa-api:   Status : 200 (OK)
>> (1) aaa-api:   Type   : json (application/json)
>> (1) aaa-api: Parsing attribute "Vendor-Specific"
>> (1) aaa-api: EXPAND H=4,I=4
>> (1) aaa-api:    --> H=4,I=4
>> (1) aaa-api: WARNING: Incompatible value assignment for attribute "Vendor-Specific", skipping...
>>
>> Any suggestions for what might be incompatible about the value?
>
> It must be prefixed with a type, length and enterprise number.  See
> https://tools.ietf.org/html/rfc2865#section-5.26

Sorry, that's wrong.  It should be enterprise number, vendor type,
vendor length.


Bjørn

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Vendor-Specific attribute with rlm_rest

Alan DeKok-2
In reply to this post by Michael A Carpenter - macarpen@us.ibm.com

> On May 7, 2020, at 2:17 PM, Michael A Carpenter - [hidden email] <[hidden email]> wrote:
>
> I'm trying to return the Vendor-Specific attribute with value "H=4,I=4" using the rlm_rest module. I've tried the following authorization response payloads:
>
> {"Attr-26": "0x483d342c493d34"}
>
> {"Vendor-Specific": "H=4,I=4"}
>
> Both resulted in error:

  Please don't do that.  It's terrible.  If you need that in order to interoperate with an idiot vendor, fine.  But if you're doing something yourself, this is 1000% the wrong thing to do.

  You *cannot* and *should not* specify values for the Vendor-Specific attribute.  That attribute does not have values like other attributes.  Instead, it carries a 32-bit vendor number, followed by encapsulated vendor attributes.

 So... why are you doing this?

> Any suggestions for what might be incompatible about the value?

  It fails to follow the RFCs.  See

https://tools.ietf.org/html/rfc8044#section-3.14

  Which defines the "vsa" data type, for the Vendor-Specific attribute.

  As the author of that specification, I feel uniquely qualified to say that your usage of Vendor-Specific is wrong. :)

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Vendor-Specific attribute with rlm_rest

Michael A Carpenter - macarpen@us.ibm.com


On May 7, 2020, at 2:45 PM, Alan DeKok <[hidden email]<mailto:[hidden email]>> wrote:


On May 7, 2020, at 2:17 PM, Michael A Carpenter - [hidden email]<mailto:[hidden email]> <[hidden email]<mailto:[hidden email]>> wrote:

I'm trying to return the Vendor-Specific attribute with value "H=4,I=4" using the rlm_rest module. I've tried the following authorization response payloads:

{"Attr-26": "0x483d342c493d34"}

{"Vendor-Specific": "H=4,I=4"}

Both resulted in error:

 Please don't do that.  It's terrible.  If you need that in order to interoperate with an idiot vendor, fine.  But if you're doing something yourself, this is 1000% the wrong thing to do.

The former, vendor is SuperMicro


 You *cannot* and *should not* specify values for the Vendor-Specific attribute.  That attribute does not have values like other attributes.  Instead, it carries a 32-bit vendor number, followed by encapsulated vendor attributes.

So... why are you doing this?

I arrived at those values based on http://lists.freeradius.org/pipermail/freeradius-users/2017-November/089770.html and https://www.supermicro.com/support/faqs/faq.cfm?faq=22374


Any suggestions for what might be incompatible about the value?

 It fails to follow the RFCs.  See

https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8044-23section-2D3.14&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=OI48QQPIMZYKrUbG21FK_VAb6BR2rxkULb952GKjKYI&m=fIq6zgM93RvSIzpzsIi7vNOmXqFH5wJxnVK6JvguSFw&s=-9g8SQJuMKtaktXW5rjyrj4jSB0k75uC1EAfZOizIzs&e=

 Which defines the "vsa" data type, for the Vendor-Specific attribute.

 As the author of that specification, I feel uniquely qualified to say that your usage of Vendor-Specific is wrong. :)

No argument here :)


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Vendor-Specific attribute with rlm_rest

Alan DeKok-2

On May 7, 2020, at 4:42 PM, Michael A Carpenter - [hidden email] <[hidden email]> wrote:
> The former, vendor is SuperMicro
> ..
> I arrived at those values based on http://lists.freeradius.org/pipermail/freeradius-users/2017-November/089770.html and https://www.supermicro.com/support/faqs/faq.cfm?faq=22374

  Arg.  I hate this kind of nonsense.  It's not like the specs have been *perfectly clear* since 1996 or so.  :(

  The server should support "Attr-26 := 0x483d342c493d34".

  Which version are you running?

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Vendor-Specific attribute with rlm_rest

Michael A Carpenter - macarpen@us.ibm.com

 Which version are you running?

# radiusd -v
radiusd: FreeRADIUS Version 3.0.20, for host x86_64-alpine-linux-musl, built on Apr 20 2020 at 16:30:06

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Vendor-Specific attribute with rlm_rest

Alan DeKok-2
On May 7, 2020, at 4:58 PM, Michael A Carpenter - [hidden email] <[hidden email]> wrote:
>
>
> Which version are you running?
>
> # radiusd -v
> radiusd: FreeRADIUS Version 3.0.20, for host x86_64-alpine-linux-musl, built on Apr 20 2020 at 16:30:06

  Hmm... are you sure you didn't add 'Attr-26' to the dictionaries?  Because from my reading of the rlm_rest code, it calls:

                RDEBUG2("Parsing attribute \"%s\"", name);
                attribute = name;
                ..
                da = dict_attrbyname(attribute);
                if (!da) {
                        RWDEBUG("Attribute \"%s\" unknown, skipping", attribute);
                        curl_free(name);
                        continue;
                }

  And the dict_attrbyname() function looks up the *exact* name in the dictionaries.  It doesn't convert "Attr-26" to "Vendor-Specific".

  So using "Attr-26" *should* result in a message of: Attribute "Attr-26" unknown, skipping

  If that happens, it should be relatively easy to update rlm_rest to allow "Attr-26", and parse it's value as a hex string.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Vendor-Specific attribute with rlm_rest

Michael A Carpenter - macarpen@us.ibm.com

>  Hmm... are you sure you didn't add 'Attr-26' to the dictionaries?  Because from my reading of the rlm_rest code, it calls:

Dictionaries are all at defaults

/ # grep Attr-26 /usr/share/freeradius/dictionary* /etc/raddb/dictionary
/ #



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Vendor-Specific attribute with rlm_rest

Alan DeKok-2
On May 7, 2020, at 5:33 PM, Michael A Carpenter - [hidden email] <[hidden email]> wrote:
>
>> Hmm... are you sure you didn't add 'Attr-26' to the dictionaries?  Because from my reading of the rlm_rest code, it calls:
>
> Dictionaries are all at defaults

  OK.  I'll have to take a deeper look into it.  I think it can be fixed without too much effort.  I just don't want to break anything else.

  I spent some time trying to find workarounds, and it looks hard.  :(  The "users" file allows "Attr-26 := 0x...".  But the "unlang" parser doesn't allow that.  The reasons are esoteric and a bit hard to fix.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Vendor-Specific attribute with rlm_rest

Michael A Carpenter - macarpen@us.ibm.com

>  OK.  I'll have to take a deeper look into it.  I think it can be fixed without too much effort.  I just don't want to break anything else.
>
>  I spent some time trying to find workarounds, and it looks hard.  :(  The "users" file allows "Attr-26 := 0x...".  But the "unlang" parser doesn't allow that.  The reasons are esoteric and a bit hard to fix.

Thanks for taking a look. Would you prefer I created a GitHub issue to track it?


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Vendor-Specific attribute with rlm_rest

Alan DeKok-2
On May 7, 2020, at 6:15 PM, Michael A Carpenter - [hidden email] <[hidden email]> wrote:
> Thanks for taking a look. Would you prefer I created a GitHub issue to track it?

  Yeah, that's good.  Thanks.

  The good news is that v4 supports this, at least in "unlang".  I don't think it's supported in rlm_rest, tho.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Vendor-Specific attribute with rlm_rest

Matthew Newton-3
On 07/05/2020 23:21, Alan DeKok wrote:
> On May 7, 2020, at 6:15 PM, Michael A Carpenter - [hidden email] <[hidden email]> wrote:
>> Thanks for taking a look. Would you prefer I created a GitHub issue to track it?
>
>    Yeah, that's good.  Thanks.
>
>    The good news is that v4 supports this, at least in "unlang".  I don't think it's supported in rlm_rest, tho.

Completely hideous, but this works:

users:

DEFAULT
         Attr-26 := "%{Tmp-String-1}",
         Fall-Through := Yes

bob     Cleartext-Password := "test"



sites-enabled/default:

authorize {
...
        update request {
          &Tmp-String-1 := "H=4,I=4"
        }

        files
...

}


$ radtest bob test 127.0.0.1 0 testing123
Sent Access-Request Id 170 from 0.0.0.0:53229 to 127.0.0.1:1812 length 73
        User-Name = "bob"
        User-Password = "test"
...
Received Access-Accept Id 170 from 127.0.0.1:1812 to 127.0.0.1:53229
length 29
        Attr-26 = 0x483d342c493d34
$
$ echo "483d342c493d34" | xxd -r -ps
H=4,I=4


--
Matthew
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Vendor-Specific attribute with rlm_rest

Michael A Carpenter - macarpen@us.ibm.com
In reply to this post by Alan DeKok-2

Thanks for taking a look. Would you prefer I created a GitHub issue to track it?

 Yeah, that's good.  Thanks.

https://github.com/FreeRADIUS/freeradius-server/issues/3438

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Vendor-Specific attribute with rlm_rest

Bjørn Mork
In reply to this post by Alan DeKok-2
Alan DeKok <[hidden email]> writes:

> On May 7, 2020, at 4:42 PM, Michael A Carpenter - [hidden email] <[hidden email]> wrote:
>> The former, vendor is SuperMicro
>> ..
>> I arrived at those values based on http://lists.freeradius.org/pipermail/freeradius-users/2017-November/089770.html and https://www.supermicro.com/support/faqs/faq.cfm?faq=22374
>
>   Arg.  I hate this kind of nonsense.  It's not like the specs have been *perfectly clear* since 1996 or so.  :(

One might consider nonsense docs a feature when it comes to IPMI :)

The faq should probably link to this video instead:
https://www.youtube.com/watch?v=GZeUntdObCA

It goes into far more details on IPMI user-authentication than the
SuperMicro manual, so it is almost on-topic here.  And it will probably
make you reconsider whether RADIUS authentication is worth it at all in
this case.

There is also a nice transcript at https://lwn.net/Articles/630778/ But
I recommend spending the time to view Matthew's presentation.  With some
popcorn.  He is really entertaining, as usual.


Bjørn


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html