Subject: Re: [Ietf-krb-wg] IETF70 Vancouver: call for agenda items

From: Shawn M Emery <[email-masked]>
Date: Tue, 06 Nov 2007 22:01:03 -0700

Larry Zhu wrote:
> IETF 70 is coming up, and it is time to start putting together an agenda.
>
> If anyone has specific items they'd like to discuss, now would be a good time to mention them.
>   

I would like to propose a topic for discussion on the issues with long 
running processes and delayed execution in relation to credential 
expiry.  Some solutions to this problem would involve standards work.  
Specifically principal nomencalture and authorization.

The problem:

There is no provision in a Kerberos environment where users make use of 
delayed execution such that they need credentials to access applications 
like secure NFS with Kerberos authentication.  There are number of hacks 
that I've seen that pose various degrees of security risk:

a. extend the lifetime of TGT to infinity
b. create a keytab with the user's long term key stored
c. create a secure channel with the KDC and access the user's keys directly

Proposed solution:

The general concept is that you can create multi-component principals 
per service and host as outlined below. With this you can easily 
create/imply authorization rules based on the principal nomenclature.

Create implicit authorization for multi-component principals (mcp) that 
make use of naming based on the user principal's single component name. 
For example:

<user>/<service>/<fqhn>@<realm>

Implementation example:

When someuser logs in to machine.example.com and executes crontab -e, 
crontab will prompt for a password, once authenticated as someuser a 
principal is created, in this example:

someuser/cron/[email-masked]

This principal has it's own keys and can act on behalf of the user 
principal.

Advantages:

If the machine is compromised then the attacker only has the mcps long 
term keys and once compromise is detected the administrator can disable 
the particular mcp account.

Authorization is granted for authentication for mcps, but do not have 
administrative rights for the associated user principal.

The administration component can be extended to support systems that 
already have host service principals to create other service principals 
for that particular host.

When the user changes their keys they are not required to login to every 
machine that holds the user's keytab file to update keys.

Provides unique principal name for auditing.

Disadvantages:

The implied authorization gives the mcp all rights as that user. So if 
the machine that holds the mcp's keys is compromised and if this is not 
known then they will have full rights as that user until the 
administrator becomes aware.

Shawn.
--
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Wed, 7 Nov 2007 01:14:44 -0800

This sounds as an interesting and fine item.

Reading the description, postdated tickets and ticket restrictions do come into mind. Even if a standard solution is too tricky, a best common practice(BCF) seems to be useful enough.

--larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shawn M Emery
Sent: Tuesday, November 06, 2007 9:01 PM
To: [email-masked]
Subject: Re: [Ietf-krb-wg] IETF70 Vancouver: call for agenda items

The problem:

Proposed solution:

Implementation example:

Advantages:

Disadvantages:

Shawn.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 7 Nov 2007 17:03:27 -0500 (EST)

> Specifically principal nomencalture and authorization.

Larry and I have talked about this, and we'll be happy to include an
agenda item to discuss this, if there is interest expressed here.
However, please be aware that we'll give priority to discussing current
work that addresses items on our charter.

-- Jeff

---

From: Leif Johansson <[email-masked]>
Date: Tue, 13 Nov 2007 15:05:31 +0100

> If anyone has specific items they'd like to discuss, now would be a good time to mention them.
Probably too late but if I could stand up and plug [email-masked] that
would be nice.

    Cheers Leif