Option for multiple PA-ETYPE-INFO(2)-ENTRY (old behaviour)

[Dameon Wagner]

On Fri, Nov 18 2016 at 14:23:16 -0500, Greg Hudson wrote
 in "Re: Option for multiple PA-ETYPE-INFO(2)-ENTRY (old behaviour)":
> On 11/18/2016 02:08 PM, Greg Hudson wrote:
> > Unfortunately, neither backporting the 1.14 tgt rekeying fixes nor
> > forward-porting the 1.13 pa-etype-info2 behavior is likely to be
> > easy, so I can't offer a solution better than the ones you've
> > already determined.
> 
> Actually, you could try reintroducing commit
> 18b02f3e839c007fff54fc9b693f479b7563ec73 to the 1.14 KDC.  That's a
> pretty simple change, and I think it should work.  (We reverted it
> because we found a more correct fix for the kinit -k issue we had
> run into.)
> 
> https://github.com/krb5/krb5/commit/18b02f3e839c007fff54fc9b693f479b7563ec73

And later on Fri, Nov 18 2016 at 18:06:29 -0500, Greg Hudson wrote
 in "Re: Option for multiple PA-ETYPE-INFO(2)-ENTRY (old behaviour)":
> I thought of another possible workaround that doesn't involve code
> changes to 1.14, which is to do (in kadmin):
>
>   setstr krbtgt/REALM session_enctypes "aes256-cts aes128-cts"
>
> I have opened http://krbdev.mit.edu/rt/Ticket/Display.html?id=8167
> for this issue, and we may introduce a KDC workaround in the future,
> along the lines of the patch I suggested in the last message.

Many thanks Greg, I've just had a look through
http://krbdev.mit.edu/rt/Ticket/Display.html?id=8519 (I think 8167 was
a typo?) and it's referenced tickets, and I think you've captured
exactly what I was trying to say, but more correctly.

Thanks for pointing out the possibility of using set_string -- it's
not something I've needed to use in the past, but I've often noticed
it in the manpage and mentally noted to look into it more "when free
time turns up"...

We're definitely going to give the setstr approach some testing, as
with our current plans it'll only be needed in the short term, so it's
preferable to back-porting code changes and then having to wean
ourselves off them at a later date (by which time they're hopefully
unnecessary).

Again, many thanks.  I'll post again after some testing so as to
update the thread.

Cheers.

Dameon.

-- 
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
Dr. Dameon Wagner, Systems Development and Support
IT Services, University of Oxford
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><