[Cap-Talk] Take two: Where would a SPKI/SDSI authorization certificate go?
David L. Nicol
david@kasey.umkc.edu
Fri, 13 Jul 2001 23:20:52 -0500
Here are two proposed additions to draft-ietf-calsch-cap-04.txt
followed by a discussion of the process of writing them.
BEGIN PROPOSAL 1
2.4.4.3 Authority Certificates
A UPN can be granted additional VCARs by presentation of
[RFC2692/RFC2693] SPKI authority certificates. The scope of such
grants is implementation-specific. The grants persist for the
duration of the session in which the certificate is presented
only.
END PROPOSAL 1
BEGIN PROPOSAL 2
7.1.11. AUTHORIZE Command
Arguments: a [RFC2692/RFC2693] SPKI Authorization Certificate
Data: None
Result: 2.0
7.1 Certificate does not signify anything
7.2 Certificate expired
7.3 Certificate VCAR denied
7.4 Too many bad certificates
The "AUTHORIZE" command allows the UPN to acquire additional
VCARs for the duration of the current session. This command
may only be called in the Identified State.
The CS determines through an internal mechanism if the
credential supplied permits the granting of any VCAR. If it
does, the UPN may acquire the new VCAR for the current session,
otherwise a security error is returned.
END PROPOSAL 2
DISCUSSION:
SPKI authorization certificates are exactly what I was asking about
earlier. (for simplifying limited, anonymous delegations.)
"Delegate" is defined in the glossary but never used in
draft-ietf-calsch-imp-guide-02.txt outside of the definition.
The question remains, what would be a standard way to associate one
with a CUA->CS instruction?
With SMTP/MIME, it seems that the certificate could be in its own
attachment in the same message, instead of being a proper iCalendar
component. for iRIP, there is not (please correct me?) a specified
way to include something else with the message. There's no
declared or obvious out-of-band standard way to shoehorn in a
piece of arbitrary additional info like a SPKI certificate.
Throwing
BEGIN:CERTIFICATE
....
END:CERTIFICATE
into the iRIP stream
would certainly do it, but it's not clear that this would be
allowed by the current specification.
CAP-04 says:
> The method by which a server composes and validates an
> authorization identity from the authentication credentials
> supplied by a client is implementation-specific.
For maximizing interoperability, we could reserve a designated
anonymous name -- perhaps the empty string, 'ANONYMOUS, or 'GUEST'
-- which would be the same everywhere, like anonymous in FTP.
... Oh, I see that anonymous is already in sec. 7.1.3.1
So I suppose certificates would be presented during the
SASL phase of the the iCalendar session... Skimming the
documents referred to by http://www.iana.org/assignments/sasl-mechanisms
does not suggest any that lend themselves to allowing anything
other than username/password pairs to get sent through them, except
for Kerberos, which is concerned with presenting a kerberos token
for validation.
Aha! rfc2245 not only includes the 'trace information ... string'
but says
A server which permits anonymous access will announce support for the
ANONYMOUS mechanism, and allow anyone to log in using that mechanism,
usually with restricted access.
(initially) leading me to conclude that, for iRIP, the appropriate way to
present
one or more SPKI authority certificates would be, included in an
extended rfc2245 trace information string:
in iMIP, the appropriate way to present
one or more SPKI authority certificates is to include them
as seperate MIME sections.
In iRIP, the appropriate way to present one or more SPKI authority
certificates is to include them in an extended rfc2245 trace information
string.
This scheme was later abandoned.
But what if you need to augment a real log-in with a certificate?
Also, rfc2245 only allows the strings to be 255 chars long. And
stuffing data in the password field is a really really ugly hack.
RFC2222 also provides:
> 7.4. External mechanism
>
> The mechanism name associated with external authentication is
> "EXTERNAL".
>
> The client sends an initial response with the authorization identity.
>
> The server uses information, external to SASL, to determine whether
> the client is authorized to authenticate as the authorization
> identity. If the client is so authorized, the server indicates
> successful completion of the authentication exchange; otherwise the
> server indicates failure.
>
> The system providing this external information may be, for example,
> IPsec or TLS.
Maybe a SPKI certificate could be presented as an External mechanism,
and a compliant CUA would set up a second, parallel session with a
CS for using a certificate based authority rather than an identity-based
authority.
CAP-04 includes this:
> 12 Security Considerations
>
> For the mandatory SASL mechanism that CAP specifies, the
> mechanism support is:
>
> MUST authentication
> MUST authorization
> MAY impersonation
This is the only place "impersonation" appears in the document. This term
does not appear in rfc2222 either.
I assume that impersonation means, there is a way for a session to
switch to a second impersonated identity, within the bounds of an
established session.
Clients specify their authentication method with the AUTHENTICATE
keyword, as in cap-04's example
> C: AUTHENTICATE KERBEROS_V4
> S: AmFYig==
> C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
> S: or//EoAADZI=
> C: DiAF5A4gA+oOIALuBkAAmw==
> S: 2.0
> S: IDENTITY=bill@example.com
> S: CAPVERSION=1.0
Maybe a proper way to present a SPKI certificate to a CS could
be
C: AUTHENTICATE EXTERNAL
C: < SPKI CERTIFICATE HERE >
C: .
S: .
No, that is explicitly ruled out by the nature of the AUTHENTICATE
command. Specifically, that there can be only oneper session.
See below for proposal for new AUTHORIZE command suitable
for inclusion into draft-ietf-calsch-cap-04.txt.
Or maybe the TLS credential exchange mechanism already covers it.
No, TLS is concerned with establishing a secure channel, and using it
for a path for out-of-band data would be ugly.
I will propose extending section 2.4.4, VCalendar Access Rights, to
include a section about getting new ones from a certificate.
Ah, the state diagram. Rather than attempting to allow
AUTHENTICATE commands to be issued from the IDENTIFIED
state, which would be incorrect, I would propose a fourth primitive,
AUTHORIZE, valid in the IDENTIFIED state, and optional for
a CS to implement, which would be followed by a SPKI authorization
certificate, to grant additional VCARs to the current UPN for
the duration of the session.
Did anyone notice there is no section 7.1.9? Also, 7.1.10 conflicts
with the state diagram. Do you start TLS before, after, or during
authentication? This is not clear. According to the state diagram
you issue STARTTLS from the IDENTIFIED state, but according to
7.1.10 you can only issue STARTTLS from the CONNECTED state. I think
this can be rectified by correcting the state diagram, and offering
STARTTLS as an alternate path, but I do not know.
Oh. SENDDATA is 7.1.9, but is mis-numbered.
--
David Nicol 816.235.1187