Re: [kitten] Proposed GSS extension for explicit credential stores

[Simo Sorce <[e-mail]>]

On Tue, 2012-04-03 at 14:28 +0200, Simon Josefsson wrote:
> Nico Williams <[e-mail]> writes:
> 
> > Simo and I have a need for extensions for acquiring credentials from,
> > and storing credentials into, an explicit credential store as opposed
> > to the one implied by process credentials/context/environment.
> 
> I have often needed this too.
> 
> > The abstract API representation of this would probably be
> >
> >     SET OF SEQUENCE {
> >         element_type_urn OCTET STRING,
> >         element OCTET STRING
> >     }
> 
> It seems nice, but I haven't digested it fully yet.
> 
> > URNs will be provided for at least the following:
> >
> >  - ccache values
> >   Values will be of the form [<TYPE>:]<ccache-path-or-id>, such as
> > the familiar "FILE:/tmp/somecc" but also "LSA:" and "CCAPI:...".
> >
> >  - keytab values
> >   Same as with ccache values, but naming a keytab.
> >
> > We'll probably provide URNs for other store element types, such as:
> >
> >  - PKCS#11 URI
> >    See http://tools.ietf.org/html/draft-pechanec-pkcs11uri-06
> >
> > We have debated, but not reached a conclusion, other possible element
> > types such as:
> >
> >  - User-ID, username
> >
> >  - AFS PAG
> 
> I'd really like to see SAML SP metadata included here initially, and
> would be willing to help with writing.  For simplicity, you could have
> multiple URns here, right?  I'm thinking something like this:
> 
>  urn.ietf.kitten.saml.sp.metadata-file =>
>  "/etc/myapp/sp-metadata.xml"
> 
>  urn.ietf.kitten.saml.sp.key-file =>
>  "/etc/myapp/sp-key.pem"
> 
>  urn.ietf.kitten.saml.sp.cert-file =>
>  "/etc/myapp/sp-cert.pem"
> 
>  urn.ietf.kitten.saml.sp.metadata =>
>  "<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ..."
> 
>  urn.ietf.kitten.saml.sp.cert =>
>  "-----BEGIN CERTIFICATE -----\nMII..."
> 
> Alternatively, there could be a "struct" approach for SAML SP
> credentials if you wanted to use only one URN for each credential,
> however it gets a bit more ugly:
> 
>  urn.ietf.kitten.saml.sp =>
>  "metadata_file=/etc/myapp/sp-metadata.xml, key_file=/etc/myapp/sp-key.pem, ..."
> 
> Thoughts?

Although values are opaque a rule we try to follow is to not put
credentials directly in there, but always use files and paths for
anything that is longer that a few hundred characters or unprintable.

These strings are supposed to be stored in configuration files, and we
do not want to force admins in a corner by requiring to set credentials
in a config file that also needs to be readable to users that shouldn't
have access to some of the credentials.

This should be the guiding principle in defining the values.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York