|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>, <krbdev@mit.edu> From: Greg Hudson <ghudson@mit.edu> Message-ID: <5da4e962-5b2e-cd2d-5e10-cdbd5d90fbbd@mit.edu> Date: Tue, 18 Feb 2020 13:40:44 -0500 MIME-Version: 1.0 In-Reply-To: <202002180220.01I2Kckx032149@hedwig.cmf.nrl.navy.mil> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: krbdev-bounces@mit.edu On 2/17/20 9:20 PM, Ken Hornstein wrote: > 3) Setting of the TKT_FLG_HW_AUTH flag in the TGT if the certificate had > had some specific policies. I thought of two ways to retrofit this capability with a low code footprint: 1. Designate a magic error code for the certauth authorize() method. The code would mean "yes the cert is authorized for this client, and also please set the hw-authent ticket flag". 2. Designate a magic authentication indicator value (probably "hwauth"). In the core KDC code near the end of AS-REQ processing, check if this indicator is asserted and set the hw-authent bit. The second approach fits with the notion that the hw-authent bit is a legacy special case of auth indicators, and it covers any interface which can assert auth indicators (certauth, kdcpreauth, KDB sign_authdata()). However, it does make an inroad into the auth indicator namespace, which is currently entirely site-defined. Also, tickets issued this way would be slightly larger than tickets issued with just the hw-authent bit set, since they would also contain the authorization data asserting the auth indicator. _______________________________________________ krbdev mailing list krbdev@mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |