Detect MSCHAPv2 inner-tunnel state

[Gary Gwin]

Hi Matthew,

Using the session-state list worked, thanks! Here's what I did. In the
inner-tunnel authorize section:

        eap {
                ok = return
        }

        update request {
                &Tmp-String-2 := &outer.session-state:Tmp-String-2
        }

        rlm_my_module

        update {
                &outer.session-state:Tmp-String-2 := &config:NT-Password
        }

I inspect Tmp-String-2 in rlm_my_module and, if populated, do not call the
API to get the NT hash again. I noticed, however, the following in the
post-auth section:

(9)   post-auth {
(9)     update {
(9)       &reply::Tmp-String-2 += &session-state:Tmp-String-2[*] ->
'0x3143394634423634423245394643353832433234464232444145463636393732'
(9)     } # update = noop

Any concerns or suggestions?

Thanks again,

Gary

On Sat, Sep 22, 2018 at 12:32 PM Matthew Newton <mcn at freeradius.org> wrote:

> On 22 September 2018 18:23:00 BST, Gary Gwin <garygwin at gmail.com> wrote:
> >During the chatty inner-tunnel MSCHAPv2 negotiation, the get NT hash
> >API is
> >invoked twice in requests 7 and 8, which works, but with unnecessary
> >script
> >and API load. I can eliminate the second invocation in step 8 by
> >checking
> >the request EAP-Message for length. That feels fragile. There must be a
> >better way to detect state to determine we're in request 8.
>
> Put the hash in the session-state list, but only if it's not already there?
>
>
> --
> Matthew
>