[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: editorial on Photuris

-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
 MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG
 A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj
 dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw
 MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl
 Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT
 DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB
 AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf
 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA
 A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK
 aTxjgASxqHhzkx7PkOnL4JrN+Q==
MIC-Info: RSA-MD5,RSA,
 AKyfBsWbZ7U1FUIEuhJONDvzkaDXZiknbFTlab7v2i6FoYNnuV/3ImvJsQm4dB01
 k1PlUsnAKtP7SWWCmvTZWAg=

Ran Atkinson wrote:
> 
> Bill,
> 
> [My co-chair hat is on]
> 
> % I have no idea what you are talking about.  PGP is not supported in the
> % base spec.  
>
> Then add it now.  See recent note from Phil Karn to the IPsec
> list agreeing this was OK.

I'm in complete agreement that an IETF standard key management protocol
should support authentication and key management between any two
arbitrary "principals" regardless of whether they be hosts or users.
But a hurried inclusion of PGP into Photuris is a serious mistake for a
number of reasons:

	1) PGP is non-standard.  You would face trouble advancing
	   Photuris along the standards track referencing a non-IETF
	   protocol.

	2) It is far from clear that PGP is the best, or even a desirable
	   approach.

	3) PGP by itself is insufficient for solving the problem -- and it
	   certainly isn't necessary for solving the problem at this stage 
 	   of the specification process.

What is needed are minor protocol changes to ensure that sufficient naming
attributes are available to identify the intended principals associated with
the Photuris exchange.  How you verify this naming information -- i.e, whether 
we need PGP or any other form of certificates -- does not need to be part
of the Photuris specification. 

There are two modes that a generic key management protocol should support:

	A) Specified Target:  the initiator knows the identity of the target
		principal before initiating the Photuris exchange.

	B) Exploratory Mode:  the initiator does not know the identity of the 
		target principal, but is interested in completing the 
		Photuris exchange so it can learn this identity and make 
		any required access decisions.

Currently Photuris doesn't support either mode for user level keying.  To
support A it must include an identification field for both the initiator and 
responder.  This enables the responder to identify the target of the Photuris 
exchange.  To support B it must be able to specify sufficient information
in lieu of the responder's "name" in order to identify the responder -- e.g.
target port number.

There are additional considerations when supporting user level keying on
multiuser hosts.  For example, a user might be authorized for a particular 
service -- but only when accessing that service from a specific host.  In
order to enforce such a policy, the enforcement mechanism must be provided
with both the authenticated user identity and the authenticated identity of
the client host.  SecureWare's HannaH product (http://www.secureware.com/) 
provides network security between any two arbitrary principals using a 
security protocol that sits on top of the transport (but within the kernel 
portion of the protocol stack so that it is transparent to the application).  
Its "Peer Authentication and Key Management Protocol" (PAKMP) provides one
mode that is quite similar to Photuris, except that it exchanges sufficient
information to support user level keying in a mixed environment of single
user workstations and multiuser hosts.  The protocol spec is online, and
shows what little needs to be added to Photuris.

Of course, if two implementations of Photuris are to be interoperable --
a good goal -- then at some point we must resolve two holy wars:

- - naming
- - how to bind a name to key material -- this would be where we might 
  consider PGP, along with many other approaches.

But these issues do not need to be resolved at this time for Bill and Phil 
to continue finalizing Photuris as a protocol specification.  For the
record, I would favor X.500 Distinguished Names and X.509 v3 certificates.
Forget the X.400 and Directory Service baggage -- just use the flexibility
these structures provide.  This is the approach we used with HannaH, and
have had no troubles at all.

Charles Watt
SecureWare, Inc.

-----END PRIVACY-ENHANCED MESSAGE-----
Follow-Ups: References: