Subject: [Ietf-krb-wg] Kerberos and PKINIT workgroup

From: <[email-masked]>
Date: Mon, 20 Sep 2010 14:05:31 +1000

Hi there
 
pkinit is a very interesting proposal for providing a single sign-on
mean for Administrators, however at the moment I cannot find anyway to:
 
-Provide remote means to pkinit a user (smartcard on systemA and pkinit
on systemB)
 
Is this an area that is been addressed/discussed in  your group ?
 
Also, is the protection of the private key necessary once the smartcard
is unlocked by means of the pin ?
 
Thanks
 
Andreas Weber 
UBS AG 
Corporate Center 
Group Technology Infrastructure Services (GTIS) 
Distributed Systems and Storage (DSS) 
Infrastrucure Software Group Engineering (ISG)
Directory and Security Software (D&S)

Level 16, Chifley Tower 
2 Chifley Square, Sydney NSW 2000 
Tel. +61-2-9324-2731
Fax  +61-2-9346-7135 
Tel. +61-2-9324-2000 (switchboard) 

email [email-masked] 

http://www.ubs.com <http://www.ubs.com/>  

Visit our website at http://www.ubs.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.
	
E-mails are not encrypted and cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses.  The sender 
therefore does not accept liability for any errors or omissions in the 
contents of this message which arise as a result of e-mail transmission.  
If verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities 
or related financial instruments.

UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.

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

---

From: Luke Howard <[email-masked]>
Date: Mon, 20 Sep 2010 16:26:45 +0200

On 20/09/2010, at 6:05 AM, <[email-masked]> <[email-masked]> wrote:

> Hi there
>  
> pkinit is a very interesting proposal for providing a single sign-on mean for Administrators, however at the moment I cannot find anyway to:
>  
> -Provide remote means to pkinit a user (smartcard on systemA and pkinit on systemB)

Microsoft has addressed this with CredSSP. It's not something that has been addressed in the IETF to my knowledge.

See:

	http://msdn.microsoft.com/en-us/library/bb931352(VS.85).aspx

and for the protocol (note the license first):

	http://msdn.microsoft.com/en-us/library/cc226764(PROT.10).aspx

regards,

-- Luke

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 20 Sep 2010 09:44:02 -0500

> Is this an area that is been addressed/discussed in your group ?

Not really because Kerberos is designed to authenticate a user to one
machine then use tickets to allow authentication to remote machines.
PKINIT is used to get the initial ticket. After that it is Kerberos
as usual. This works for users as well as administrators. If the
user or admin accounts do not have passwords, but only a smart card,
this might address your issue.

But there is another way which is not at the Kerberos level, but at the
smart level, using PC/SC. For example, a Windows domain uses Kerberos, and
has PKINIT implemented for login on its clients. The Windows Remote Desktop
Connection can be used to allow use of the smart card over the network. On
Windows 7 Remote Desktop Connection, Look under: Local Resources-> Local
  devices and resources-> More... Smart cards should be one of the choices.
Some Unix RDC clients might have smart card support too.

> is unlocked by means of the pin ?

This is off topic for this list.  But yes, leaving a smart card unlocked
does require some trust of the operating system.

I would suggest that Kerberos questions be sent to [email-masked],
and smart card questions be sent to some other list, like
[email-masked]

-- 

  Douglas E. Engert  <[email-masked]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Sep 2010 09:45:21 -0500

On Mon, Sep 20, 2010 at 04:26:45PM +0200, Luke Howard wrote:
> Microsoft has addressed this with CredSSP. It's not something that has
> been addressed in the IETF to my knowledge.

It's something I've wanted before as well.  The obvious thing to do is
to have a PKCS#11 agent for SSHv2.  But it's not quite as simple as
that.  The main issue is that one should not be prompted for a PIN on
the remote system, thus the PKCS#11 token should have to appear as one
that requires no login, and attempting to use its private objects should
result in UI elements on the client side being triggered.

Nico

---

From: Luke Howard <[email-masked]>
Date: Mon, 20 Sep 2010 16:47:23 +0200

> result in UI elements on the client side being triggered.

It's not clear to me from the docs how CredSSP actually proxies the smartcard operations.

-- Luke

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 20 Sep 2010 10:00:59 -0500

On 9/20/2010 9:45 AM, Nicolas Williams wrote:
>> On 20/09/2010, at 6:05 AM,<[email-masked]>  <[email-masked]>  wrote:

The prompt should be tunneled back to the user... You still need to
login to the card.  The user could also be using a reader with a key pad,
so the PIN is never over the wire at all.

The PC/SC protocol, has the capabilities to work remotely, and is
independent of PKCS#11.

--

---

From: "Ryan Sleevi" <[email-masked]>
Date: Mon, 20 Sep 2010 11:02:26 -0400

> It's not clear to me from the docs how CredSSP actually proxies the

CredSSP is just one half of the operation. The other half is Microsoft's
use of smart cards over RDP, as virtual devices, and is available in the
MS-RDPESC specification (
http://msdn.microsoft.com/en-us/library/cc242596(PROT.10).aspx ). As with
CredSSP, note the license.

CredSSP just proxies the smart card PIN along, while MS-RDPESC allows the
RDP server to interact with the client's smart card. Combined, they give
the functionality Luke and Douglas were referring to: the remote machine
can PKINIT as if the smart card were connected directly to it, allowing it
to obtain it's own TGT.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 20 Sep 2010 11:19:31 -0400

> so the PIN is never over the wire at all.

Sure.  Nico's point is that the prompt should be generated and handled on 
the system where the smartcard is; that is, the one in front of the user, 
rather than being passed back up the PKCS#11 chain to the ultimate 
"application" running on some remote machine.

Unfortunately, PKCS#11 really isn't well-suited to this, because it doesn't 
deal well (at all) with slots appearing and disappearing dynamically.

> The PC/SC protocol, has the capabilities to work remotely, and is

PC/SC is really mostly an API, rather than a wire protocol.  Certainly 
pcsc-lite has a protocol used between its libraries and pcscd, and that 
could be tunneled remotely, with some effort, but AFAIK that's entirely 
private to pcsc-lite and doesn't interoperate with anything that exists on 
Windows.

In any case, we're getting a bit off topic for the ietf-krb-wg list.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Sep 2010 10:58:20 -0500

> It's not clear to me from the docs how CredSSP actually proxies the

Well, I wasn't talking about how a given proprietary (in the sense of
not being an open standard) scheme (CredSSP) works, but about how an
Internet standard might/should.  There can be a big difference there!

First, one would need a secure transport for the remote smartcard
client.  Or rather, more than one secure transport.  SSHv2 is perfect
for some uses, but probably not for others.

For example, think of NFSv4 (or SMB, or WeDAV, or...) servers that are
actually caching proxies, and which might therefore require delegated
credentials.  Kerberos gives you delegated credentials, but other
mechanisms do not (e.g., PKU2U, LIPKEY, SCRAM, ...).

One solution is to add an in-band channel to NFSv4 (and so on) to proxy
the relevant mechanism.  Another is to add an out-of-band channel to do
the same.  Out-of-band channels suffer in, for example, firewalled
environments.

SSHv2 and NFSv4 already have the necessary mechanisms for adding such
in-band channels (based on agent forwarding, in the SSHv2 case, and
callbacks, in the NFSv4 case).  In-band signalling seems harder in the
case of HTTP (though not impossible).  There's not a single good answer
for all relevant application protocols and deployment environments.

We'll likely need in-band and out-of-band channels both.  That's a
complicating factor.

Second, note that there's two kinds of things to proxy: smartcard/token
access (PKCS#11), and GSS-API/SASL mechanism credentials access (e.g.,
for SCRAM).  In general I'd prefer the latter over the former, since
it's possible to give the user that much more information in the latter
case, should they need to authorize access or audit manually.  For who
knows what a remote system is using your private keys to sign
(especially if the hash of the document being signed is generated on the
remote system).

If the rationale for a remote PKCS#11 access mechanism is "so I can use
it in PKINIT", then I think the immediate answer is "use Kerberos
credential delegation" (which is just as dissatisfactory, I think, as a
remote PKCS#11 agent would be, in terms of access controls).  Or, if you
really need to use INITIAL TGTs everywhere (but, why? this needs to be
explained), then a remote Kerberos GSS credential access mechanism seems
much better than a remote PKCS#11 token access mechanism.

Third, there are UI interface issues to consider.  And security issues
as well (are PINs sent to the remote system? or do we hand it logged in
proxy sessions? how is access to token objects authorized? how is it
audited?).

If you wonder why this feature doesn't exist, the answer, mainly, is:
lack of demand (till now).  But it's also a more complex problem than
might at first seem.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Sep 2010 11:03:37 -0500

On Mon, Sep 20, 2010 at 11:19:31AM -0400, Jeffrey Hutzelman wrote:
> --On Monday, September 20, 2010 10:00:59 AM -0500 "Douglas E.
> Engert" <[email-masked]> wrote:
> Sure.  Nico's point is that the prompt should be generated and
> handled on the system where the smartcard is; that is, the one in
> front of the user, rather than being passed back up the PKCS#11
> chain to the ultimate "application" running on some remote machine.

Yes.

> Unfortunately, PKCS#11 really isn't well-suited to this, because it
> doesn't deal well (at all) with slots appearing and disappearing
> dynamically.

The way to deal with this is to have make imaginary slots, and then
pretend that tokens are inserted/pulled out as necessary.

But, yes, PKCS#11 is a bit clunky an API.

> In any case, we're getting a bit off topic for the ietf-krb-wg list.

Well, most of this subject is going to be.  A remote GSS-API credentials
access protocol might fall in KITTEN WG's purview.  Everything else has
no obviously correct forum at the IETF.  Given that the intention of the
OP is to use remote smartcard access for PKINIT, I think it makes sense
to discuss some of it here for now.

The first question (which I should have asked earlier) should be: why is
Kebreros ticket forwarding (GSS credential delegation) not sufficient
for your use case?

Nico

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 20 Sep 2010 09:14:29 -0700

Do any of these possibilities address the fundamental security question of how we connect the card to the user, if the card is on a different machine from the user's?

The whole point of PKINIT is that the smart card is closely connected to the human being it identifies, much more closely connected than a password is.  If we start using something other than Kerberos itself (or the card's X.509 infrastructure) to secure over-network relationships then we've complicated our security architecture in a way that makes me question an awful lot of things.

> The PC/SC protocol, has the capabilities to work remotely, and is

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Sep 2010 11:30:00 -0500

On Mon, Sep 20, 2010 at 09:14:29AM -0700, Henry B. Hotz wrote:
> Do any of these possibilities address the fundamental security
> question of how we connect the card to the user, if the card is on a
> different machine from the user's?
> 
> The whole point of PKINIT is that the smart card is closely connected
> to the human being it identifies, much more closely connected than a
> password is.  If we start using something other than Kerberos itself
> (or the card's X.509 infrastructure) to secure over-network
> relationships then we've complicated our security architecture in a
> way that makes me question an awful lot of things.

I agree.  And I just asked much the same question in two other replies.

However, I do believe we'll end up needing a remote GSS-API credentials
access protocol(s), for some GSS mechanisms cannot safely delegate
credentials.  Even in the case of Kerberos, which supports credential
delegation, I think it'd be better to proxy access to credentials.

Though I also prefer that we design application protocols such that
credential delegation isn't necessary.  I just don't think we can avoid
cred. deleg. altogether, mostly because there will be many cases where
we cannot dissuade people from building non-fully-trusted edges around
core services, and in these cases I much prefer remote GSS credential
access protocols to credential delegation.

I believe that thus we'll be able to avoid the need to proxy smartcard
access APIs (e.g., PKCS#11).  At least for a while.  But someone is
bound to need that in a non-GSS context, and we can only build so many
remote credentials access protocls (IPsec, TLS, S/MIME, PGP, GSS-API,
etcetera).

Nico

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 20 Sep 2010 13:01:31 -0500

The original e-mail for this thread was from [email-masked]
who is not a member of the list. So please include him on the cc:
or he can join the list if he wants.

On 9/20/2010 11:03 AM, Nicolas Williams wrote:
>> Engert"<[email-masked]>  wrote:

--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Sep 2010 14:04:21 -0500

> or he can join the list if he wants.

OK.  In the meantime, there's the mailing list archives:

https://lists.anl.gov/pipermail/ietf-krb-wg/2010-September/thread.html
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Markus Moeller" <[email-masked]>
Date: Wed, 22 Sep 2010 19:54:36 +0100

Could the preauthentication method used to get the initial ticket not be added as a flag/attribute to the ticket on which a server can check depending on his policy ?

Markus
  ----- Original Message ----- 
  From: [email-masked] 
  To: [email-masked] 
  Sent: Monday, September 20, 2010 5:05 AM
  Subject: [Ietf-krb-wg] Kerberos and PKINIT workgroup

  Hi there

  Also, is the protection of the private key necessary once the smartcard is unlocked by means of the pin ?

  Thanks

  Andreas Weber 
  UBS AG 
  Corporate Center 

  Level 16, Chifley Tower 

  http://www.ubs.com 

------------------------------------------------------------------------------

------------------------------------------------------------------------------

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 22 Sep 2010 15:54:53 -0700

You're right we ignored a lot of the original questions.

> Could the preauthentication method used to get the initial ticket not be added as a flag/attribute to the ticket on which a server can check depending on his policy ?

There aren't that many pre-auth methods in the wild, yet, but I think this is going to become a bigger deal.  Since the needed information is in such non-uniform form, my preferred solution is to set up separate realms for each pre-auth method, with cross-realm trusts to each of the service realms.  One could, for example set up an MIT realm supporting only FAST/encrypted timestamp, a Heimdal realm supporting only PKINIT/smart-card, and a CyberSafe realm supporting only RSA tokens.  Applications merely select the acceptable realms, and no new APIs or protocols are needed.

This is *NOT* (yet) what we are doing.

I still believe it would be a good idea to record something about how the original authentication was done and how much we trust it, but the wg has not been able to converge on anything.  (See KAML for instance.)

> Is this an area that is been addressed/discussed in  your group ?

That point has now been discussed a bit, though I don't think it had been before.  I'm not entirely satisfied with the results so far.

> Also, is the protection of the private key necessary once the smartcard is unlocked by means of the pin ?

That's a matter of "local policy".  Personally I don't like the risks associated with keeping the card in the reader (and unlocked), but there probably isn't a big difference between keeping it in for a minute (to do PKINIT) vs leaving it in for a couple of hours.  You need some level of trust in the system you're giving the card to.

> <ATT00001..txt>

---

From: Michiko Short <[email-masked]>
Date: Wed, 22 Sep 2010 23:13:34 +0000

Perhaps I am missing something, but are you suggesting if a user can authenticate with multiple pre-auth methods they need to have multiple accounts?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henry B. Hotz
Sent: Wednesday, September 22, 2010 3:55 PM
To: Markus Moeller
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] Kerberos and PKINIT workgroup

> Thanks
>  
> Andreas Weber
> UBS AG
> Corporate Center
> Group Technology Infrastructure Services (GTIS) Distributed Systems 
> and Storage (DSS) Infrastrucure Software Group Engineering (ISG) 
> should not disseminate, distribute or copy this e-mail.  Please notify 
> the sender immediately by e-mail if you have received this e-mail by 
> mistake and delete this e-mail from your system.
> 
> construed as a solicitation or offer to buy or sell any securities or 
> related financial instruments.
> 
>  

------------------------------------------------------
The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 22 Sep 2010 16:44:43 -0700

> Perhaps I am missing something, but are you suggesting if a user can authenticate with multiple pre-auth methods they need to have multiple accounts?

Depends on what you mean by accounts.  

I would regard the equivalent principals in the various realms to be the same account because they represent the same user.  As you know I'm not a Windows expert, but I think multiple mappings to the same Windows Domain account would probably capture what I'm talking about fairly well.  I think adding DEFAULT auth-to-local mappings for non-default realms in MIT Kerberos might also work.

If you're talking about the details of how new users are created, then yes, what I proposed might create a synchronization/provisioning problem.  Since a genuinely different pre-auth method is likely tied to a different hardware token, and that token has its own provisioning issues, I don't think a new entry in a new Kerberos realm is a significant overhead.  In fact being able to match different Kerberos vendors to different hardware tokens probably simplifies your overall integration costs.

Excuse me if I'm getting too far off-topic.